Policy-Based Security

Starting in Data Fabric 6.2.0 (MEP 7.0.0), the Data Fabric Platform supports Policy-Based Security, a feature that administrators can use to classify security controls into a manageable number of security policies.

A security policy is a classification that encapsulates security controls on data. Security controls define which users are authorized to access and modify data objects, whether to audit data operations, and whether to protect data in motion with wire-level encryption. Administrative users can create and manage security policies through the Control System, maprcli, REST API, Hadoop and Linux commands, and Java APIs.

For example, consider a scenario in which one of your data classifications is sensitive employee data. With policy-based security, you can create a security policy named employeeData. When you create the security policy, you define access control expressions (ACEs) that specify which users are allowed to access the employee data. You can then apply the security policy to relevant employee data objects. When you need to grant new users access to the employee data, you only need to modify that one security policy instead of modifying the ACEs defined on each of the employee data objects.

The following image depicts the Policy-Based Security architecture and process within the Data Fabric Platform:
Create security policies Tag data with security policies Enforcing Security Policies at the Volume-Level

The following steps summarize how Policy-Based Security works, list the requirements for creating and using security policies, and include links to related documentation. The information presented is intended to familiarize you with Policy-Based Security before you start creating and using security policies. Once you are familiar with Policy-Based Security, you may also be interested in the Policy-Based Security Quick Reference.

1. Create security policies

An administrator defines data classifications for a business and then creates a security policy for each classification. A data classification represents a group of data with corresponding security controls to control access to data. Security policies can include the following security controls:
Security Control Description
ACEs (access control expressions) Authorizes users and groups to access and modify various data objects; lists users and groups with read, write, and execute access to the data objects.
Auditing Data Access Operations Advanced auditing controls that define which operations on the data to audit.
Encryption in Data Fabric On-wire and data-at-rest encryption.
An administrator with cluster-level cp (create security policy) permission can create security policies through the Control System, maprcli command-line interface, or REST API. Administrators with the proper permissions can view and modify security policies. The administrator that creates a security policy can delegate the management of the security policy to a policy owner. Security policies can be removed from data objects as needed.
Table 1. Requirements for creating and using security policies
Some setup is required before an administrator can create security policies and apply them to data objects. The following points briefly discuss the requirements and provide links to related topics for additional information:
  • Enable Policy-Based Security
    Policy-Based Security is enabled by default in new data-fabric installations (version 6.2.0 and later). If you upgrade from an earlier version of data-fabric, you must manually enable Policy-Based Security. Before you enable Policy-Based Security, verify that all features in your current version are enabled. If you upgrade from a version that does not support extended attributes, enable extended attributes before you enable Policy-Based Security, as shown:
    /opt/mapr/bin/maprcli cluster feature enable -name mfs.feature.fileace.support
    To enable Policy-Based Security, run:
    /opt/mapr/bin/maprcli cluster feature enable -name mfs.feature.pbs
    For changes to take effect, run the following command to restart the CLDB service:
    maprcli node services -cldb start -nodes <node name>
    Attention: If you enable extended attribute support on a release that supports generic extended attributes but does not support Policy-Based Security, the extended attribute for security policy (security.mapr.policy) is treated as a generic key-value extended attribute and is not interpreted as a security policy attribute by the Data Fabric file system.

    See Upgrade Workflows (Release 6.1 to 6.2) and Installer.

  • Designate a global policy master

    You must set one cluster as the global policy master before you can create security policies. The cluster set as the global policy master is the only cluster on which you can create or update security policies. After you create or update policies, you must propagate the policies to other clusters via volume mirroring or export/import commands, as described in Security Policy Domain and Policy Management.

  • Set permissions for creating and managing security policies

    Administrative permissions are required to create and manage security policies. Administrators can set permissions through cluster-level and policy-level ACLs. Policy-level permissions can be set when creating and modifying a security policy through the maprcli, REST API, or the Control System.

    • To create security policies, an administrator must have cluster-level cp (create security policy) permission. By default, the cp permission is not assigned to any administrator. Administrators can assign this permission to themselves or other users with administrative privileges.
    • The cluster owner/mapr administrator has overriding permissions and can view, create, and edit any security policy, regardless of the permissions specified in the administrative ACLs, even if the permissions specified in the administrative ACLs are removed.
    • After creating a security policy, the administrator can delegate the management of the policy to a user they define as the policy owner.
    • Any user with a valid mapr ticket can view security policy IDs and names regardless of administrative permissions.

    See Granting Security Policy Permissions.

  • Set the security policy state

    The security policy state indicates whether a security policy can be applied to data objects and whether security policy ACEs are enforced. When a security policy is first created, users cannot apply it to data objects until a user with the appropriate privileges changes the security policy to allow tagging. By default, a security policy has allowtagging=false and accesscontrol=Disarmed when created.

    In their default state, policies applied to resources are not enforced until a user with the appropriate privileges changes the access control from Disarmed to Armed.

    See Changing the State of a Security Policy.

    For additional information, see:

2. Tag data objects with security policies

Users with the appropriate permissions can apply security policies to data objects in the Data Fabric Platform. Users can apply security policies to the following data objects:
Data Fabric File System Data Fabric Database
  • Volumes
  • Directories
  • Files
  • JSON tables
  • JSON column families
  • JSON fields
Note: If you upgraded your data-fabric cluster to 6.2.x from a pre-6.2.0 version, you can add security policies to existing tables using the maprcli table set|add command after you enable Policy-Based Security.
Table 2. Requirements for tagging data objects with security policies
Permission requirements vary depending on the Data Fabric Platform core component. The following table lists the users that can apply security policies to data objects in the data-fabric filesystem and data-fabric database:
Data Fabric File System Data Fabric Database
  • Owner of the data object
  • Data Fabric administrator (typically mapr)
  • Superuser (root)

The superuser cannot tag filesystem objects when the cldb.reject.root flag is set.

See Tagging Volumes, Directories, and Files with Security Policies.
  • Data Fabric administrator (typically mapr)
  • User with ACE administrative access (adminaccessperm permission)

See Tagging JSON Tables, Column Families, and Fields with Security Policies

You may also want to read about Security Policy Inheritance and Replication.

Once you tag a file/directory with a security policy, it remains effective preserving the same level of access control, even when you mirror the file/directory to another cluster. To support this, policies across all clusters participating in mirroring come from a global namespace. Hence, policies are only allowed to be created on a cluster that is designated as the global policy master. All other clusters should import the policy created (using the security policy import/export command).

3. Enforce security policies

Security policies ensure consistent security enforcement and prevent applications from bypassing security controls. Applications can securely read and write to a data-fabric cluster because the Data Fabric Platform enforces security policies across all filesystem clients, including the data-fabric FUSE-based POSIX client and NFS. When performing data operations, the Data Fabric Platform automatically enforces the security controls defined in security policies. If security policies are not applied to data objects, the system enforces security controls directly defined on the data objects, such as ACEs or POSIX mode bits.
Table 3. Requirements for enforcing security policies
There are three levels of enforcement for security policies:
  • Security policy level - Enforced through settings that control the security policy state.

    The security policy state indicates whether a security policy can be applied to data objects and whether the system enforces security policy ACEs. When a security policy is first created, you cannot apply it to data objects until you change the security policy state. By default, a security policy has allowtagging=false and accesscontrol=Disarmed when first created. See Changing the State of a Security Policy, policy create, and policy modify.

  • Volume level - Enforced through volume-level enforcement modes.

    The enforcement mode is set at the volume-level and applies to all data objects within a volume, such as files and tables. The enforcement mode defines the security controls to enforce on data objects in a volume during data access. By default, security policies applied to data objects and resource controls (POSIX mode bits or ACEs) are evaluated to determine access. See Volume-Level Security Policy Enforcement Mode, Security Policy Enforcement Process, and Enforcing Security Policies at the Volume-Level.

  • Cluster level - Enforced through the cldb.pbs.access.control.enabled option.

    When the cldb.pbs.access.control.enabled option is disabled, the system does not evaluate or enforce access controls (ACEs set in security policies) for any data operations in the cluster. When disabled, the cldb.pbs.access.control.enabled option overrides volume-level enforcements. The system only evaluates and enforces the POSIX mode bits or ACEs directly applied to data objects to determine access. The system continues to enforce wire-level encryption and auditing controls configured in the security policies. See Disabling Policy Access Controls at the Cluster-Level.

Use Case with Example Configuration

See Example Using Security Policies.

Parent topic: Security