Menu
Amazon Simple Queue Service
Developer Guide

Creating Custom Policies Using the Amazon SQS Access Policy Language

If you want to allow Amazon SQS access based only on an AWS account ID and basic permissions (such as for SendMessage or ReceiveMessage), you don't need to write your own policies. You can just use the Amazon SQS AddPermission action.

If you want to explicitly deny or allow access based on more specific conditions (such as the time the request comes in or the IP address of the requester), you need to write your own Amazon SQS policies and upload them to the AWS system using the Amazon SQS SetQueueAttributes action.

Key Concepts

To write your own policies, you must be familiar with JSON and a number of key concepts.

allow

The result of a statement that has effect set to allow.

action

The activity that the principal has permission to perform, typically a request to AWS.

default-deny

The result of a statement that that has no allow or explicit deny settings.

condition

Any restriction or detail about a permission. Typical conditions are related to date and time and IP addresses.

effect

The result that you want the statement of a 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, allow, and explicit deny.

explicit deny

The result of a statement that has 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.

issuer

The user who writes a policy to grant permissions to a resource. The issuer, by definition is always the resource owner. AWS does not 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 and a key.

policy

The document that acts as a container for one or more statements.

Amazon SQS uses the policy to determine whether to grant access to a user for a resource.

principal

The user who receives permission in the policy.

resource

The object that the principal requests access to.

statement

The formal description of a single permission, written in the access policy language as part of a broader policy document.

requester

The user who sends a request for access to a resource.

Architecture

The following figure and table describe the main components that provide access control for your Amazon SQS resources.


						Architectural Overview

1

You, the resource owner.

2

Your resources contained within the AWS service (for example, Amazon SQS queues).

3

Your policies. It is a good practice to have one policy per resource The AWS service itself provides an API you use to upload and manage your policies.

4

Requesters and their incoming requests to the AWS service.

5

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.

Process Workflow

The following figure and table describe the general workflow of access control with the Amazon SQS access policy language.


						Architectural Overview

1

You write an Amazon SQS policy for your queue.

2

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.

3

Someone sends a request to use your Amazon SQS queue.

4

Amazon SQS examines all available Amazon SQS policies and determines which ones are applicable.

5

Amazon SQS evaluates the policies and determines whether the requester is allowed to use your queue.

6

Based on the policy evaluation result, Amazon SQS either returns an Access denied error to the requester or continues to process the request.

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 overrides any default-deny.

  • An explicit deny overrides any allow.

  • The order in which the policies are evaluated is not important.

The following figure and table describe in detail how Amazon SQS evaluates decisions about access permissions.


						Architectural Overview

1

The decision starts with a default-deny.

2

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 is not important

3

The enforcement code looks for an explicit deny instruction that could apply to the request. If it finds even one, the enforcement code returns a decision of deny and the process finishes.

4

If no explicit deny instruction is found, the enforcement code looks for any allow instructions that could 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).

5

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

If an Amazon SQS policy doesn't directly apply to a request, the request results in a 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 or an explicit deny based on the value of the 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.


						Architectural Overview

If a user sends a request from the U.S., the condition is met (the request is not 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.


						Architectural Overview

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.


						Overriding

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.

Amazon SQS Access Policy Examples

The following are examples of typical Amazon SQS access control policies.

Example 1: Give Permission to One Account

The following example Amazon SQS policy gives AWS account 1111-2222-3333 permission to send to and receive from queue2 owned by AWS account 4444-5555-6666.

Copy
{ "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 SetQueueAttributes action because the AddPermission action doesn't permit specifying a time restriction when granting access to a queue.

Copy
{ "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" example: it restricts access to before June 30, 2009 at 12 noon (UTC), it restricts access to the IP range 10.52.176.0/24. It is necessary to write this policy and to upload it to Amazon SQS using the SetQueueAttributes action because the AddPermission action doesn't permit specifying an IP address restriction when granting access to a queue.

Copy
{ "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":"10.52.176.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" 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 SetQueueAttributes action because the AddPermission action doesn't permit deny access to a queue (it allows only granting access to a queue).

Copy
{ "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" } ] }