This section explains how to manage access policies for S3 buckets in a Qumulo cluster.
Access policies let you control specific sets of S3 API actions that each user or group can perform. They provide an additional layer of access management for S3 buckets by adding further restrictions to those of access keys, presigned URLs, and file system access control lists.
Managing access policies for S3 buckets in Qumulo clusters is similar to managing SMB share access, only with a larger set of items that you can specify in the Actions
field of the policy statement.
For information about working with access policies for S3 buckets and for qq
CLI examples, see the following sections in the Qumulo qq
CLI Command Guide:
Anonymous Access to S3 Buckets
By default, S3 buckets in a Qumulo cluster are in a no policy state, in which Qumulo Core disallows unsigned, anonymous requests and the qq s3_get_bucket_policy
command returns {}
.
In Qumulo Core, anonymous S3 connections use the system Guest
account, which is restricted to read-only S3 API actions. To permit anonymous access in an S3 bucket policy, grant access to one of the following principals:
- The
Everyone
group - The
Guest
account - Any group that includes the
Guest
account as a member
When you upgrade Qumulo Core version 7.1.1, the system replaces anonymous S3 bucket access configuration with a default S3 bucket policy that permits all S3 API actions to all principals.
Prerequisites
The following prerequisites let you manage the access policy for an S3 bucket effectively.
-
Grant your users access to the S3 bucket by using S3 access keys or presigned URLs, or enable read-only, anonymous access to the S3 bucket.
-
Configure inheritable file ACLs by using the
qq
CLI, SMB, or NFSv4.1 access control lists (ACLs). -
Ensure that you have the following required role-based access control (RBAC) privileges.
-
PRIVILEGE_S3_BUCKETS_READ
-
PRIVILEGE_S3_BUCKETS_WRITE
-
-
(Optional) To delegate the management of an access policy for an S3 bucket to another user, grant the
s3:PutBucketPolicy
ands3:DeleteBucketPolicy
S3 API actions to that user in theActions
field of a policy statement.
How Policy Statements for S3 Buckets are Structured
Policy statements for S3 buckets use the JSON format. For example:
{
"Id": "Example overall access policy description",
"Statements": [{
"Action": [
"s3:GetBucketPolicy",
...
],
"Effect": "Allow",
"Index": 1,
"Principal": {
"Qumulo": ["Everyone"]
},
"Sid": "Example policy statement description"
},{
...
}],
"Version": "2012-10-17"
}
To retrieve an example policy file, run the qq s3_get_bucket_policy --example
command.
The S3 bucket policy statement contains the following fields.
Field Name | Description |
---|---|
(Optional)Id |
Describes the functionality of your overall policy |
Statements |
Contains a list of statements, and the following fields for each policy statement Note
The order of the fields has no effect on the permissions that an access policy grants for an S3 bucket.
|
(Optional) Version |
If you specify this field, enter 2012-10-17 , the latest policy version from Amazon. For more information, see IAM JSON Policy Elements: Version. |
Actions Supported in Qumulo Core
The following table describes the subset of the Amazon S3 API Actions which Qumulo Core supports.
- Certain permissions (such as
s3:AbortMultipartUpload
) grant permission to both S3 API and Qumulo REST API variants of an API call. - Certain permissions (such as
s3:GetBucketAcl
) grant permission to S3 APIs that are currently implemented partially within Qumulo Core. s3:*
matches all S3 API actions.
API Action | Description |
---|---|
s3:AbortMultipartUpload |
Abort a multipart upload to the S3 bucket |
s3:DeleteBucket |
Delete the S3 bucket |
s3:DeleteBucketPolicy |
Remove the access policy from the S3 bucket |
s3:DeleteObject |
Delete any object from the S3 bucket |
s3:DeleteObjectTagging |
Delete all tags from any object in the S3 bucket |
s3:DeleteObjectVersion |
Delete any object version from the S3 bucket |
s3:GetBucketAcl |
Retrieve the access control list (ACL) for the S3 bucket |
s3:GetBucketLocation |
Retrieve the region in which the S3 bucket is located Note
Currently, because Qumulo Core doesn’t use regions, the system always returns local . |
s3:GetBucketNotification |
Retrieve the notification configuration for the S3 bucket |
s3:GetBucketObjectLockConfiguration |
Retrieve the object lock configuration for the S3 bucket |
s3:GetBucketPolicy |
Retrieve the bucket policy for the S3 bucket |
s3:GetBucketReplication |
Retrieve the replication state for the S3 bucket |
s3:GetBucketVersioning |
Retrieve the versioning state for the S3 bucket |
s3:GetEncryptionConfiguration |
Retrieve the encryption state for the S3 bucket |
s3:GetLifecycleConfiguration |
Retrieve the lifecycle configuration for the S3 bucket |
s3:GetObject |
Download any object from the S3 bucket Note
The file system permissions take precedence over this permission. |
s3:GetObjectAcl |
Download the access control list (ACL) for any object in the S3 bucket |
s3:GetObjectAttributes |
Retrieve the attributes for any object in the S3 bucket |
s3:GetObjectTagging |
Retrieve the tags for any object in the S3 bucket |
s3:ListBucket |
Enumerate all objects in the S3 bucket |
s3:ListBucketMultipartUploads |
Enumerate all multipart uploads to the S3 bucket |
s3:ListMultipartUploadParts |
Enumerate all multipart upload parts in the S3 bucket |
s3:PutBucketPolicy |
Configure the access policy for the S3 bucket |
s3:PutBucketVersioning |
Configure bucket versioning for the S3 bucket |
s3:PutObject |
Write or overwrite any object in the S3 bucket |
s3:PutObjectTagging |
Configure tags for any object in the S3 bucket |
Principals Supported in Qumulo Core
The following table describes examples of principals which Qumulo Core supports.
Identity Specification Example | Description |
---|---|
Mary Lou |
A username or group name |
local:Jane |
A user or group created by using the Qumulo REST API in the local domain, prefixed by local: |
local:guest |
An anonymous connection |
world:Everyone |
Any user connected to Qumulo Core, including unauthenticated, anonymous connections |
Authenticated Users |
Any authenticated user, excluding guest or anonymous connections |
EXAMPLE_DOMAIN\Jose Ramirez |
A user or group in a specific Active Directory domain, prefixed by the domain name |
ad:Company Name |
A user or group in any connected Active Directory domain, prefixed by ad: |
uid:1234 |
A POSIX UID that identifies users by their RFC 2307
, prefixed by uid: |
gid:1234 |
A POSIX GID that identifies users by their RFC 2307
, prefixed by gid: |
auth_id:12345678 |
The numeric auth_id of a user or group |
|
A Windows-style security identifier (SID), optionally prefixed by sid: |
Role-Based Access Control (RBAC) Overrides
For the S3 API and Qumulo REST API, if a user has the role-based access control privilege (RBAC) to perform an API action, Qumulo Core ignores the access policy and permits the API action.
The following table describes the relationship between Qumulo Core privileges and the S3 API actions associated with them.
Qumulo Core Privilege | Associated S3 API Actions |
---|---|
S3_BUCKETS_READ |
|
S3_BUCKETS_WRITE |
|
S3_UPLOADS_READ |
|
S3_UPLOADS_WRITE |
s3:AbortMultipartUpload |