Package google.cloud.orgpolicy.v1

Index

Policy (message)
Policy.BooleanPolicy (message)
Policy.ListPolicy (message)
Policy.ListPolicy.AllValues (enum)
Policy.RestoreDefault (message)

Policy

Defines a Cloud Organization Policy which is used to specify Constraints for configurations of Cloud Platform resources.

Fields
`version`	`int32` Version of the `Policy`. Default version is 0;
`constraint`	`string` The name of the `Constraint` the `Policy` is configuring, for example, `constraints/serviceuser.services`. A list of available constraints is available. Immutable after creation.
`etag`	`bytes` An opaque tag indicating the current version of the `Policy`, used for concurrency control. When the `Policy` is returned from either a `GetPolicy` or a `ListOrgPolicy` request, this `etag` indicates the version of the current `Policy` to use when executing a read-modify-write loop. When the `Policy` is returned from a `GetEffectivePolicy` request, the `etag` will be unset. When the `Policy` is used in a `SetOrgPolicy` method, use the `etag` value that was returned from a `GetOrgPolicy` request as part of a read-modify-write loop for concurrency control. Not setting the `etag`in a `SetOrgPolicy` request will result in an unconditional write of the `Policy`.
`update_time`	`Timestamp` The time stamp the `Policy` was previously updated. This is set by the server, not specified by the caller, and represents the last time a call to `SetOrgPolicy` was made for that `Policy`. Any value set by the client will be ignored.
Union field `policy_type`. The field to populate is based on the `constraint_type` value in the `Constraint`. `list_constraint` => `list_policy` `boolean_constraint` => `boolean_policy` A `restore_default` message may be used with any `Constraint` type. Providing a *_policy that is incompatible with the `constraint_type` will result in an `invalid_argument` error. Attempting to set a `Policy` with a `policy_type` not set will result in an `invalid_argument` error. `policy_type` can be only one of the following:
`list_policy`	`ListPolicy` List of values either allowed or disallowed.
`boolean_policy`	`BooleanPolicy` For boolean `Constraints`, whether to enforce the `Constraint` or not.
`restore_default`	`RestoreDefault` Restores the default behavior of the constraint; independent of `Constraint` type.

BooleanPolicy

Used in policy_type to specify how boolean_policy will behave at this resource.

Fields

Fields
`enforced`	`bool` If `true`, then the `Policy` is enforced. If `false`, then any configuration is acceptable. Suppose you have a `Constraint` `constraints/compute.disableSerialPortAccess` with `constraint_default` set to `ALLOW`. A `Policy` for that `Constraint` exhibits the following behavior: - If the `Policy` at this resource has enforced set to `false`, serial port connection attempts will be allowed. - If the `Policy` at this resource has enforced set to `true`, serial port connection attempts will be refused. - If the `Policy` at this resource is `RestoreDefault`, serial port connection attempts will be allowed. - If no `Policy` is set at this resource or anywhere higher in the resource hierarchy, serial port connection attempts will be allowed. - If no `Policy` is set at this resource, but one exists higher in the resource hierarchy, the behavior is as if the`Policy` were set at this resource. The following examples demonstrate the different possible layerings: Example 1 (nearest `Constraint` wins): `organizations/foo` has a `Policy` with: {enforced: false} `projects/bar` has no `Policy` set. The constraint at `projects/bar` and `organizations/foo` will not be enforced. Example 2 (enforcement gets replaced): `organizations/foo` has a `Policy` with: {enforced: false} `projects/bar` has a `Policy` with: {enforced: true} The constraint at `organizations/foo` is not enforced. The constraint at `projects/bar` is enforced. Example 3 (RestoreDefault): `organizations/foo` has a `Policy` with: {enforced: true} `projects/bar` has a `Policy` with: {RestoreDefault: {}} The constraint at `organizations/foo` is enforced. The constraint at `projects/bar` is not enforced, because `constraint_default` for the `Constraint` is `ALLOW`.

enforced

bool

If true, then the Policy is enforced. If false, then any configuration is acceptable.

Suppose you have a Constraint constraints/compute.disableSerialPortAccess with constraint_default set to ALLOW. A Policy for that Constraint exhibits the following behavior: - If the Policy at this resource has enforced set to false, serial port connection attempts will be allowed. - If the Policy at this resource has enforced set to true, serial port connection attempts will be refused. - If the Policy at this resource is RestoreDefault, serial port connection attempts will be allowed. - If no Policy is set at this resource or anywhere higher in the resource hierarchy, serial port connection attempts will be allowed. - If no Policy is set at this resource, but one exists higher in the resource hierarchy, the behavior is as if thePolicy were set at this resource.

The following examples demonstrate the different possible layerings:

Example 1 (nearest Constraint wins): organizations/foo has a Policy with: {enforced: false} projects/bar has no Policy set. The constraint at projects/bar and organizations/foo will not be enforced.

Example 2 (enforcement gets replaced): organizations/foo has a Policy with: {enforced: false} projects/bar has a Policy with: {enforced: true} The constraint at organizations/foo is not enforced. The constraint at projects/bar is enforced.

Example 3 (RestoreDefault): organizations/foo has a Policy with: {enforced: true} projects/bar has a Policy with: {RestoreDefault: {}} The constraint at organizations/foo is enforced. The constraint at projects/bar is not enforced, because constraint_default for the Constraint is ALLOW.

ListPolicy

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_under field of the associated Constraint defines whether ancestry prefixes can be used. You can set allowed_values and denied_values in the same Policy if all_values is ALL_VALUES_UNSPECIFIED. ALLOW or DENY are used to allow or deny all values. If all_values is set to either ALLOW or DENY, allowed_values and denied_values must be unset.

Fields
`allowed_values[]`	`string` List of values allowed at this resource. Can only be set if `all_values` is set to `ALL_VALUES_UNSPECIFIED`.
`denied_values[]`	`string` List of values denied at this resource. Can only be set if `all_values` is set to `ALL_VALUES_UNSPECIFIED`.
`all_values`	`AllValues` The policy all_values state.
`suggested_value`	`string` Optional. The Google Cloud Console will try to default to a configuration that matches the value specified in this `Policy`. If `suggested_value` is not set, it will inherit the value specified higher in the hierarchy, unless `inherit_from_parent` is `false`.
`inherit_from_parent`	`bool` 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/foo` has a `Policy` with values: {allowed_values: "E1" allowed_values: "E2"} `projects/bar` has a `Policy` with: {all: DENY} The accepted values at `organizations/foo` are `E1`, 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`.

AllValues

This enum can be used to set Policies that apply to all possible configuration values rather than specific values in allowed_values or denied_values.

Setting this to ALLOW will mean this Policy allows all values. Similarly, setting it to DENY will mean no values are allowed. If set to either ALLOW or DENY,allowed_valuesanddenied_valuesmust be unset. Setting this toALL_VALUES_UNSPECIFIEDallows for settingallowed_valuesanddenied_values`.

Enums
`ALL_VALUES_UNSPECIFIED`	Indicates that allowed_values or denied_values must be set.
`ALLOW`	A policy with this set allows all values.
`DENY`	A policy with this set denies all values.

RestoreDefault

This type has no fields.

Ignores policies set above this resource and restores the constraint_default enforcement behavior of the specific Constraint at this resource.

Suppose that constraint_default is set to ALLOW for the Constraint constraints/serviceuser.services. Suppose that organization foo.com sets a Policy at their Organization resource node that restricts the allowed service activations to deny all service activations. They could then set a Policy with the policy_type restore_default on several experimental projects, restoring the constraint_default enforcement of the Constraint for only those projects, allowing those projects to have all services activated.