I've noticed that some of our older S3 buckets have the 'block all public access' setting turned off, even though none of the data there should be publicly accessible. We typically grant access to other teams using cross-account roles or bucket policies. Before I enable this block public access setting, are there any specific checks I should perform to prevent disruptions?
5 Answers
You should check your S3 access logs or CloudTrail logs if they're enabled. That should give you some idea of any access patterns. Switching the access on or off is generally a quick operation, so if your processes allow it, testing in live might be feasible, and then incorporate this into your infrastructure as code setup.
The most straightforward approach, although a bit risky, is to do a trial test in a lower environment. It’s quick and gives you a sense of the impact, but I understand that might not be possible if you don't have a lower environment set up.
Don’t forget to verify if you’re accessing the bucket through CloudFront. In the past, you would need open permissions for that, but with the new origin access control, it’s crucial to check and update your distributions accordingly.
I've been using the IAM Access Analyzer to ensure no public access is inadvertently allowed. That's worked well for me so far!
It might be a good idea to first test the changes with a new bucket to ensure connections work smoothly before making adjustments to the production environment. This way, you can avoid changing permissions on a live bucket, which could cause issues for users.
That's true, but creating a new bucket and having teams migrate can also shift the burden to other services, which isn’t always ideal.
Yeah, I'm not sure if they have a testing environment, but if public access is involved, it's definitely something that you want to address as soon as possible!