Beitrag von Holger Jakob, Mai 2023

ECS S3 Identity and Access Management (IAM)

As mentioned in my previous post covering how to prevent objects from being accidentally deleted, this one will cover ECS Identity and Access Management (IAM). 


ECS Identity and Access Management is an excellent way to implement granular control on user permissions. It is required for object lock enabled buckets and has led us to start using IAM as the only was to provision users and their access to ECS. Like the blog post mentioned above has shown, it is also an easy way to ensure that users are unable to delete objects if this is required.

What did we struggle with?

Backup ONE provides Managed Services for ECS and in that customer base, as well as our own publicly available systems, we have struggled with the following issues.

  • We treat a tenant in a namespace even if there are several applications used. This requires us to limit access of a user to certain buckets.
  • Applications quite often issue the list all my buckets command to generate a list of buckets to choose from. Some expect buckets to be created already and generate errors if they can’t generate that list. Handy applications like S3 Browsers also want to show a user all the buckets available for example.

The most simple approach would be to create a user and set the permissions using the ECS system policy ECSS3FullAccess. Everything will work just fine except that access is not restricted to the buckets a user should have access to. Check the comments on permissions you may not want to be enabled which would all be enabled when using the ECSS3FullAcdess policy. 

The second approach was to create a user specific policy that limits the resources to the buckets the user should have access to. This achieves the goad to limit access but should this application want to list all buckets, this would fail. 

How to achieve restricted access while being able to list buckets?

One would not believe it, but it took us a while to figure out the way we now implement IAM đŸ˜Š

Having two S3 permission sets in a policy achieves everything that we want to.

  • First specify an S3 permission set and limit the access to a bucket and its objects
  • Secondly specify an S3 permission set that allows listing all buckets

Process flow to implement this

The process flow can either be implemented using the ECS UI in combination with the AWS CLI Tools, it could be automated using the Rest API, it can be done using a Postman Collection with prepared variables to issue the commands, curl or any other way you feel comfortable with. 

Whatever you choose, these are the steps we follow:

  • Create a user and generate the access key and secret key
  • Initially use the ECSS3FullAccess policy for the user
  • Create bucket and set object lock configuration if required
  • Set the lifecycle policy and ensure broken multipart uploads are deleted as well as cleaning up versions if versioning or object lock is enabled
  • Create the user policy to limit bucket access and update the user to use the user-specific policy and no longer the ECSS3FullAccess policy

With this, the configuration is completed and safe.

Comment on permissions

Based on our experience with operations in different customer environments, a few words on selected permissions available for the S3 user policy.

Bucket level permissions:

  • CreateBucket: may not be allowed to users to enforce naming schemes
  • DeleteBucket: even though only empty buckets can be deleted, this is not required for regular users
  • PutBucketPolicy: allows granting or restricting access to the bucket to other users or public access. You may want to control that in the policy.
  • DeleteBucketPolicy: may change user access to objects and should be controlled in the policy

Object Lock permissions should only be granted if they are really required. Should a user enable compliance mode and a retention period, there is no way to delete this data prior to retention expiry. Especially for service providers this may be dangerous. Permissions:

  • PutBucketObjectLockConfiguration: Setting the object lock permission should only be possible during initial configuration through the ECSS3FullAccess policy
  • EnableObjectLock: Enabling object lock should be available initially only
  • BypassGovernance Edition: Deletion of objects prior to retention expiry must be used very carefully

IAM Implementation support required?
Should you look for JSON examples for policies or if you are looking for assistance to develop an IAM concept, do not hesitate to reach out. We can provide postman collections or examples that allow to start quickly with custom settings and permission sets.

Looking for other ECS related information?

Do not hesitate to reach out to Backup ONE AG using the contact form in our website. We’ll be happy to assist. Ideas for additional posts are welcome 😊.