Overview of S3 Access Management

Prev Next

S3 access can be controlled using the following means:

  • (Recommended) Identity policies and bucket policiesCreating Identity 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 or groups. It defines actions that the user(s) and/or group(s) are allowed or denied to perform against buckets and/or objects specified in the policy.

      Identity policies let you set permissions for all supported actions.

    • 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 policies. Some NFS request types are mapped to S3 permissions and therefore can be allowed or denied by identity and bucket policies.

  • (Legacy) S3 ACLsManaging S3 Access Control Rules (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.

    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 user 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.