Controlling access permissions on S3 buckets and objects is done exclusively through Access Control Lists (ACLs).
Overview
Each bucket and object has an ACL attached to it as a sub resource. The ACL defines which grantees are granted access and what permission type each grantee has. A grantee can be a user or a predefined group. When a request is received against a resource, VAST Cluster checks the corresponding ACL to verify that the requester has the necessary access permissions
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.)
Who can I grant permission to?
ACLs can grant permissions to individual VAST Cluster users and to predefined groups.
Users must be specified as grantees by their VAST ID (VID) (see How do I specify a user as a grantee?).
The following groups are predefined:
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.
Caution
If 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 need to specify the user by VID, VAST Cluster's proprietary internal user ID.
To retrieve a user's VID, run the user query VAST CLI command and specify the user database as the context of the query. The output includes the user's VID.
For example, by querying the user with UID 1234 in the user database, the output gives us VID 102:
vcli: admin> user query --uid 1234 --context udb +---------------------+---------------------------------------------------------+ | vid | 102 | | uid | 1234 | | sid | S-1-111-2158861062-4234128909-3370954163-3291251275-1 | | allow_create_bucket | False | | allow_delete_bucket | False | | access_keys | [] | | leading_gid | 0 | | leading_sid | S-255-0-0-0-0-0-4294967295-4294967295-0-0-0-0-0-0-0-0-0 | | groups | [] | | groups_details | [] | | ttl | 1612164639 | | username | joeb | +---------------------+---------------------------------------------------------+
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 ACLs for a User
It is possible to grant a user 'S3 Superuser' permission. This overrides all ACLs and gives the user full permissions on all objects and buckets. This is useful for applications such as backup applications which need to restore object attributes.
Comments
0 comments
Article is closed for comments.