10 months ago


Amazon Simple Queue

Amazon Simple Queue Service Developer Guide IAM-Related Features of SQS Policies 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 (p. 67)). API Version 2009-02-01 63

Amazon Simple Queue Service Developer Guide AWS IAM and SQS Policies Together 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 (p. 66). You can still use the original format instead (/). 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. AWS IAM and SQS Policies Together 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. 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 SQS policies: the SQS policy system lets you grant permission to other AWS Accounts, whereas AWS IAM doesn't. API Version 2009-02-01 64