Prevent Download S3 Bucket
Niki Debruin
I have a ton of files on my S3 bucket and add a bucket policy to make them all public.Now it lists the entire directory (or the first 1000 items) when I browse the root.How can I prevent directory browsing?
Also, setting access levels on the bucket so that 'everyone' cannot read, means that every new file you upload to your bucket will need to have its permission set to 'everyone' before it can be browsed. This isn't practical if you're adding files regularly.
The best solution is to first set access levels on the bucket to deny 'everyone' read access, but then create a bucket policy that allows everyone to read what's inside the bucket. This way, nobody will be able to list the contents of your bucket, but any new files you add will be readable by everyone who has the link to that file.
You can set the ACL on the directory and the individual files independently, do not give read permissions on the directory but allow it for the individual files. There are many tools to help with this including bucket explorer or s3 fox.
how can I prevent the accidental deletion of a bucket? I've enabled versioning to prevent the accidental deletion of objects, but if someone just deletes the whole bucket, my data is down the drain, right? I've read upon the retention policy and locking it, but then I would need to disable object versioning. I could implement the following:
The most robust way to prevent a bucket from being destroyed is to use AWS IAM policy to block the s3:DeleteBucket action on this bucket for whatever user or role Terraform is authenticating as. I would recommend this as the first choice, because it keeps that rule out of band of the configuration that might cause the attempt to delete the object and thus makes it much less likely that someone will accidentally allow deleting the object at the same time as planning to delete it.
is to prevent the destruction of a bucket is it not? This implies that I should be able to tag each bucket with the lifecycle argument. Then apply the conditional statement to the single cloudtrail bucket such that only the cloudtrail bucket associated with nf-logging is destroyed meanwhile the other buckets are preserved.
There is no feature in Terraform/aws_s3_bucket at the moment that allows apply -destroy to skip the deletion of an S3 bucket and finish with a success status. The only features available at the moment will cause either the plan phase or the apply phase to fail. This differs from CloudFormation which has the DeletionPolicy attribute for this purpose.
Maybe you can split the S3 bucket (and related CloudTrail configuration) into a separate Terraform configuration. That would allow you to run apply -destroy on your application without destroying the CloudTrail bucket. In the past I have used the AWS SSM Parameter Store as discussed in The terraform_remote_state Data Source - Terraform by HashiCorp to share the bucket name between the two configurations.
Please note that the AWS Management Console currently neither hides the delete command nor reports on its execution being unsuccessful for buckets with such policies, however, the bucket remains in place ;)
So @Steffen's answer is right but I wanted to put another important note. While the policy will protect against the actual bucket being deleted. It won't protect against the items in the bucket being deleted. Which makes sense, but what you should be aware of is that in the AWS console if you choose delete bucket, it will remove all the items in the bucket, then fail to delete the bucket. So any data you had in the bucket will go away. This isn't obvious at first, and could cause serious issues for someone if they're not aware.
The Amazon S3 Block Public Access feature provides settings for access points, buckets, and accounts tohelp you manage public access to Amazon S3 resources. By default, new buckets, access points, and objectsdon't allow public access. However, users can modify bucket policies, access point policies, orobject permissions to allow public access. S3 Block Public Access settings override thesepolicies and permissions so that you can limit public access to these resources.
With S3 Block Public Access, account administrators and bucket owners can easily set upcentralized controls to limit public access to their Amazon S3 resources that are enforcedregardless of how the resources are created.
When Amazon S3 receives a request to access a bucket or an object, it determines whether thebucket or the bucket owner's account has a block public access setting applied. If therequest was made through an access point, Amazon S3 also checks for block public access settings for theaccess point. If there is an existing block public access setting that prohibits the requestedaccess, Amazon S3 rejects the request.
Amazon S3 Block Public Access provides four settings. These settings are independent and can beused in any combination. Each setting can be applied to an access point, a bucket, or an entireAWS account. If the block public access settings for the access point, bucket, or account differ,then Amazon S3 applies the most restrictive combination of the access point, bucket, and accountsettings.
Public access isgranted to buckets and objects through access control lists (ACLs), access point policies, bucket policies, orall. To help ensure that all of your Amazon S3 access points, buckets, and objects have theirpublic access blocked, we recommend that you turn on all four settings for block publicaccess for your account. These settings block public access for all current and futurebuckets and access points.
Before applying these settings, verify that your applications will workcorrectly without public access. If you require some level of public access to yourbuckets or objects, for example to host a static website as described at Hosting a static website using Amazon S3, you can customize theindividual settings to suit your storage use cases.
S3 Block Public Access provides four settings. You can apply these settings in anycombination to individual access points, buckets, or entire AWS accounts. If you apply asetting to an account, it applies to all buckets and access points that are owned by thataccount. Similarly, if you apply a setting to a bucket, it applies to all access pointsassociated with that bucket.
When this setting is set to TRUE, the specifiedoperations fail (whether made through the REST API, AWS CLI, or AWSSDKs). However, existing policies and ACLs for buckets and objectsare not modified. This setting enables you to protect against publicaccess while allowing you to audit, refine, or otherwise alter theexisting policies and ACLs for your buckets and objects.
Access points don't have ACLs associated with them. If youapply this setting to an access point, it acts as a passthrough to theunderlying bucket. If an access point has this setting enabled, requestsmade through the access point behave as though the underlying bucket hasthis setting enabled, regardless of whether the bucket actuallyhas this setting enabled.
Setting this option to TRUE causes Amazon S3 to ignore allpublic ACLs on a bucket and any objects that it contains. Thissetting enables you to safely block public access granted by ACLswhile still allowing PUT Object calls that include a public ACL (asopposed to BlockPublicAcls, which rejects PUT Objectcalls that include a public ACL). Enabling this setting doesn'taffect the persistence of any existing ACLs and doesn't prevent newpublic ACLs from being set.
Setting this option to TRUE for a bucket causes Amazon S3to reject calls to PUT Bucket policy if the specified bucket policyallows public access. Setting this option to TRUE for abucket also causes Amazon S3 to reject calls to PUT access point policy for allof the bucket's same-account access points if the specified policy allowspublic access.
Setting this option to TRUE for an access point causes Amazon S3to reject calls to PUT access point policy and PUT Bucket policy that aremade through the access point if the specified policy (for either the access pointor the underlying bucket) allows public access.
You can use this setting to allow users to manage access point and bucketpolicies without allowing them to publicly share the bucket or theobjects it contains. Enabling this setting doesn't affect existingaccess point or bucket policies.
To use this setting effectively, we recommend that you applyit at the account level. A bucket policycan allow users to alter a bucket's block public accesssettings. Therefore, users who have permission to change abucket policy could insert a policy that allows them to disablethe block public access settings for the bucket. If this settingis enabled for the entire account, rather than for a specificbucket, Amazon S3 blocks public policies even if a user alters thebucket policy to disable this setting.
Setting this option to TRUE restricts access to anaccess point or bucket with a public policy to only AWS service principalsand authorized users within the bucket owner's account and access pointowner's account. This setting blocks all cross-account access to theaccess point or bucket (except by AWS service principals), while stillallowing users within the account to manage the access point orbucket.
Enabling this setting doesn't affect existing access point or bucketpolicies, except that Amazon S3 blocks public and cross-account accessderived from any public access point or bucket policy, including non-publicdelegation to specific accounts.
Calls to GET Bucket acl and GET Object acl always return the effectivepermissions in place for the specified bucket or object. For example,suppose that a bucket has an ACL that grants public access, but the bucketalso has the IgnorePublicAcls setting enabled. In this case,GET Bucket acl returns an ACL that reflects the access permissions that Amazon S3is enforcing, rather than the actual ACL that is associated with thebucket.
f5d0e4f075