Overview
Access Control Lists (ACLs) are a resource-based method for managing S3 access. An ACL defines which grantees 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 via S3 RPCs is supported with S3 Native and Mixed Last Wins. Retrieving S3 ACLs is supported with NFS and SMB security flavors as well.
When a request is received against a resource, VAST Cluster performs an access check as follows:
With S3 Native security flavor, the check begins with any identity or 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 on the requested object or bucket to verify that the requesting user has the necessary access permissions.
With Mixed Last Wins security flavor, S3 clients are allowed to set S3 ACLs, but identity and bucket policies are ignored.
With NFS and SMB security flavors, the check skips identity and bucket policies and S3 ACLs.
When you create a bucket or an object, 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 via non-S3 clients in a view that is using S3 Native security flavor.
Who Can I Grant Permission to?
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.
How Do I Specify 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 queryVAST CLI command and specify udb as the context of the query. The output includes the user'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 |
Is it Possible to Override All S3 ACLs for a User?
Yes. Aside from the use of identity or bucket policies, which override ACLs where relevant, there is also a VMS permission setting that can be enabled per user which overrides S3 ACLs. The setting is called 'S3 Superuser'. It overrides all ACLs to give a user all permissions on all objects and buckets that can be set via S3 ACLs. This could be useful, for example, for applications such as backup applications which need to restore object attributes. Note, however, that identity and bucket policies override the S3 superuser permission.
How Do I Set and Retrieve S3 ACLs?
Operations to set or retrieve S3 ACLs are listed in Supported S3 Requests.