| Did this page help you? Yes No Tell us about it... |
This section describes the elements you can use in a policy and its statements. The
elements are listed here in the general order you use them in a policy. The
Id, Version, and Statement are top-level policy elements; the rest
are statement-level elements. JSON examples are provided.
All elements are optional for the purposes of parsing the policy document itself. The
order of the elements doesn't matter (e.g., the Resource element can come
before the Action element). You're not required to specify any Conditions in
the policy.
The Version is the access policy language version. This is an optional element,
and currently the only allowed value is 2008-10-17.
"Version":"2008-10-17"
The Id is an optional identifier for the
policy. We recommend you use a UUID for the value, or incorporate a UUID as part of the
ID to ensure uniqueness.
![[Important]](images/important.png) | Important |
|---|---|
The AWS service (e.g., SQS or Amazon SNS) implementing the access policy language might require this element and have uniqueness requirements for it. For service-specific information about writing policies, see Special Information for SQS Policies. |
"Id":"cd3ad3d9-2776-4ef1-a904-4c229d1642ee"
The Statement is the main element for a statement. It can include
multiple elements (see the subsequent sections in this guide).
The Statement element contains an array of individual statements. Each
individual statement is a distinct JSON block enclosed in curly brackets { }.
"Statement":[{...},{...},{...}]The Sid (statement ID) is an optional identifier you provide for the
policy statement. Essentially it is just a sub-ID of the policy document's ID.
| Important |
|---|---|
The AWS service (e.g., SQS or Amazon SNS) implementing the access policy language might require this element and have uniqueness requirements for it. For service-specific information about writing policies, see Special Information for SQS Policies. |
"Sid" : "1"
The Effect is a required element that indicates whether you want the
statement to result in an allow or an explicit deny (for more information, see Explicit Deny).
Valid values for Effect are Allow and
Deny.
"Effect":"Allow"
The Principal is the person or persons who
receive or are denied permission according to the policy. You must specify the principal
by using the principal's AWS account ID (e.g., 1234-5678-9012, with or without the
hyphens). You can specify multiple principals, or a wildcard (*) to indicate all
possible users. You can view your account ID by logging in to your AWS account at http://aws.amazon.com and clicking Account Activity.
In JSON, you use "AWS": as a prefix for
the principal's AWS account ID. In the following example, two principals are included in
the statement.
"Principal":[ "AWS": "123456789012", "AWS": "999999999999" ]
The NotPrincipal element is useful if you want to make an exception to a
list of principals. You could use this, for example, if you want to prevent all AWS
accounts except a certain one. The Principal is the person or persons who
receive or are denied permission according to the policy. You must specify the principal
by using the principal's AWS account ID (e.g., 1234-5678-9012, with or without the
hyphens). You can specify multiple principals, or a wildcard (*) to indicate all
possible users. You can view your account ID by logging in to your AWS account at http://aws.amazon.com and clicking Account Activity.
In JSON, you use "AWS": as a prefix for the principal's AWS account ID.
In the following example, two principals are included in the statement.
"Principal":[ "AWS": "123456789012", "AWS": "999999999999" ]
The Action is the specific type or types
of access allowed or denied (for example, read or write). You can specify multiple
values for this element. The values are free-form but must match values the AWS service
expects (for more information, see Special Information for SQS Policies). You can use a wildcard (*) to
give the principal access to all the actions the specific AWS service lets you share
with other developers. For example, Amazon SQS lets you
share only a particular subset of all the possible SQS actions. So, using the
wildcard doesn't give someone full control of the queue; it only gives access to
that particular subset of actions.
"Action":["sqs:SendMessage","sqs:ReceiveMessage"]
The prefix and the action name are case insensitive. For example,
sqs:SendMessage is equivalent to SQS:sendmessage.
The NotAction element is useful if you want to make an exception to a
list of actions. You could use this, for example, if you want your users to be able to
use only the SQS SendMessage.
The following example refers to all actions other than the SQS
SendMessage. You would use this in a policy with
"Effect":"Deny" to keep users from accessing any other actions.
"NotAction":"sqs:SendMessage"
The Resource is the object or objects the policy
covers. The value can include a multi-character match wildcard (*) or a single-character
match wildcard (?) anywhere in the string. The values are free-form, but must follow the
format the AWS service expects. For example, for Amazon SQS, you specify a queue in the
following format: /<account ID of queue owner>/<queue name>. For
example: /987654321012/queue1.
"Resource":"/987654321000/queue2"
This section describes the Condition element and the information you can
use inside the element.
The Condition element is the most complex part of the policy
statement. We refer to it as the condition block, because
although it has a single Condition element, it can contain multiple
conditions, and each condition can contain multiple key-value pairs. The following
figure illustrates this. Unless otherwise specified for a particular key, all keys
can have multiple values.
When creating a condition block, you specify the name of each condition, and at
least one key-value pair for each condition. AWS defines the conditions and keys you
can use (they're listed in the subsequent sections). An example of a condition is
NumericEquals. Let's say you have a fictional resource, and you
want to let John use it only if some particular numeric value
foo equals either A or B, and another numeric value
bar equals C. Then you would create a condition block that
looks like the following figure.
Let's say you also want to restrict John's access to after January 1, 2009. Then
you would add another condition, DateGreaterThan, with a date equal to
January 1, 2009. The condition block would then look like the following
figure.
As illustrated in the following figure, we always apply a logical AND
to the conditions within a condition block, and to the keys within a condition. We
always apply a logical OR to the values for a single key. All
conditions must be met to return an allow or an explicit deny decision. If a
condition isn't met, the result is a default deny.
As mentioned, AWS defines the conditions and keys you can use (for example, one of
the keys is aws:CurrentTime, which lets you restrict access based on
the date and time). The AWS service itself can also define its own service-specific
keys. For a list of available keys, see Available Keys.
For a concrete example that uses real keys, let's say you want to let John access your Amazon SQS queue under the following three conditions:
The time is after 12:00 noon on 8/16/2010
The time is before 3:00 p.m. on 8/16/2010
The request comes from an IP address within the 192.168.176.0/24 range or the 192.168.143.0/24 range
Your condition block has three separate conditions, and all three of them must be met for John to have access to your queue.
The following shows what the condition block looks like in your policy.
"Condition" : {
"DateGreaterThan" : {
"aws:CurrentTime" : "2009-04-16T12:00:00Z"
},
"DateLessThan": {
"aws:CurrentTime" : "2009-04-16T15:00:00Z"
},
"IpAddress" : {
"aws:SourceIp" : ["192.168.176.0/24","192.168.143.0/24"]
}
}AWS provides a set of common keys supported by all AWS services that adopt the access policy language for access control. These keys are:
aws:CurrentTime—For date/time conditions (see Date Conditions)
aws:EpochTime—The date in epoch or UNIX time, for use with date/time conditions (see Date Conditions)
aws:SecureTransport—Boolean representing whether the
request was sent using SSL (see Boolean Conditions)
aws:SourceArn—The Amazon Resource Name (ARN) of the
source (see Amazon Resource Name (ARN))
aws:SourceIp—The requester's IP address, for use with
IP address conditions (see IP Address)
aws:UserAgent—Information about the requester's client
application, for use with string conditions (see String Conditions)
The key names are case insensitive. For example, aws:CurrentTime is
equivalent to AWS:currenttime.
![[Note]](images/note.png) | Note |
|---|---|
If you use |
Each AWS service that uses the access policy language might also provide service-specific keys. For a list of any service-specific keys you can use, see Special Information for SQS Policies.
These are the general types of conditions you can specify:
String
Numeric
Date and time
Boolean
IP address
String conditions let you constrain using string matching rules. The actual data type you use is a string.
| Condition | Description |
|---|---|
|
|
Strict matching Short version: |
|
|
Strict negated matching Short version: |
|
|
Strict matching, ignoring case Short version: |
|
|
Strict negated matching, ignoring case Short version: |
|
|
Loose case-insensitive matching. The values can include a multi-character match wildcard (*) or a single-character match wildcard (?) anywhere in the string. Short version: |
|
|
Negated loose case-insensitive matching. The values can include a multi-character match wildcard (*) or a single-character match wildcard (?) anywhere in the string. Short version: |
Numeric conditions let you constrain using numeric matching rules. You can use both whole integers or decimal numbers. Fractional or irrational syntax is not supported.
| Condition | Description |
|---|---|
|
|
Strict matching Short version: |
|
|
Strict negated matching Short version: |
|
|
"Less than" matching Short version: |
|
|
"Less than or equals" matching Short version: |
|
|
"Greater than" matching Short version: |
|
|
"Greater than or equals" matching Short version: |
Date conditions let you constrain using date and time matching rules. You must
specify all date/time values with one of the W3C implementations of the ISO 8601
date formats (for more information, go to http://www.w3.org/TR/NOTE-datetime). You use these conditions with the
aws:CurrentTime key to restrict access based on
request time.
| Note |
|---|---|
Wildcards are not permitted for date conditions. |
| Condition | Description |
|---|---|
|
|
Strict matching Short version: |
|
|
Strict negated matching Short version: |
|
|
A point in time at which a key stops taking effect Short version: |
|
|
A point in time at which a key stops taking effect Short version: |
|
|
A point in time at which a key starts taking effect Short version: |
|
|
A point in time at which a key starts taking effect Short version: |
| Condition | Description |
|---|---|
|
|
Strict Boolean matching |
IP address conditions let you constrain based on IP address matching rules.
You use these with the aws:SourceIp key. The value must be in the
standard CIDR format (for example, 10.52.176.0/24). For more information, go to
RFC 4632.
| Condition | Description |
|---|---|
|
|
Approval based on the IP address or range |
|
|
Denial based on the IP address or range |
Amazon Resource Name (ARN) conditions let you constrain based on ARN matching rules. The actual data type you use is a string.
| Condition | Description |
|---|---|
|
|
Strict matching for ARN Short version: |
|
|
Strict negated matching for ARN Short version: |
|
|
Loose case-insensitive matching of the ARN. Each of the six colon-delimited components of the ARN is checked separately and each can include a multi-character match wildcard (*) or a single-character match wildcard (?). Short version: |
|
|
Negated loose case-insensitive matching of the ARN. The values can include a multi-character match wildcard (*) or a single-character match wildcard (?) anywhere in the string. Short version: |