Volume-Level Security Policy Enforcement Mode
Before Core 6.2.0, Data Fabric supported enforcement based on mode and ACEs set directly on data objects. With Core 6.2.0 and above, security policies provide an additional or alternative way to control access to data. The volume-level enforcement mode specifies which of these methods a volume uses to govern access to data.
NOTE
If you upgraded to Data Fabric
6.2.x from a pre-6.2.0 version, data objects in volumes behave as they did in the pre-6.2.0
version of Data Fabric if security
policies have not been applied to them.Volume-Level Enforcement Modes
Regardless of the enforcement mode set, the system always enforces the ACEs directly set on a volume. HPE Ezmeral Data Fabric Database tables inherit the enforcement mode setting from the parent volume.
The enforcement mode governs access checks on volumes as follows:
- Mode: PolicyAceAndDataAce (Default)
- Enforce Security Policies:
Yes
- Mode: PolicyAceOnly
- Enforce Security Policies:
Yes
- Mode: DataAceOnly
- Enforce Security Policies:
No
- Mode: PolicyAceAuditAndDataAce (Permissive mode)
- Enforce Security Policies:
Performs checks, but does not fail; audits instead
Important Information Related to the Enforcement Mode
The following sections describe some additional requirements, options, and behaviors
related to the enforcement mode:
- Modifying the enforcement mode
- You must have volume-level ACL permission to change the enforcement mode. You can change the enforcement mode when you create or modify a volume through the Control System, CLI, or REST API. See Enforcing Security Policies at the Volume-Level for instructions.
- Volume-level enforcement mode override
- The only setting that supersedes the volume-level enforcement mode is the
cldb.pbs.access.control.enabled
cluster-level setting. If you disablecldb.pbs.access.control.enabled
, the ACEs set in all security policies are disabled across the cluster. Typically, you would only disable security policies at the cluster-level if the security policies caused a serious issue. See Disabling Policy Access Controls at the Cluster-Level. - Auditing and wire-level encryption
- The enforcement mode does not govern auditing and wire-level encryption; auditing
and wire-level encryption is always enforced regardless of the enforcement mode
set.
- Wire-level encryption for tables is controlled by the filesystem through
hadoop mfs -setnetworkencryption on|off <table_path>
. - Auditing must be enabled at the volume level for auditing to occur. To enable
audit for all data objects in the volume, use the
-forceauditenable
parameter. If auditing is disabled, permissive mode will not audit operations. - You can selectively turn all volume-level audit operations on or off through an
optional
audit
flag. You cannot set this flag on individual objects within a volume. When you set this flag on a volume, it applies to all objects within that volume. See volume create and volume modify. - Data Fabric Database
JSON tables also have an
audit
flag that controls the auditing of database operations. See table create and table edit. - Although you can tag resources at the volume, table, column family, and column (field) level in the database, the database only performs auditing and wire-level encryption at the volume and table level. The database does not perform auditing and wire-level encryption at the column family and column (field) level.
- Wire-level encryption for tables is controlled by the filesystem through
- Snapshot of a volume
- The Snapshot of a volume is set to the enforcement mode that was set on the
volume when the snapshot was taken. For example, if the enforcement mode on a volume
was
PolicyAceOnly
when the snapshot was taken and later changed toPolicyAceAndDataAceOnly
, access to the snapshot is based onPolicyAceOnly
. 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.