Granting Security Policy Permissions

Permission Levels

Policy-Based Security supports cluster-level and policy-level permissions.

The following table describes the two permission levels:

Permission Level	Description
Cluster-level	Controls which administrators can create and view security policies in a cluster. Administrators with cluster-level `cp` permission can create security policies. Administrators with cluster-level `fc` permission can view all the security policies created.
Policy-level	Controls which administrators can view and modify security policies. Policy-level permissions are set on a per-policy basis. Permissions set on one security policy do not apply to other security policies.

Administrators with cluster-level permissions can set cluster-level and security policy-level permissions through any of the following tools:

Control System
REST API commands
maprcli acl set|edit commands
maprcli security policy create commands

For additional information, refer to the section Setting Permissions on Security Policies.

IMPORTANT

Note these important considerations for security-policy permissions:

On a fresh cluster install, the root user and the data-fabric user (typically named mapr or hadoop on each node) have cp permission. On an upgraded cluster, only the data-fabric user user has cp permission.
As the cluster owner, the data-fabric user (typically named mapr or hadoop on each node), has overriding permission on security policies, including the administrative ACLs. The data-fabric user can create, view, and modify security policies, regardless of the cluster-level and policy-level permission specified.
By default, administrators do not have permission to create security policies. Administrators need cluster-level cp (create security policy) permission to create security policies. Administrators with cluster-level a (admin) permission can grant cp permission to themselves or other administrators.
TIP
You must designate a cluster as the global policy master before you create security policies. Setting a global policy master creates a global namespace for security policies. See Security Policy Domain and Policy Management.
Any user with a valid data-fabric ticket can view security policy IDs and names. This allows non-administrative users to determine which security policies to apply to data objects.

Permission Codes

Cluster-level and security policy-level permission codes that are set through ACLs grant security policy access to administrators. An administrator (with cluster-level a (admin) and cp (create security policy) permissions) that creates a security policy has full control over the security policy unless they specifically grant other administrators access to the security policy through policy-level permissions.

The following sections describe the cluster-level and policy-level permission codes for security policy access:

Cluster-Level Permission Codes

The following table lists some cluster-level permission codes and how they relate to security policies. For a complete list of cluster-level permission codes, see acl.

Cluster-level permission code	Description
`a (admin)`	Grants administrative access to cluster ACLs. Can grant `create security policy (cp)` permission to themselves or other administrators. Cannot view or edit the details of any security policy created by other admins. Can only view the security policy ID and name. Needs security policy-level permissions to view or edit security policies created by other admins.
`cp (create security policy)`	ATTENTION Administrators need this permission to create security policies. Administrators with `a (admin)` cluster-level permission can grant `cp` permission to themselves or other administrators. Administrators can view and edit all parts of the security policies they create, including the ACEs and permissions on the security policies. Grants the administrator that creates a security policy the following security policy-level permissions on the security policy: `Full Control (fc)` `Admin (a)` `Read (r)` Administrators who create security policies can override their access to the security policies by designating policy owners who can then manage the security policies. See policy create, policy modify, and refer to the `-user` parameter.
`fc (full control)`	Grants full control over the cluster and enables all cluster-level administrative options. Cannot change the cluster-level ACLs. Can view all security policies. Cannot create security policies. Cannot edit the details of any security policy unless specifically granted access to a security through policy-level permissions.

Policy-Level Permission Codes

Separate read (r) and edit (fc) permissions for policy owners allow some policy owners to view policy information while others can edit policy information. This allows most administrators to administer the system without seeing the data and also prevents some policy owners from adding their credentials to the administrative ACLs to manipulate the data access ACEs.

Policy-level permissions are set on a per-policy basis. Permissions set on one security policy do not apply to other security policies.

The following table lists the policy-level permission codes needed to perform actions on security policies.

Policy-level permission code	Description
`a (admin)`	Can view and modify permissions on the security policy. Cannot view or modify the security policy; can only view the security policy name and ID.
`fc (full control)`	Can view and edit any part of the security policy, including the data access ACEs. Cannot view or modify permissions on the security policy.
`r (read)`	Can view all parts of a security policy, but cannot modify any part of the security policy.

Permissions Table

The following table lists the cluster-level and policy-level permissions needed to perform specific actions on security policies:

NOTE

Administrators who create a security policy have policy-level r, a, and fc permission on the security policy.

Action	Cluster-Level	Policy-Level
Create a security policy	`cp`	--
View details of all security policies	`fc`	--
View details of a security policy	--	`r`
View and edit permissions on a security policy (ACLs)	--	`a`
View and edit the details of a security policy (ACEs, auditing, wire-level encryption)	--	`fc`

Setting Permissions on Security Policies

An administrator with cluster-level permissions can set security policy permissions during policy creation. Administrators with proper edit permissions on a security policy can modify security policy permissions.

Setting Permissions from the Control System

To set permissions during security policy creation, see Creating a Security Policy.
To modify permissions on existing security policies, see Modifying a Security Policy.

Setting Permissions from the CLI and REST API

To grant cluster-level (cp) permission to a cluster administrator, see acl.
To set permissions during security policy creation, see policy create.
To modify permissions on existing security policies, see policy modify, acl set, and acl edit.

Viewing Security Policy Permissions

To display cluster-level permissions, run:

/opt/mapr/bin/maprcli acl show -type cluster

To display policy-level permissions, run:

/opt/mapr/bin/maprcli security policy info -name <policy name> \
[-cluster cluster name ] [ -output terse|verbose ] \
[ -columns <comma-separated list of column names> ] \
[ -expandaces true|false ] -json

HPE Ezmeral Data Fabric – Customer-Managed 7.9.0 Documentation
Abstract	This site contains documentation for the customer-managed platform of the HPE Ezmeral Data Fabric version 7.9.0 including installation, configuration, administration, and reference content, as well as content for the associated bundled ecosystem components and drivers.
Published	November 2024
Edition	7.9.0