Policy Evaluation

Owned by Rumena Zlatkova (Deactivated)
Last updated: Dec 21, 2023 by Bala Harish A(AC)
6 min read

These are the administrator roles and the rules for the order of policy evaluation. Administrator roles are based on ownership and access permissions defined within the Gateway and storage contexts. While these are all users, possibly in different LDAP DNs and/or PAM, and can all be the same set of users, the following definitions are useful for describing the normal responsibilities that each classification administrator has. They are normal boundaries where access control is segregated.

Role-Based Access Control

While Swarm only defines the role of the owner, role-based access control (RBAC) definitions with varying complexity can be created as required for the organization using the Gateway's access control policies. The Cluster, Tenant, Domain, and Bucket "administrators" are common roles that can be used, but they are not required or hard-coded into the system.

Administrator Roles

Type and Administrator Role

Example

Type and Administrator Role

Example

CLUSTER

Define who can create tenants and non-tenanted domains

Analogous to the Swarm administrator except they are defined in an external identity management system. This user or group is specified in the policy.json root Policy configuration file.

This policy.json file defines and grants full permissions to the cluster administrators group called ClusterAdmins. The members of the ClusterAdmins group are the cluster administrators users and are often the same that maintaining the physical infrastructure.

{ "Version": "2008-10-17", "Id": "ClusterAdminsPolicy", "Statement": [ { "Sid": "1", "Effect": "Allow", "Principal": { "group": [ "ClusterAdmins" ] }, "Action": [ "*" ], "Resource": "/*" } ] }

TENANT

Define who can create domains for the tenant

Owner of the tenant object as specified by the X-Owner-Meta metadata header. It is common for the tenant administrator to create a Policy document for the tenant that grants permissions for a group of users to act on the same authority of the tenant administrator.

This tenant Policy document grants full access to a group called TenantAdmins whose members come from users within the acme tenant.

PUT /_admin/manage/tenants/acme/etc/policy.json { "Version": "2008-10-17", "Id": "TenantAdminsPolicy", "Statement": [ { "Effect": "Allow", "Sid": "1", "Principal": { "group": [ "TenantAdmins" ] }, "Action": [ "" ], "Resource": "/" } ] }

DOMAIN

Define who can create buckets and unnamed objects

Owner of the storage domain as specified by the X-Owner-Meta metadata header. It is common for the domain administrator, owner of the storage domain, to create a Policy document for the domain that grants permissions for a group of users to act on the same authority of the domain administrator.

This domain Policy document grants full access to a group called DomainAdmins whose members come from users within the domain.

PUT http://DOMAIN/?policy { "Version": "2008-10-17", "Id": "DomainAdminsPolicy", "Statement": [ { "Effect": "Allow", "Sid": "1", "Principal": { "group": [ "DomainAdmins" ] }, "Action": [ "" ], "Resource": "/" } ] }

BUCKET

Define who can create named objects within the bucket

Owner of the bucket as specified by the X-Owner-Meta header. The bucket administrator, owner of the bucket, can attach a Policy document to the bucket that defines the access control policy for the bucket and its contents.

This bucket policy grants any authenticated user full access under http://DOMAIN/mybucket/incoming/* and grants users in the Finance group full access under http://DOMAIN/mybucket/reports/* .

All objects are contained with the bucket context mybucket . The access control policy matches named objects with the prefixes incoming/ and reports/ within that bucket.

Note

Notice the bucket name is included when specifying resources in the bucket policy.

Object Ownership

All objects created and updated through the Gateway have the X-Last-ModifiedBy-Meta metadata value set to the authenticated user performing the request. The value is blank if an object is created by an anonymous user. Additionally, unless the request includes an X-Owner-Meta metadata value, it is assigned the value of the authenticated user or blank for anonymous. If X-Owner-Meta is blank, everyone is considered to be the owner for policy evaluation.

  • For users authenticated within the same domain as the objects, the format of the metadata values is the base user name. For example: "john".

  • For users authenticated from a different domain than the objects, the format is fully qualified with the authenticating domain. For example: "john@another.com".

  • For users authenticated from the root IDSYS, the format is user + "@". For example: "john@".

  • If an object is created by a cluster administrator using an administrative override, the format is the same since the user is authenticated from the root IDSYS. For example "admin@".

See Modifying Policies.

Evaluation Precedence

When evaluating a user's authorization to perform a requested action, all relevant Policy documents are first merged together. Policies can exist at the root, tenant, storage domain, and bucket levels and, depending upon the request's level within the API hierarchy, one or more of these policies are merged together for evaluation.

For example, if a user requests to read an unnamed object within a storage domain, the Root Policy, Tenant Policy, and Domain Policy are merged together. Requesting the read of a named object within a bucket also merges the Bucket Policy along with the root, tenant, and storage domain policies.

This is the policy evaluation logic:

The evaluation logic follows the precedence rules:

  1. By default, all requests to a resource are denied to anyone except the owner specified by the header X-Owner-Meta on the resource.

  2. An allow overrides any default denial from #1.

  3. An explicit deny overrides any allows.

Info

The order in which the policies are evaluated has no effect.

The result of an explicit deny overriding allow is that if an action is denied to all users ("user" : ["*"]), even if also explicitly allowing oneself the same action, one is denied the ability to perform the action.

If a request is for a non-existent domain or bucket context object, policy evaluation is short-circuited and an HTTP 404 response code is returned to the client. When the domain or bucket exists, policy evaluation returns an HTTP 403 if the user is not authorized to perform the action. The practical implication is a user authorized to access a storage domain may be able to detect the existence of a bucket for which they do not have access. This paragraph only applies to context objects and not to objects that hold user content.

If the X-Owner-Meta header is blank or missing from a storage domain or bucket object, its ownership is anonymous and all users match as the owner. The result is that everyone has owner permissions on the storage domain or bucket. It is a best practice to always assign ownership to context objects.

© DataCore Software Corporation. · https://www.datacore.com · All rights reserved.