Cloud Asset V1 API - Class Google::Cloud::OrgPolicy::V1::Policy::BooleanPolicy (v0.32.0)

Version 0.32.0

• 1.0.2 (latest)
• 1.0.1
• 0.32.0
• 0.31.0
• 0.30.0
• 0.29.3
• 0.28.1
• 0.27.0
• 0.26.1
• 0.25.0
• 0.24.0
• 0.23.0
• 0.22.0
• 0.21.1
• 0.20.1
• 0.19.0
• 0.18.0
• 0.17.3

Reference documentation and code samples for the Cloud Asset V1 API class Google::Cloud::OrgPolicy::V1::Policy::BooleanPolicy.

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

Inherits

• Object

Extended By

• Google::Protobuf::MessageExts::ClassMethods

Includes

• Google::Protobuf::MessageExts

Methods

#enforced

def enforced() -> ::Boolean

Returns

• (::Boolean) — 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.

#enforced=

def enforced=(value) -> ::Boolean

Parameter

• value (::Boolean) — 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.

Returns

• (::Boolean) — 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.