Skip to content

Bucket Policies

What is a Bucket Policy?

Bucket policies define access permissions for an S3 bucket and its objects. These policies allow you to specify:

  • Who may access the bucket.
  • What actions they may perform.
  • On what resource.
  • Under what conditions.

Bucket policies are attached to a bucket. There can only be one bucket policy applied to an S3 bucket at any given time, but a bucket policy can contain multiple statements.

Key Components of a Bucket Policy

  • Version: specifies the policy language version. 2012-10-17 is the latest and most widely used version.
  • Statement: defines the specific rules in the policy. Each statement includes:
    • Sid or Statement ID: Optional identifier for the statement. It is recommended to give a human readable and meaningful name.
    • Effect: Specifies whether the statement allows or denies the action. Possible values: Allow, Deny.
    • Principal: Identifies who the statement applies to.
      • \* for all users.
      • arn:aws:iam:::user/<user_uid> for a specific user.
    • Action: Defines the actions allowed or denied. For example: s3:GetObject or s3:PutObject.
    • Resource: Specifies the bucket or objects the policy applies to. Use the following format:
      • arn:aws:s3:::<bucket_name>[/<optional_prefix>]
    • Condition (optional): Adds constraints, such as IP restrictions or object prefixes.

Important

While SCS3 buckets do not support a traditional file system hierarchy, you can simulate a folder structure using object keys that include slashes /. This is useful for defining Resource and Condition components to target specific prefixes to manage permissions for subsets of objects.

Example Bucket Policies

Anonymous Access

This policy enables anonymous users to download objects from the example bucket.
This could be used for hosting a static website for example.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PublicReadAccess",
      "Effect": "Allow",
      "Principal": "*",
      "Action": ["s3:GetObject"],
      "Resource": ["arn:aws:s3:::example/*"]
    }
  ]
}

More Complex Access

The below policy contains 3 statements. Here is a breakdown of what it does:

  • Anonymous Read:
    • Grants anonymous users read and list access to objects under the anonymous/ prefix.
  • Read/Write for a User:
    • Assuming an SCS3 user with ID 6b283d31-4df1-4ad5-a893-57ece142e2a4.
    • Grants this user read, write, and delete permissions for objects under the rw/ prefix.
  • Restricted Listing for a User:
    • Assuming an SCS3 user with ID 6b283d31-4df1-4ad5-a893-57ece142e2a4.
    • Allows this user to list objects in the bucket but only for keys starting with the rw/ prefix.
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Anonymous read on versioning-testing/anonymous",
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": [
        "s3:ListBucket",
        "s3:GetObject"
      ],
      "Resource": [
        "arn:aws:s3:::versioning-testing/anonymous/*"
      ]
    },
    {
      "Sid": "Allow RW objects on bucket/rw/*",
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam:::user/6b283d31-4df1-4ad5-a893-57ece142e2a4"
        ]
      },
      "Action": [
        "s3:PutObject",
        "s3:DeleteObject",
        "s3:GetObject"
      ],
      "Resource": "arn:aws:s3:::versioning-testing/rw/*"
    },
    {
      "Sid": "Allow listing on bucket/rw/*",
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam:::user/6b283d31-4df1-4ad5-a893-57ece142e2a4"
        ]
      },
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::versioning-testing",
      "Condition": {
        "StringLike": {
          "s3:prefix": "rw/*"
        }
      }
    }
  ]
}

Note

The ID of the user may be retrieved from the Switch Cloud Portal. See SCP S3 Service for more information.

IP-based Access Restriction

This policy allows anonymous users to list and download objects from the example bucket only if their public IP address is within the specified ranges. This can be used, for example, to allow access from a corporate network or a specific VPN gateway. Any requests from outside the defined IP ranges will receive an Access Denied response.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AnonymousAccessFromSpecificIPRanges",
      "Effect": "Allow",
      "Principal": "*",
      "Action": [
        "s3:ListBucket",
        "s3:GetObject"
      ],
      "Resource": [
        "arn:aws:s3:::example/*",
        "arn:aws:s3:::example"
      ],
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": [
            "203.0.113.0/24",
            "2001:db8::/32"
          ]
        }
      }
    }
  ]
}

Supported Policies

SCS3 implements many policies however it is not 100% compatible with AWS S3. To check what is supported, refer to limitations.

Manage Bucket Policies

To apply a bucket policy to an S3 bucket, use the following command (no output if successful):

aws s3api put-bucket-policy --bucket <bucket-name> --policy file://<policy-file>.json

To check the policy currently applied to an S3 bucket, use the following command:

 aws s3api get-bucket-policy --bucket <bucket-name>

If the bucket has configured no policy you will get:

Example output 
An error occurred (NoSuchBucketPolicy) when calling the GetBucketPolicy operation: The bucket policy does not exist

To remove a bucket policy, use the following command (no output if successful):

aws s3api delete-bucket-policy --bucket <bucket-name>

Best Practices for Bucket Policies

  • Follow the Principle of Least Privilege: Grant only the permissions necessary for a specific task.

  • Restrict Anonymous Access: Use Principal: "*" sparingly and only when necessary, such as for public read access to a static website. Validate that no sensitive data is exposed. Do not allow anonymous uploads. Ensure all uploads require proper authentication and authorization to prevent unauthorized data uploads.

  • Use Conditions for Fine-Grained Control: Apply conditions like s3:prefix to limit access to specific objects or folders.

  • Test Policies Before Deployment: Validate JSON syntax using a JSON linter. Apply policies to a test bucket to confirm they behave as intended before using them in production.

  • Regularly Review and Update Policies: Periodically audit bucket policies to ensure they comply with organizational security standards and remove obsolete rules.

  • Only Use Policies When Needed: It is often better to use multiple buckets than grant access to different users based on prefix through policies.