Multi-tenancy support for the S3 protocol was added to the VAST Data platform in version 5.1. This document describes how tenant and user attribution occur for S3 requests, and how to configure Access Keys for S3 users in a Multi-Tenant environment when running versions 5.1 or 5.2.
Tenants, VIP Pools, and Client IPs
Vast Multi-tenancy for S3 functions a little differently than for other protocols. For NFS and SMB, a client is mapped to a specific tenant based on either which VIP Pool their connection is made, and/or based on the Clients IP Address. Each Tenant is required to have either a distinct VIP Pool, and/or a set of Client IP addresses in order to allow for this mapping.
For S3 requests, mapping of a client request to a tenant is based primarily on the Access Key used to authenticate the request. Each access key uniquely maps to a user within a specific tenant, so the tenant can be determined from the access key. For requests where an access key is not provided (eg, anonymous requests, when enabled) the bucket name is used instead – and as a result bucket names must be unique across the entire cluster.
VIP Pool and client IP ranges can optionally be used in the tenant definition, in which case the request will be rejected if these do not match the corresponding addresses of the request. If no VIP Pools are specifically assigned to a tenant, then any VIP Pools assigned to “All Tenants” can be used to access that tenant via S3.
Assigning an Access Key to a Tenant User
Step 1 – Create the Local User (if required)
It is generally recommended to use Active Directory/LDAP based accounts for S3 users in the Vast system. If you are using an AD/LDAP user you can skip to Step 2. If using a local user that has already been created, you can also skip to Step 2.
When creating a local user in Vast, the general configuration for the user is not created in a specific tenant, but exists across all tenants; however, specific configurations, such as the S3 Access Keys, are assigned to that user on a per-tenant basis.
To create a local user, first, we need to create the generic user entry.
Browse to the User Management -> Users tab in the Vast GUI, and click on the ‘Create User’ button in the top right. The ‘Add User’ screen will be displayed. Fill in the ‘Name’ and ‘UID’ fields for the user, but leave all other options disabled/empty. Click ‘Create’ to create the user.
Add User
Step 2 – Querying the User in a Specific Tenant
Browse to the User Management -> Users tab in the GUI. By default, any local users on the system will be shown; however, these users are shown within the ‘default’ Tenant context. To view/edit a user within the context of a specific Tenant, whether the user is a local user or an AD/LDAP user, we need to search for that user, specifying the Tenant to search within.
Click on the ‘Query Users’ (magnifying glass) icon in the top right corner of the Users screen to display the Query Users screen.
In the Query Screen, enter the username of the user that you wish to modify, and from the Tenant dropdown box select the name of the Tenant you wish to view/modify this user within, then click Query.
Query User
Presuming the user is found in either the local user database or the identity provider configured for the tenant being searched, you should see the results of the query. Especially when using local users, this looks similar to the default user list shown when first browsing to this page; however, in this case, the user shown is within the context of the selected tenant, the name of which is also displayed in the top right of the results box.
User management
Step 3 – Assigning an Access/Secret key to the User
Right-click on the user entry discovered by searching, and click on ‘Edit’ to edit the user. A pop-up window similar to the one below will be displayed – be sure to confirm the ‘Tenant’ field in the top left matches the tenant that you were wanting to edit the user within.
Many of the fields within the displayed window can not be edited as they are defined at the ‘default’ level; the various S3 field – Identity Policies, Allow Create/Delete Bucket, and Access Keys are all per tenant and thus can be edited.
User Details
Click on “Create new key” to create a new S3 Access/Secret key pair. Be sure to copy the secret key when doing this, as it will not be displayed again.
Access Keys
Any requests made using the generated access key will be mapped to the tenant in which the key was created, and will be mapped to the user it was assigned to within that tenant.
If you re-do the steps above using a different tenant but the same user, you will see that when editing that user, no Access Keys are displayed – only keys assigned to the context of the tenant that you’re viewing the user within will be shown when editing a user.
Identity Policies
S3 identity Policies are defined per Tenant. When creating the policy, you can select the tenant it belongs to.
Add policy
When assigning an Identity Policy to a user, follow the same Query/Edit process described above for assigning an Access Key so that the policy is applied to the user within the context of the desired tenant.