¶ Control Access via Policies
¶ Identity-based policies
- Attached to the IAM identity requiring access,
- Using IAM permission policies, either in-line or managed, they can then be associated to the user, a group that the user belongs to, or via a role that the user has permission to assume.
- Identity-based policies define the resource in the policy.
You can of course use conditions within your policies to manage and refine access to your resources even further. For example, in this policy, the identity would be able to perform the actions CreateBucket, DeleteBucket, and PutObject on the s3deepdive bucket on the condition that their source IP address was within the range of the CIDR block 10.1.0.0/16.
¶ Resource-based policies
- Differ in the fact that the policy is associated with a resource rather than the identity.
- come in the form of Access Control Lists and bucket policies.
- Need to define within the policy who will be allowed or denied access.
- This is managed differently depending on if you're using bucket policies or Access Control Lists.
¶ Bucket Policy
- A bucket policy is written in JSON and is directly attached to your bucket as another means of granting and restricting access control. And by default, when you create a bucket, no bucket policy exists.
- You must specify a principle element, which defines the principal who is associated with the action and effect defined in the statement.
Resoruce Base policy needs principal, identity based does not.
¶ When to use IAM vs Bucket policies
- You can use both IAM policies and bucket policies to control access.
- They are not mutually exclusive.
- They can both be used together to control access.
¶ S3 Access Control List (ACL)
-
resource-based access control method.
-
allow you to control access to buckets in addition to specific objects within a bucket by groupings and AWS accounts.
-
One advantage of being able to use ACLs is that you can set different permissions per object.
-
ACLs do not follow the same JSON format as policies defined by IAM and bucket policies.
-
ACLs are far less granular, and different permissions can be applied depending if you are applying an ACL at the bucket level or the object level.
-
Due to the basic structure of an ACL, it is not possible to implicitly deny access using ACLs.
-
ACLs can't implement conditional elements
-
You can specify different permissions for different predefined S3 groups defined by the Grantee column.
-
Permissions are based on the grantee of which there are four:
- Bucket Owner
- Everyone (Public Access)
- Authenticated User group (anyone with an AWS account)
- S3 log delivery group
-
a Deny always takes precedence over an Allow
¶ Managing Public Access
- By default, all public access to S3 buckets is blocked.
¶ Options to allow access
¶ Block public access to buckets and objects granted through new access controllers
¶ Block public access to buckets and objects granted through any access controllers
¶ Block public access to buckets and objects granted through new public bucket or access point policies
¶ Block public and cross account access to buckets and objects, through any public bucket or access point policy
¶ CORS (Cross Origin Resource Sharing)
- Allows specific resources on a web page to be requested from a different domain than it's own.
- Allows you to build client-side web applications and then, if required, utilise CORS support to access resources stored in S3.
- CORS configuration can be found in the bucket Permissions tab.
¶ Rules
A match is made when one of the following 3 rules are met:
- The requestor's Origin header matches an entry made in the AllowedOrigins element.
- The method used in the request, for example a POST or DELETE operation is matched in the AllowedMethods element.
- The headers used within the requests Access-Control-Request-Headers header with a preflight request matches a value in the AllowedHeader element.