Example Using Security Policies

This example demonstrates how to secure data, set permissions, and create, view, and modify a security policy.

Assume that you want to protect sensitive employee data in the cluster, and you only want to permit security policy and data access to the following users and groups:

Type Name Role
User PolicyAdmin
  • Creates security policies
User ITAdmin
  • Modifies nonsensitive properties of security policies
User HrVP
  • Decides who can access employee data
  • Is a member of the HR group
Group HR
  • Views the properties of the employee data policy
  • Reads and writes employee data
Group Finance
  • Reads employee data

The following commands grant cluster-level permissions and create a security policy named employeeData with the policy-level permissions and Access Control Expression (ACE)s needed to fulfill the roles shown in the preceding table:

  1. User mapr grants cluster-level permissions and confirms that the permissions are properly set:
    /opt/mapr/bin/maprcli acl edit -type cluster \
      -user PolicyAdmin:login,cp ITAdmin:login,fc \
      -group HR:login Finance:login
    /opt/mapr/bin/maprcli acl show -type cluster

    Verify that the ACLs are set correctly:

    /opt/mapr/bin/maprcli acl show -type cluster
    
    Allowed actions             Principal         
    [login, cp]                 User PolicyAdmin  
    [login, ss, cv, fc]         User ITAdmin      
    [login]                     Group HR          
    [login]                     Group Finance 
  2. User PolicyAdmin creates the security policy, and sets policy-level permissions and ACEs for only HrVP:
    /opt/mapr/bin/maprcli security policy create -name employeeData \
      -description "Confidential Employee Data" \
      -user HrVP:r,a \
      -readace u:HrVP -writeace u:HrVP

    The following output shows that only HrVP has permissions and ACEs:

    /opt/mapr/bin/maprcli security policy info -name employeeData \
      -columns acl,securityPolicyAces -json
    
    {
    	"timestamp":1541086042314,
    	"timeofday":"2018-11-01 08:27:22.314 GMT-0700 AM",
    	"status":"OK",
    	"total":1,
    	"data":[
    		{
    			"acl":{
    				"Principal":"User HrVP",
    				"Allowed actions":"[r, a]"
    			},
    			"securityPolicyAces":{
    				"readfileace":"u:HrVP",
    				"readdirace":"u:HrVP",
    				"lookupdirace":"u:HrVP",
    				"readdbace":"u:HrVP",
    				"traversedbace":"u:HrVP",
    				"consumeace":"u:HrVP",
    				"writefileace":"u:HrVP",
    				"addchildace":"u:HrVP",
    				"deletechildace":"u:HrVP",
    				"writedbace":"u:HrVP",
    				"produceace":"u:HrVP",
    				"topicace":"u:HrVP"
    			}
    		}
    	]
    }
  3. User HrVP modifies the policy, adding policy-level permissions and ACEs for the HR and Finance groups:
    /opt/mapr/bin/maprcli security policy modify -name employeeData \
      -user HrVP:a -group HR:r \
      -readace 'g:HR|g:Finance' -writeace g:HR

    The following sample output shows that the groups HR and Finance now have permissions and ACEs:

    /opt/mapr/bin/maprcli security policy info -name employeeData \
      -columns acl,securityPolicyAces -json
    
    {
    	"timestamp":1541086614445,
    	"timeofday":"2018-11-01 08:36:54.445 GMT-0700 AM",
    	"status":"OK",
    	"total":1,
    	"data":[
    		{
    			"acl":[
    				{
    					"Principal":"User HrVP",
    					"Allowed actions":"[r, a]"
    				},
    				{
    					"Principal":"Group HR",
    					"Allowed actions":"[r]"
    				}
    			],
    			"securityPolicyAces":{
    				"readdirace":"g:HR | g:Finance",
    				"topicace":"g:HR",
    				"traversedbace":"g:HR | g:Finance",
    				"lookupdirace":"g:HR | g:Finance",
    				"consumeace":"g:HR | g:Finance",
    				"addchildace":"g:HR",
    				"readdbace":"g:HR | g:Finance",
    				"readfileace":"g:HR | g:Finance",
    				"writedbace":"g:HR",
    				"deletechildace":"g:HR",
    				"produceace":"g:HR",
    				"writefileace":"g:HR"
    			}
    		}
    	]
    }

    The policy-level permissions and ACEs defined in step 3 could have been included in step 2; however, they were separated to illustrate the following:

    • The need to reapply policy-level permissions from step 2 because the new settings overwrite the previous settings
    • Use of the | symbol when specifying ACEs
  4. A user in the HR group checks the state of the security policy:
    /opt/mapr/bin/maprcli security policy info -name employeeData \
    -columns allowtagging,accesscontrol -json

    The security policy is still in a state that restricts it from being used (allowtagging=false) or enforced (accesscontrol=Disarmed):

    {
    	"timestamp":1541087645422,
    	"timeofday":"2018-11-01 08:44:05.422 GMT-0700 AM",
    	"status":"OK",
    	"total":1,
    	"data":[
    		{
    			"allowtagging":false,
                         "accesscontrol":"Disarmed"		}
    	]
    }
  5. User ITAdmin changes the state of the policy from allowtagging=false and accesscontrol=Disarmed to allowtagging=true and accesscontrol=Armed and then confirms the changes:
    /opt/mapr/bin/maprcli security policy modify -name employeeData -allowtagging true -accesscontrol Armed
    
    /opt/mapr/bin/maprcli security policy info -name employeeData -columns allowtagging,accesscontrol -json
    
    {
    	"timestamp":1541087645422,
    	"timeofday":"2018-11-01 08:44:05.422 GMT-0700 AM",
    	"status":"OK",
    	"total":1,
    	"data":[
    		{
    			"allowtagging":true,
                         "accesscontrol":"Armed"		}
    	]
    }
After the state is changed, users can apply the policy to data objects and the system will enforce the security controls set in the policy. In the following example, the policy is applied during volume creation:
/opt/mapr/bin/maprcli volume create \
  -securitypolicy employeeData ... other options ... \
  -name employeeDataVolume

With this policy applied, users in the HR group can read and write data in employeeDataVolume. Users in the Finance group can only read data.