Newly created S3 buckets are secure and private by default, but AWS S3 provides features that allows administrators to share buckets with other authenticated and unauthenticated (public) entities. This makes it possible to share a bucket between different applications running in separate AWS accounts, and to use the S3 service to host public information (e.g. a static website).
However, we often see developers relax permissions for a bucket or make bucket access public to try and resolve/troubleshoot a permissions issue. If not immediately remediated, this can lead to a data breach down the road. Given that these types of lapses occur all too frequently, AWS has implemented new features to give organizations more control over the ability to enable public access.
This post looks at the two types of AWS S3 public access blocks and show you how to use Turbot Guardrails to ensure they are automatically enabled across all of your accounts and buckets.
S3 Account Public Access Blocks
Account-level public access blocks have the ability to eliminate public access in both access control lists (ACLs) and in S3 bucket IAM resource policies. You also have the option to block the creation of any new public access and/or to retroactively apply those settings to existing ACLs and bucket policies. This work can be easily accomplished through the console UI for a single account, but retroactively enabling those settings across hundreds of accounts (and making sure they are not turned off) is a job for automation.
S3 Account Public Access Blocks
Bucket-level public access blocks apply protection in broad strokes, but won’t work in use cases where some bucket sharing is necessary. For example, a customer might want to share a bucket between their data lake account and separate accounts that perform compute functions on the data. In these circumstances you can use bucket level access blocks (instead of account level) to allow for some public or cross-account sharing on a bucket-by-bucket basis.
Enabling these public blocks across thousands of buckets, maintaining exception lists and ensuring that the configuration does not drift, is not something that can be done manually, it requires an automated continuous compliance solution.
Get it done with Turbot Guardrails
In Turbot Guardrails, AWS S3 public access block settings are readily available to control your cloud resource configurations. Setting the correct Turbot Guardrails policies can be accomplished with just a few clicks:
AWS S3 Account-Level Public Access Block:
AWS S3 Bucket Public Access Block:
Setting the configuration via the Turbot Guardrails Terraform Provider is just as easy:
After setting these policies, Turbot Guardrails will identify all AWS accounts and S3 buckets that are not enabled for public access block settings, and then handle remediation (i.e. set the configurations).
If you are not yet ready to enforce remediation, you can still assess the impact of this in your environment by setting the value to 'Check: Per Public Access Block > Settings at the Turbot level. In ‘Check’ mode Turbot Guardrails will alarm on accounts and buckets that do not have public blocks in place. After review of the alarms, selectively apply the enforcement settings or create exceptions as desired.
Given that denying public access may not be applicable for all accounts and buckets, make use of Turbot Guardrails policy exceptions and time-based expiration settings features to mark exceptions to the rule or automatically reset a configuration when the exception expires.
Make it happen!
See for yourself how easy it is to manage your public access block settings. A ready-to-run Terraform template is available to enable this configuration from the Turbot Development Kit (TDK). If you need any assistance, let us know in our Slack community #guardrails channel. If you are new to Turbot, connect with us to learn more!