All Amazon S3 buckets and the objects in them are private by default, but there are various identity and S3 access control options available for users to adjust permissions for objects within each S3 bucket. It’s important for any enterprise organization planning on using Amazon S3 storage to have a good understanding of these options to effectively manage permission to their Amazon S3 resources.
This article takes a look at managing access to Amazon S3 objects and how to effectively store multiple objects with different permissions within the same S3 bucket.
Use the links below to jump down to the sections on:
When it comes to maintaining access and security control to resources, most public cloud platforms operate on a shared responsibility model between the customers and the cloud provider. In the case of AWS cloud, AWS is responsible for maintaining the underlying cloud infrastructure security while the customers are responsible for managing and maintaining the access to the customer data stored on the cloud infrastructure.
With an abstracted service such as Amazon S3, customers are required to manage all aspects of the data they store there, including the access permissions to the objects stored within Amazon S3 buckets and their ongoing management and operational tasks. Amazon S3 provides various options to control the access to the customer data stored on S3. One way to do this is via permissions and various IAM roles.
There are a number of different S3 access configuration options available within Amazon S3 that are important to familiarize before we can look into the details.
Amazon S3 Access Policy: An Amazon S3 access policy describes who has access to what and at what level of permission in Amazon S3. An access policy is typically attached to S3 resources (such as buckets and objects, which are known as bucket policies) or to an AWS user (known as user policies). Both of these policies are expressed using a JSON file and can be used to permit all of the available actions in Amazon S3.
Bucket policy: A resource-based policy that can be used to grant permissions to S3 buckets and the objects inside them. The bucket owner can create and associate a bucket policy with an S3 bucket, and the permissions defined in the bucket policy are then applied to all the S3 objects owned by the bucket owner inside the bucket (objects not owned by the bucket owner do not inherit these permissions from a bucket policy).
An access policy typically contains the following elements:
All Amazon S3 resources and their related sub-resources are private by default and only accessible by the AWS account that created them. Access to S3 objects must be explicitly granted to other users for wider access.
There are multiple ways to define access to the objects stored inside Amazon S3 buckets. These can be leveraged by customers to store multiple S3 objects with different permissions inside the same S3 bucket.
A bucket policy can be leveraged by the bucket owner to grant permissions to the bucket and the objects inside the bucket that are owned by the bucket owner. A bucket policy can be created using the AWS Policy Generator easily.
See the below example of an Amazon bucket policy that defines the access permission to the AWS bucket named “chan-s3-eu-west-2-bucket-01.” The bucket policy has been configured with multiple statements:
Statement1: Grants “allow” access (effect) to all S3 operations (actions) to all user principles. This is applicable to all S3 objects (resource) inside the bucket whose names end with “.jpg.”
Statement2: Grants “deny” access to all S3 operations to all user principles. This is applicable to all S3 objects inside the bucket whose names end with “.pdf.”
This bucket policy therefore enables different access permissions to different objects within the same S3 bucket, providing S3 users with a great deal of flexibility when storing various objects in the same bucket.
Bucket policies are used specifically to manage permissions between different AWS accounts and their users. Refer to the AWS documentation for additional bucket policy examples here.
With AWS IAM, multiple users can be created within the same AWS account and user policies can be associated with these accounts to manage their S3 access permissions for objects.
Refer to the example below using the same S3 bucket where a specific user policy has been defined to achieve customized permissions to a specific development user account (development-user-chan-s3-eu-west-2-bucket-01).
This user policy can be associated with a specific user as illustrated below. In this example, it has been associated with an AWS IAM user named “development-user-chan-s3-eu-west-2-bucket-01” which will grant the above customized permissions and restrictions to just this user.
In addition to bucket and user policies, you can also leverage Access Control Lists (ACLs) in order to control access to objects in an S3 bucket. Both S3 buckets and objects have ACLs that can be leveraged to grant access to S3 objects.
It should be noted however that AWS recommends the use of access policies over ACLs where possible due to the scalability and manageability associated with the former. Unless there is an unusual requirement where customers need to control access to specific objects individually, it is recommended to disable the ACLs where possible.
Access controls are defined explicitly in the object ACL. This method provides a specific and a granular way to maintain access permissions at the individual S3-object level inside a bucket. Object ACLs can be leveraged when different access permissions (other than what’s defined via bucket or user policies) need to be defined for each object within the same S3 bucket. In addition, object ACLs can also be leveraged for unique scenarios such as when managing access permissions to S3 objects that are not owned by the bucket owner (therefore not inherited via bucket policies).
See the below example where, using the same Amazon S3 bucket as above, a specific object (titled “vpn-05072cb0f5bd00442.txt”) has been explicitly given public read access using the object’s ACL.
Access controls can also be defined explicitly at the Amazon S3 bucket level. See the below example of how the same S3 bucket has been given the “Read” access to everyone for public access to the bucket.
However, bucket ACL’s are only recommended to be used for granting permission to specific AWS services (such as CloudFront) rather than user permissions.
As illustrated above, Amazon S3 objects can be permissioned using a combination of S3 bucket policies, user policies and object ACLs to achieve a complex mix of different access permissions in the same bucket. Enterprise organizations with complex, advanced S3 storage use cases can leverage this flexibility offered by Amazon S3 in order to meet their complex object storage requirements.
For even more security and other benefits and uses for AWS storage, consider the capabilities you can gain with NetApp Cloud Volumes ONTAP as a data management layer for your AWS account. Learn more about Enterprise Data Security for Cloud File Sharing with Cloud Volumes ONTAP, storage efficiencies to lower storage costs, automatic tiering of EBS block storage to S3, hybrid and multicloud data mobility.