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.
NOTEYou must have appropriate permissions to create security policies.
-
Specify the security properties under the Properties
pane of the page:
-
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 toYes
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.
- Set the policy to
- 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.
NOTEIf 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
readaces
property in the CLI. - Select Writes to grant:
- write permission on files
- add and delete child permissions on directories
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.
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.
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.
- Select Reads to grant:
- 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:
- Click Save to create the security policy.
Creating a Security Policy Using the CLI and REST API
About this task
/opt/mapr/bin/maprcli security policy create -name <policyName>
curl -k -X POST 'https://<hostname>:8443/rest/security/policy/create?name=<policyName>" --user mapr:mapr
policy create
.