Controlling User Access to Your AWS Account

You can use an SQS policy with a queue to specify which AWS Accounts have access to the queue. You can specify the type of access and conditions (e.g., permission to use SendMessage, ReceiveMessage, if the request is before December 31, 2010). The specific actions you can grant permission for are a subset of the overall list of SQS actions. When you write an SQS policy and specify * to mean "all the SQS actions", that means all actions in that subset.

The following diagram illustrates the concept of one of these basic SQS policies that covers the subset of actions. The policy is for queue_xyz, and it gives AWS Account 1 and AWS Account 2 permission to use any of the allowed actions with the queue. Notice that the resource in the policy is specified as 123456789012/queue_xyz (where 123456789012 is the AWS Account ID of the account that owns the queue).

With the introduction of AWS IAM and the concepts of Users and Amazon Resource Names (ARNs), a few things have changed about SQS policies. The following diagram and table describe the changes.

	In addition to specifying which AWS Accounts have access to the queue, you can specify which Users in your own AWS Account have access to the queue. The Users can't be in another AWS Account.
	The subset of actions included in "*" has expanded (for a list of allowed actions, see Amazon SQS Actions).
	You can specify the resource using the Amazon Resource Name (ARN), which is how you must specify resources in AWS IAM policies. For information about the ARN format for SQS queues, see Amazon SQS ARNs. You can still use the original format instead (<account_ID>/<queue_name>).

So for example, according to the SQS policy shown in the preceding figure, anyone possessing the root account's security credentials for AWS Account 1 or AWS Account 2 could access queue_xyz. Also, Users Bob and Susan in your own AWS Account (with ID 123456789012) can access the queue.

Also, before the introduction of AWS IAM, SQS automatically gave the creator of a queue full control over the queue (e.g., access to all possible SQS actions with that queue). This is no longer true, unless the creator is using the AWS Account's credentials. Any User who has permission to create a queue must also have permission to use other SQS actions in order to do anything with the queues they create.

There are two ways you can give your Users permissions for your SQS resources: through the SQS policy system or the AWS IAM policy system. You can use one or the other, or both. For the most part, you can achieve the same results with either. For example, the following diagram shows an IAM policy and an SQS policy that are equivalent. The IAM policy allows the SQS ReceiveMessage and SendMessage actions for the queue called queue_xyz in your AWS Account, and it's attached to the Users Bob and Susan (which means Bob and Susan have the permissions stated in the policy). The SQS policy also gives Bob and Susan permission to access ReceiveMessage and SendMessage for the same queue.

There is one difference between IAM and SQS policies: the SQS policy system lets you grant permission to other AWS Accounts, whereas AWS IAM doesn't.

It's up to you how you use both of the systems together to manage your permissions, based on your needs. The following examples show how the two policy systems work together.

1

In this example, Bob has both an AWS IAM policy and an SQS policy that apply to him. The AWS IAM policy gives him permission to use ReceiveMessage on queue_xyz, whereas the SQS policy gives him permission to use SendMessage on the same queue. The following diagram illustrates the concept.

If Bob were to send a request to receive a message from queue_xyz, the AWS IAM policy would allow the action. If Bob were to send a request to send a message to queue_xyz, the SQS policy would allow the action.

2

In this example, we build on example 1 (where Bob has two policies that apply to him). Let's say that Bob abuses his access to queue_xyz, so you want to remove his entire access to that queue. The easiest thing to do is add a policy that denies him access to all actions on the queue. This third policy overrides the other two, because an explicit deny always overrides an allow (for more information about policy evaluation logic, see Evaluation Logic). The following diagram illustrates the concept.

Alternatively, you could add an additional statement to the SQS policy that denies Bob any type of access to the queue. It would have the same effect as adding a AWS IAM policy that denies him access to the queue.

For examples of policies that cover Amazon SQS actions and resources, see Example AWS IAM Policies for Amazon SQS. For more information about writing SQS policies, go to the Amazon Simple Queue Service Developer Guide.

For Amazon SQS, queues are the only resource type you can specify in a policy. Following is the Amazon Resource Name (ARN) format for queues:

arn:aws:sqs:region:account_ID:queue_name

For more information about ARNs, go to ARNs in Using Identity and Access Management.

Following is an ARN for a queue named my_queue in the us-east-1 region, belonging to AWS Account 123456789012.

arn:aws:sqs:us-east-1:123456789012:my_queue

If you had a queue named my_queue in each of the different Regions that Amazon SQS supports, you could specify the queues with the following ARN.

arn:aws:sqs:*:123456789012:my_queue

You can use * and ? wildcards in the queue name. For example, the following could refer to all the queues Bob has created, which he has prefixed with bob_.

arn:aws:sqs:*:123456789012:bob_*

As a convenience to you, SQS has a queue attribute called Arn whose value is the queue's ARN. You can get the value by calling the SQS GetQueueAttributes action.

All Amazon SQS actions that you specify in a policy must be prefixed with the lowercase string sqs:. For example, sqs:CreateQueue.

Before the introduction of AWS IAM, you could use an SQS policy with a queue to specify which AWS Accounts have access to the queue. You could also specify the type of access (e.g., sqs:SendMessage, sqs:ReceiveMessage, etc.). The specific actions you could grant permission for were a subset of the overall set of SQS actions. When you wrote an SQS policy and specified * to mean "all the SQS actions", that meant all actions in that subset. That subset originally included:

With the introduction of AWS IAM, that list of actions expanded to include the following actions:

The actions related to granting and removing permissions from a queue (sqs:AddPermission, etc.) are reserved and so don't appear in the preceding two lists. This means that Users in the AWS Account can't use those actions. However, the AWS Account can use those actions.

Amazon SQS implements the following policy keys, but no others. For more information about policy keys, see Condition.

This section shows several simple AWS IAM policies for controlling User access to Amazon SQS.

1: Allow a User to create and use his or her own queues

In this example, we create a policy for Bob that lets him access all Amazon SQS actions, but only with queues whose names begin with the literal string bob_queue.

{
   "Version": "2012-10-17",
   "Statement":[{
      "Effect":"Allow",
      "Action":"sqs:*",
      "Resource":"arn:aws:sqs:*:123456789012:bob_queue*"
      }
   ]
}

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

In this example, we create a group for developers and attach a policy that lets the group use the Amazon SQS SendMessage action, but only with the AWS Account's queue named CompanyTestQueue.

{
   "Version": "2012-10-17",
   "Statement":[{
      "Effect":"Allow",
      "Action":"sqs:SendMessage",
      "Resource":"arn:aws:sqs:*:123456789012:CompanyTestQueue"
      }
   ]
}

3: Allow managers to get the general size of queues

In this example, we create a group for managers and attach a policy that lets the group use the Amazon SQS GetQueueAttributes action with all of the AWS Account's queues.

{
   "Version": "2012-10-17",
   "Statement":[{
      "Effect":"Allow",
      "Action":"sqs:GetQueueAttributes",
      "Resource":"*"   
     }
   ]
}

4: Allow a partner to send messages to a particular queue

You could do this with an SQS policy or an AWS IAM policy. Using an SQS policy might be easier if the partner has an AWS Account. However, anyone in the partner's company who possesses the AWS Account credentials could send messages to the queue (and not just a particular User). We'll assume you want to limit access to a particular person (or application), so you need to treat the partner like a User within your own company, and use a AWS IAM policy instead of an SQS policy.

In this example, we create a group called WidgetCo that represents the partner company, then create a User for the specific person (or application) at the partner company who needs access, and then put the User in the group.

We then attach a policy that gives the group SendMessage access on the specific queue named WidgetPartnerQueue.

We also want to prevent the WidgetCo group from doing anything else with queues, so we add a statement that denies permission to any Amazon SQS actions besides SendMessage on any queue besides WidgetPartnerQueue. This is only necessary if there's a broad policy elsewhere in the system that gives Users wide access to Amazon SQS.

{
   "Version": "2012-10-17",
   "Statement":[{
         "Effect":"Allow",
         "Action":"sqs:SendMessage",
         "Resource":"arn:aws:sqs:*:123456789012:WidgetPartnerQueue"
      },
      {
         "Effect":"Deny",
         "NotAction":"sqs:SendMessage",
         "NotResource":"arn:aws:sqs:*:123456789012:WidgetPartnerQueue"
      }
   ]
}

In addition to creating IAM users with their own security credentials, IAM also enables you to grant temporary security credentials to any user allowing this user to access your AWS services and resources. You can manage users who have AWS accounts; these users are IAM users. You can also manage users for your system who do not have AWS accounts; these users are called federated users. Additionally, "users" can also be applications that you create to access your AWS resources.

You can use these temporary security credentials in making requests to Amazon SQS. The API libraries compute the necessary signature value using those credentials to authenticate your request. If you send requests using expired credentials Amazon SQS denies the request.

First, use IAM to create temporary security credentials, which include a security token, an Access Key ID, and a Secret Access Key. Second, prepare your string to sign with the temporary Access Key ID and the security token. Third, use the temporary Secret Access Key instead of your own Secret Access Key to sign your Query API request. Finally, when you submit the signed Query API request, don't forget to use the temporary Access Key ID instead of your own Access Key ID and include the security token. For more information about IAM support for temporary security credentials, go to Granting Temporary Access to Your AWS Resources in Using IAM.