Menu
I keep seeing this in bucket policy examples and I dont know what is it
"Condition": {
"StringEquals": {
"s3:x-amz-acl": "bucket-owner-full-control"
}
Does this mean the user has to add a header "s3:x-amz-acl" that has value "bucket-owner-full-control"? Is this enforcing an actual acl or is this arbitrary? Can it be any header and string or is there significants to s3:x-amz-acl and bucket-owner-full-control?
211
When you create a bucket or an object, Amazon S3 creates a default ACL that grants the resource owner full control over the resource. This is shown in the following sample bucket ACL (the default object ACL has the same structure):
Amazon S3 access control lists (ACLs) enable you to manage access to buckets and objects. Each bucket and object has an ACL attached to it as a subresource. It defines which AWS accounts or groups are granted access and the type of access.
Access control lists (ACLs) are one of the resource-based access policy options (see Overview of managing access) that you can use to manage access to your buckets and objects. You can use ACLs to grant basic read/write permissions to other AWS accounts. There are limits to managing permissions using ACLs.
As shown in the preceding table, an ACL allows only a finite set of permissions, compared to the number of permissions you can set in an access policy (see Amazon S3 actions ). Each of these permissions allows one or more Amazon S3 operations.
This policy snippet requires that the request contain the specification of a canned ACL, using the header x-amz-acl (case-insensitive), with the value bucket-owner-full-control.
A constraint on this condition normally is used to ensure that the owner of the object (which is always the uploading user, not necessarily the owner of the bucket) can't create an object that the bucket owner is unable to read ("full control" is an unfortunate misnomer, because the bucket owner can already delete foreign objects, and despite this cannot further delegate permissions on the object).
But it isn't arbitrary.
Specifically: s3:x-amz-acl is an S3-specific IAM policy condition key that happens to be named exactly the same as the header that it matches.
It is not an arbitrary header match, even though such a capability might be handy at times. Most other HTTP headers are not subject to policy conditions, and you can't use, e.g. an s3:x-random-http-header condition.
There are global condition keys like aws:SecureTransport that can be used to deny a request that isn't using HTTPS, and aws:UserAgent that evaluates against the HTTP User-Agent header, but note the documented caveat that this "should not be used to prevent unauthorized parties from making direct AWS requests" because it is easily forged by the user agent. Otherwise there are not a lot of options for allowing/denying requests related to headers.
Unlike the condition key, the value string bucket-owner-full-control is not actually validated within the policy, since it's just a string, but if you don't specify a valid value, it will simply never match.
128
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
