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