Creating a Security Policy

Describes how to create a security policy using the Control System, CLI, and REST API.

About this task

Administrators with cluster-level cp (create security policy) permission can create security policies from the Control System, CLI, and REST API. Before creating security policies, first set a cluster as the global policy master. After creating the policy as its owner, edit all parts of the policy, including the policy Access Control Expression (ACE)s. After creating a security policy, the policy is disarmed with the tagging set to false (or No in the Control System), by default, which makes the policy unavailable for tagging. You can modify the policy state to make it available for tagging. See Changing the State of a Security Policy for more information.

Creating a Security Policy Using the Control System

Procedure

Log in to the Control System, and click (Security Settings) to display the Security page.
Click Create PolicyCreate New Policy to display the Create Security Policy page.

NOTE You must have appropriate permissions to create security policies.
Specify the security properties under the Properties pane of the page:
1. Specify a name for the policy in the Name field, and enter a brief description of the policy in the Description text box.
  Security policy names must be unique within the cluster and must contain only alphanumeric characters, hyphens (-), and underscores (_). The maximum length of the security policy name is 32 characters.
2. Specify Yes to enable wire-level encryption by moving the slider. Otherwise, click No.
  By default, this setting is enabled on secure clusters and disabled on insecure clusters.
3. Specify Yes to enable auditing by moving the slider. Otherwise, click No.
  If auditing is enabled, choose Default to accept the default list of operations to audit, or choose Custom to select or deselect the operations to audit. Note that including setattr automatically enables the following operations:
  - chown
  - chgrp
  - chperm
  If you exclude setattr, these operations are automatically disabled. If you do nothing with setattr (neither enable nor disable), you can enable or disable chown, chgrp, and chperm in any combination.
4. Specify whether (Yes or No) to allow data-fabric data objects to be tagged with this security policy.
  
  NOTE Tagging must be set to Yes to allow users to associate the security policy with a table, column family, or field. Security policies preside over chosen tables and their related column families and field data by default.
  
  For more information, see Changing the State of a Security Policy.
Select one of the following access control states from the Access Control pull-down menu in the Data Access Control pane:
- Armed—Enforce the ACEs in the security policy on the data-fabric data objects tagged with the policy.
- Disarmed—Do not enforce the ACEs, if any, in the policy on the data-fabric data objects tagged with the policy.
- Denied—Deny all access to the data-fabric data objects tagged with the policy and log any attempt to access.
For more information, see Changing the State of a Security Policy.
Click Add Access Permissions in the Data Access Control pane to set data access controls. The Add Access Permission window appears.
Do one of the following from the Add Access Permission window:
- Set the policy to Public. Setting the Public slider to Yes makes this policy accessible to everyone.
- Leave this slider at its default setting of No to customize access permissions, and then enter the comma-separated list of users, groups, or roles to be granted to in the Users, Groups, and Roles text boxes respectively.
- Select the Custom ACE checkbox to manually enter the ACE in the appropriate text box shown.
  For more information on how to build the custom ACE, see Managing Access Control Expressions.
Click Next: Select Permissions to display the Add Access Permissions window.

Select and check options, as needed, from the Add Access Permissions window. The following table describes the permissions that can be granted to specified users, groups, and roles.

NOTE If you opt to select Reads, Writes, and/or Executes at the top of the Add Access Permissions window, the system automatically checks appropriate options beneath the Directories, Files, and Tables headings of the Add Access Permissions window.

Select Reads to grant:
- read permission on directories and files
- lookup permission on directories
This is the same as the readaces property in the CLI.
Select Writes to grant:
- write permission on files
- add and delete child permissions on directories
This is the same as the writeaces property in the CLI.
Select Executes to grant execute permission on files. This is the same as the executefileace property in the CLI.

Object	Permission
Directories	Read the contents of a directory. If this is not selected, mode bits are used to determine read access. To read the contents of a directory that is tagged with this security policy, the user must also have read permissions on the volume, the parent directory (if any), and the file. This is the same as the `readdirace` property in the CLI. Lookup or list the contents in a directory. If this is not selected, mode bits are used to determine lookup access. To read the contents of a directory that is tagged with this security policy, the user must also have read permissions on the volume and the directory. This is the same as the `lookupdirace` property in the CLI. Add Child to add a file or subdirectory. If this is not selected, mode bits are used to determine permissions to create files and subdirectories. To add a child to a directory that is tagged with this security policy, the user must also have write permissions on the volume and parent directories, add child permission on the parent directory, and read and execute permissions on all directories in the path. This is the same as the `addchildace` property in the CLI. Delete Child to delete a file or subdirectory. If this is not selected, mode bits are used to determine permissions to create files and/or subdirectories. To delete a child of a directory that is tagged with this security policy, the user must also have write permissions on the volume and parent directories, delete child permission on the parent directory, and read and execute permissions on all directories in the path. This is the same as the `deletechildace` property in the CLI. For more information, see Managing File and Directory ACEs.
Files	Read a file. If this is not selected, mode bits are used to determine read access to file. To read a file that is tagged with this security policy, the user must also have read permissions on the volume. This is the same as the `readfileace` property in the CLI. Write to a file. If this option is not selected, mode bits are used to determine read access to the file. To write to a file that is tagged with this security policy, the user must also have write permissions on the volume. This is the same as the `writefileace` property in the CLI. Execute a file. If this is not selected, mode bits are used to determine execute access to the file. To execute a file that is tagged with this security policy, the user must also have read permissions on the volume. This is the same as the `executefileace` property in the CLI. For more information, see Managing File and Directory ACEs.
Tables	Read a table. If this is not selected, mode bits are used to determine read access to table. To read a table that is tagged with this security policy, the user must also have read permissions on the volume. This is the same as the `readtableace` property in the CLI. Traverse CF a table. Allows the grantee to descend a hierarchy of fields to access fields on which the grantee has write or read permission. This is the same as the `traverseperm` property in the CLI. Write to a table. If this is not checked, mode bits are used to determine read access to the table. To write to a table that is tagged with this security policy, the user must also have write permissions on the volume. This is the same as the `writetableace` property in the CLI. Unmasked Data a table. If this checkbox is not checked, it disallows the grantee to see all table data.

Click Add to add the data access permissions to the policy.
Opt to do one of the following, or proceed to the next step.
- Add Another, and repeat the initial step for adding access permissions through to the final step for other users, groups, and roles.
- to create a copy of the data access controls, which can then be modified by clicking .
Grant users and/or groups permissions to perform administrative operations on the policy in the Policy Administration Control pane:
1. Select the entity type, user or group, from the Type drop-down list, and enter the entity name in the Entities field.
2. Check the checkbox associated with the following permissions to grant the entity the type of permission:
  - Read access for the policy.
  - Admin access to set and modify ACLs on the policy.
  - Full control over the policy.
3. Proceed to the next step, or click one of the following to add access controls for other users and groups:
  - Add Another and repeat the the initial step through the final step of the add access control procedure for other users and groups.
  - (Duplicate) to create a copy of the access control.
  - (Delete) to delete a listed permission.
Click Save to create the security policy.

Creating a Security Policy Using the CLI and REST API

About this task

The basic command to create a security policy:

/opt/mapr/bin/maprcli security policy create -name <policyName>

Send a request of type POST. For example:

curl -k -X POST 'https://<hostname>:8443/rest/security/policy/create?name=<policyName>" --user mapr:mapr

For more information, see policy create.