Security Policy Domain and Policy Management
Describes how to create the security-policy domain, propagate security policies to all the clusters within the domain, and some considerations for moving data.
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, Member1, or Member4.
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.
maprcli dashboard info -json | grep -i global "globalPolicyMaster":true
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.
| Security-policy cluster type | Allowed operations | Prohibited operations |
|---|---|---|
| Master (cluster set as the global policy master) |
|
|
| Member |
|
|
3 – Propagate Security Policies to Member Clusters
- Schedule Volume Mirroring
-
Schedule automatic volume mirroring to propagate the security-policy metadata in the
mapr.pbs.basevolume 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.basevolume 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.
| 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.
- 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.