AWS S3 Bucket names can include the account ID for easier cross-account management and introducing name entropy via a manageable naming convention
AWS S3 is a shared service that requires all bucket names to be uniquely identifiable across the entire AWS ecosystem, rather than just within individual accounts. This is different from resources such as Amazon EKS clusters, which only need unique names within each AWS account. In S3, any bucket name can be present across any AWS account, as all accounts use the same service.
Due to this shared environment managing buckets becomes an additional challenge when working across multiple AWS accounts, as it adds cognitive and organisational overhead to correlate buckets back to each account. An easy solution to this is to incorporate your AWS account ID into every bucket name. This will provide a simple reference that will indicate where buckets are across your organisation with the least amount of effort to define unique IDs for each account. Each account’s account ID can be easily referenced in IaC variables and via the console providing an easy reference point for new buckets.
Another benefit to including the account ID is the incorporation of entropy into the bucket names making buckets harder to guess. Easily guessable or common bucket names can result in the adoption of activity and resulting charges for that bucket to your account. Because S3 is a centralized service, some bucket names could already be in active use and as a bucket name acts as a namespace for your S3 resources rather than a complete ownership claim, that activity will be charged to your new ownership.
An active example of this is provided in our reference below, where a user created a bucket whose name is in use by open source software. In creating the bucket the user was immediately hit with ownership for all the failed S3 calls from users of the software using the default configuration pointing to their new bucket.
By incorporating your account ID into the bucket name, you introduce a layer of randomness that makes it more difficult for unauthorised users to guess your bucket name. This proactive approach adds a level of obscurity which can protect against targeted or random service attacks like this.
Since bucket names cannot be changed, any adjustments will require the recreation of existing buckets. This retroactive change can be complex and time-consuming, especially if the buckets are in active use requiring updates to associated code and applications.
Implementing this naming strategy for new buckets is much easier. Policy controls can be established to regulate the creation of new buckets in your AWS account and organisation, enforcing compliance with a suitable naming convention. These policies can be easily applied, especially in organisations that have developed proper account access and user management practises.
To effectively address this issue, it’s essential to assess how many of your existing buckets do not meet the new naming criteria. This assessment will help you gauge the scale of the problem you are facing. SkySiege was built to provide this visibility to easily determine and rectify issues like this. Single Cloud Assessments are completed the same day letting you know the state of your resources faster than anyone else:
SkySiege Cloud Security Assessments scan for this issue and provide same-day reports..
Available for individual projects or organisations.
