Amazon Simple Queue Service
Developer Guide (API Version 2012-11-05)
Did this page help you?  Yes | No |  Tell us about it...
« PreviousNext »
View the PDF for this guide.Go to the AWS Discussion Forum for this product.Go to the Kindle Store to download this guide in Kindle format.

Access Control Using AWS Identity and Access Management (IAM)

Amazon SQS has its own resource-based permissions system that uses policies written in the same language used for AWS Identity and Access Management (IAM) policies. This means that you can achieve the same things with Amazon SQS policies that you can with IAM policies, such as using variables in IAM policies. For more information, see Policy Variables in the Using IAM guide.

The main difference between using Amazon SQS policies versus IAM policies is that you can grant another AWS Account permission to your queues with an Amazon SQS policy, and you can't do that with an IAM policy.

Note

When you grant other AWS accounts access to your AWS resources, be aware that all AWS accounts can delegate their permissions to users under their accounts. This is known as cross-account access. Cross-account access enables you to share access to your AWS resources without having to manage additional users. For information about using cross-account access, go to Enabling Cross-Account Access in Using IAM.

This section describes how the Amazon SQS policy system works with IAM.

You can use an Amazon 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 Amazon SQS actions. When you write an Amazon SQS policy and specify * to mean "all the Amazon SQS actions", that means all actions in that subset.

The following diagram illustrates the concept of one of these basic Amazon 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).

Basic Amazon SQS policy

With the introduction of 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.

Amazon SQS policy with new features
1

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.

2

The subset of actions included in "*" has expanded (for a list of allowed actions, see Amazon SQS Actions).

3

You can specify the resource using the Amazon Resource Name (ARN), which is how you must specify resources in IAM policies. For information about the ARN format for Amazon SQS queues, see Amazon SQS ARNs.

You can still use the original format instead (<account_ID>/<queue_name>).

So for example, according to the Amazon SQS policy shown in the preceding figure, anyone possessing the 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.

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

IAM and Amazon SQS Policies Together

There are two ways you can give your Users permissions for your Amazon SQS resources: through the Amazon SQS policy system or the 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 Amazon SQS policy that are equivalent. The IAM policy allows the Amazon 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 Amazon SQS policy also gives Bob and Susan permission to access ReceiveMessage and SendMessage for the same queue.

Equivalent IAM and Amazon SQS policies

Note

The preceding example shows simple policies with no conditions. You could specify a particular condition in either policy and get the same result.

There is one difference between IAM and Amazon SQS policies: the Amazon SQS policy system lets you grant permission to other AWS Accounts, whereas 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 IAM policy and an Amazon SQS policy that apply to him. The IAM policy gives him permission to use ReceiveMessage on queue_xyz, whereas the Amazon SQS policy gives him permission to use SendMessage on the same queue. The following diagram illustrates the concept.

IAM and Amazon SQS policies for Bob

If Bob were to send a request to receive a message from queue_xyz, the IAM policy would allow the action. If Bob were to send a request to send a message to queue_xyz, the Amazon 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.

The "Deny" policy overrides the other two

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

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

Amazon SQS ARNs

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 IAM ARNs in Using IAM.

Following is an ARN for a queue named my_queue in the US East (N. Virginia) 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, Amazon SQS has a queue attribute called Arn whose value is the queue's ARN. You can get the value by calling the Amazon SQS GetQueueAttributes action.

Amazon SQS Actions

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

Before the introduction of IAM, you could use an Amazon 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., Amazon SQS:SendMessage, Amazon SQS:ReceiveMessage, etc.). The specific actions you could grant permission for were a subset of the overall set of Amazon SQS actions. When you wrote an Amazon SQS policy and specified * to mean "all the Amazon SQS actions", that meant all actions in that subset. That subset originally included:

  • Amazon SQS:SendMessage

  • Amazon SQS:ReceiveMessage

  • Amazon SQS:ChangeMessageVisibility

  • Amazon SQS:DeleteMessage

  • Amazon SQS:GetQueueAttributes (for all attributes except Policy)

  • Amazon SQS:GetQueueUrl

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

  • Amazon SQS:CreateQueue

  • Amazon SQS:DeleteQueue

  • Amazon SQS:ListQueues

The actions related to granting and removing permissions from a queue (Amazon 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 Keys

Amazon SQS implements the following policy keys, but no others.

AWS-Wide Policy Keys

  • aws:CurrentTime—To check for date/time conditions.

  • aws:EpochTime—To check for date/time conditions using a date in epoch or UNIX time.

  • aws:MultiFactorAuthAge—To check how long ago (in seconds) the MFA-validated security credentials making the request were issued using Multi-Factor Authentication (MFA). Unlike other keys, if MFA is not used, this key is not present.

  • aws:principaltype—To check the type of principal (user, account, federated user, etc.) for the current request.

  • aws:SecureTransport—To check whether the request was sent using SSL. For services that use only SSL, such as Amazon RDS and Amazon Route 53, the aws:SecureTransport key has no meaning.

  • aws:SourceArn—To check the source of the request, using the Amazon Resource Name (ARN) of the source. (This value is available for only some services. For more information, see Amazon Resource Name (ARN) under "Element Descriptions" in the Amazon Simple Queue Service Developer Guide.)

  • aws:SourceIp—To check the IP address of the requester. Note that if you use aws:SourceIp, and the request comes from an Amazon EC2 instance, the public IP address of the instance is evaluated.

  • aws:UserAgent—To check the client application that made the request.

  • aws:userid—To check the user ID of the requester.

  • aws:username—To check the user name of the requester, if available.

Note

Key names are case sensitive.

Example IAM Policies for Amazon SQS

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

Note

In the future, Amazon SQS might add new actions that should logically be included in one of the following policies, based on the policy’s stated goals.

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.

Note

Amazon SQS doesn't automatically grant the creator of a queue permission to subsequently use the queue. Therefore, in our IAM policy, we must explicitly grant Bob permission to use all the Amazon SQS actions in addition to CreateQueue.

{
   "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 Amazon SQS policy or an IAM policy. Using an Amazon SQS policy might be easier if the partner has an AWS Account. However, anyone in the partner's company who possesses the AWS security 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 IAM policy instead of an Amazon 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"
      }
   ]
}

Using Temporary Security Credentials

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.

To call an Amazon SQS Query API action using Temporary Security Credentials

  1. Request a temporary security token with AWS Identity and Access Management. For more information, go to Creating Temporary Security Credentials to Enable Access for IAM Users in Using IAM.

    IAM returns a security token, an Access Key ID, and a Secret Access Key.

  2. Prepare your Query as you normally would, but use the temporary Access Key ID in place of your own Access Key ID and include the security token. Sign your request using the temporary Secret Access Key instead of your own.

  3. Submit your signed query string with the temporary Access Key ID and the security token.

    The following example demonstrates how to use temporary security credentials to authenticate an Amazon SQS request.

    How you structure the AUTHPARAMS depends on how you are signing your API request. For information on AUTHPARAMS in Signature Version 4, go to Examples of Signed Signature Version 4 Requests.

    http://sqs.us-east-1.amazonaws.com/
    ?Action=CreateQueue
    &DefaultVisibilityTimeout=40
    &QueueName=testQueue
    &Attribute.1.Name=VisibilityTimeout
    &Attribute.1.Value=40
    &Version=2011-10-01
    &Expires=2011-10-18T22%3A52%3A43PST
    &SecurityToken=SecurityTokenValue
    &AWSAccessKeyId= Access Key ID provided by AWS Security Token Service
    &AUTHPARAMS

    The following example uses Temporary Security Credentials to send two messages with SendMessageBatch.

    http://sqs.us-east-1.amazonaws.com/
    ?Action=SendMessageBatch
    &SendMessageBatchRequestEntry.1.Id=test_msg_001
    &SendMessageBatchRequestEntry.1.MessageBody=test%20message%20body%201
    &SendMessageBatchRequestEntry.2.Id=test_msg_002
    &SendMessageBatchRequestEntry.2.MessageBody=test%20message%20body%202
    &SendMessageBatchRequestEntry.2.DelaySeconds=60
    &Version=2011-10-01
    &Expires=2011-10-18T22%3A52%3A43PST
    &SecurityToken=SecurityTokenValue
    &AWSAccessKeyId=Access Key ID provided by AWS Security Token Service
    &AUTHPARAMS