inheritFromParent property
Determines the inheritance behavior for this Policy.
By default, a ListPolicy set at a resource supersedes any Policy set
anywhere up the resource hierarchy. However, if inherit_from_parent is
set to true, then the values from the effective Policy of the parent
resource are inherited, meaning the values set in this Policy are added
to the values inherited up the hierarchy. Setting Policy hierarchies
that inherit both allowed values and denied values isn't recommended in
most circumstances to keep the configuration simple and understandable.
However, it is possible to set a Policy with allowed_values set that
inherits a Policy with denied_values set. In this case, the values
that are allowed must be in allowed_values and not present in
denied_values. For example, suppose you have a Constraint
constraints/serviceuser.services, which has a constraint_type of
list_constraint, and with constraint_default set to ALLOW. Suppose
that at the Organization level, a Policy is applied that restricts the
allowed API activations to {E1, E2}. Then, if a Policy is applied to
a project below the Organization that has inherit_from_parent set to
false and field all_values set to DENY, then an attempt to activate any
API will be denied. The following examples demonstrate different possible
layerings for projects/bar parented by organizations/foo: Example 1
(no inherited values): organizations/foo has a Policy with values:
{allowed_values: "E1" allowed_values:"E2"} projects/bar has
inherit_from_parent false and values: {allowed_values: "E3"
allowed_values: "E4"} The accepted values at organizations/foo are E1,
E2. The accepted values at projects/bar are E3, and E4. Example 2
(inherited values): organizations/foo has a Policy with values:
{allowed_values: "E1" allowed_values:"E2"} projects/bar has a Policy
with values: {value: "E3" value: "E4" inherit_from_parent: true} The
accepted values at organizations/foo are E1, E2. The accepted values
at projects/bar are E1, E2, E3, and E4. Example 3 (inheriting
both allowed and denied values): organizations/foo has a Policy with
values: {allowed_values: "E1" allowed_values: "E2"} projects/bar has a
Policy with: {denied_values: "E1"} The accepted values at
organizations/foo are E1, E2. The value accepted at projects/bar
is E2. Example 4 (RestoreDefault): organizations/foo has a Policy
with values: {allowed_values: "E1" allowed_values:"E2"} projects/bar has
a Policy with values: {RestoreDefault: {}} The accepted values at
organizations/foo are E1, E2. The accepted values at projects/bar
are either all or none depending on the value of constraint_default (if
ALLOW, all; if DENY, none). Example 5 (no policy inherits parent
policy): organizations/foo has no Policy set. projects/bar has no
Policy set. The accepted values at both levels are either all or none
depending on the value of constraint_default (if ALLOW, all; if
DENY, none). Example 6 (ListConstraint allowing all):
organizations/foo has a Policy with values: {allowed_values: "E1"
allowed_values: "E2"} projects/bar has a Policy with: {all: ALLOW} The
accepted values at organizations/foo are E1, E2. Any value is accepted at projects/bar. Example 7 (ListConstraint allowing none): organizations/foohas aPolicywith values: {allowed_values: "E1" allowed_values: "E2"}projects/barhas aPolicywith: {all: DENY} The accepted values atorganizations/fooareE1, E2. No value is accepted
at projects/bar. Example 10 (allowed and denied subtrees of Resource
Manager hierarchy): Given the following resource hierarchy O1->{F1, F2};
F1->{P1}; F2->{P2, P3}, organizations/foo has a Policy with values:
{allowed_values: "under:organizations/O1"} projects/bar has a Policy
with: {allowed_values: "under:projects/P3"} {denied_values:
"under:folders/F2"} The accepted values at organizations/foo are
organizations/O1, folders/F1, folders/F2, projects/P1,
projects/P2, projects/P3. The accepted values at projects/bar are
organizations/O1, folders/F1, projects/P1.
Implementation
core.bool? inheritFromParent;