With an Amazon Simple Queue Service policy, you can grant another AWS account user permission to use your queues. With an Identity Access Management policy, you can't do that. This means you can achieve better Simple Queue Service access control using the IAM.

Download this free guide

4 Ways to Take the Fear Out of Picking a PaaS Vendor

With dozens of PaaS vendors all touting different approaches, it’s easy to get overwhelmed when looking to buy and implement these tools for your business. Discover 4 key approaches that will help you make a solid PaaS purchasing decision.

By submitting my Email address I confirm that I have read and accepted the Terms of Use and Declaration of Consent.

By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.

You also agree that your personal information may be transferred and processed in the United States, and that you have read and agree to the Terms of Use and the Privacy Policy.

Without the IAM, the SQS automatically gave the creator of a queue access to all Amazon SQS actions with the queue. It wasn't a good idea because the creator may be in a role that specifies he should not be allowed to use certain SQS actions.

With the IAM, the creator is no longer granted automatic permission unless he is using the AWS security credentials. Any user who has permission to create a queue must have permission to use other SQS actions in order to do anything with the queues they create.

SQS vs. IAM policy diagrams

Diagram 1 shows a simple SQS policy. The policy gives AWS Account 1 and AWS Account 2 permission to use any of the allowed actions in the queue_abc.

Diagram 1

With the IAM, Diagram 2 shows that user John and user Carol have been granted permission to use any actions in the queue_abc. The users must be created in your ownAWS Account so they can have access to the queue.

Diagram 2

The list of Amazon SQS actions included in "*" has expanded to allow user John and user Carol to create, delete and list queues. The sqs:* in the resource, using the Amazon Resource Name (ARN) format, indicates all regions you've registered for in your queue.

Four IAM policy examples

Listed below are three examples of setting up simple IAM policies and one example of using the condition element in a policy.

Example 1: Allow a user to create and use his or her own queue

This policy allows user John to access all SQS actions on john_queue. The SQS doesn't automatically grant the creator of a queue permission to subsequently use the queue. With IAM, you can grant user John permission to use all the SQS actions.

{

"Version": "2012-10-17",

"Statement":[{

"Effect":"Allow",

"Action":"sqs:*",

"Resource":"arn:aws:sqs:*:123456789012:john_queue*"

}

Word of caution: A Resource error message will be shown if you specify multiple regions (sqs:*) in the policy when in reality you've registered for a region, say US East (N. Virginia), when you've signed up for an AWS account. To fix the problem, replace the wildcard “*” with us-east-1, like this:

"arn:aws:sqs:us-east-1:123456789012:john_queue*"

Example 2: Allow developers to write messages to a shared test queue

This policy allows a group of developers to use the SQS SendMessage and ReceiveMessage actions on the AWS Account user's queue named CloudTestQueue.

{

"Version": "2012-10-17",

"Statement":[{

"Effect":"Allow",

"Action":["sqs:SendMessage","sqs:ReceiveMessage"],

"Resource":"arn:aws:sqs:us-east-1:123456789012:CloudTestQueue"

}

]

}

Word of caution: If the group of developers is denied access, they can't send or receive SQS messages. To fix the problem, create the group in your own AWS account.

Example 3: Allow a partner to send messages to a particular queue

This policy allows user Tom in the WheelCo group, which represents a partner company, to take SendMessage action on WheelQueue. It denies the WheelCo group permission to take any SQS actions except SendMessage on any queue except WheelQueue.

{

"Version": "2012-10-17",

"Statement":[{

"Effect":"Allow",

"Action":"sqs:SendMessage",

"Resource":"arn:aws:sqs:us-east-1:123456789012:WheelQueue"

},

{

"Effect":"Deny",

"NotAction":"sqs:SendMessage",

"NotResource":"arn:aws:sqs:us-east-1:123456789012:WheelQueue"

}

]

}

Word of caution: You must use the explicit "deny" in the second statement in order to override the "allow" in the first statement.

Example 4: Allow developers to write messages to a shared test queue

The condition element is the most complex part of the policy statement. It can contain multiple conditions, and each condition can contain multiple key-value pairs.

Let's take a look at three conditions user Bob must meet and how policy conditions and keys are used to allow him access to your SQS queue.

Condition 1: The time is after 11:00 on 5/16/2014

"DateGreaterThan": {"aws:CurrentTime": "2014-05-16T11:00:00Z"

The DateGreaterThan condition indicates the point in time at which the current time key begins taking effect.

Condition 2: The time is before 3:00 p.m. on 5/16/2014

"DateLessThan": {"aws:CurrentTime": "2014-05-16T15:00:00Z"

The DateLessThan condition indicates the point in time at which the current time key stops taking effect.

Condition 3: The request comes from an IP address within the 193.167.176.0/24 range or the 193.167.143.0/24 range

"IpAddress": {"aws:SourceIp": ["193.167.176.0/24","193.167.143.0/24"]

The ipAddress condition indicates the IP address range as specified in the SourceIP key.

Here is a sample policy that includes the conditions in the Statement element.

{

"Version": "2012-10-17",

"Statement":[{

"Effect":"Allow",

"Action":"sqs:*",

"Resource":"arn:aws:sqs:us-east-1:123456789012:queue_xyz"

"Condition": {

"DateGreaterThan" : {

"aws:CurrentTime" : "2014-05-16T11:00:00Z"

},

"DateLessThan": {

"aws:CurrentTime" : "2014-05-20T15:00:00Z"

},

"IpAddress" : {

"aws:SourceIp" : ["193.167.176.0/24","193.167.143.0/24"]

}

}

}

]

}

Learn more about:

Word of caution: User Bob will be denied access if he tries to access the queue_xyz before the point of time when the SOURCEIP key starts taking effect set at the DateGreaterThan condition. To fix the problem, change the current time key set for 2014-05-16 to an earlier date, so user Bob can access the queue, like this:

"DateGreaterThan": {"aws:CurrentTime": "2014-05-10T11:00:00Z"}

SQS Amazon actions in IAM policies

The following is a list of SQS actions you could use on a queue in an IAM policy.

In conclusion

Before you write the policy, make sure you have created users or groups in your own account. Always test the policy to make sure it works before you put it into production.

About the author:Judith M. Myerson is the former ADP security officer/manager at a naval facility, where she led enterprise projects for its materiel management system. Currently a consultant and subject matter expert, she is the author of several books and articles on cloud use, compliance regulations, mobile security, software engineering, systems engineering and risk management. She received her master of science degree in engineering from the University of Pennsylvania and is certified in risk and information system control (CRISC).

0 comments

Register

Login

Forgot your password?

Your password has been sent to:

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy