Overview of S3 Access Management
S3 access can be controlled using the following means:
(Recommended) Identity policies and bucket policies
Identity and bucket policies define permissions through statements that allow and deny particular actions on certain resources.
An identity policy is attached to one or more users, groups, or IAM Roles. It defines actions that the user, group, or IAM role are allowed or denied to perform on buckets and/or objects specified in the policy.
A bucket policy is attached to a view. It defines actions that particular user(s) and/or group(s) are allowed or denied to perform against this view and files or directories under the view.
Identity and bucket policies allow for more granular permission setting than S3 ACLs, and also let you manage permissions for actions that cannot be controlled using ACLs. With identity policies, you can manipulate permissions more efficiently than with by modifying each bucket's or each object's ACL.
Identity and bucket policies are checked prior to S3 ACLs. If an access decision can be made based on applicable identity and bucket policies, the ACLs are not checked.
Note
Requests are only checked against identity and bucket policies if the view policy is set to S3 Native security flavor. With S3 Native security flavor, requests from all protocols are checked against identity and bucket policies.
(Legacy) S3 ACLs
S3 ACLs are a legacy method for managing access which does not cover all actions. ACLs are limited to legacy S3 action types. Newer features require permissions that cannot be granted via ACLs. This is applicable for views with S3, and mixed security flavors.
Permission checking looks at ACLs only if the request is not covered by an identity or bucket policy. If ACLs are disabled for a view, they are ignored.
For views that are controlled with the S3 Native security flavor, if the user that creates the bucket or object does not specify an ACL, a basic default ACL is set automatically on each bucket and object granting FULL CONTROL to the owner.
S3 ACLs can be modified by S3 API requests.
User settings in VMS
VMS lets you configure the following S3 permission settings per user. They can be overridden by permissions set in identity policies:
Permission to create buckets.
Permission to delete buckets.
'superuser' permission, a VAST permission that gives the user the equivalent of ACL 'full control' permission on all buckets and objects, overriding ACLs. It is considered equivalent to the NFS super user "root".
Note
This is a legacy feature. VAST S3 Superuser permission is only available if it was set for a user prior to upgrade to version 5.2.
Managing S3 Access Control Lists (ACLs)
Overview
Access Control Lists (ACLs) are a resource-based method for managing S3 access. An ACL defines which grantees (users or groups) are granted access, and what permission type each grantee has. A grantee can be a user or a group.
Setting S3 ACLs on buckets and objects using S3 RPCs is supported with S3 Native and Mixed Last Wins security flavors. Retrieving S3 ACLs is supported with by all security flavors.
When a request is received against a resource, VAST Cluster performs an access check as follows:
With the S3 Native security flavor, the check begins with any identity and bucket policies. If there are no applicable policies, or no statements in policies that deny or allow the requested action, the decision is made by checking S3 ACLs (if ACLs are enabled) on the requested object or bucket to verify that the requesting user has the necessary access permissions.
With all other security flavors, identity and bucket policies are ignored, and ACLs are checked.
When you create a bucket or an object, with S3 security flavor, VAST Cluster creates a default ACL that grants the owner full control over the bucket or object (assuming no ACL is specified in the call that creates the bucket.)
This default ACL is also used when files and directories are created using non-S3 clients in a view that uses the S3 Native security flavor.
Enabling and Disabling ACLs
You can enable or disable ACLs for views that have the S3 security flavor (ACLs are always enabled for views with other security flavors). If ACLs are disabled, access is determined solely by any identity policies that apply to the user or group, or by bucket policies that apply to the bucket.
You enable the use of ACLs when you create or modify a view, if the S3 security flavor is selected for the view (this is selected in the view policy associated with the view).
Granting Permissions using ACLs
ACLs can grant permissions to individual VAST Cluster users, groups, and the following predefined groups:
AUTHENTICATED_USERS. This group represents all users who can authenticate to the S3 service. ACLs granted to this group allow access to any user that has network access to the cluster provided the request is signed (authenticated).
ALL_USERS. This group represents all users in the world with network connectivity to the cluster. ACLs granted to this group allow access to any user that has network access to the cluster. The requests can be signed (authenticated) or unsigned (anonymous). Unsigned requests omit the Authentication header in the request.
Note
Anonymous requests are blocked unless the Anonymous access setting is enabled for the relevant view.
Caution
If anonymous access is enabled and an ACL grants permission to the ALL_USERS group, any client that sends an unsigned request (also known as sending a request in anonymous mode) to access the object with the requested permission type will be granted the requested access. Therefore, it is good practice to exercise caution with granting permissions to the All Users group. For example, if you assign WRITE permission to this group for accessing a bucket, any requester could store objects in your bucket or delete objects you might want to keep.
Specifying a User as a Grantee
To grant ACLs to a user, you can specify the user as one of the following:
A principal name in the format user@domain, where user is the user name and domain is configured for an external auth provider on the cluster (for example, LDAP).
A VID, which is a VAST ID used in the cluster's internal user database. A user VID is retrievable by running the user query VAST CLI command and specify udb as the context of the query. The output includes the user's VID.
Example
This example shows a client code snippet to grant WRITE permission to a bucket (BobsBucket )for a specific user (user_login@domain.com).
response = s3_client.put_bucket_acl(
AccessControlPolicy={
'Grants': [
{
'Grantee': {
'Type': 'AmazonCustomerByEmail',
'EmailAddress': 'user_login@domain.com'
},
'Permission': 'WRITE'
},
],
'Owner': {
'DisplayName': 'BSmith',
'ID': '4'
}
},
Bucket='BobsBucket',
)Specifying a Group as a Grantee
To grant permissions to a group, specify the group as the principal as follows:
Set the type to GroupLoginName and specify the group in the format group@domain, where group is the group name and domain is configured for an external auth provider on the cluster (such as LDAP).
Specify the group's VID, which is the VAST ID used in the cluster's internal user database. A group VID can be retrieved by running the group query VAST CLI command and specify udb as the context of the query. The output includes the group's VID.
What Permissions Can I Grant?
You can grant any of the following permissions to any valid grantee in an ACL.
Permission Type | When Granted on a Bucket | When Granted on an Object |
|---|---|---|
READ | Allows grantee to list the objects in the bucket | Allows grantee to read the object data and its metadata |
WRITE | Allows grantee to create, overwrite, and delete any object in the bucket | Not applicable |
READ_ACP | Allows grantee to read the bucket ACL | Allows grantee to read the object ACL |
WRITE_ACP | Allows grantee to write the ACL for the applicable bucket | Allows grantee to write the ACL for the applicable object |
FULL_CONTROL | Allows grantee the READ, WRITE, READ_ACP, and WRITE_ACP permissions on the bucket | Allows grantee the READ, READ_ACP, and WRITE_ACP permissions on the object |
How Do I Set and Retrieve S3 ACLs?
Operations to set or retrieve S3 ACLs are listed in Supported S3 Requests.