GoogleCloudOrgpolicyV1ListPolicy
import type { GoogleCloudOrgpolicyV1ListPolicy } from "https://googleapis.deno.dev/v1/cloudasset:v1.ts";Used in policy_type to specify how list_policy behaves at this resource.
ListPolicy can define specific values and subtrees of Cloud Resource
Manager resource hierarchy (Organizations, Folders, Projects) that are
allowed or denied by setting the allowed_values and denied_values fields.
This is achieved by using the under: and optional is: prefixes. The
under: prefix is used to denote resource subtree values. The is: prefix
is used to denote specific values, and is required only if the value contains
a ":". Values prefixed with "is:" are treated the same as values with no
prefix. Ancestry subtrees must be in one of the following formats: -
"projects/", e.g. "projects/tokyo-rain-123" - "folders/", e.g. "folders/1234"
- "organizations/", e.g. "organizations/1234" The
supports_underfield of the associatedConstraintdefines whether ancestry prefixes can be used. You can setallowed_valuesanddenied_valuesin the samePolicyifall_valuesisALL_VALUES_UNSPECIFIED.ALLOWorDENYare used to allow or deny all values. Ifall_valuesis set to eitherALLOWorDENY,allowed_valuesanddenied_valuesmust be unset.
§Properties
List of values allowed at this resource. Can only be set if all_values
is set to ALL_VALUES_UNSPECIFIED.
List of values denied at this resource. Can only be set if all_values is
set to ALL_VALUES_UNSPECIFIED.
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.