Bucket policy examples using condition keys
You can use access policy language to specify conditions when you grant permissions. You
can use the optional Condition element, or Condition block, to
specify conditions for when a policy is in effect.
For policies that use Amazon S3 condition keys for object and bucket operations, see the following examples. For more information about condition keys, see Policy condition keys for Amazon S3. For a complete list of Amazon S3 actions, condition keys, and resources that you can specify in policies, see Actions, resources, and condition keys for Amazon S3 in the Service Authorization Reference.
For more information about the permissions to S3 API operations by S3 resource types, see Required permissions for Amazon S3 API operations.
Examples: Amazon S3 condition keys for object operations
The following examples show how you can use Amazon S3‐specific condition keys for object operations. For a complete list of Amazon S3 actions, condition keys, and resources that you can specify in policies, see Actions, resources, and condition keys for Amazon S3 in the Service Authorization Reference.
For more information about the permissions to S3 API operations by S3 resource types, see Required permissions for Amazon S3 API operations.
Several of the example policies show how you can use conditions keys with PUT Object operations. PUT Object operations allow access control list (ACL)–specific headers that you can use to grant ACL-based permissions. By using these condition keys, you can set a condition to require specific access permissions when the user uploads an object. You can also grant ACL–based permissions with the PutObjectAcl operation. For more information, see PutObjectAcl in the Amazon S3 Amazon Simple Storage Service API Reference. For more information about ACLs, see Access control list (ACL) overview.
Topics
Example 2: Granting s3:PutObject permission to copy objects with a restriction on the copy source
Example 3: Granting access to a specific version of an object
Example 5: Restricting access by the AWS account ID of the bucket owner
Example 7: Excluding certain principals from a Deny statement
Example 8: Enforcing clients to conditionally upload objects based on object key names or ETags
Example 1: Granting s3:PutObject
permission requiring that objects be stored using server-side encryption
Suppose that Account A owns a bucket. The account administrator wants to grant Jane, a
user in Account A, permission to upload objects with the condition that Jane always
request server-side encryption with Amazon S3 managed keys (SSE-S3). The Account A
administrator can specify this requirement by using the
s3:x-amz-server-side-encryption condition key as shown. The
key-value pair in the following Condition block specifies the
s3:x-amz-server-side-encryption condition key and SSE-S3
(AES256) as the encryption type:
"Condition": { "StringNotEquals": { "s3:x-amz-server-side-encryption": "AES256" }}
When testing this permission by using the AWS CLI, you must add the required encryption by
using the --server-side-encryption parameter, as shown in the following
example. To use this example command, replace the with your own information. user input
placeholders
aws s3api put-object --bucketamzn-s3-demo-bucket--keyHappyFace.jpg--bodyc:\HappyFace.jpg--server-side-encryption "AES256" --profileAccountAadmin
Example 2: Granting s3:PutObject
permission to copy objects with a restriction on the copy source
In a PUT object request, when you specify a source object, the request is a
copy operation (see CopyObject). Accordingly, the bucket owner can grant
a user permission to copy objects with restrictions on the source, for
example:
-
Allow copying objects only from the specified source bucket (for example,
).amzn-s3-demo-source-bucket -
Allow copying objects from the specified source bucket and only the objects whose key name prefix starts with as specific prefix, such as
(for example,public/).amzn-s3-demo-source-bucket/public/* -
Allow copying only a specific object from the source bucket (for example,
).amzn-s3-demo-source-bucket/example.jpg
The following bucket policy grants a user ()
the Daves3:PutObject permission. This policy allows him to copy objects
only with a condition that the request include the s3:x-amz-copy-source
header and that the header value specify the
/
key name prefix. To use this example policy, replace the amzn-s3-demo-source-bucket/public/* with your own information.user
input placeholders
Test the policy with the AWS CLI
You can test the permission using the AWS CLI copy-object
command. You specify the source by adding the --copy-source
parameter; the key name prefix must match the prefix allowed in the
policy. You need to provide the user Dave credentials using the
--profile parameter. For more information about setting
up the AWS CLI, see Developing with Amazon S3 using the AWS CLI in the Amazon S3 API Reference.
aws s3api copy-object --bucket--keyamzn-s3-demo-source-bucketHappyFace.jpg--copy-sourceamzn-s3-demo-source-bucket/public/PublicHappyFace1.jpg--profileAccountADave
Give permission to copy only a specific object
The preceding policy uses the StringNotLike condition. To grant permission
to copy only a specific object, you must change the condition from
StringNotLike to StringNotEquals and then specify
the exact object key, as shown in the following example. To use this example
command, replace the with your own information.user input
placeholders
"Condition": { "StringNotEquals": { "s3:x-amz-copy-source": "amzn-s3-demo-source-bucket/public/PublicHappyFace1.jpg" } }
Example 3: Granting access to a specific version of an object
Suppose that Account A owns a versioning-enabled bucket. The bucket has several versions
of the object. The
Account A administrator now wants to grant the user
HappyFace.jpg permission to get only a
specific version of the object. The account administrator can accomplish this by
granting the user Dave the
Daves3:GetObjectVersion permission conditionally, as shown in the
following example. The key-value pair in the Condition block specifies
the s3:VersionId condition key. In this case, to retrieve the object
from the specified versioning-enabled bucket,
needs to know the exact object
version ID. To use this example policy, replace the Dave with your own information.user input
placeholders
For more information, see GetObject in the Amazon Simple Storage Service API Reference.
Test the policy with the AWS CLI
You can test the permissions in this policy by using the AWS CLI get-object
command with the --version-id parameter to identify the specific
object version to retrieve. The command retrieves the specified version of the
object and saves it to the
file.OutputFile.jpg
aws s3api get-object --bucket--keyamzn-s3-demo-bucketHappyFace.jpgOutputFile.jpg--version-idAaaHbAQitwiL_h47_44lRO2DDfLlBO5e--profileAccountADave
Example 4: Granting permissions based on object tags
For examples of how to use object tagging condition keys with Amazon S3 operations, see Tagging and access control policies.
Example 5: Restricting access by the AWS account ID of the bucket owner
You can use either the aws:ResourceAccount or
s3:ResourceAccount condition key to write IAM or virtual private
cloud (VPC) endpoint policies that restrict user, role, or application access to the
Amazon S3 buckets that are owned by a specific AWS account ID. You can use these
condition keys to restrict clients within your VPC from accessing buckets that you
don't own.
However, be aware that some AWS services rely on access to AWS managed buckets.
Therefore, using the aws:ResourceAccount or
s3:ResourceAccount key in your IAM policy might also affect
access to these resources. For more information, see the following resources:
-
Restrict access to buckets in a specified AWS account in the AWS PrivateLink Guide
-
Restrict access to buckets that Amazon ECR uses in the Amazon ECR Guide
-
Provide required access to Systems Manager for AWS managed Amazon S3 buckets in the AWS Systems Manager Guide
For more information about the aws:ResourceAccount and
s3:ResourceAccount condition keys and examples that show how to use
them, see Limit access to Amazon S3 buckets owned by specific AWS accounts
Example 6: Requiring a minimum TLS version
You can use the s3:TlsVersion condition key to write IAM, virtual private
cloud endpoint (VPCE), or bucket policies that restrict user or application access
to Amazon S3 buckets based on the TLS version that's used by the client. You can use this
condition key to write policies that require a minimum TLS version.
Note
When AWS services make calls to other AWS services on your behalf (service-to-service calls), certain network-specific authorization context is redacted, including s3:TlsVersion, aws:SecureTransport, aws:SourceIp, and aws:VpcSourceIp. If your policy uses these condition keys with Deny statements, AWS service principals might be unintentionally blocked. To allow AWS services to work properly while maintaining your security requirements, exclude service principals from your Deny statements by adding the aws:PrincipalIsAWSService condition key with a value of false. For example:
{ "Effect": "Deny", "Action": "s3:*", "Resource": "*", "Condition": { "Bool": { "aws:SecureTransport": "false", "aws:PrincipalIsAWSService": "false" } } }
This policy denies access to S3 operations when HTTPS is not used (aws:SecureTransport is false), but only for non-AWS service principals. This ensures your conditional restrictions apply to all principals except AWS service principals.
The following example bucket policy denies
PutObject requests by clients that have a TLS version earlier than
1.2, for example, 1.1 or 1.0. To use this example policy, replace the
with
your own information.user input placeholders
The following example bucket policy allows
PutObject requests by clients that have a TLS version later than
1.1, for example, 1.2, 1.3, or later:
Example 7: Excluding certain
principals from a Deny statement
The following bucket policy denies s3:GetObject access to the
, except to principals with the account number
amzn-s3-demo-bucket. To use this
example policy, replace the 123456789012 with your own information.user input
placeholders
Example 8: Enforcing clients to conditionally upload objects based on object key names or ETags
With conditional writes, you can add an additional header to your WRITE
requests in order to specify preconditions for your S3 operation. This header
specifies a condition that, if not met, will result in the S3 operation failing. For
example you can prevent overwrites of existing data by validating there is no object
with the same key name already in your bucket during object upload. You can
alternatively check an object's entity tag (ETag) in Amazon S3 before writing an
object.
For bucket policy examples that use conditions in a bucket policy to enforce conditional writes, see Enforce conditional writes on Amazon S3 buckets.
Examples: Amazon S3 condition keys for bucket operations
The following example policies show how you can use Amazon S3 specific condition keys for bucket operations.
Topics
Example 1: Granting s3:GetObject
permission with a condition on an IP address
You can give authenticated users permission to use the s3:GetObject
action if the request originates from a specific range of IP addresses (for example,
), unless the IP address is
one that you want to exclude (for example,
192.0.2.*). In the
192.0.2.188Condition block, IpAddress and
NotIpAddress are conditions, and each condition is provided a
key-value pair for evaluation. Both of the key-value pairs in this example use the
aws:SourceIp AWS wide key. To use this example policy, replace
the with your own
information.user input placeholders
Note
The IPAddress and NotIpAddress key values specified
in the Condition block use CIDR notation, as described in RFC 4632.
For more information, see http://www.rfc-editor.org/rfc/rfc4632.txt
You can also use other AWS‐wide condition keys in Amazon S3 policies. For
example, you can specify the aws:SourceVpce and
aws:SourceVpc condition keys in bucket policies for VPC
endpoints. For specific examples, see Controlling access from VPC
endpoints with bucket policies.
Note
For some AWS global condition keys, only certain resource types are supported. Therefore, check whether Amazon S3 supports the global condition key and resource type that you want to use, or if you'll need to use an Amazon S3 specific condition key instead. For a complete list of supported resource types and condition keys for Amazon S3, see Actions, resources, and condition keys for Amazon S3 in the Service Authorization Reference.
For more information about the permissions to S3 API operations by S3 resource types, see Required permissions for Amazon S3 API operations.
Example 2: Getting a list of objects in a bucket with a specific prefix
You can use the s3:prefix condition key to limit the response of the ListObjectsV2 API operation to key names with a
specific prefix. If you are the bucket owner, you can use this condition key to
restrict a user to list the contents of a specific prefix in the bucket. The
s3:prefix condition key is useful if the objects in the bucket are
organized by key name prefixes.
The Amazon S3 console uses key name prefixes to show a folder concept. Only the console
supports the concept of folders; the Amazon S3 API supports only buckets and objects. For
example, if you have two objects with the key names
and
public/object1.jpg, the
console shows the objects under the
public/object2.jpg folder. In the Amazon S3 API,
these are objects with prefixes, not objects in folders. For more information about
using prefixes and delimiters to filter access permissions, see Controlling access to a bucket with user policies. public
In the following scenario, the bucket owner and the parent account to which the user
belongs are the same. So the bucket owner can use either a bucket policy or a user
policy to grant access. For more information about other condition keys that you can
use with the ListObjectsV2 API operation, see ListObjectsV2.
Note
If the bucket is versioning-enabled, to list the objects in the bucket, you
must grant the s3:ListBucketVersions permission in the following
policies, instead of the s3:ListBucket permission. The
s3:ListBucketVersions permission also supports the
s3:prefix condition key.
User policy
The following user policy grants the s3:ListBucket permission (see ListObjectsV2) with a Condition
statement that requires the user to specify a prefix in the request with a value
of . To use this example policy,
replace the projects with
your own information.user input placeholders
The Condition statement restricts the user to listing only object keys that
have the prefix. The added explicit
projectsDeny statement denies the user from listing keys with any other
prefix, no matter what other permissions the user might have. For example, it's
possible that the user could get permission to list object keys without any
restriction, either through updates to the preceding user policy or through a bucket
policy. Because explicit Deny statements always override
Allow statements, if the user tries to list keys other than those
that have the prefix, the request
is denied. projects
Bucket policy
If you add the Principal element to the above user policy, identifying the
user, you now have a bucket policy, as shown in the following example. To use
this example policy, replace the with your own information.user input
placeholders
Test the policy with the AWS CLI
You can test the policy using the following list-object
AWS CLI command. In the command, you provide user credentials using the
--profile parameter. For more information about setting
up and using the AWS CLI, see Developing with Amazon S3 using the AWS CLI in the Amazon S3 API Reference.
aws s3api list-objects --bucket--prefixamzn-s3-demo-bucketprojects--profileAccountA
Example 3: Setting the maximum number of keys
You can use the s3:max-keys condition key to set the maximum number of keys
that a requester can return in a ListObjectsV2 or ListObjectVersions request. By default, these API
operations return up to 1,000 keys. For a list of numeric condition operators that
you can use with s3:max-keys and accompanying examples, see Numeric Condition Operators in the
IAM User Guide.