How do I set up Wasabi for user access separation?

One common request Wasabi receives is how to set up the Wasabi system config to user access separation at the Sub-User, Bucket and/or Folder level.

1. User Access Separation At the Sub-User Level

Separation at the Sub-User level means this:

• The sub user account should not be allowed to see the contents of existing buckets

• The sub user should be allowed to create/delete his own buckets and access objects in their own buckets

In some scenarios, you may wish to separate users from accessing the data of other users by limiting their access to their own buckets. While Sub-Users can see the names of all the buckets present in the account, they should only be allowed to upload/delete objects to their own buckets and should not have access to see or change the content of other users buckets.

The following steps must be followed to achieve this:

1. Create a Wasabi root account (if one does not already exist). Then create an IAM policy for each Sub-Users that limits their access to just their own storage bucket using the policy shown in the screenshots later

2. Create a sub-user account for each customer that leverages this bucket policies. Attach this policy along with "IAMUserChangePassword" policy to the sub-user for giving console access and change their password.

3. Create an API key set for each sub-user/customer for use with their storage apps

4. Test the access separation by logging into the console as a sub-user

For this article, let's consider the following for example purposes:

• We have created & named a policy as " Sub-User-Policy"

• We have one sub-user named "user-john". This sub-user will be able to create/delete his own buckets. They will be allowed all s3 actions (read/write/update/delete) inside their buckets. However, they will not be able to view other users bucket or make any change to them.

Step 1 When logged in as a Root User, Create an IAM policy for Sub-Users that limits their access to just their own storage bucket.

To start, you can take the policy example below and use it to build your policy.

In this example, an IAM policy called " Sub-User-Policy" is created for sub-users " user-john "

From the left side menu of the Wasabi web console UI, choose the tab labeled Policies -> Create Policy option to create a policy using the example below.

The actual policy syntax for limiting Sub-Users access to just their own storage bucket is provided below (this can be edited to reflect the proper sub-user name in your actual use case).

Here we have given sample of such policies:

Note: To perform any bucket/object operations through the console the sub-user MUST have "ListAllMyBuckets" permission. This will allow the sub-user to list all the buckets when logged into the console, but can access and see contents only from the bucket that sub-user has permission to

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Sid": "ListMy",
 "Effect": "Allow",
 "Action": "s3:ListAllMyBuckets",
 "Resource": "arn:aws:s3:::*"
 },
 {
 "Sid": "AllowAll-S3ActionsToOwnBucket",
 "Effect": "Allow",
 "Action": "s3:*",
 "Resource":"arn:aws:s3:::user-john*"
 }
 ]
}

Note: In the Resource section, we are defining the prefix "user-john" followed by a wildcard "*" meaning John can create as many buckets as he would like as long as it has prefix "user-john" and he additionally he will be able to exercise all s3 rights on those buckets. Buckets that do not start with this prefix cannot be accessed by John.

Step 2 You can create sub-users for each customer. From the 'Users' tab on Wasabi web console menu options, you can create a user using the guidelines below.

As part of the Add User creation process, you will want to associate " user-john " with two policies "Sub-User-Policy" and "IAMUserChangePassword". You can attach more policies to the user according to your use case. (you do this after the Groups selection as shown below; note that Groups is not required). Review and then create the user.

Step 3 Once you have created the sub-user and associated the appropriate policy, you should then create the API key set for this sub-user. This is the key set that you will use with the third-party storage app used to send the storage to Wasabi. The standard Wasabi process of creating API keys applies here, except that you apply it to the sub-user, not the root user (as shown below).  You can get to this by selecting the "Access Keys" tab from the menu of the left side of the web UI.

* Similarly you can create other sub-users " by repeating the step 2 and 3 *

Step 4 Now you can test this access separation for the above created sub-user

On the login page, click on "Sign in as a Subuser" (this option is below password line). Once you click that, you will see this page

Line 1: Enter Name of Sub-User (in this example we had named our sub-user as "user-john")

Line 2: Enter Email ID or Alias name of root account owner

Line 3: Enter Sub-User password

Once inside the console, our Sub-User "user-john" can create/delete and access all buckets that has the required prefix. He will receive "Access Denied" for all actions on other buckets

------------------------------------------------------------------------------------------------------

2. User Access Separation At the Bucket Level

Separation at the  bucket level means this:

• user1 has access to bucket 1 & user2 has access to bucket 2

• user1 has no access to bucket2 & user 2 has no access to bucket 1

In some scenarios, you may wish to separate users at the bucket level (each user has their own bucket and while a user can access their own bucket, they can't access other users buckets)

At a high-level, the following steps are involved:

1. Create a Wasabi root account (if one does not already exist)

2. Create a storage bucket for each customer

3. Create an IAM policy for each customer that limits their access to just their storage bucket

4. Create a sub-user account for each customer that leverages the bucket policies

5. Create an API key set for each sub-user/customer for use with their storage apps

For this article, let's consider the following names for example purposes:

• bucket names = user1-bucket, user2-bucket etc.

• sub-user names = user1, user2 etc.

• policy names = user1-limit, user2-limit

(these names will be used as examples in the explanation below)

Steps 1 & 2 (creation of the root user and storage buckets) should be familiar to all Wasabi users so they are not covered in depth here.

Step 3 (creation of an IAM policy for each customer that limits their access to just their storage bucket) will be new to some Wasabi users so the process is covered here.

To start, you can take the policy example below and use it to build your policy.

In this example, an IAM policy called  user1-limit is created for customer1 and a bucket name of  user1-bucket is used.

From the Wasabi web console UI, choose the Policies -> Create Policy option to create a policy using the example below.

The actual policy syntax for limiting access to customer1-bucket is provided below (this can be edited to reflect the proper bucket name in your actual use case).

Here we have given sample of 2 policies:

Policy Type 1: This policy is for customers who want to allow sub-users to perform bucket operations through the console

Note: To perform any bucket/object operations through the console the sub-user MUST have "ListAllMyBuckets" permission. This will allow the sub-user to list all the buckets when logged into the console, but can access content only from the bucket that sub-user has permission to

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Action": "s3:ListAllMyBuckets",
 "Resource": "arn:aws:s3:::*"
 },
 {
 "Effect": "Allow",
 "Action": "s3:*",
 "Resource": [
 "arn:aws:s3:::user1-bucket",
 "arn:aws:s3:::user1-bucket/*"
 ]
 }
 ]
}

Policy Type 2: This policy is for customers who have sensitive information in the bucket names and do not want the sub-users to list all the bucket names. Please note with this policy the sub-user cannot perform operations from the console.

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:*"
],
"Resource": [
"arn:aws:s3:::user1-bucket/*",
"arn:aws:s3:::user1-bucket"
]
}
]
}

Explicit Deny: Sometimes customers can have issues with policy type 2 still listing all bucket names for sub-users in third-party applications when not specifying the direct bucket path. In a situation where this occurs, the customer may need to attach an additional policy to a sub-user explicitly denying access/actions to all buckets not mentioned in the policy.

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Deny",
 "Action": [
 "s3:ListBucket",
 "s3:GetBucketLocation",
 "s3:ListBucketMultipartUploads"
 ],
 "NotResource": [
 "arn:aws:s3:::user1-bucket/*",
 "arn:aws:s3:::user1-bucket"
 ]
 },
 {
 "Effect": "Deny",
 "Action": "s3:*",
 "NotResource": [
 "arn:aws:s3:::user1-bucket/*",
 "arn:aws:s3:::user1-bucket"
 ]
 }
 ]
}

Now that you have created a bucket limit policy for each customer, you can create sub-users for each customer (step 4 described above). From the Wasabi web console IAM menu, you can create a user using the guidelines below. Remember to select the "Programmatic (create API key)" option so you can create an API key set for future use with this customer's storage app. You can also provide this customer with console access if needed.

As part of the Add User creation process, you will want to associate the customer1-limit policy to customer1 (you do this after the Groups selection as shown below; note that Groups is not required).

As shown in the above steps, API keys were created at the same time as creating the sub-user. Once you have created the sub-user and associated the appropriate limit policy, if you did not already, you should then create the API key set for this sub-user. This is the key set that you will use with the third-party storage app used to send the storage to Wasabi. The standard Wasabi process of creating API keys applies here, except that you apply it to the sub-user, not the root user (as shown below)

Now that you have done the necessary Wasabi system config, you can use the service in a manner that prevents customer1 from accessing customer2 buckets (and visa-versa).

One important config setting that must be used in the storage app is setting the 'path'. See highlighted area of screen shot below for the sample app 'Mountain Duck'. In this example, the path of /user1-bucket is set (along with the configuration of the API key set for user1). One must do this as a means of ensuring that the storage app only tries to mount the bucket associated with user1. Most storage apps connect and try to 'list all buckets' (this would fail because of the policy limitations that were set).

-----------------------------------------------------------------------------------------------------

3. User Access Separation At the Folder Level

Separation at the  folder level means this:

• user1 & user2 share a common bucket

• user1 has access to folder1 & user2 has access to folder2

• user1 has no access to folder2 & user2 has no access to folder 1

In some scenarios, you may wish to separate users at the folder level (users share a common bucket but each user has their own folder that is not accessible by other users with access to the same bucket)

Policy to be attached to the sub-user to give access to a specific folder within a specific bucket:

{
 "Version":"2012-10-17",
 "Statement": [
 {
 "Sid": "AllowUserToSeeBucketListInTheConsole",
 "Action": ["s3:ListAllMyBuckets", "s3:GetBucketLocation", "s3:GetBucketCompliance"],
 "Effect": "Allow",
 "Resource": ["arn:aws:s3:::*"]
 },
 {
 "Sid": "AllowRootAndHomeListingOfCompanyBucket",
 "Action": ["s3:ListBucket"],
 "Effect": "Allow",
 "Resource": ["arn:aws:s3:::"],
 "Condition":{"StringEquals":{"s3:prefix":["","/"],"s3:delimiter":["/"]}}
 },
 {
 "Sid": "AllowListingOfUserFolder",
 "Action": ["s3:ListBucket"],
 "Effect": "Allow",
 "Resource": ["arn:aws:s3:::"],
 "Condition":{"StringLike":{"s3:prefix":["/*"]}}
 },
 {
 "Sid": "AllowAllS3ActionsInUserFolder",
 "Effect": "Allow",
 "Action": ["s3:*"],
 "Resource": ["arn:aws:s3::://*"]
 }
 ]
}

------------------------------------------------------------------------------------------------------------

4. Sub-user-limiting access policy to allow read/write/delete inside their own bucket but not allow to delete the bucket itself

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "arn:aws:s3:::*"
},
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::bucket-name",
"arn:aws:s3:::bucket-name/*"
]
},
{
"Effect": "Deny",
"Action": "s3:DeleteBucket",
"Resource": [
"arn:aws:s3:::bucket-name",
"arn:aws:s3:::bucket-name/*"
]
}
]
}