Security Policy Implementation Workflow
Describes the security policy workflow, in general, and the steps in implementing a security policy.
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.
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.
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.
Security-policy fabric type | Allowed operations | Prohibited operations |
---|---|---|
Master (fabric set as the global policy master) |
|
|
Member |
|
|
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.
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.
- 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.