S3 Security & Bucket Policy

Overview

S3 security operates on two dimensions: user-based (IAM policies) and resource-based (bucket policies, ACLs). Understanding how these interact is critical for the exam. The most common and recommended approach today is using S3 Bucket Policies.

Security Mechanisms

User-Based Security (IAM Policies)

As an IAM user, you can have IAM policies attached to you that define which S3 API calls you're allowed to make. For example, an IAM policy might say "this user can perform s3:GetObject and s3:PutObject on bucket X."

Resource-Based Security

These are policies attached to the S3 resource itself (the bucket or object), rather than to the user:

Encryption

A third layer of security: encrypt objects using encryption keys so even if someone gains access, the data is unreadable without the key.

The Access Decision Rule

An IAM principal (user, role, or service) can access an S3 object if:

   ┌─────────────────────────────────────────────┐
   │  (IAM permissions ALLOW it)                 │
   │           OR                                │
   │  (Resource policy ALLOWS it)                │
   │                                             │
   │           AND                               │
   │                                             │
   │  (There is NO explicit DENY anywhere)       │
   └─────────────────────────────────────────────┘

This means access can be granted through either the IAM policy or the bucket policy — you don't need both. But an explicit deny in either one will always win.

S3 Bucket Policy Deep Dive

Bucket policies are JSON documents and they're the focus of S3 security for the exam. Here's what a typical public-read policy looks like:

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

Breaking Down Each Field

Three Main Use Cases for Bucket Policies

1. Grant public access to the bucket (for static websites)
2. Force encryption at upload (deny unencrypted uploads)
3. Grant cross-account access (allow users from another AWS account)

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

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AccountBCanRead",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::<ACCOUNT_B_ID>:user/<USER_NAME>" },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-shared-bucket/*"
    }
  ]
}

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowUploads",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::<ACCOUNT_B_ID>:user/<USER_NAME>" },
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::my-shared-bucket/*"
    }
  ]
}

Access Scenarios Explained

Scenario 1: Public Access (Website Visitors)

A website visitor on the internet wants to read files from your S3 bucket.

┌──────────────────┐                    ┌──────────────────────────────┐
│  Website Visitor  │──── HTTP GET ────▶│  S3 Bucket                   │
│  (anonymous)      │                   │                              │
│                   │                   │  Bucket Policy:              │
│                   │                   │  Allow * → s3:GetObject      │
│                   │                   │  on arn:aws:s3:::bucket/*    │
└──────────────────┘                    └──────────────────────────────┘

The bucket policy with Principal: "*" allows anyone to read objects. This is how you make a bucket public for hosting a website.

Scenario 2: IAM User in Same Account

An IAM user within your AWS account wants to access S3.

┌──────────────────┐    ┌────────────────────┐    ┌───────────┐
│  IAM User        │───▶│  IAM Policy        │───▶│ S3 Bucket │
│  (your account)  │    │  attached to user   │    │           │
│                  │    │  Allow s3:*         │    │           │
└──────────────────┘    └────────────────────┘    └───────────┘

The IAM policy attached to the user grants S3 permissions. No bucket policy needed — the IAM policy alone is sufficient because the access rule says "IAM permissions allow it OR resource policy allows it."

Scenario 3: EC2 Instance Accessing S3

An EC2 instance needs to read/write to S3 (e.g., to pull application config or store logs).

┌──────────────────┐    ┌────────────────────┐    ┌───────────┐
│  EC2 Instance    │───▶│  IAM Role          │───▶│ S3 Bucket │
│                  │    │  (Instance Profile) │    │           │
│                  │    │  Allow s3:GetObject │    │           │
└──────────────────┘    └────────────────────┘    └───────────┘

Scenario 4: Cross-Account Access

An IAM user in another AWS account wants to access your S3 bucket.

┌──────────────────────┐    ┌──────────────────────────────┐
│  IAM User            │───▶│  S3 Bucket (your account)    │
│  (Account B)         │    │                              │
│                      │    │  Bucket Policy:              │
│                      │    │  Allow Account B user        │
│                      │    │  → s3:GetObject              │
└──────────────────────┘    └──────────────────────────────┘

For cross-account access, you must use a Bucket Policy. The IAM policy in Account B alone is not enough — the bucket in your account needs to explicitly allow the other account.

Block Public Access Settings

This is an extra layer of security invented by AWS specifically to prevent company data leaks. It's a safety net that sits above bucket policies.

┌─────────────────────────────────────────────────┐
│  Block Public Access (ON by default)            │
│  ┌───────────────────────────────────────────┐  │
│  │  Bucket Policy: Allow * → s3:GetObject    │  │
│  │  (This would make it public, BUT...)      │  │
│  └───────────────────────────────────────────┘  │
│                                                 │
│  Block Public Access OVERRIDES the policy!      │
│  Bucket stays PRIVATE even with public policy.  │
└─────────────────────────────────────────────────┘

Hands-On: Making a Bucket Public with Policy Generator

Step 1: Disable Block Public Access

1. Go to your bucket → Permissions tab
2. Under Block public access → click Edit
3. Untick "Block all public access"
4. Type confirm to acknowledge this is a dangerous action
5. Save → Permissions overview now shows "Objects can be public"

Step 2: Create a Bucket Policy Using the Policy Generator

1. Scroll down to Bucket policy → click Edit
2. Click Policy generator (opens AWS Policy Generator tool)
3. Fill in:
   • Policy Type: S3 Bucket Policy
   • Effect: Allow
   • Principal: * (anyone)
   • AWS Service: Amazon S3
   • Actions: GetObject
   • ARN: Copy your bucket ARN from the S3 console, then add /* at the end
     • Example: arn:aws:s3:::stephane-demo-s3-v5/*
4. Click Add Statement → Generate Policy
5. Copy the JSON → paste it into the bucket policy editor
6. Save changes

Step 3: Verify

1. Go to your object (e.g., coffee.jpg)
2. Copy the Object URL (the short public one)
3. Paste it in a new browser tab
4. The image now loads — public access is working

Questions & Answers