S3 Security
User Based
- IAM Policies – what calls should be allowed for a specific IAM’s user
Resources Based (can be account)
- Bucket Policies – bucket wide rules from S3 console. Can allow cross accounts and public access.
- Object Access Control List (ACL)
- Bucket Access Control List
IAM principal can access S3 object if:
- user IAM permissions allow OR resource policy allows
- AND No explicit deny
Bucket Policies
- grant access to bucket
- force objects to be encrypted at upload
- grant access to another account
Bucket setting for public access override policy to prevent data leaks (can be set at account level).
Note: versioning is enabled at bucket level
AWS bucket policies vs resource policies
AWS Bucket Policies and Resource Policies (often referred to in the context of IAM policies and permissions) are both used to define permissions for accessing AWS resources. While they share similarities, they have different scopes and use cases. Here’s a breakdown of their differences:
Bucket Policies (S3 Bucket Policies)
Scope: Bucket policies are specific to Amazon S3 and are used to manage access control to S3 buckets and objects within a bucket.
Policy Type: Bucket policies are resource-based policies. They define permissions directly on an S3 bucket and specify which entities (users, roles, accounts) can perform specific actions (e.g., s3:GetObject, s3:PutObject) on that bucket or objects within it.
Use Cases:
Control access to an entire S3 bucket.
Apply permissions to all objects within the bucket.
You can specify actions that are allowed or denied, as well as conditions (like IP address or VPC).
Example: Granting public read access to objects in a bucket or restricting access to certain IP ranges. Example of a bucket policy allowing public read access to all objects in a bucket: { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::my-bucket-name/*" } ] }
Resource Policies (IAM Resource Policies)
Scope: Resource policies can apply to a broader range of AWS services, not just S3. These policies are typically used to define permissions for a specific resource like an SQS queue, SNS topic, Lambda function, IAM roles, or API Gateway.
Policy Type: Resource policies are also resource-based policies, but they are not exclusive to S3. They define who can access a specific resource and under what conditions.
Use Cases:
Granting permissions to access AWS services like Lambda, SNS, SQS, or KMS.
Defining permissions for a specific resource (like allowing an IAM role to invoke a Lambda function).
Example: Allowing an IAM role to access an SNS topic or giving a Lambda function permission to access an SQS queue. Example of a resource policy for an SNS topic allowing a specific IAM role to publish messages: { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:role/my-role" }, "Action": "sns:Publish", "Resource": "arn:aws:sns:us-east-1:123456789012:my-topic" } ] }
Key Differences:
Service Scope:
Bucket Policies are specific to S3 buckets and objects.
Resource Policies apply to other AWS resources (e.g., SNS, Lambda, SQS, etc.).
Purpose:
Bucket policies are used to control access to S3 buckets and objects.
Resource policies manage access to a broader set of AWS resources.
Attachment:
Bucket policies are directly attached to S3 buckets.
Resource policies are typically attached to the resource they control (e.g., SNS, Lambda, etc.).
Permissions:
Bucket policies are specifically focused on defining access control for S3 resources.
Resource policies apply to permissions for a variety of AWS services, granting access to those specific resources.
In Summary:
- Bucket Policies are a specific type of resource policy used for S3. They are only relevant to S3 and define access control for S3 resources.
- Resource Policies are a broader category that applies to multiple AWS services beyond S3. They control access for resources like Lambda functions, SNS topics, SQS queues, and more.