Security Policy Domain and Policy Management

This topic describes the security policy domain, how to create the security-policy domain, how to create security policies, and how to propagate the security policies to clusters within the security policy domain.

A security-policy domain is a group of clusters that directly or indirectly share data and use the same security policies to control access to the data. A security-policy domain consists of one master security-policy cluster and zero or more member security-policy clusters to create a global security-policy namespace. Before you can create security policies, you must set one cluster as the security-policy master.

Each security-policy cluster operates independently and therefore does not require network connectivity to the other clusters to enforce policies. A security-policy server in each of the security-policy clusters enforces the policies and manages the security-policy metadata in an internal volume named mapr.pbs.base.

You can only create and modify security policies on the cluster designated as the global policy master. When you create or update security policies, the policy server updates the mapr.pbs.base volume with the security policy metadata. The policy server does not propagate the security policies to member clusters. To propagate the policies to a member cluster, you must schedule volume mirroring or export the metadata to a file and then import the file into a member cluster. Once a member cluster has the security-policy metadata, the metadata can be propagated from that cluster to other member clusters using the same methods.

In the following diagram, Member1 and Member2 get the security policy metadata from Master and Member4 and Member3 get the policy metadata from Member1 and Member2. If Member2 goes down, Member3 can mirror from Master or Member1 or Member4, assuming that they already have the policy metadata.

Important: If the master security-policy cluster goes down, there is no automatic fail-over or recovery for security policies. If this occurs, promote a member cluster to global policy master. If or when the original master cluster is working again, set it to member. Configuring the Global Policy Master contains the steps required to change the global master policy cluster.

1 – Create a Security Policy Domain

By default, all clusters are member security-policy clusters. You cannot create security policies until you set one cluster as the global policy master. You can set a cluster as the global policy master from the Control System (GUI) or CLI through the cldb.pbs.global.master option. See Configuring the Global Policy Master for instructions.

A best practice is to create only one security-policy domain. Plan your security-policy domain such that the security policies you create can be applied to resources across all clusters in the domain. The UID must be consistent across all clusters in the domain, similar to ACEs.

Note: For future reference, note which cluster you set as the global policy master. There is no failover or recovery if the cluster specified as the master goes down. If a master cluster needs to go offline or fails, set one of the member security-policy clusters as the new master. When the original master cluster comes back up, set it as a member cluster. To identify which cluster is master, run:

maprcli dashboard info -json | grep -i global "globalPolicyMaster":true

You can also identify the role of a cluster in the Control System.

2 - Create and Update Security Policies on the Global Policy Master

You can create and update security policies on the global policy master only. You cannot create or modify security policies on member security-policy clusters. See Creating Security Policies for instructions.

The following table lists the operations you can and cannot perform on the global policy master and member security-policy clusters:

Security policy cluster type	Allowed operations	Disallowed operations
Master (cluster set as the global policy master)	Create Modify Export View Tagging	Import
Member	Import Export View Tagging	Create Modify

3 – Propagate Security Policies to Member Clusters

After you create or update security policies on the global policy master, you can schedule volume mirroring or use the export/import commands to propagate the policies to a member cluster. Once a member cluster has the security-policy metadata, it can propagate the policy metadata to the other member clusters through the same methods.

Important: Policies must be present on a destination cluster for tagging and operations, such as mirroring and dump-restore, to succeed. When you restore a volume from a snapshot or promote a snapshot to a read-write volume, the security policies and settings applied to the volume at the time of the snapshot are also restored.

Schedule Volume Mirroring

Schedule automatic volume mirroring to propagate the security-policy metadata in the mapr.pbs.base volume on the global policy master to a member cluster. Once a member cluster has the policy metadata, propagation can occur between the member cluster and other member clusters. Refer to Mirror Volumes for instructions.

Export Policy Metadata from the Global Policy Master

Manually export the security policy metadata in the mapr.pbs.base volume on the master cluster to a file and then import the file into a member cluster. Once the member cluster has the policy metadata, you can export from that member cluster and then import into another member cluster.

Run policy export on the global policy master cluster, and then run policy import on the target member cluster.

Data Movement Considerations

The policy server in each security-policy cluster 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 ClusterA will have a different composite ID on ClusterB and ClusterC.

Cluster Name	Security Policy	Cluster ID
ClusterA	HIPAA	200
ClusterB	HIPAA	500
ClusterC	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 cluster to another, only the data is copied. The policy server on the destination cluster 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 cluster. The policy server on the destination cluster 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 cluster 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.