One common request Wasabi receives is how to set up the Wasabi system config to user access separation at the bucket and/or folder 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
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
To separate users at the bucket level, please follow the procedure below. To separate users at the folder level, please jump toward the end of this article.
User Access Separation At The Bucket Level
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:
- Create a Wasabi root account (if one does not already exist)
- Create a storage bucket for each customer
- Create an IAM policy for each customer that limits their access to just their storage bucket
- Create a sub-user account for each customer that leverages the bucket policies
- 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 IAM -> 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).
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).
Once you have created the sub-user and associated the appropriate limit 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)
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).
User Access Separation At The Folder Level
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)
Updates to this article for this procedure are being developed; please contact us for assistance.