# Using policies with Amazon SQS This topic provides examples of identity-based policies in which an account administrator can attach permissions policies to IAM identities (users, groups, and roles). **Important** We recommend that you first review the introductory topics that explain the basic concepts and options available for you to manage access to your Amazon Simple Queue Service resources. For more information, see [Overview of managing access in Amazon SQS](sqs-overview-of-managing-access.md). With the exception of `ListQueues`, all Amazon SQS actions support resource-level permissions. For more information, see [Amazon SQS API permissions: Actions and resource reference](sqs-api-permissions-reference.md). ## Using Amazon SQS and IAM policies There are two ways to give your users permissions to your Amazon SQS resources: using the Amazon SQS policy system (resource-based policies) and using the IAM policy system (identity-based policies). You can use one or both methods, with the exception of the `ListQueues` action, which is a regional permission that can only be set in an IAM policy. For example, the following diagram shows an IAM policy and an Amazon SQS policy equivalent to it. The IAM policy grants the rights to the Amazon SQS `ReceiveMessage` and `SendMessage` actions for the queue called `queue_xyz` in your AWS Account, and the policy is attached to users named Bob and Susan (Bob and Susan have the permissions stated in the policy). This Amazon SQS policy also gives Bob and Susan rights to the `ReceiveMessage` and `SendMessage` actions for the same queue. **Note** The following example shows simple policies without conditions. You can specify a particular condition in either policy and get the same result. ![\[Diagram comparing an IAM policy and an Amazon SQS policy equivalent to it. The IAM policy grants the rights to the Amazon SQS ReceiveMessage and SendMessage actions for the queue called queue_xyz in your AWS Account, and the policy is attached to users named Bob and Susan (Bob and Susan have the permissions stated in the policy). This Amazon SQS policy also gives Bob and Susan rights to the ReceiveMessage and SendMessage actions for the same queue.\]](http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/sqs-iam-policies-equivalent.png) There is one major 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 is up to you how you use both of the systems together to manage your permissions. The following examples show how the two policy systems work together. + In the first example, Bob has both an IAM policy and an Amazon SQS policy that apply to his account. The IAM policy grants his account permission for the `ReceiveMessage` action on `queue_xyz`, whereas the Amazon SQS policy gives his account permission for the `SendMessage` action on the same queue. The following diagram illustrates the concept. ![\[Diagram comparing the components of an IAM policy to an Amazon SQS policy. In the first example, Bob has both an IAM policy and an Amazon SQS policy that apply to his account. The IAM policy grants his account permission for the ReceiveMessage action on queue_xyz, whereas the Amazon SQS policy gives his account permission for the SendMessage action on the same queue.\]](http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/sqs-iam-policies-union.png) If Bob sends a `ReceiveMessage` request to `queue_xyz`, the IAM policy allows the action. If Bob sends a `SendMessage` request to `queue_xyz`, the Amazon SQS policy allows the action. + In the second example, Bob abuses his access to `queue_xyz`, so it becomes necessary to remove his entire access to the queue. The easiest thing to do is to add a policy that denies him access to all actions for the queue. This policy overrides the other two because an explicit `deny` always overrides an `allow`. For more information about policy evaluation logic, see [Using custom policies with the Amazon SQS Access Policy Language](sqs-creating-custom-policies.md). The following diagram illustrates the concept. ![\[Diagram showing an IAM policy override with an Amazon SQS policy. Bob abuses his access to queue_xyz, so it becomes necessary to remove his entire access to the queue. The easiest thing to do is to add a policy that denies him access to all actions for the queue. This policy overrides the other two because an explicit deny always overrides an allow.\]](http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/sqs-iam-policies-deny-override.png) You can also add an additional statement to the Amazon SQS policy that denies Bob any type of access to the queue. It has the same effect as adding an IAM policy that denies Bob access to the queue. For examples of policies that cover Amazon SQS actions and resources, see [Basic examples of Amazon SQS policies](sqs-basic-examples-of-sqs-policies.md). For more information about writing Amazon SQS policies, see [Using custom policies with the Amazon SQS Access Policy Language](sqs-creating-custom-policies.md). ## Permissions required to use the Amazon SQS console A user who wants to work with the Amazon SQS console must have the minimum set of permissions to work with the Amazon SQS queues in the user's AWS account. For example, the user must have the permission to call the `ListQueues` action to be able to list queues, or the permission to call the `CreateQueue` action to be able to create queues. In addition to Amazon SQS permissions, to subscribe an Amazon SQS queue to an Amazon SNS topic, the console also requires permissions for Amazon SNS actions. If you create an IAM policy that is more restrictive than the minimum required permissions, the console might not function as intended for users with that IAM policy. You don't need to allow minimum console permissions for users that make calls only to the AWS CLI or Amazon SQS actions. # Identity-based policy examples for Amazon SQS By default, users and roles don't have permission to create or modify Amazon SQS resources. To grant users permission to perform actions on the resources that they need, an IAM administrator can create IAM policies. To learn how to create an IAM identity-based policy by using these example JSON policy documents, see [Create IAM policies (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) in the *IAM User Guide*. For details about actions and resource types defined by Amazon SQS, including the format of the ARNs for each of the resource types, see [Actions, Resources, and Condition Keys for Amazon Simple Queue Service](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonsqs.html) in the *Service Authorization Reference*. **Note** When you configure lifecycle hooks for Amazon EC2 Auto Scaling, you don't need to write a policy to send messages to an Amazon SQS queue. For more information, see [Amazon EC2 Auto Scaling Lifecycle Hooks](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html) in the *Amazon EC2 User Guide*. ## Policy best practices Identity-based policies determine whether someone can create, access, or delete Amazon SQS resources in your account. These actions can incur costs for your AWS account. When you create or edit identity-based policies, follow these guidelines and recommendations: + **Get started with AWS managed policies and move toward least-privilege permissions** – To get started granting permissions to your users and workloads, use the *AWS managed policies* that grant permissions for many common use cases. They are available in your AWS account. We recommend that you reduce permissions further by defining AWS customer managed policies that are specific to your use cases. For more information, see [AWS managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) or [AWS managed policies for job functions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) in the *IAM User Guide*. + **Apply least-privilege permissions** – When you set permissions with IAM policies, grant only the permissions required to perform a task. You do this by defining the actions that can be taken on specific resources under specific conditions, also known as *least-privilege permissions*. For more information about using IAM to apply permissions, see [ Policies and permissions in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) in the *IAM User Guide*. + **Use conditions in IAM policies to further restrict access** – You can add a condition to your policies to limit access to actions and resources. For example, you can write a policy condition to specify that all requests must be sent using SSL. You can also use conditions to grant access to service actions if they are used through a specific AWS service, such as CloudFormation. For more information, see [ IAM JSON policy elements: Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) in the *IAM User Guide*. + **Use IAM Access Analyzer to validate your IAM policies to ensure secure and functional permissions** – IAM Access Analyzer validates new and existing policies so that the policies adhere to the IAM policy language (JSON) and IAM best practices. IAM Access Analyzer provides more than 100 policy checks and actionable recommendations to help you author secure and functional policies. For more information, see [Validate policies with IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) in the *IAM User Guide*. + **Require multi-factor authentication (MFA)** – If you have a scenario that requires IAM users or a root user in your AWS account, turn on MFA for additional security. To require MFA when API operations are called, add MFA conditions to your policies. For more information, see [ Secure API access with MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) in the *IAM User Guide*. For more information about best practices in IAM, see [Security best practices in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) in the *IAM User Guide*. ## Using the Amazon SQS console To access the Amazon Simple Queue Service console, you must have a minimum set of permissions. These permissions must allow you to list and view details about the Amazon SQS resources in your AWS account. If you create an identity-based policy that is more restrictive than the minimum required permissions, the console won't function as intended for entities (users or roles) with that policy. You don't need to allow minimum console permissions for users that are making calls only to the AWS CLI or the AWS API. Instead, allow access to only the actions that match the API operation that they're trying to perform. To ensure that users and roles can still use the Amazon SQS console, also attach the Amazon SQS `AmazonSQSReadOnlyAccess` AWS managed policy to the entities. For more information, see [Adding permissions to a user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) in the *IAM User Guide*. ## Allow users to view their own permissions This example shows how you might create a policy that allows IAM users to view the inline and managed policies that are attached to their user identity. This policy includes permissions to complete this action on the console or programmatically using the AWS CLI or AWS API. ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "ViewOwnUserInfo", "Effect": "Allow", "Action": [ "iam:GetUserPolicy", "iam:ListGroupsForUser", "iam:ListAttachedUserPolicies", "iam:ListUserPolicies", "iam:GetUser" ], "Resource": ["arn:aws:iam::*:user/${aws:username}"] }, { "Sid": "NavigateInConsole", "Effect": "Allow", "Action": [ "iam:GetGroupPolicy", "iam:GetPolicyVersion", "iam:GetPolicy", "iam:ListAttachedGroupPolicies", "iam:ListGroupPolicies", "iam:ListPolicyVersions", "iam:ListPolicies", "iam:ListUsers" ], "Resource": "*" } ] } ``` ## Allow a user to create queues In the following example, we create a policy for Bob that lets him access all Amazon SQS actions, but only with queues whose names are prefixed with the literal string `alice_queue_`. Amazon SQS doesn't automatically grant the creator of a queue permissions to use the queue. Therefore, we must explicitly grant Bob permissions to use all Amazon SQS actions in addition to `CreateQueue` action in the IAM policy. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [{ "Effect": "Allow", "Action": "sqs:*", "Resource": "arn:aws:sqs:*:123456789012:alice_queue_*" }] } ``` ------ ## Allow developers to write messages to a shared queue In the following 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 queue that belongs to the specified AWS account and is named `MyCompanyQueue`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [{ "Effect": "Allow", "Action": "sqs:SendMessage", "Resource": "arn:aws:sqs:*:123456789012:MyCompanyQueue" }] } ``` ------ You can use `*` instead of `SendMessage` to grant the following actions to a principal on a shared queue: `ChangeMessageVisibility`, `DeleteMessage`, `GetQueueAttributes`, `GetQueueUrl`, `ReceiveMessage`, and `SendMessage`. **Note** Although `*` includes access provided by other permission types, Amazon SQS considers permissions separately. For example, it is possible to grant both `*` and `SendMessage` permissions to a user, even though a `*` includes the access provided by `SendMessage`. This concept also applies when you remove a permission. If a principal has only a `*` permission, requesting to remove a `SendMessage` permission *doesn't* leave the principal with an *everything-but* permission. Instead, the request has no effect, because the principal doesn't possess an explicit `SendMessage` permission. To leave the principal with only the `ReceiveMessage` permission, first add the `ReceiveMessage` permission and then remove the `*` permission. ## Allow managers to get the general size of queues In the following 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 queues that belong to the specified AWS account. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [{ "Effect": "Allow", "Action": "sqs:GetQueueAttributes", "Resource": "*" }] } ``` ------ ## Allow a partner to send messages to a specific queue You can accomplish this task using an Amazon SQS policy or an IAM policy. If your partner has an AWS account, it might be easier to use an Amazon SQS policy. However, any user in the partner's company who possesses the AWS security credentials can send messages to the queue. If you want to limit access to a particular user or application, you must treat the partner like a user in your own company and use an IAM policy instead of an Amazon SQS policy. This example performs the following actions: 1. Create a group called WidgetCo to represent the partner company. 1. Create a user for the specific user or application at the partner's company who needs access. 1. Add the user to the group. 1. Attach a policy that gives the group access only to the `SendMessage` action for only the queue named `WidgetPartnerQueue`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [{ "Effect": "Allow", "Action": "sqs:SendMessage", "Resource": "arn:aws:sqs:*:123456789012:WidgetPartnerQueue" }] } ``` ------ # Basic examples of Amazon SQS policies This section shows example policies for common Amazon SQS use cases. You can use the console to verify the effects of each policy as you attach the policy to the user. Initially, the user doesn't have permissions and won't be able to do anything in the console. As you attach policies to the user, you can verify that the user can perform various actions in the console. **Note** We recommend that you use two browser windows: one to grant permissions and the other to sign into the AWS Management Console using the user's credentials to verify permissions as you grant them to the user. ## Example 1: Grant one permission to one AWS account The following example policy grants AWS account number `111122223333` the `SendMessage` permission for the queue named `444455556666/queue1` in the US East (Ohio) region. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Id": "Queue1_Policy_UUID", "Statement": [{ "Sid":"Queue1_SendMessage", "Effect": "Allow", "Principal": { "AWS": [ "111122223333" ] }, "Action": "sqs:SendMessage", "Resource": "arn:aws:sqs:us-east-2:444455556666:queue1" }] } ``` ------ ## Example 2: Grant two permissions to one AWS account The following example policy grants AWS account number `111122223333` both the `SendMessage` and `ReceiveMessage` permission for the queue named `444455556666/queue1`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Id": "Queue1_Policy_UUID", "Statement": [{ "Sid":"Queue1_Send_Receive", "Effect": "Allow", "Principal": { "AWS": [ "111122223333" ] }, "Action": [ "sqs:SendMessage", "sqs:ReceiveMessage" ], "Resource": "arn:aws:sqs:*:444455556666:queue1" }] } ``` ------ ## Example 3: Grant all permissions to two AWS accounts The following example policy grants two different AWS accounts numbers (`111122223333` and `444455556666`) permission to use all actions to which Amazon SQS allows shared access for the queue named `123456789012/queue1` in the US East (Ohio) region. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Id": "Queue1_Policy_UUID", "Statement": [{ "Sid":"Queue1_AllActions", "Effect": "Allow", "Principal": { "AWS": [ "111122223333", "444455556666" ] }, "Action": "sqs:*", "Resource": "arn:aws:sqs:us-east-2:123456789012:queue1" }] } ``` ------ ## Example 4: Grant cross-account permissions to a role and a username The following example policy grants `role1` and `username1` under AWS account number `111122223333` cross-account permission to use all actions to which Amazon SQS allows shared access for the queue named `123456789012/queue1` in the US East (Ohio) region. Cross-account permissions don't apply to the following actions: + `[AddPermission](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_AddPermission.html)` + `[CancelMessageMoveTask](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_CancelMessageMoveTask.html)` + `[CreateQueue](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_CreateQueue.html)` + `[DeleteQueue](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_DeleteQueue.html)` + `[ListMessageMoveTask](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ListMessageMoveTasks.html)` + `[ListQueues](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ListQueues.html)` + `[ListQueueTags](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ListQueueTags.html)` + `[RemovePermission](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_RemovePermission.html)` + `[SetQueueAttributes](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SetQueueAttributes.html)` + `[StartMessageMoveTask](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_StartMessageMoveTask.html)` + `[TagQueue](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_TagQueue.html)` + `[UntagQueue](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_UntagQueue.html)` ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Id": "Queue1_Policy_UUID", "Statement": [{ "Sid":"Queue1_AllActions", "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::111122223333:role/role1", "arn:aws:iam::111122223333:user/username1" ] }, "Action": "sqs:*", "Resource": "arn:aws:sqs:us-east-2:123456789012:queue1" }] } ``` ------ ## Example 5: Grant a permission to all users The following example policy grants all users (anonymous users) `ReceiveMessage` permission for the queue named `111122223333/queue1`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Id": "Queue1_Policy_UUID", "Statement": [{ "Sid":"Queue1_AnonymousAccess_ReceiveMessage", "Effect": "Allow", "Principal": "*", "Action": "sqs:ReceiveMessage", "Resource": "arn:aws:sqs:*:111122223333:queue1" }] } ``` ------ ## Example 6: Grant a time-limited permission to all users The following example policy grants all users (anonymous users) `ReceiveMessage` permission for the queue named `111122223333/queue1`, but only between 12:00 p.m. (noon) and 3:00 p.m. on January 31, 2009. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Id": "Queue1_Policy_UUID", "Statement": [{ "Sid":"Queue1_AnonymousAccess_ReceiveMessage_TimeLimit", "Effect": "Allow", "Principal": "*", "Action": "sqs:ReceiveMessage", "Resource": "arn:aws:sqs:*:111122223333:queue1", "Condition" : { "DateGreaterThan" : { "aws:CurrentTime":"2009-01-31T12:00Z" }, "DateLessThan" : { "aws:CurrentTime":"2009-01-31T15:00Z" } } }] } ``` ------ ## Example 7: Grant all permissions to all users in a CIDR range The following example policy grants all users (anonymous users) permission to use all possible Amazon SQS actions that can be shared for the queue named `111122223333/queue1`, but only if the request comes from the `192.0.2.0/24` CIDR range. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Id": "Queue1_Policy_UUID", "Statement": [{ "Sid":"Queue1_AnonymousAccess_AllActions_AllowlistIP", "Effect": "Allow", "Principal": "*", "Action": "sqs:*", "Resource": "arn:aws:sqs:*:111122223333:queue1", "Condition" : { "IpAddress" : { "aws:SourceIp":"192.0.2.0/24" } } }] } ``` ------ ## Example 8: Allowlist and blocklist permissions for users in different CIDR ranges The following example policy has two statements: + The first statement grants all users (anonymous users) in the `192.0.2.0/24` CIDR range (except for `192.0.2.188`) permission to use the `SendMessage` action for the queue named `111122223333`/queue1. + The second statement blocks all users (anonymous users) in the `12.148.72.0/23` CIDR range from using the queue. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Id": "Queue1_Policy_UUID", "Statement": [{ "Sid":"Queue1_AnonymousAccess_SendMessage_IPLimit", "Effect": "Allow", "Principal": "*", "Action": "sqs:SendMessage", "Resource": "arn:aws:sqs:*:111122223333:queue1", "Condition" : { "IpAddress" : { "aws:SourceIp":"192.0.2.0/24" }, "NotIpAddress" : { "aws:SourceIp":"192.0.2.188/32" } } }, { "Sid":"Queue1_AnonymousAccess_AllActions_IPLimit_Deny", "Effect": "Deny", "Principal": "*", "Action": "sqs:*", "Resource": "arn:aws:sqs:*:111122223333:queue1", "Condition" : { "IpAddress" : { "aws:SourceIp":"12.148.72.0/23" } } }] } ``` ------ # Using custom policies with the Amazon SQS Access Policy Language To grant basic permissions (such as [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html) or [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html)) based only on an AWS account ID, you don’t need to write a custom policy. Instead, use the Amazon SQS [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_AddPermission.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_AddPermission.html) action. To allow or deny access based on specific conditions, such as request time or the requester's IP address, you must create a custom Amazon SQS policy and upload it using the [SetQueueAttributes](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SetQueueAttributes.html) action. **Topics** + [Access control architecture](sqs-creating-custom-policies-architecture.md) + [Access control process workflow](sqs-creating-custom-policies-process-workflow.md) + [Access Policy Language key concepts](sqs-creating-custom-policies-key-concepts.md) + [Access Policy Language evaluation logic](sqs-creating-custom-policies-evaluation-logic.md) + [Relationships between explicit and default denials](sqs-creating-custom-policies-relationships-between-explicit-default-denials.md) + [Custom policy limitations](sqs-limitations-of-custom-policies.md) + [Custom Access Policy Language examples](sqs-creating-custom-policies-access-policy-examples.md) # Amazon SQS access control architecture The following diagram describes the access control for your Amazon SQS resources. ![\[Describes access control for your Amazon SQS resources.\]](http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/AccessPolicyLanguage_Arch_Overview.png) ![\[In the previous diagram, section number one.\]](http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-1-red.png) You, the resource owner. ![\[In the previous diagram, section number two.\]](http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-2-red.png) Your resources contained within the AWS service (for example, Amazon SQS queues). ![\[In the previous diagram, section number three.\]](http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-3-red.png) Your policies. It is a good practice to have one policy per resource. The AWS service provides an API you use to upload and manage your policies. ![\[In the previous diagram, section number four.\]](http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-4-red.png) Requesters and their incoming requests to the AWS service. ![\[In the previous diagram, section number five.\]](http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-5-red.png) The access policy language evaluation code. This is the set of code within the AWS service that evaluates incoming requests against the applicable policies and determines whether the requester is allowed access to the resource. # Amazon SQS access control process workflow The following diagram describes the general workflow of access control with the Amazon SQS access policy language. ![\[The general workflow of access control with the Amazon SQS access policy language.\]](http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/AccessPolicyLanguage_Basic_Flow.png) ![\[Figure one in the previous diagram.\]](http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-1-red.png) You write an Amazon SQS policy for your queue. ![\[Figure two in the previous diagram.\]](http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-2-red.png) You upload your policy to AWS. The AWS service provides an API that you use to upload your policies. For example, you use the Amazon SQS `SetQueueAttributes` action to upload a policy for a particular Amazon SQS queue. ![\[Figure three in the previous diagram.\]](http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-3-red.png) Someone sends a request to use your Amazon SQS queue. ![\[Figure four in the previous diagram.\]](http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-4-red.png) Amazon SQS examines all available Amazon SQS policies and determines which ones are applicable. ![\[Figure five in the previous diagram.\]](http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-5-red.png) Amazon SQS evaluates the policies and determines whether the requester is allowed to use your queue. ![\[Figure six in the previous diagram.\]](http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-6-red.png) Based on the policy evaluation result, Amazon SQS either returns an `Access denied` error to the requester or continues to process the request. # Amazon SQS Access Policy Language key concepts To write your own policies, you must be familiar with [JSON](http://json.org/) and a number of key concepts. **Allow** The result of a [Statement](#statement) that has [Effect](#effect) set to `allow`. **Action** The activity that the [Principal](#principal) has permission to perform, typically a request to AWS. **Default-deny** The result of a [Statement](#statement) that has no [Allow](#allow) or [Explicit-deny](#explicit-deny) settings. **Condition** Any restriction or detail about a [Permission](#permission). Typical conditions are related to date and time and IP addresses. **Effect** The result that you want the [Statement](#statement) of a [Policy](#policy) to return at evaluation time. You specify the `deny` or `allow` value when you write the policy statement. There can be three possible results at policy evaluation time: [Default-deny](#default-deny), [Allow](#allow), and [Explicit-deny](#explicit-deny). **Explicit-deny** The result of a [Statement](#statement) that has [Effect](#effect) set to `deny`. **Evaluation** The process that Amazon SQS uses to determine whether an incoming request should be denied or allowed based on a [Policy](#policy). **Issuer** The user who writes a [Policy](#policy) to grant permissions to a resource. The issuer, by definition is always the resource owner. AWS doesn't permit Amazon SQS users to create policies for resources they don't own. **Key** The specific characteristic that is the basis for access restriction. **Permission** The concept of allowing or disallowing access to a resource using a [Condition](#condition) and a [Key](#key). **Policy** The document that acts as a container for one or more **[statements](#statement)**. ![\[Policy A containing statement 1 and statement 2 is equivalent to policy A that contains statement 1, and Policy B that contains statement 2.\]](http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/AccessPolicyLanguage_Statement_and_Policy.png) Amazon SQS uses the policy to determine whether to grant access to a user for a resource. **Principal** The user who receives [Permission](#permission) in the [Policy](#policy). **Resource** The object that the [Principal](#principal) requests access to. **Statement** The formal description of a single permission, written in the access policy language as part of a broader [Policy](#policy) document. **Requester** The user who sends a request for access to a [Resource](#resource). # Amazon SQS Access Policy Language evaluation logic At evaluation time, Amazon SQS determines whether a request from someone other than the resource owner should be allowed or denied. The evaluation logic follows several basic rules: + By default, all requests to use your resource coming from anyone but you are denied. + An *[Allow](sqs-creating-custom-policies-key-concepts.md#allow)* overrides any *[Default-deny](sqs-creating-custom-policies-key-concepts.md#default-deny)*. + An *[Explicit-deny](sqs-creating-custom-policies-key-concepts.md#explicit-deny)* overrides any **allow**. + The order in which the policies are evaluated isn't important. The following diagram describes in detail how Amazon SQS evaluates decisions about access permissions. ![\[Flow chart describing how Amazon SQS evaluates decisions about access permissions.\]](http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/AccessPolicyLanguage_Evaluation_Flow.png) ![\[In the previous diagram, number one.\]](http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-1-red.png) The decision starts with a **default-deny**. ![\[In the previous diagram, number two.\]](http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-2-red.png) The enforcement code evaluates all the policies that are applicable to the request (based on the resource, principal, action, and conditions). The order in which the enforcement code evaluates the policies isn't important. ![\[In the previous diagram, number three.\]](http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-3-red.png) The enforcement code looks for an **explicit-deny** instruction that can apply to the request. If it finds even one, the enforcement code returns a decision of **deny** and the process finishes. ![\[In the previous diagram, number four.\]](http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-4-red.png) If no **explicit-deny** instruction is found, the enforcement code looks for any **allow** instructions that can apply to the request. If it finds even one, the enforcement code returns a decision of **allow** and the process finishes (the service continues to process the request). ![\[In the previous diagram, number five.\]](http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-5-red.png) If no **allow** instruction is found, then the final decision is **deny** (because there is no **explicit-deny** or **allow**, this is considered a **default-deny**). # Relationships between explicit and default denials in the Amazon SQS Access Policy Language If an Amazon SQS policy doesn't directly apply to a request, the request results in a *[Default-deny](sqs-creating-custom-policies-key-concepts.md#default-deny)*. For example, if a user requests permission to use Amazon SQS but the only policy that applies to the user can use DynamoDB, the requests results in a **default-deny**. If a condition in a statement isn't met, the request results in a **default-deny**. If all conditions in a statement are met, the request results in either an *[Allow](sqs-creating-custom-policies-key-concepts.md#allow)* or an *[Explicit-deny](sqs-creating-custom-policies-key-concepts.md#explicit-deny)* based on the value of the *[Effect](sqs-creating-custom-policies-key-concepts.md#effect)* element of the policy. Policies don't specify what to do if a condition isn't met, so the default result in this case is a **default-deny**. For example, you want to prevent requests that come from Antarctica. You write Policy A1 that allows a request only if it doesn't come from Antarctica. The following diagram illustrates the Amazon SQS policy. ![\[Policy A1, which contains Effect equal to Allow, and Condition equal to if request is not from Antarctica.\]](http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/sqs-security-custom-policy-allow-request-if-not-from-antarctica.png) If a user sends a request from the U.S., the condition is met (the request isn't from Antarctica), and the request results in an **allow**. However, if a user sends a request from Antarctica, the condition isn't met and the request defaults to a **default-deny**. You can change the result to an **explicit-deny** by writing Policy A2 that explicitly denies a request if it comes from Antarctica. The following diagram illustrates the policy. ![\[Policy A2, which contains Effect equal to Deny, and Condition equal to if request is from Antarctica.\]](http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/sqs-security-custom-policy-explicitly-deny-request-if-from-antarctica.png) If a user sends a request from Antarctica, the condition is met and the request results in an **explicit-deny**. The distinction between a **default-deny** and an **explicit-deny** is important because an **allow** can overwrite the former but not the latter. For example, Policy B allows requests if they arrive on June 1, 2010. The following diagram compares combining this policy with Policy A1 and Policy A2. ![\[A side-by-side comparison between scenario 1 and scenario 2.\]](http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/sqs-security-custom-policy-compare-allow-request-deny-request-policies-override.png) In Scenario 1, Policy A1 results in a **default-deny** and Policy B results in an **allow** because the policy allows requests that come in on June 1, 2010. The **allow** from Policy B overrides the **default-deny** from Policy A1, and the request is allowed. In Scenario 2, Policy B2 results in an **explicit-deny** and Policy B results in an **allow**. The **explicit-deny** from Policy A2 overrides the **allow** from Policy B, and the request is denied. # Limitations of Amazon SQS custom policies ## Cross-account access Cross-account permissions don't apply to the following actions: + `[AddPermission](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_AddPermission.html)` + `[CancelMessageMoveTask](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_CancelMessageMoveTask.html)` + `[CreateQueue](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_CreateQueue.html)` + `[DeleteQueue](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_DeleteQueue.html)` + `[ListMessageMoveTask](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ListMessageMoveTasks.html)` + `[ListQueues](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ListQueues.html)` + `[ListQueueTags](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ListQueueTags.html)` + `[RemovePermission](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_RemovePermission.html)` + `[SetQueueAttributes](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SetQueueAttributes.html)` + `[StartMessageMoveTask](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_StartMessageMoveTask.html)` + `[TagQueue](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_TagQueue.html)` + `[UntagQueue](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_UntagQueue.html)` ## Condition keys Currently, Amazon SQS supports only a limited subset of the [condition keys available in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#AvailableKeys). For more information, see [Amazon SQS API permissions: Actions and resource reference](sqs-api-permissions-reference.md). # Custom Amazon SQS Access Policy Language examples The following are examples of typical Amazon SQS access policies. ## Example 1: Give permission to one account The following example Amazon SQS policy gives AWS account 111122223333 permission to send to and receive from `queue2` owned by AWS account 444455556666. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Id": "UseCase1", "Statement" : [{ "Sid": "1", "Effect": "Allow", "Principal": { "AWS": [ "111122223333" ] }, "Action": [ "sqs:SendMessage", "sqs:ReceiveMessage" ], "Resource": "arn:aws:sqs:us-east-2:444455556666:queue2" }] } ``` ------ ## Example 2: Give permission to one or more accounts The following example Amazon SQS policy gives one or more AWS accounts access to queues owned by your account for a specific time period. It is necessary to write this policy and to upload it to Amazon SQS using the [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SetQueueAttributes.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SetQueueAttributes.html) action because the [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_AddPermission.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_AddPermission.html) action doesn't permit specifying a time restriction when granting access to a queue. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Id": "UseCase2", "Statement" : [{ "Sid": "1", "Effect": "Allow", "Principal": { "AWS": [ "111122223333", "444455556666" ] }, "Action": [ "sqs:SendMessage", "sqs:ReceiveMessage" ], "Resource": "arn:aws:sqs:us-east-2:444455556666:queue2", "Condition": { "DateLessThan": { "AWS:CurrentTime": "2009-06-30T12:00Z" } } }] } ``` ------ ## Example 3: Give permission to requests from Amazon EC2 instances The following example Amazon SQS policy gives access to requests that come from Amazon EC2 instances. This example builds on the "[Example 2: Give permission to one or more accounts](#two-accounts)" example: it restricts access to before June 30, 2009 at 12 noon (UTC), it restricts access to the IP range `203.0.113.0/24`. It is necessary to write this policy and to upload it to Amazon SQS using the [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SetQueueAttributes.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SetQueueAttributes.html) action because the [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_AddPermission.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_AddPermission.html) action doesn't permit specifying an IP address restriction when granting access to a queue. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Id": "UseCase3", "Statement" : [{ "Sid": "1", "Effect": "Allow", "Principal": { "AWS": [ "111122223333" ] }, "Action": [ "sqs:SendMessage", "sqs:ReceiveMessage" ], "Resource": "arn:aws:sqs:us-east-2:444455556666:queue2", "Condition": { "DateLessThan": { "AWS:CurrentTime": "2009-06-30T12:00Z" }, "IpAddress": { "AWS:SourceIp": "203.0.113.0/24" } } }] } ``` ------ ## Example 4: Deny access to a specific account The following example Amazon SQS policy denies a specific AWS account access to your queue. This example builds on the "[Example 1: Give permission to one account](#one-account)" example: it denies access to the specified AWS account. It is necessary to write this policy and to upload it to Amazon SQS using the [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SetQueueAttributes.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SetQueueAttributes.html) action because the [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_AddPermission.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_AddPermission.html) action doesn't permit deny access to a queue (it allows only granting access to a queue). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Id": "UseCase4", "Statement" : [{ "Sid": "1", "Effect": "Deny", "Principal": { "AWS": [ "111122223333" ] }, "Action": [ "sqs:SendMessage", "sqs:ReceiveMessage" ], "Resource": "arn:aws:sqs:us-east-2:444455556666:queue2" }] } ``` ------ ## Example 5: Deny access if it isn't from a VPC endpoint The following example Amazon SQS policy restricts access to `queue1`: 111122223333 can perform the [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html) and [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html) actions only from the VPC endpoint ID `vpce-1a2b3c4d` (specified using the `aws:sourceVpce` condition). For more information, see [Amazon Virtual Private Cloud endpoints for Amazon SQS](sqs-internetwork-traffic-privacy.md#sqs-vpc-endpoints). **Note** The `aws:sourceVpce` condition doesn't require an ARN for the VPC endpoint resource, only the VPC endpoint ID. You can modify the following example to restrict all actions to a specific VPC endpoint by denying all Amazon SQS actions (`sqs:*`) in the second statement. However, such a policy statement would stipulate that all actions (including administrative actions needed to modify queue permissions) must be made through the specific VPC endpoint defined in the policy, potentially preventing the user from modifying queue permissions in the future. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Id": "UseCase5", "Statement": [{ "Sid": "1", "Effect": "Allow", "Principal": { "AWS": [ "111122223333" ] }, "Action": [ "sqs:SendMessage", "sqs:ReceiveMessage" ], "Resource": "arn:aws:sqs:us-east-2:111122223333:queue1" }, { "Sid": "2", "Effect": "Deny", "Principal": "*", "Action": [ "sqs:SendMessage", "sqs:ReceiveMessage" ], "Resource": "arn:aws:sqs:us-east-2:111122223333:queue1", "Condition": { "StringNotEquals": { "aws:sourceVpce": "vpce-1a2b3c4d" } } } ] } ``` ------ # Using temporary security credentials with Amazon SQS In addition to creating users with their own security credentials, IAM also allows you to grant temporary security credentials to any user, allowing the user to access your AWS services and resources. You can manage users who have AWS accounts. You can also manage users for your system who don't have AWS accounts (federated users). In addition, applications that you create to access your AWS resources can also be considered to be "users." You can use these temporary security credentials to make 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. **Note** You can't set a policy based on temporary credentials. ## Prerequisites 1. Use IAM to create temporary security credentials: + Security token + Access Key ID + Secret Access Key 1. Prepare your string to sign with the temporary Access Key ID and the security token. 1. Use the temporary Secret Access Key instead of your own Secret Access Key to sign your Query API request. **Note** When you submit the signed Query API request, use the temporary Access Key ID instead of your own Access Key ID and to include the security token. For more information about IAM support for temporary security credentials, see [Granting Temporary Access to Your AWS Resources](https://docs.aws.amazon.com/IAM/latest/UserGuide/TokenBasedAuth.html) in the *IAM User Guide*. ## To call an Amazon SQS Query API action using temporary security credentials 1. Request a temporary security token using AWS Identity and Access Management. For more information, see [Creating Temporary Security Credentials to Enable Access for IAM Users](https://docs.aws.amazon.com/IAM/latest/UserGuide/CreatingSessionTokens.html) in the *IAM User Guide*. IAM returns a security token, an Access Key ID, and a Secret Access Key. 1. Prepare your query using the temporary Access Key ID instead of your own Access Key ID and include the security token. Sign your request using the temporary Secret Access Key instead of your own. 1. 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. The structure of *`AUTHPARAMS`* depends on the signature of the API request. For more information, see [Signing AWS API Requests](https://docs.aws.amazon.com/general/latest/gr/signing_aws_api_requests.html) in the *Amazon Web Services General Reference*. ``` https://sqs.us-east-2.amazonaws.com/ ?Action=CreateQueue &DefaultVisibilityTimeout=40 &QueueName=MyQueue &Attribute.1.Name=VisibilityTimeout &Attribute.1.Value=40 &Expires=2020-12-18T22%3A52%3A43PST &SecurityToken=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY &AWSAccessKeyId=AKIAIOSFODNN7EXAMPLE &Version=2012-11-05 &AUTHPARAMS ``` The following example uses temporary security credentials to send two messages using the `SendMessageBatch` action. ``` https://sqs.us-east-2.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 &Expires=2020-12-18T22%3A52%3A43PST &SecurityToken=je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY &AWSAccessKeyId=AKIAI44QH8DHBEXAMPLE &Version=2012-11-05 &AUTHPARAMS ``` # Access management for encrypted Amazon SQS queues with least privilege policies You can use Amazon SQS to exchange sensitive data between applications by using server-side encryption (SSE) integrated with [AWS Key Management Service (KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html). With the integration of Amazon SQS and AWS KMS, you can centrally manage the keys that protect Amazon SQS, as well as the keys that protect your other AWS resources. Multiple AWS services can act as event sources that send events to Amazon SQS. To enable an event source to access the encrypted Amazon SQS queue, you need to configure the queue with a [customer-managed](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) AWS KMS key. Then, use the key policy to allow the service to use the required AWS KMS API methods. The service also requires permissions to authenticate access to enable the queue to send events. You can achieve this by using an Amazon SQS policy, which is a resource-based policy that you can use to control access to the Amazon SQS queue and its data. The following sections provide information on how to control access to your encrypted Amazon SQS queue through the Amazon SQS policy and the AWS KMS key policy. The policies in this guide will help you achieve [least privilege](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege). This guide also describes how resource-based policies address the [confused-deputy problem](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html) by using the [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn), [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount), and [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principalorgid](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principalorgid) global IAM condition context keys. **Topics** + [Overview](#sqs-least-privilege-overview) + [Least privilege key policy for Amazon SQS](#sqs-least-privilege-use-case) + [Amazon SQS policy statements for the dead-letter queue](#sqs-policy-dlq) + [Prevent the cross-service confused deputy problem](#sqs-confused-deputy-prevention) + [Use IAM Access Analyzer to review cross-account access](#sqs-cross-account-findings) ## Overview In this topic, we will walk you through a common use case to illustrate how you can build the key policy and the Amazon SQS queue policy. This use case is shown in the following image. ![\[Publishing Amazon SNS messages to Amazon SQS.\]](http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/sqs-least-privilege.png) In this example, the message producer is an [Amazon Simple Notification Service (SNS)](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) topic, which is configured to fanout messages to your encrypted Amazon SQS queue. The message consumer is a compute service, such as an [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) function, an [Amazon Elastic Compute Cloud (EC2)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts.html) instance, or an [AWS Fargate](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/AWS_Fargate.html) container. Your Amazon SQS queue is then configured to send failed messages to a [Dead-letter Queue (DLQ)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html). This is useful for debugging your application or messaging system because DLQs let you isolate unconsumed messages to determine why their processing didn't succeed. In the solution defined in this topic, a compute service such as a Lambda function is used to process messages stored in the Amazon SQS queue. If the message consumer is located in a virtual private cloud (VPC), the [`DenyReceivingIfNotThroughVPCE`](#sqs-restrict-message-to-endpoint) policy statement included in this guide lets you restrict message reception to that specific VPC. **Note** This guide contains only the required IAM permissions in the form of policy statements. To construct the policy, you need to add the statements to your Amazon SQS policy or your AWS KMS key policy. This guide doesn't provide instructions on how to create the Amazon SQS queue or the AWS KMS key. For instructions on how to create these resources, see [Creating an Amazon SQS queue](creating-sqs-standard-queues.md#step-create-standard-queue) and [Creating keys](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html). The Amazon SQS policy defined in this guide doesn’t support redriving messages directly to the same or a different Amazon SQS queue. ## Least privilege key policy for Amazon SQS In this section, we describe the required least privilege permissions in AWS KMS for the customer-managed key that you use to encrypt your Amazon SQS queue. With these permissions, you can limit access to only the intended entities while implementing least privilege. The key policy must consist of the following policy statements, which we describe in detail below: + [Grant administrator permissions to the AWS KMS key](#sqs-use-case-kms-admin-permissions) + [Grant read-only access to the key metadata](#sqs-use-case-read-only-permissions) + [Grant Amazon SNS KMS permissions to Amazon SNS to publish messages to the queue](#sqs-use-case-publish-messages-permissions) + [Allow consumers to decrypt messages from the queue](#sqs-use-case-decrypt-messages-permissions) ### Grant administrator permissions to the AWS KMS key To create an AWS KMS key, you need to provide AWS KMS administrator permissions to the IAM role that you use to deploy the AWS KMS key. These administrator permissions are defined in the following `AllowKeyAdminPermissions` policy statement. When you add this statement to your AWS KMS key policy, make sure to replace ** with the Amazon Resource Name (ARN) of the IAM role used to deploy the AWS KMS key, manage the AWS KMS key, or both. This can be the IAM role of your deployment pipeline, or the [administrator role for your organization](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_access.html) in your [AWS Organizations.](https://aws.amazon.com/organizations/) ``` { "Sid": "AllowKeyAdminPermissions", "Effect": "Allow", "Principal": { "AWS": [ "" ] }, "Action": [ "kms:Create*", "kms:Describe*", "kms:Enable*", "kms:List*", "kms:Put*", "kms:Update*", "kms:Revoke*", "kms:Disable*", "kms:Get*", "kms:Delete*", "kms:TagResource", "kms:UntagResource", "kms:ScheduleKeyDeletion", "kms:CancelKeyDeletion" ], "Resource": "*" } ``` **Note** In an AWS KMS key policy, the value of the `Resource` element needs to be `*`, which means "this AWS KMS key". The asterisk (`*`) identifies the AWS KMS key to which the key policy is attached. ### Grant read-only access to the key metadata To grant other IAM roles read-only access to your key metadata, add the `AllowReadAccessToKeyMetaData` statement to your key policy. For example, the following statement lets you list all of the AWS KMS keys in your account for auditing purposes. This statement grants the AWS root user read-only access to the key metadata. Therefore, any IAM principal in the account can have access to the key metadata when their identity-based policies have the permissions listed in the following statement: `kms:Describe*`, `kms:Get*`, and `kms:List*`. Make sure to replace ** with your own information. ``` { "Sid": "AllowReadAcesssToKeyMetaData", "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam:::root" ] }, "Action": [ "kms:Describe*", "kms:Get*", "kms:List*" ], "Resource": "*" } ``` ### Grant Amazon SNS KMS permissions to Amazon SNS to publish messages to the queue To allow your Amazon SNS topic to publish messages to your encrypted Amazon SQS queue, add the `AllowSNSToSendToSQS` policy statement to your key policy. This statement grants Amazon SNS permissions to use the AWS KMS key to publish to your Amazon SQS queue. Make sure to replace ** with your own information. **Note** The `Condition` in the statement limits access to only the Amazon SNS service in the same AWS account. ``` { "Sid": "AllowSNSToSendToSQS", "Effect": "Allow", "Principal": { "Service": [ "sns.amazonaws.com" ] }, "Action": [ "kms:Decrypt", "kms:GenerateDataKey" ], "Resource": "*", "Condition": { "StringEquals": { "aws:SourceAccount": "" } } } ``` ### Allow consumers to decrypt messages from the queue The following `AllowConsumersToReceiveFromTheQueue` statement grants the Amazon SQS message consumer the required permissions to decrypt messages received from the encrypted Amazon SQS queue. When you attach the policy statement, replace ** with the IAM runtime role ARN of the message consumer. ``` { "Sid": "AllowConsumersToReceiveFromTheQueue", "Effect": "Allow", "Principal": { "AWS": [ "" ] }, "Action": [ "kms:Decrypt" ], "Resource": "*" } ``` ### Least privilege Amazon SQS policy This section walks you through the least privilege Amazon SQS queue policies for the use case covered by this guide (for example, Amazon SNS to Amazon SQS). The defined policy is designed to prevent unintended access by using a mix of both `Deny` and `Allow` statements. The `Allow` statements grant access to the intended entity or entities. The `Deny` statements prevent other unintended entities from accessing the Amazon SQS queue, while excluding the intended entity within the policy condition. The Amazon SQS policy includes the following statements, which we describe in detail below: + [Restrict Amazon SQS management permissions](#sqs-use-case-restrict-permissions) + [Restrict Amazon SQS queue actions from the specified organization](#sqs-use-case-restrict-permissions-from-org) + [Grant Amazon SQS permissions to consumers](#sqs-use-grant-consumer-permissions) + [Enforce encryption in transit](#sqs-encryption-in-transit) + [Restrict message transmission to a specific Amazon SNS topic](#sqs-restrict-transmission-to-topic) + [(Optional) Restrict message reception to a specific VPC endpoint](#sqs-restrict-message-to-endpoint) ### Restrict Amazon SQS management permissions The following `RestrictAdminQueueActions` policy statement restricts the Amazon SQS management permissions to only the IAM role or roles that you use to deploy the queue, manage the queue, or both. Make sure to replace the ** with your own information. Specify the ARN of the IAM role used to deploy the Amazon SQS queue, as well as the ARNs of any administrator roles that should have Amazon SQS management permissions. ``` { "Sid": "RestrictAdminQueueActions", "Effect": "Deny", "Principal": { "AWS": "*" }, "Action": [ "sqs:AddPermission", "sqs:DeleteQueue", "sqs:RemovePermission", "sqs:SetQueueAttributes" ], "Resource": "", "Condition": { "StringNotLike": { "aws:PrincipalARN": [ "arn:aws:iam:::role/", "" ] } } } ``` ### Restrict Amazon SQS queue actions from the specified organization To help protect your Amazon SQS resources from external access (access by an entity outside of your [AWS organization](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html)), use the following statement. This statement limits Amazon SQS queue access to the organization that you specify in the `Condition`. Make sure to replace ** with the ARN of the IAM role used to deploy the Amazon SQS queue; and the **, with your organization ID. ``` { "Sid": "DenyQueueActionsOutsideOrg", "Effect": "Deny", "Principal": { "AWS": "*" }, "Action": [ "sqs:AddPermission", "sqs:ChangeMessageVisibility", "sqs:DeleteQueue", "sqs:RemovePermission", "sqs:SetQueueAttributes", "sqs:ReceiveMessage" ], "Resource": "", "Condition": { "StringNotEquals": { "aws:PrincipalOrgID": [ "" ] } } } ``` ### Grant Amazon SQS permissions to consumers To receive messages from the Amazon SQS queue, you need to provide the message consumer with the necessary permissions. The following policy statement grants the consumer, which you specify, the required permissions to consume messages from the Amazon SQS queue. When adding the statement to your Amazon SQS policy, make sure to replace ** with the ARN of the IAM runtime role used by the consumer; and **, with the ARN of the IAM role used to deploy the Amazon SQS queue. ``` { "Sid": "AllowConsumersToReceiveFromTheQueue", "Effect": "Allow", "Principal": { "AWS": "" }, "Action": [ "sqs:ChangeMessageVisibility", "sqs:DeleteMessage", "sqs:GetQueueAttributes", "sqs:ReceiveMessage" ], "Resource": "" } ``` To prevent other entities from receiving messages from the Amazon SQS queue, add the `DenyOtherConsumersFromReceiving` statement to the Amazon SQS queue policy. This statement restricts message consumption to the consumer that you specify—allowing no other consumers to have access, even when their identity-permissions would grant them access. Make sure to replace ** and ** with your own information. ``` { "Sid": "DenyOtherConsumersFromReceiving", "Effect": "Deny", "Principal": { "AWS": "*" }, "Action": [ "sqs:ChangeMessageVisibility", "sqs:DeleteMessage", "sqs:ReceiveMessage" ], "Resource": "", "Condition": { "StringNotLike": { "aws:PrincipalARN": "" } } } ``` ### Enforce encryption in transit The following `DenyUnsecureTransport` policy statement enforces the consumers and producers to use secure channels (TLS connections) to send and receive messages from the Amazon SQS queue. Make sure to replace ** with the ARN of the IAM role used to deploy the Amazon SQS queue. ``` { "Sid": "DenyUnsecureTransport", "Effect": "Deny", "Principal": { "AWS": "*" }, "Action": [ "sqs:ReceiveMessage", "sqs:SendMessage" ], "Resource": "", "Condition": { "Bool": { "aws:SecureTransport": "false" } } } ``` ### Restrict message transmission to a specific Amazon SNS topic The following `AllowSNSToSendToTheQueue` policy statement allows the specified Amazon SNS topic to send messages to the Amazon SQS queue. Make sure to replace ** with the ARN of the IAM role used to deploy the Amazon SQS queue; and **, with the Amazon SNS topic ARN. ``` { "Sid": "AllowSNSToSendToTheQueue", "Effect": "Allow", "Principal": { "Service": "sns.amazonaws.com" }, "Action": "sqs:SendMessage", "Resource": "", "Condition": { "ArnLike": { "aws:SourceArn": "" } } } ``` The following `DenyAllProducersExceptSNSFromSending` policy statement prevents other producers from sending messages to the queue. Replace ** and ** with your own information. ``` { "Sid": "DenyAllProducersExceptSNSFromSending", "Effect": "Deny", "Principal": { "AWS": "*" }, "Action": "sqs:SendMessage", "Resource": "", "Condition": { "ArnNotLike": { "aws:SourceArn": "" } } } ``` ### (Optional) Restrict message reception to a specific VPC endpoint To restrict the receipt of messages to only a specific [VPC endpoint](https://aws.amazon.com/about-aws/whats-new/2018/12/amazon-sqs-vpc-endpoints-aws-privatelink/), add the following policy statement to your Amazon SQS queue policy. This statement prevents a message consumer from receiving messages from the queue unless the messages are from the desired VPC endpoint. Replace ** with the ARN of the IAM role used to deploy the Amazon SQS queue; and ** with the ID of the VPC endpoint. ``` { "Sid": "DenyReceivingIfNotThroughVPCE", "Effect": "Deny", "Principal": "*", "Action": [ "sqs:ReceiveMessage" ], "Resource": "", "Condition": { "StringNotEquals": { "aws:sourceVpce": "" } } } ``` ## Amazon SQS policy statements for the dead-letter queue Add the following policy statements, identified by their statement ID, to your DLQ access policy: + `RestrictAdminQueueActions` + `DenyQueueActionsOutsideOrg` + `AllowConsumersToReceiveFromTheQueue` + `DenyOtherConsumersFromReceiving` + `DenyUnsecureTransport` In addition to adding the preceding policy statements to your DLQ access policy, you should also add a statement to restrict message transmission to Amazon SQS queues, as described in the following section. ### Restrict message transmission to Amazon SQS queues To restrict access to only Amazon SQS queues from the same account, add the following `DenyAnyProducersExceptSQS` policy statement to the DLQ queue policy. This statement doesn't limit message transmission to a specific queue because you need to deploy the DLQ before you create the main queue, so you won't know the Amazon SQS ARN when you create the DLQ. If you need to limit access to only one Amazon SQS queue, modify the `aws:SourceArn` in the `Condition` with the ARN of your Amazon SQS source queue when you know it. ``` { "Sid": "DenyAnyProducersExceptSQS", "Effect": "Deny", "Principal": { "AWS": "*" }, "Action": "sqs:SendMessage", "Resource": "", "Condition": { "ArnNotLike": { "aws:SourceArn": "arn:aws:sqs:::*" } } } ``` **Important** The Amazon SQS queue policies defined in this guide don't restrict the `sqs:PurgeQueue` action to a certain IAM role or roles. The `sqs:PurgeQueue` action enables you to delete all messages in the Amazon SQS queue. You can also use this action to make changes to the message format without replacing the Amazon SQS queue. When debugging an application, you can clear the Amazon SQS queue to remove potentially erroneous messages. When testing the application, you can drive a high message volume through the Amazon SQS queue and then purge the queue to start fresh before entering production. The reason for not restricting this action to a certain role is that this role might not be known when deploying the Amazon SQS queue. You will need to add this permission to the role’s identity-based policy to be able to purge the queue. ## Prevent the cross-service confused deputy problem The [confused deputy problem](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html) is a security issue where an entity that doesn't have permission to perform an action can coerce a more privileged entity to perform the action. To prevent this, AWS provides tools that help you protect your account if you provide third parties (known as cross-account) or other AWS services (known as cross-service) access to resources in your account. The policy statements in this section can help you prevent the cross-service confused deputy problem. Cross-service impersonation can occur when one service (the calling service) calls another service (the called service). The calling service can be manipulated to use its permissions to act on another customer's resources in a way it shouldn’t otherwise have permission to access. To help protect against this issue, the resource-based policies defined in this post use the [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn), [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount), and [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principalorgid](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principalorgid) global IAM condition context keys. This limits the permissions that a service has to a specific resource, a specific account, or a specific organization in AWS Organizations. ## Use IAM Access Analyzer to review cross-account access You can use [AWS IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) to review your Amazon SQS queue policies and AWS KMS key policies and alert you when an Amazon SQS queue or a AWS KMS key grants access to an external entity. IAM Access Analyzer helps identify [resources](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-resources.html) in your organization and accounts that are shared with an entity outside the zone of trust. This zone of trust can be an AWS account or the organization within AWS Organizations that you specify when you enable IAM Access Analyzer. IAM Access Analyzer identifies resources shared with external principals by using logic-based reasoning to analyze the resource-based policies in your AWS environment. For each instance of a resource shared outside of your zone of trust, Access Analyzer generates a finding. [Findings](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-findings.html) include information about the access and the external principal granted to it. Review the findings to determine whether the access is intended and safe, or whether the access is unintended and a security risk. For any unintended access, review the affected policy and fix it. Refer to this [blog post](https://aws.amazon.com/blogs/aws/identify-unintended-resource-access-with-aws-identity-and-access-management-iam-access-analyzer/) for more information on how AWS IAM Access Analyzer identifies unintended access to your AWS resources. For more information on AWS IAM Access Analyzer, see the [AWS IAM Access Analyzer documentation](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html). # Amazon SQS API permissions: Actions and resource reference When you set up [Access control](security_iam_service-with-iam.md#access-control) and write permissions policies that you can attach to an IAM identity, you can use the following table as a reference. The table lists each Amazon Simple Queue Service action, the corresponding actions for which you can grant permissions to perform the action, and the AWS resource for which you can grant the permissions. Specify the actions in the policy's `Action` field, and the resource value in the policy's `Resource` field. To specify an action, use the `sqs:` prefix followed by the action name (for example, `sqs:CreateQueue`). Currently, Amazon SQS supports the [global condition context keys available in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html). Use the scroll bars to see the rest of the table. **Amazon Simple Queue Service API and required permissions for actions** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-api-permissions-reference.html)