One common request Wasabi receives from our resellers is how to set up the Wasabi system config to ensure that customer1 can't access the files of customer2. The most popular way of doing this is to use separate storage buckets for each customer along with sub-user & bucket policies. This article will describe the steps required to achieve this.
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 = customer1-bucket, customer2-bucket etc.
- sub-user names = customer1, customer2 etc.
- policy names = customer1-limit, customer2-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
customer1-limit is created for customer1 and a bucket name of
customer1-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 /customer1-bucket is set (along with the configuration of the API key set for customer1). One must do this as a means of ensuring that the storage app only tries to mount the bucket associated with customer1. Most storage apps connect and try to 'list all buckets' (this would fail because of the policy limitations that were set).