Go to main content

Oracle® ZFS Storage Appliance Object API Guide for Amazon S3 Service Support, Release OS8.8.0

Exit Print View

Updated: January 2019
 
 

Specifying S3 ACL Permissions

S3 ACLs enable you to manage access to buckets and objects. Each bucket and object has an ACL attached to it as a subresource. It defines which user or user groups are granted access, as well as the type of access granted. For instance, when a request is received against a resource, the S3 API checks the corresponding ACL to verify that the requester has the necessary access permissions. Each time you create a bucket or object, the S3 API creates a default ACL Policy that grants the resource owner full access control over the newly created resource as shown in the following example.

Example: Default ACL Policy for new bucket or object.

<?xml version="1.0" encoding="UTF-8"?>
<AccessControlPolicy xmlns="https://s3.amazonaws.com/doc/2018-05-23/">
  <Owner>
    <ID>***Owner-Canonical-User-ID***</ID>
    <DisplayName>Bucket Owner Display Name</DisplayName>
  </Owner>
  <AccessControlList>
    <Grant>
      <Grantee xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" 
               xsi:type="Canonical User">
        <ID>***Canonical-User ID or Group URI ***</ID>
        <DisplayName>Appliance Grantee's username</DisplayName>
      </Grantee>
      <Permission>FULL_CONTROL</Permission>
    </Grant>
  </AccessControlList>
</AccessControlPolicy>

Where:

  • <Owner> reflects the appliance canonical user ID for the owner that created the bucket.

  • <Grant> reflects the name of the grantee, and the permission granted.

    Note that the default ACL Policy includes only one <Grant> element for the bucket owner. To grant bucket permission to others, you need to add a <Grant> element for each additional user or predefined group. Each <Grant> element must always identify the name of the grantee, as well as the permissions granted.

  • <Grantee> reflects the name of an individual or predefined group receiving access permission.

    The grantee can either be an authorized appliance user or an S3 predefined group. When granting access to individual appliance users, you need to specify the canonical user ID associated with the appliance user account. When granting permission to an S3 predefined group, you need to specify the predefined group URI. For a list of supported predefined groups, see Supported Amazon S3 Predefined User Groups.

  • <Permission> reflects the type of access permission that is being granted to the grantee. For a list of supported ACL permissions, see Supported S3 ACL Permissions.

Setting ACL Policy Permissions in a Request

Use one of the following request methods when using S3 APIs (such as PUT/GET/DELETE) to set access policy permissions:

  • When creating resources – Set the ACL permissions in the request's HTTP header.

  • When editing ACLs associated with existing resources – Set the ACL permissions either in the request's HTTP header or in the request's body.

Supported Amazon S3 Predefined User Groups

The following table describes the supported Amazon S3 predefined user groups.

Table 12  Amazon S3 Predefined User Groups
Predefined User Group
Description
All Users Group
The All Users Group is represented by the following URI: http://acs.amazonaws.com/groups/global/AllUsers
Access permission to this group enables anyone to access the resource. The requests can either be signed (authenticated) or unsigned (anonymous).

Note -  Unsigned requests omit the Authentication header in the request. Anonymous users will be mapped to the user nobody in Oracle ZFS Storage Appliance.

For security reasons, a resource owner should never grant the All Users Group any of the following permissions: WRITE, WRITE_ACP, or FULL_CONTROL.
Authenticated Users Group
The Authenticated Users Group is represented by the following URI: http://acs.amazonaws.com/groups/global/AuthenticatedUsers
This group represents all Oracle ZFS Storage Appliance authenticated user accounts. Access permission to this group enables any authenticated user access to the resource. Therefore, when using this group, all requests must be signed (authenticated) .