Organization Policy Service gives you centralized, programmaticcontrol over your organization's resources. As theorganization policyadministrator,you can define an organization policy, which is a set of restrictions calledconstraints that apply toGoogle Cloud resources and descendants of those resources in theGoogle Cloud resourcehierarchy.

This page provides supplemental information aboutorganizationpolicyconstraints that apply to Cloud Load Balancing. You use organization policyconstraints to enforce settings across an entire project, folder,or organization.

Organization policies only apply to new resources. Constraints are notenforced retroactively. If you have pre-existing load-balancing resources thatare inviolation of anew organization policy, you will need to address such violations manually.

For a complete list of available constraints, seeOrganization policyconstraints.

Restrict load balancer types

Use an organization policy to restrict the Cloud Load Balancing types thatcan be created in your organization. Set the following organization policyconstraint:

• Name: Restrict Load Balancer Creation Based on Load Balancer Types
• ID:constraints/compute.restrictLoadBalancerCreationForTypes

When you set thecompute.restrictLoadBalancerCreationForTypesconstraint, you specify an allowlist or denylist of the Cloud Load Balancingtypes. The list of allowed or denied values can only include values from thefollowing list:

• Application Load Balancers

  • GLOBAL_EXTERNAL_MANAGED_HTTP_HTTPS for the global external Application Load Balancer
  • EXTERNAL_HTTP_HTTPS for the classic Application Load Balancer
  • GLOBAL_INTERNAL_MANAGED_HTTP_HTTPS for the cross-region internal Application Load Balancer
  • EXTERNAL_MANAGED_HTTP_HTTPS for the regional external Application Load Balancer
  • INTERNAL_HTTP_HTTPS for the regional internal Application Load Balancer

• Proxy Network Load Balancers

  • GLOBAL_EXTERNAL_MANAGED_TCP_PROXY for the global external proxy Network Load Balancer with aTCP proxy
  • GLOBAL_EXTERNAL_MANAGED_SSL_PROXY for the global external proxy Network Load Balancer withan SSL proxy
  • EXTERNAL_TCP_PROXY for the classic proxy Network Load Balancer with a TCP proxy
  • EXTERNAL_SSL_PROXY for the classic proxy Network Load Balancer with an SSL proxy
  • GLOBAL_INTERNAL_MANAGED_TCP_PROXY for the cross-region internal proxy Network Load Balancerwith a TCP proxy
  • REGIONAL_EXTERNAL_MANAGED_TCP_PROXY for the regional external proxy Network Load Balancerwith a TCP proxy
  • REGIONAL_INTERNAL_MANAGED_TCP_PROXY for the regional internal proxy Network Load Balancerwith a TCP proxy

• Passthrough Network Load Balancers

  • EXTERNAL_NETWORK_TCP_UDP for the external passthrough Network Load Balancer
  • INTERNAL_TCP_UDP for the internal passthrough Network Load Balancer

To include all internal or all external load balancer types, use thein:prefix followed byINTERNAL orEXTERNAL. For example, allowingin:INTERNALallows all internal load balancers from the preceding list.

For sample instructions about how to use this constraint, seeSet up listconstraints with organizationpolicies.

After you set the policy, the policy is enforced when adding the respectiveGoogle Cloudforwardingrules. The constraint is notenforced on existing Cloud Load Balancing configurations.

If you attempt to create a load balancer of a type that violates theconstraint, the attempt fails and an error message is generated. The errormessage has the following format:

Constraint constraints/compute.restrictLoadBalancerCreationForTypesviolated for projects/PROJECT_NAME. Forwarding Rule projects/PROJECT_NAME/region/REGION/forwardingRules/FORWARDING_RULE_NAMEof typeSCHEME is not allowed.

If you set multiplerestrictLoadBalancerCreationForTypes constraints atdifferent resource levels, they areenforcedhierarchically.For this reason, we recommended that you set theinheritFromParent field totrue, which ensures that policies at higher layers are also considered.

GKE error messages

If you are using Google Kubernetes Engine (GKE), and someone in your organizationhas created an organization policy that limits which types of load balancers canbe created, then you'll see an error message similar to the following:

Warning  Sync    28s   loadbalancer-controller  Error during sync: error runningload balancer syncing routine: loadbalancerFORWARDING_RULE_NAMEdoes not exist: googleapi: Error 412:Constraint constraints/compute.restrictLoadBalancerCreationForTypes violated forprojects/PROJECT_ID. Forwarding Ruleprojects/PROJECT_ID/global/forwardingRules/FORWARDING_RULE_NAMEof typeLOAD_BALANCER_TYPE is not allowed, conditionNotMet

Depending on the policy, this might limit your ability to create new loadbalancer resources such asServices,Ingresses, orGateways. Contact yourorganization policy administrators to help you understand which restrictions arein place.

You can view GKE error messages by running the following commands:

kubectl get events -w

kubectl describeRESOURCE_KINDNAME

Replace the following:

• RESOURCE_KIND: the kind of load balancer,ingress orservice
• NAME: the name of the load balancer

Disable global load balancing

This legacy managed constraint disables creation ofglobal load-balancingproducts.When enforced, only regional load-balancing products without global dependenciescan be created.

• Name: Disable Global Load Balancing
• ID:constraints/compute.disableGlobalLoadBalancing

By default, users are allowed to create global load-balancing products.

For sample instructions about how to use this constraint, seeSet up booleanconstraints with organizationpolicies.

Restrict the types of protocol forwarding deployments

Use anorganizationpolicy to restrict thetypes of protocol forwarding deployments (internal or external) that can becreated in your organization. Set the following organization policy constraint:

• Name: Restrict Protocol Forwarding Based on type of IP Address
• ID:constraints/compute.managed.restrictProtocolForwardingCreationForTypes

To configure thecompute.managed.restrictProtocolForwardingCreationForTypesconstraint, you specify an allowlist or denylist of the type of protocolforwarding deployment to be allowed or denied. The list of allowed or deniedvalues can only include the following values:

• INTERNAL
• EXTERNAL

By default, newly created organizations have this policy configured to allowonlyINTERNAL protocol forwarding. That is, any forwarding rules associatedwith target instances are limited to using internal IP addresses only. If youwant to use protocol forwarding with external IP addresses, or, if you want toprohibit users from using protocol forwarding with internal IP addresses, thenyou need to update this organization policy.

After you update the policy, the changes are enforced when you create any newforwarding rules associated with target instances. The constraint is notenforced retroactively on existing protocol forwarding configurations.

For sample instructions about how to use this constraint, seeSet up listconstraints with organizationpolicies.

If you attempt to create a protocol forwarding deployment of a type thatviolates the constraint, the attempt fails and an error message is generated.The error message has the following format:

Constraint constraints/compute.managed.restrictProtocolForwardingCreationForTypesviolated for projects/PROJECT_NAME. Forwarding Ruleprojects/PROJECT_NAME/region/REGION/forwardingRules/FORWARDING_RULE_NAMEof typeSCHEME is not allowed.

If you set multiplecompute.managed.restrictProtocolForwardingCreationForTypesconstraints at different resource levels, and if you set theinheritFromParent field totrue, then the constraints are enforcedhierarchically.

Enforce Shared VPC restrictions

Use the following organization policies to restrict how users are allowed toset up Shared VPC deployments.

Restrict Shared VPC host projects

This legacy managed constraint lets you restrict the Shared VPC hostprojects that a resource can attach to.

• Name: Restrict Shared VPC host projects
• ID:constraints/compute.restrictSharedVpcHostProjects

By default, a project can attach to any host project in the same organization,thereby becoming a service project. When you set thecompute.restrictSharedVpcHostProjects constraint, you specify an allowlist ordenylist of host projects in the following ways:

• Specify a project in the following format:
  • projects/PROJECT_ID
• Specify a project, folder, or organization. The constraint appliesto all projects under the specified resource in the resource hierarchy. Use thefollowing format:
  • under:organizations/ORGANIZATION_ID
  • under:folders/FOLDER_ID

For sample instructions about how to use this constraint, seeSet up listconstraints with organizationpolicies.

Restrict Shared VPC subnetworks

This legacy managed constraint defines the set of Shared VPC subnetsthat eligible resources can use. This constraint does not apply to resourceswithin the same project.

• Name: Restrict Shared VPC subnetworks
• ID:constraints/compute.restrictSharedVpcSubnetworks

By default, eligible resources can use any Shared VPC subnet. Whenyou set thecompute.restrictSharedVpcSubnetworks constraint, you specify arestricted list of subnets in the following ways:

• Specify a subnet in the following format:
  • projects/PROJECT_ID/regions/REGION/subnetworks/SUBNET_NAME
• Specify a project, folder, or organization. The constraint appliesto all subnets under the specified resource in the resource hierarchy. Use thefollowing format:
  • under:organizations/ORGANIZATION_ID
  • under:folders/FOLDER_ID
  • under:projects/PROJECT_ID

For sample instructions about how to use this constraint, seeSet up listconstraints with organizationpolicies.

Restrict cross-project backend buckets and backend services

You can use this constraint to limit the backend services and backend bucketsthat a URL map can reference. This constraint does not apply to backend servicesand backend buckets within the same project as the URL map.

• Name: Restrict cross-project backend buckets and backend services
• ID:constraints/compute.restrictCrossProjectServices

By default, a URL map in one project can reference compatible backend servicesand backend buckets from other projects in the same organization as long as theuser performing the action has thecompute.backendServices.use,compute.regionBackendServices.use, orcompute.backendBuckets.use permission.

To configure therestrictCrossProjectServices constraint, you can specify anallowlist or denylist of backend services or backend buckets in the followingways:

• Specify backend services in the following format:
  • projects/PROJECT_ID/regions/REGION/backendservices/BACKEND_SERVICE_NAME
  • projects/PROJECT_ID/global/backendservices/BACKEND_SERVICE_NAME

• Specify backend buckets in the following format:

  • projects/PROJECT_ID/regions/REGION/backendbuckets/BACKEND_BUCKET_NAME
  • projects/PROJECT_ID/global/backendbuckets/BACKEND_BUCKET_NAME

• Specify a project, folder, or organization. The constraint applies to allbackend services and backend buckets under the specified resource in theresource hierarchy. Use the following format:

  • under:organizations/ORGANIZATION_ID
  • under:folders/FOLDER_ID
  • under:projects/PROJECT_ID

After you set up an organization policy with this constraint, the constraintgoes into effect the next time you use thegcloud compute url-maps command toattach a backend service or a backend bucket to a URL map. The constraint doesnot retroactively affect existing references to any cross-project backendservices or backend buckets.

This constraint applies to all deployment types, Shared VPC included. Toavoid conflicts, we recommend not using both this constraint and thecompute.restrictSharedVpcBackendServices constraint described in the nextsection.

For sample instructions about how to use this constraint, seeSet up listconstraints with organizationpolicies.

Restrict Shared VPC backend services

You can use this constraint to limit the backend services that a URL map canreference in Shared VPC deployments that usecross-project service referencing.This constraint does not apply to backend services within the same project asthe URL map.

• Name: Restrict Shared VPC backend services
• ID:constraints/compute.restrictSharedVpcBackendServices

We recommend using thecompute.restrictCrossProjectServices constraintdocumented in the previous section instead. Thecompute.restrictCrossProjectServices constraint applies to all deploymenttypes, Shared VPC or otherwise, and applies to both backend buckets andbackend services.

Restrict Shared VPC project lien removal

This legacy managed constraint restricts the set of users that can remove aShared VPC host project lien without organization-level permission wherethis constraint is already set toTrue.

• Name: Restrict Shared VPC project lien removal
• ID:constraints/compute.restrictXpnProjectLienRemoval

By default, any user with the permission to update liens can remove aShared VPC host project lien. Enforcing this constraint requires thatpermission be granted at the organization level.

For sample instructions about how to use this constraint, seeSet up booleanconstraints with organizationpolicies.

Restrict TLS capabilities with custom constraints

To meet your compliance requirements and restrict certain Transport LayerSecurity (TLS) capabilities, you can create the following organization policyconstraint and use it along withcustom constraints for SSL policyresources:

• Name: Require SSL policy
• ID:constraints/compute.requireSslPolicy

By using thecompute.requireSslPolicy constraint along with your owncustom constraints for SSL policy fields,you can create restrictions tailored to your deployments. For example, you cando the following:

• Improve security and meet compliance requirements by restricting the use ofearlier TLS versions (such as 1.0 and 1.1) and cipher suites.
• Improve performance by reducing the number of required handshakes and byimproving the compatibility of the load balancer with clients.
• Apply a restriction to a specific resource node and its children. For example,if you deny TLS version 1.0 for an organization, it is also denied for allfolders and projects (children) that descend from that organization.

To enforce an SSL policy for an Application Load Balancer or a proxy Network Load Balancer,you mustattach it to the load balancer's target HTTPS proxy or target SSLproxy.

To update existing SSL policies, seeManage SSL policies.

Use boolean rules in organization policies

gcloud resource-manager org-policies enable-enforce \    --organizationORGANIZATION_ID \    constraints/compute.restrictXpnProjectLienRemoval

gcloud resource-manager org-policies enable-enforce \    --organizationORGANIZATION_ID \    constraints/compute.disableGlobalLoadBalancing

Set up list rules in organization policies

Set up an organization policy to apply an SSL policy to target HTTPS proxies and target SSL proxies

To set up custom constraints, seeUse custom constraints to restrict TLScapabilities.

What's next

• To learn about the resource hierarchy that applies to organization policies,seeResourcehierarchy.
• For an overview of organization policies and constraints, seeIntroduction tothe Organization PolicyService.
• For instructions about working with constraints and organization policiesin the Google Cloud console, seeIntroduction to the Organization Policy Service.
• For instructions about working with constraints and organization policiesingcloud, seeUsingconstraints.
• For a complete list of available constraints, seeOrganization policyconstraints.
• For API methods relevant to organization policies, see theCloud Resource Manager APIreference documentation.