Security Policy Inheritance and Replication

Security policies are inherited during data-object creation and copied over during mirroring and replication.

Security policies cannot be mirrored or replicated unless you have configured a global policy master. For information about the security policy domain and configuring a global policy master, see Security Policy Domain and Policy Management.

How Volumes, Directories, and Tables Inherit Security Policy Settings

Volume Inheritance

By default, child and mirror (remote and local) volumes inherit the following volume properties:

securitypolicy
enforcementmode

A mirror volume can inherit the properties from the source volume of the mirror. A standard volume can inherit properties from another standard volume, referred to as the parent volume in this context. In addition, data objects inside a volume can inherit the security settings from the volume in which they reside.

The allowgrant flag controls whether new volumes inherit the properties set in the parent volume. The parent volume is the last volume in the path parameter when you create and mount a volume using the path parameter for the mount point. Volumes created under the parent volume inherit the properties of the parent volume. If you modify the settings in the parent volume after you create child volumes, the modified properties in the parent volume do not propagate to the child volumes.

Directory Inheritance

The setinherit flag controls whether or not subdirectories and files inherit the security policies applied to the parent directory. When setinherit is enabled (true), new files and directories under the parent directory inherit the security policies applied to the parent directory. If you modify the security policies applied to the parent directory, existing files and subdirectories within the parent directory do not change

When setinherit is disabled (false), files and subdirectories created under the parent directory do not inherit the security policies applied to the parent directory. By default, the files and directories get the default Access Control Expression (ACE), an empty string (""

). Note that POSIX mode bits are set on the files and directories.

Table Inheritance

JSON tables inherit the enforcementmode set on the parent volume. The enforcement mode controls which data access controls the system enforces on the volume and data objects within the volume. You cannot set the enforcement mode directly on a table. See Enforcing Security Policies at the Volume-Level.

When a security policy is applied to a table, column families created within the table inherit the security policy, as described:

Any new column family created (without a security policy) inherits and enforces the table security policy during runtime. The security policy of the column family, which is undefined, remains unchanged.
Any new column family created (with a column family security policy) enforces the security policy of the table in conjunction with the security policy applied to the column family.
Modifying the security policy applied to the table does not affect the security policies applied to column families, whether they are defined or not.
All column families (without security policies) inherit and enforce the latest security policies of the table.

Within a JSON table, each comma-separated segment of characters is called a JSON field. For example, a given JSON field path may be represented as “a.b.c.” One or more security policy tags can be assigned to a JSON field. If a JSON field has no security policy, the field inherits the security policy of its predecessor at the field level. For example, if security policies are applied to fields "a" and "c," but not to "b," field "b" inherits its permission level from field "a." This behavior mimics the inheritance behavior of ACEs.

How Security Policy Settings Propagate During Volume and Table Replication

Volume Replication

The following table describes how security policy settings propagate during volume replication:

Data Object	Behavior
Standard and local mirror volumes	The system copies the security policy settings over during replication.
Remote mirror volumes	The system copies the security policy settings and policies with which the resource is tagged, over to the destination cluster during replication, if the following condition is met: The remote mirror volume cluster must be associated with the same master security policy cluster as the source volume cluster. For information about master security policy clusters, see Setting Global Configuration Options for Policy-Based Security.
Tiered volumes	The system does not propagate the security policy settings because security is enforced by the primary (or front-end) volume
Files and directories	When individual files and directories are copied, the security policies associated with the files and directories are also copied over.

JSON Table Replication

When tables are replicated, all security policies attached are transferred at time of replication.

The following table describes how security policy settings propagate during some common replication scenarios:

Replication Scenario	Description
Replicate tables from a data-fabric 6.2.x cluster to a pre-data-fabric 6.2.0 cluster	Replication fails because the pre-data-fabric 6.2.0 destination cluster does not support Policy-Based Security.
Replicate tables from a data-fabric 6.2.x cluster to another data-fabric 6.2.x (or later) cluster	The security policies applied to tables, column families, and columns are preserved. Note these considerations for replication in this scenario: When creating the replica as part of the ReplicaSetup phase in Autosetup, the destination table is created with the same security policy settings, and column family and column security policies as the source. The security policies defined for the source cluster must be available on the destination cluster by way of the security policy global namespace. See Setting Global Configuration Options for Policy-Based Security. If a security policy defined for the source is not found on the destination, creation of the table, column family, or column will fail, thereby failing the ReplicaSetup. Autosetup will keep retrying the ReplicaSetup until the tags are replicated. Column-family creation from the Gateway during replication is not distinguishable from column-family creation from the client.
Change Data Capture (CDC)	When you replicate to a CDC stream, the system ignores and drops the security policies.
Secondary-index table schema	While security policies are not replicated as part of a secondary-index table schema, the same security policies are enforced as the primary table. This behavior is similar to the behavior of ACEs on column families and columns.