Security Policy Implementation Workflow

Describes the security policy workflow, in general, and the steps in implementing a security policy.

In the diagram below, all member fabrics, that is, Member Fabric 1, Member Fabric 2, Member Fabric 3, and Member Fabric 4 get the policy metadata from the global policy master.

The security policies are mirrored to all member fabrics in the global namespace from the global policy master.

1 – Create a Security Policy Domain

By default, the primary fabric is set as the global policy master and all secondary fabrics are member fabrics in the global namespace, with respect to security policies. You must create security policies on the primary fabric as security policies are propagated to secondary fabrics or member fabrics by way of mirroring of the security policies. The mirroring takes place every 15 minutes.

.
IMPORTANT
If a primary fabric needs to go offline or fails, set one of the member fabrics as the new primary fabric.

Use the following command to set a member fabric as the primary fabric.

maprcli clustergroup updateprimary -clustername <specify actual fabric name here>    

Once a new member fabric is converted into a primary cluster, it automatically becomes the global policy master.

To identify if a fabric is the global policy master, run the following command on the command line for the fabric:
maprcli config load --keys "cldb.pbs.global.master"

The value of cldb.pbs.global.master is 1 in the output of the aforementioned command, for the fabric that is designated as the global policy master. For a member fabric, the value is 0.

2 - Create and Update Security Policies

You can create and update security policies on the global policy master only. You cannot create or modify security policies on member fabrics. See Creating a Security Policy for instructions to create a security policy.

The following table lists the operations you can and cannot perform on the global policy master and member security-policy fabrics:
Security-policy fabric type Allowed operations Prohibited operations
Master (fabric set as the global policy master)
  • Create
  • Modify
  • Export
  • View
  • Tagging
  • Import
Member
  • Import
  • Export
  • View
  • Tagging
  • Create
  • Modify

3 – Propagate Security Policies

Once you create security policies on the global policy master, the policy metadata is automatically mirrored on to the other fabrics that are members of the global namespace.

Data Movement Considerations

The policy server in each security-policy fabric manages security policies and composite IDs. A composite ID is a unique, internal integer that maps to a security policy or set of security policies. The policy server stores the mapping in an internal volume named mapr.pbs.composite.

When you assign a security policy to a filesystem resource, the composite ID for that security policy is stored with the resource. Storing the composite ID with the resource instead of the security policy itself optimizes storage. For example, if a policy named HIPAA maps to composite ID 200, this composite ID is stored with any file you tag with HIPAA.

Security policies are shared across the security policy domain, but composite IDs are not. The same security policy on fabricA will have a different composite ID on fabricB and fabricC, as shown in the following table:
Fabric Name Security Policy Fabric ID
fabricA HIPAA 200
fabricB HIPAA 500
fabricC HIPAA 800

By default, up to one million composite IDs can be created instantly after which there is a throttle process in place. The default limit of one million composite IDs is sufficient for about one thousand security policies. Using security policies as intended should not trigger the throttle process. However, using security policies for general tagging purposes can quickly exhaust composite IDs and trigger throttling.

Important Notes About Composite IDs
  • You cannot see or interact with composite IDs. However, if you copy a file from one fabric to another, only the data is copied. The policy server on the destination fabric does not recognize the composite ID associated with the file and therefore cannot enforce the access controls configured in the policy. To avoid this issue, use mirroring to synchronize data. During mirroring, security policies are propagated to the destination fabric. The policy server on the destination fabric assigns new composite IDs to the security policies before data synchronization starts. The composite ID/security policy mappings are present when data synchronizes.
  • Do not schedule mirroring for the composite ID internal volume mapr.pbs.composite.
  • Composite IDs are only used with filesystem resources. The database stores policies as an array of policy IDs in the key-value store. The database policy IDs are unique across the global policy domain, which simplifies table replication. For example, policy IDs in JSON tables can be copied from one fabric to another. The server deals with the policy ID, not the policy name. Policy IDs are evaluated and translated to the policy name on the client side.