S3 Bucket Policies

S3 Bucket Policies are JSON-based access policy documents that you attach to an S3 bucket to define permissions for the bucket and its objects. They are a powerful and flexible way to manage access to your S3 resources, allowing you to grant or deny permissions to AWS accounts, IAM users, IAM roles, and even anonymous users.

Key Characteristics of S3 Bucket Policies

1. JSON Format: Bucket policies are written in JSON, following a specific structure that includes elements like Version, Id, Statement, Effect, Principal, Action, Resource, and Condition.

2. Resource-Based Policies: Unlike IAM policies, which are identity-based (attached to users, groups, or roles), bucket policies are resource-based. This means they are directly attached to the S3 bucket itself.

3. Granular Control: You can define very specific permissions, such as:
   

   • Allowing or denying specific S3 actions (e.g.,s3:GetObject,s3:PutObject,s3:DeleteObject,s3:ListBucket).
   • Specifying which principals (users, roles, accounts) can perform these actions.
   • Defining which resources (the entire bucket, specific prefixes, or individual objects) the policy applies to.
   • Adding conditions based on IP addresses, time of day, specific headers, or other request parameters.
   ​

4. Evaluation Logic: When a request comes to S3, AWS evaluates all applicable policies (IAM policies, bucket policies, ACLs) to determine if the request is allowed or denied.

   • An explicit DENY in any policy (IAM or bucket) always overrides an ALLOW.
   • If there is no explicit DENY, an explicit ALLOW in any policy grants permission.
   • By default, all requests are denied unless explicitly allowed.
   
   

Structure of a Bucket Policy

A typical S3 bucket policy statement includes:

• Version: The policy language version (e.g., "2012-10-17").
• Id: An optional identifier for the policy.
• Statement: An array of individual policy statements. Each statement defines a set of permissions.
  • Sid: An optional statement ID for easier identification.
  • Effect: Specifies whether the statement Allows or Denys access.
  • Principal: Defines who is allowed or denied access. This can be:
    • An AWS account ID (e.g., "AWS": "arn:aws:iam::123456789012:root").
    • An IAM user ARN (e.g., "AWS": "arn:aws:iam::123456789012:user/Alice").
    • An IAM role ARN (e.g., "AWS": "arn:aws:iam::123456789012:role/MyRole").
    • "*" for anonymous access (public access).
    • "Federated": "arn:aws:iam::123456789012:saml-provider/MySAMLProvider" for federated users.
  • Action: Specifies the S3 API operations that are allowed or denied (e.g., "s3:GetObject", "s3:PutObject", "s3:ListBucket"). You can use wildcards (e.g., "s3:*") for all S3 actions.
  • Resource: Specifies the S3 resources to which the policy applies. This is typically the bucket ARN or object ARNs.
    • For the bucket itself: "arn:aws:s3:::your-bucket-name"
    • For objects within the bucket: "arn:aws:s3:::your-bucket-name/*" (using a wildcard for all objects)
  • Condition: (Optional) Specifies conditions under which the policy statement is effective (e.g., aws:SourceIp, aws:UserAgent, s3:x-amz-acl). 

Example Bucket Policy: Granting Public Read Access

​{
"Version": "2012-10-17",
"Statement": [
    {
"Sid": "PublicReadGetObject",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::your-bucket-name/*"
    }
  ]
}

Example Bucket Policy: Restricting Access to a Specific IP Address

​{
"Version": "2012-10-17",
"Id": "S3PolicyId1",
"Statement": [
    {
"Sid": "IPAllow",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": "arn:aws:s3:::your-bucket-name/*",
"Condition": {
"NotIpAddress": {
"aws:SourceIp": "203.0.113.0/24"
        }
      }
    }
  ]
}

Best Practices

• Least Privilege: Always grant only the necessary permissions.
• Combine with IAM: Use IAM policies for user-specific permissions and bucket policies for broader, resource-level permissions.
• Block Public Access: AWS recommends using the "Block Public Access" settings at the account or bucket level to prevent unintended public access, especially for sensitive data.
• Test Thoroughly: Always test your policies to ensure they provide the intended access control without inadvertently exposing data or blocking legitimate users.