Policy-Based Security

Starting in core version 6.2.0 (EEP 7.0.0), HPE Ezmeral Data Fabric 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. You can create and manage security policies through the Control System, maprcli, REST API, Hadoop and Linux commands, and Java APIs.

You can apply security, such as access control expressions (ACEs), directly on data objects; however, this can be cumbersome and inconsistent especially if you have to modify security settings across thousands of data objects. Instead, you can define the security controls in a security policy and then apply the security policy to the data objects. If you need to modify the security controls on the data objects, just update the security policy. The update propagates across all the data objects to which the policy is applied and the system automatically enforces the controls set in the policy.

For example, consider sensitive employee information as a data classification. You could create a security policy that defines which users are authorized to access the sensitive employee information and then apply the security policy to all the data objects that contain the sensitive information. When you need to add or remove user access to the data, you can easily update the security policy and the change is reflected across all the data objects with sensitive employee information.

The following image shows the Policy-Based Security architecture and process within HPE Ezmeral Data Fabric:

The following steps summarize the Policy-Based Security process, 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, see 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.
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 HPE Ezmeral Data Fabric installations (version 6.2.0 and later). If you upgrade from an earlier version of HPE Ezmeral 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 HPE Ezmeral Data Fabric filesystem.

    See Upgrade Workflows (Release 6.x to 7.0.0) 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 HPE Ezmeral Data Fabric. Users can apply security policies to the following data objects:
HPE Ezmeral Data Fabric File System HPE Ezmeral Data Fabric Database
  • Volumes
  • Directories
  • Files
  • JSON tables
  • JSON column families
  • JSON fields
NOTE If you upgraded your HPE Ezmeral 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 HPE Ezmeral Data Fabric core component. The following table lists the users that can apply security policies to data objects in the HPE Ezmeral Data Fabric filesystem and database:
HPE Ezmeral Data Fabric File System HPE Ezmeral Data Fabric Database
  • Owner of the data object
  • HPE Ezmeral 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.
  • HPE Ezmeral 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.

When you tag an object with a security policy, the policy remains effective when the object is mirrored to another cluster because the clusters are part of a global namespace. This global namespace is created by designating one cluster as the global policy master and the other clusters as members. You can only create policies on the global policy master. Member clusters can import the policies from the global policy master or export them to other member clusters.

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 HPE Ezmeral Data Fabric cluster because HPE Ezmeral Data Fabric enforces security policies across all filesystem clients, including the HPE Ezmeral Data Fabric FUSE-based and NFS POSIX clients. When performing data operations, HPE Ezmeral Data Fabric 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.