The VAST S3 implementation includes two methods for managing who has permissions, which S3 resources they have permission for, and which actions they have permission to do on those resources (buckets and objects).
The following access management methods are supported:
-
Identity Policies. These are attached to users and groups. They define permissions by actions and resources. Identity policies enable you to allow or deny all supported actions.
-
S3 ACLs. These are attached to resources. They define permissions by users, groups and wide categories of actions. They are an legacy method for managing access and do not cover all actions.
Permissions denied by identity policies override permissions allowed by identity policies. Permissions allowed or denied by identity policies override S3 ACLs.
Requests are only checked against identity policies if the view policy uses S3 Native security flavor. With S3 Native security flavor, requests from all protocols are checked against identity policies. Several NFS request types are mapped to S3 permissions and therefore can be allowed or denied by identity policies.
Identity policies allow more granular permission setting than the legacy ACLs as well as enabling you to grant permission for actions that cannot be permitted using ACLs. Whereas ACLs grant wide permissions such as "write" permissions which include multiple actions, identity policies are attached to users and groups.
Identity policies enable you to change permissions more efficiently than by modifying each bucket's or each object's ACL.
Identity policies are the primary access control method available with the VAST Cluster S3 service.
Identity policies comprise statements that grant or deny permissions for any combination of specific actions on any combination of specified resources.
Identity policies are manageable exclusively through VMS. They are created using JSON document structure and uploaded to VMS. You can create, modify and delete identity policies, and you can attach them to users and to groups.
Identity policies supersede ACLs as the recommended access control method for the VAST S3 service, covering permission control for the full range of supported actions in this version. ACLs continue to be supported, and are limited to legacy S3 action types. Every new bucket and object is created with a default ACL granting FULL CONTROL to the owner. Permission checking looks at ACLs in the event that the incoming request is not covered by any user policy.
Note
All permissions required for the Object Locking feature must be assigned through identity policies.
VMS stores identity policies that were created on the cluster and may also store identity policies that were replicated from another cluster. That is, in native replication where data is replicated from one cluster to another cluster, identity policies are also replicated. Replicated identity policies are disabled on the remote cluster. They are available to be enabled in the event of a native replication failover.
To view all identity policies:
-
From the left navigation menu, select User Management and then Identity Policies.
The following attributes are displayed per policy:
Name
The name of the identity policy.
Users
Indicates if any users are attached to the policy and which users.
Groups
Indicates if any groups are attached to the policy and which groups.
Enabled
Indicates if the policy is enabled on the cluster.
You can create multiple identity policies and attach multiple policies to each user and group. Identity policies are managed via VMS. Adding an identity policy to VMS involves writing the policy in JSON format and then adding it to VMS.
VAST identity policies support a subset of the elements specified by Amazon's IAM JSON Policy Reference For information about how to write a policy in the required JSON format with supported elements, see How to Write an Identity Policy.
For the procedure for adding a policy to VMS, see How to Add an Identity Policy to VMS.
An identity policy comprises a series of statements. Each statement allows or deny a scope of S3 actions on a scope of S3 resources.
To write an identity policy, follow the identity policy syntax and save your file with the .json file extension. Refer to the element reference below for details about each element, whether it's required or optional, valid values and formats.
For your reference, some examples are provided below.
Following is the syntax supported for identity policies. Refer to the element reference below for more details, such as which elements of the syntax are required, valid values and so on.
The following conventions are used in the provided syntax:
-
The following characters are JSON tokens and are included in identity policies:
{ } [ ] " , : -
The following characters are special characters in the grammar and are not included in identity policies:
= < > ( ) | -
If an element allows multiple values, it is indicated using repeated values, a comma delimiter, and an ellipsis (...).
For example:
[<action_string>, <action_string>, ...]
-
If multiple values are allowed, it is also valid to include only one value. For only one value, the trailing comma must be omitted. If the element takes an array (marked with [ and ]) but only one value is included, the brackets are optional.
For example, both of the following are valid, with and without the brackets:
"Action": [<action_string>]
"Action": <action_string>
-
A vertical line (|) between elements indicates alternatives. Parentheses in the syntax define the scope of the alternatives. Example:
("Action" | "NotAction") -
Elements that must be literal strings are enclosed in double quotation marks ("). For example,
"Allow".
Note
The Condition element is not supported.
The identity policy syntax is:
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "SID",
("Action" | "NotAction"): ("*" | [<action_string>, <action_string>, ...]),
"Effect": ("Allow" | "Deny"),
("Resource" | "NotResource"):
("*" | [<resource_string>, <resource_string>, ...])
}
]
}
|
Element |
Required/Optional |
Description |
Usage Notes and Valid Values |
|---|---|---|---|
|
Version |
Required |
Specifies the language syntax rules that are to be used to process the policy. |
There is one supported value for version: This is the current version of the policy language. |
|
Statement |
Required |
The main element in a policy, the Statement element contains one or more permission statements. |
The Statement element can contain a single statement or an array of individual statements. Each individual statement block must be enclosed in curly braces { }. For multiple statements, the array must be enclosed in square brackets [ ]. |
|
Sid |
Optional |
An optional identifier for the policy statement. You can assign a Sid value to each statement in a statement array. The Sid value must be unique within a JSON policy. You can't retrieve a particular statement based on the Sid value. |
The Sid element supports ASCII uppercase letters (A-Z), lowercase letters (a-z), and numbers (0-9). |
|
Action, NotAction |
Required (Action or NotAction) |
Specifies an action or actions. With Action:
With NotAction:
Using NotAction can result in a shorter policy by listing only a few actions that should not match, rather than including a long list of actions that will match. |
The Action or NotAction element can specify all actions, using the expression Specify "S3:ACTION"
ACTION is the AWS S3 action name of any supported S3 action. For supported actions and their Amazon S3 action name, see Supported S3 API Actions. For example: You can use wildcards to specify multiple actions, such as:
|
|
Effect |
Required |
Specifies whether a statement results in an allow or an explicit deny. |
Valid values are |
|
Resource, NotResource |
Required (Resource or NotResource) |
Specifies buckets and/or objects. With Resource, the specified buckets and/or objects are covered by a statement. WIth NotResource, all buckets and/or objects except those specified are covered by a statement. |
You can specify one resource element or multiple resource elements in a statement. The expression The following are valid for
|
The following identity policy grants a user access to one of your buckets, DOC-EXAMPLE-BUCKET1, and allows the user to add, update, and delete objects.
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action": "s3:ListAllMyBuckets",
"Resource":"*"
},
{
"Effect":"Allow",
"Action":["s3:ListObjects","s3:GetBucketLocation"],
"Resource":"arn:aws:s3:::DOC-EXAMPLE-BUCKET1"
},
{
"Effect":"Allow",
"Action":[
"s3:PutObject",
"s3:PutObjectAcl",
"s3:GetObject",
"s3:GetObjectAcl",
"s3:DeleteObject"
],
"Resource":"arn:aws:s3:::DOC-EXAMPLE-BUCKET1/*"
}
]
}
The following policy contains one statement that grants permission to perform all actions on all objects in all buckets:
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "Allow Everything",
"Action":
"*",
"Effect": "Allow",
"Resource":
"*"
}
]
}
The following identity policy contains one statement that grants permission to perform the GetObject action on all objects in the bucket dev:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Allow All GetObject in dev Bucket",
"Action": [
"s3:GetObject"
],
"Effect": "Allow",
"Resource": "arn:aws:s3:::dev/*"
}
]
}
The following identity policy grants permission for multiple actions on the bucket product and on all objects in the same bucket, while also denying delete permission on the same bucket and objects.
{ "Version": "2012-10-17",
"Statement": [
{
"Sid": "Allow Multiple Actions on product bucket and its objects",
"Action": [
"s3:Get*",
"s3:Put*",
"s3:Head*",
"s3:List*"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::product",
"arn:aws:s3:::product/*"
]
},
{
"Sid": "Deny delete product bucket and objects",
"Action": [
"s3:DeleteBucket",
"s3:DeleteObject"
],
"Effect": "Deny",
"Resource": [
"arn:aws:s3:::product",
"arn:aws:s3:::product/*"
]
}
]}
The recommended way to add identity policies to VMS is via the VAST Web UI.
Note
It is possible to add identity policies via the VAST CLI but since policies are multiline, you may find that your SSH terminal does not succeed in creating the policies.
To add an identity policy to VMS via VAST CLI, use the s3policy create command.
To modify an identity policy that was already added, use the S3policy modify command.
-
In the VAST Web UI, open the Identity Policies page (under User Management in the menu).
-
Click Create Policy.
The Add Policy dialog opens.
-
In the Name field, enter a name for the policy. Do not include spaces in the name.
-
Either type the policy in the Policy field, or click Upload JSON file and browse to the .json policy file that you want to add. For help writing a policy, see How to Write an Identity Policy.
After uploading a policy, you can also edit the policy text in the Policy field.
-
Click Create.
The policy is added to the set of available policies and displayed in the Identity Policies page. It is now available to attach to users.
You can attach multiple identity policies to each user and to each group. In order to attach or remove policies, you can query any relevant providers for a user or group and then edit the user or group and add and/or remove identity policies from the user/group.
-
Navigate to the Users page (User Management > Users).
-
Click the
button to run a query to retrieve the user from a provider. (Even if the user already appears in a query result, you may need to run the query for the next step to work.) -
Enter the user's UID, user name or SID and select a context for the query.
-
Click Query.
The query is run and the retrieved user is displayed on the Users page.
-
From the Actions column, click the
button for the user and select Edit.The User Details dialog opens. The dialog has a field named S3 Policies.
-
From the S3 Policies dropdown, select a policy that you want to attach to the user.
The policy name is entered into the S3 Policies field.
Note
If the policy that you select covers permission to create and/or delete buckets, the policy will override the Allow Create Bucket and Allow Delete Bucket permission settings per user.
-
If you want to attach another policy to the user, open the dropdown again and select another policy. The first policy that you already attached appears checked in the dropdown list.
The second policy is also added to the S3 Policies field.
-
Repeat as needed to attach additional policies to the user. To remove policies, open the dropdown and deselect each policy that you want to remove.
-
Click Update.
The policies are attached to the user.
-
Navigate to the Groups page (User Management > Groups).
-
Click the
button to run a query to retrieve the group from a provider. (Even if the group already appears in a query result, you may need to run the query for the next step to work.) -
Enter the group's GID, Groupname or SID and select a context for the query.
-
Click Query.
The query is run and the retrieved group is displayed on the Groups page.
-
From the Actions column, click the
button for the group and select Edit.The Update Group dialog opens. The dialog has a field named S3 Policies.
-
From the S3 Policies dropdown, select a policy that you want to attach to the group.
The policy name is entered into the S3 Policies field.
Note
If the policy that you select covers permission to create and/or delete buckets, the policy will override the Allow Create Bucket and Allow Delete Bucket permission setting per user.
-
If you want to attach another policy to the group, open the dropdown again and select another policy. The first policy that you already attached appears checked in the dropdown list.
The second policy is also added to the S3 Policies field.
-
Repeat as needed to attach additional policies to the group. To remove policies, open the dropdown and deselect each policy that you want to remove.
-
Click Update.
The policies are attached to the group.
Use the group querygroup query command.
-
From the left navigation menu, select User Management and then Identity Policies.
-
Click
to open the Actions menu for the policy you want to edit and select Edit. -
Make changes as needed. You can change the name, edit the policy text, and/or upload a new JSON file.
-
Click Update.
The changes you made to the policy are updated.
Note
You cannot delete an identity policy that was replicated from a native replication peer.
-
From the left navigation menu, select User Management and then Identity Policies.
-
Click
to open the Actions menu for the identity policy you want to delete, and select Remove. -
Click Yes to confirm the deletion.
The policy is deleted.
Identity policies may be disabled and enabled. Identity policies that are created on the cluster are enabled by default. When enabled, policities are effective for any users and groups that are attached to them.
If there is a protected path replicating data from another cluster to the local cluster, the identity policies on the source cluster are replicated to the cluster. They appear in the Identity Policies listing and they are disabled by default, so that you can choose to enable them only in the event of failover if you wish.
-
From the left navigation menu, select User Management and then Identity Policies.
-
Click
to open the Actions menu for the policy you want to edit and select Enable or Disable. -
Click Yes to confirm the change.
The policy is now enabled or disabled.
To enable or disable identity policies from the VAST CLI, use the S3policy modify command.
Note
Setting S3 ACLs on buckets and objects via S3 RPCs is supported with S3 Native security flavor.
Retrieving S3 ACLs is supported with NFS security flavor as well.
To read about how permissions are controlled with each security flavor, see Controlling File and Directory Permissions Across Protocols.
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.
When a request is received against a resource, VAST Cluster performs an access check that differs depending on the security flavor. In S3 Native flavor, the check begins with any identity policies that are attached to the requesting user or to a group to which the user belongs. If there are no identity policies that apply to the user, or no statements in identity 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. In NFS security flavor, the check skips identity 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 NFSv3 or NFSv4.1 clients in a view that is using S3 Native security flavor.
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.
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 (LDAP, NIS).
-
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.
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 |
Yes. Aside from the use of identity 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 policies override the S3 superuser permission.
To set or retrieve S3 ACLs, you can use the operations listed under Bucket Access Control List (ACL) Operations and Object ACL Operations.
Comments
0 comments
Article is closed for comments.