Achieve better SQS access control using Amazon IAM

Learn how to attain better Amazon Simple Queue Service control with Amazon Identity Access Management.

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.

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.

SQS policy 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 own AWS Account so they can have access to the queue.

SQS user accessDiagram 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 2: 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"]

            }

                        }

  }

   ]

}

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. 

SendMessage ReceiveMessage ChangeMessageVisibility
DeleteMessage GetQueueAttributes GetQueueUrl
CreateQueue DeleteQueue ListQueues

The last three actions were added after the IAM was introduced.

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).

This was first published in June 2014

Dig deeper on Using Amazon Web Services (AWS) for cloud applications

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchAWS

SearchSOA

TheServerSide

SearchFinancialApplications

SearchBusinessAnalytics

SearchCRM

Close