Organization policy constraints
Stay organized with collections
Save and categorize content based on your preferences.
This page provides a list of all available Google-managed organization policy
constraints.
Automatically enforced constraints
If an organization policy isn't enforced, it inherits from its lowest ancestor
where an organization policy is enforced. If no organization policy is enforced
anywhere in the ancestor hierarchy, the Google-managed default behavior of the
constraint is enforced.
If the Google-managed default behavior of an organization policy constraint
restricts an operation, then that operation is restricted even if you never
explicitly defined an organization policy. To allow those operations, you must
create organization policies that override the parent policy.
The following organization policy constraints have a Google-managed default
behavior that restricts operations:
You can create organization policies using the following constraints.
Managed constraints
Service
Constraint
Description
Compute Engine
Allowed VLAN Attachment encryption settings
This list constraint defines the allowed encryption settings for new VLAN Attachments. By default, VLAN Attachments are allowed to use any encryption settings. Set IPSEC as the allowed value to enforce creating encrypted VLAN attachments only.
This constraint ensures that preview features are blocked unless this constraint is explicitly allowed. Once set to allow, you can control which preview features can individually be enabled or disabled for your project. Only enabled preview features can be accessed in the project. Subsequently disabling the policy does not change the status of individual preview features already set & they can be individually disabled. This constraint only applies to Compute Alpha API features.
constraints/compute.managed.blockPreviewFeatures
Compute Engine
Block Project-wide SSH Keys
Preview: This constraint prevents the block-project-ssh-keys metadata key from being set to false at the project, project-zonal, or instance level for Compute Engine VMs within the organization, project, or folder where this constraint is enforced. By default, project-wide SSH keys are allowed and can be disabled at the project, project-zonal, or instance level using this metadata key. To allow project-wide SSH keys for specific VMs, you can exempt them from this policy using tags and conditional rules. Important: Enforcing this constraint does not affect existing VMs where block-project-ssh-keys is already set to false; they will retain access unless their metadata is updated.
constraints/compute.managed.blockProjectSshKeys
Compute Engine
Disable Guest Attributes of Compute Engine metadata
Preview: This constraint, when enforced, disables Compute Engine API access to the Guest Attributes of Compute Engine VMs. By default, the Compute Engine API can be used to access Compute Engine VM guest attributes. You can allow specific VM instances to use guest attributes. First apply tags to mark the instances, and then use conditional rules based on tag values to properly scope those instances out of enforcement.
This boolean constraint disables hardware-accelerated nestedvirtualization for all Compute Engine VMs belonging to the organization, project, or folder where this constraint is set to True. By default, hardware-accelerated nested virtualization is allowed for all Compute Engine VMs running on Intel Haswell or newer CPU platforms.
Preview: This constraint, when enforced, prevents the creation or update of VM instances using machine types that are not FIPS compliant. By default, all machine types are allowed. You can exempt specific VMs using tags and conditional rules.
This constraint prevents the serial-port-enable metadata key from being set to true for Compute Engine VMs within the organization, project, or folder where this constraint is enforced. By default, serial port access can be enabled on a per-VM, per-zone, or per-project basis using this metadata key. To allow serial port access for specific VMs, you can exempt them from this policy using tags and conditional rules. Important: Enforcing this constraint does not affect existing VMs where serial-port-enable is already set to true; they will retain access unless their metadata is updated.
This constraint, when enforced, disables serial port logging to Stackdriver from Compute Engine VMs. By default, serial port logging for Compute Engine VMs is disabled, and can be selectively enabled on a per-VM or per-project basis using metadata attributes. Disabling serial port logging can cause certain services that rely on it, such as Google Kubernetes Engine clusters, to not function correctly. Before you enforce this constraint, verify that the products in your project do not rely on serial port logging. You can allow specific VM instances to use serial port logging. First apply tags to mark the instances, and then use conditional rules based on tag values to properly scope those instances out of enforcement.
Disable creation of Compute Engine instances that use the deprecated container startup agent (konlet).
Preview: This boolean constraint prevents the creation of Compute Engine instances that use konlet, the deprecated container startup agent. When enabled, you can't create compute instances that have the `gce-container-declaration` metadata key.This constraint also prevents creation of compute instances from instance templates that contain the `gce-container-declaration` metadata key, which affects managed instance groups (MIGs) that use such instance templates.
Restricts usage of Global Internal DNS (gDNS) for projects that have a ZonalOnly DNS setting.
This constraint, when enforced, restricts gDNS usage. This restriction disables gDNS VM creation and updating VMs to use gDNS. Reverting a zDNS project to gDNS won't be blocked, but lead to policy violation enforcement during subsequent Instance API invocations.
constraints/compute.managed.disallowGlobalDns
Compute Engine
Require OS Config
This constraint, when enforced, requires enablement of VM Manager (OS Config) on all new projects. On new and existing projects, this constraint prevents metadata updates that disable VM Manager at the project, project-zonal, or instance level. You can allow specific VM instances to disable VM Manager. First apply tags to mark the instances, and then use conditional rules based on tag values to properly scope those instances out of enforcement.
constraints/compute.managed.requireOsConfig
Compute Engine
Require OS Login
This constraint, when enforced, requires enablement of OS Login on all newly created Projects. On new and existing projects, this constraint prevents metadata updates that disable OS Login at the project, project-zonal, or instance level. You can allow specific VM instances to disable OS Login. First apply tags to mark the instances, and then use conditional rules based on tag values to properly scope those instances out of enforcement.
constraints/compute.managed.requireOsLogin
Compute Engine
Restrict Non-Confidential Computing
Preview: Requires all new VMs to be created with Confidential Computing enabled. By default, new VMs are not required to use Confidential Computing. You can apply/exempt this constraint by using tags to mark VM Instances and then enforcing the constraint with conditional rules based on the applied tags.
This constraint lets you restrict the types of protocol forwarding deployments (internal or external) that can be created in your organization. To configure the constraint, you specify an allowlist of the type of protocol forwarding deployment to be allowed. The allowlist can only include the following values:
INTERNAL
EXTERNAL
. For example, if the allowlist is set to INTERNAL, your users can only set up internal protocol forwarding. That is, any forwarding rules associated with target instances are restricted to the INTERNAL load balancing scheme and must use only internal IP addresses.
constraints/compute.managed.restrictProtocolForwardingCreationForTypes
Compute Engine
Restrict VM IP forwarding
This constraint defines whether Compute Engine VM instances can enable IP forwarding. By default, if no policy is specified, any VM can enable IP forwarding in any virtual network. If enforced, this constraint will deny the creation or update of VM instances with IP forwarding enabled. You can allow specific VM instances to enable IP forwarding. First apply tags to mark the instances, and then use conditional rules based on tag values to properly scope those instances out of enforcement.
constraints/compute.managed.vmCanIpForward
Compute Engine
Restrict External IPs For VM instances
This constraint defines whether Compute Engine VM instances are allowed to use IPv4 external IP addresses. By default, all VM instances are allowed to use external IP addresses. If enforced, this constraint will deny the creation or update of VM instances with IPv4 external IP addresses. This constraint will not restrict the usage of IPv6 external IP addresses. You can allow specific VM instances to use external IPv4 IP addresses. First apply tags to mark the instances, and then use conditional rules based on tag values to properly scope those instances out of enforcement.
constraints/compute.managed.vmExternalIpAccess
Google Kubernetes Engine
Enable Autopilot privileged admission control
Enable allowlist-based admission control for privileged Autopilot workloads when creating or updating GKE clusters. CAUTION: Setting `allowAnyGKEPath` to `False` causes cluster creation and update to fail unless you include the `--autopilot-privileged-admission` flag with a value that conforms to the policy. This change affects all clusters in the organization, not just those in Autopilot mode. For details, see https://docs.cloud.google.com/kubernetes-engine/docs/concepts/about-autopilot-privileged-workloads#about-managed-constraint.
Require that the DenyServiceExternalIPs admission controller is enabled
Require that the DenyServiceExternalIPs admission controller remains enabled in GKE clusters. For details, see https://cloud.google.com/kubernetes-engine/docs/how-to/hardening-your-cluster#deny_external_IPs
Require that Attribute-Based Access Control is disabled
Reject requests to enable Attribute-Based Access Control (ABAC) on GKE clusters. ABAC is a legacy authentication method that's disabled by default in all new clusters. For details, see https://cloud.google.com/kubernetes-engine/docs/how-to/hardening-your-cluster#leave_abac_disabled
constraints/container.managed.disableABAC
Google Kubernetes Engine
Require disabling the insecure kubelet read-only port in GKE clusters
Require that the insecure kubelet read-only port (10255) remains disabled. For details, see https://cloud.google.com/kubernetes-engine/docs/how-to/disable-kubelet-readonly-port
Require that client certificate authentication is disabled
Don't manually enable the legacy method of client certificate authentication.. For details, see https://cloud.google.com/kubernetes-engine/docs/how-to/api-server-authentication#disabling_authentication_with_a_client_certificate
Requires disabling RBAC bindings to system identities in GKE clusters.
Disable non-default ClusterRoleBindings and RoleBindings that reference the system:anonymous, system:authenticated, or system:unauthenticated system identities when creating or updating GKE clusters. For details, see https://cloud.google.com/kubernetes-engine/docs/best-practices/rbac#prevent-default-group-usage
Disallow using the default Compute Engine service account as the node pool service account.
Don't use the default Compute Engine service account as the cluster or node pool service account. Use a minimally-privileged IAM service account instead. For details, see https://cloud.google.com/kubernetes-engine/docs/how-to/hardening-your-cluster#use_least_privilege_sa
Require that Cloud Logging is enabled in GKE clusters
Require that all GKE clusters use at least the default Cloud Logging configuration. For details, see https://cloud.google.com/kubernetes-engine/docs/how-to/hardening-your-cluster#stackdriver_logging
constraints/container.managed.enableCloudLogging
Google Kubernetes Engine
Require using only the DNS-based endpoint to access GKE clusters.
Enable the DNS-based endpoint for GKE control plane access and disable IP-based endpoints when creating or updating clusters. For details, see https://cloud.google.com/kubernetes-engine/docs/how-to/latest/network-isolation#dns-based-endpoint.
Require enabling Google Groups for RBAC in GKE clusters.
Enable Google Groups for RBAC when creating or updating GKE clusters. For details, see https://cloud.google.com/kubernetes-engine/docs/how-to/google-groups-rbac.
Require enabling network policy enforcement in GKE clusters.
Enable the use of Kubernetes NetworkPolicies by enabling network policy enforcement or GKE Dataplane V2. For details, see https://cloud.google.com/kubernetes-engine/docs/how-to/network-policy or https://cloud.google.com/kubernetes-engine/docs/how-to/dataplane-v2.
constraints/container.managed.enableNetworkPolicy
Google Kubernetes Engine
Require enabling private nodes in GKE clusters.
Enable private nodes when creating or updating GKE clusters and node pools. For details, see https://cloud.google.com/kubernetes-engine/docs/how-to/latest/network-isolation#configure-cluster-networking.
constraints/container.managed.enablePrivateNodes
Google Kubernetes Engine
Require enabling self-managed secrets Encryption in GKE clusters.
Enable Secret encryption with self-managed keys when creating or updating GKE clusters. For details, see https://cloud.google.com/kubernetes-engine/docs/how-to/encrypting-secrets.
Require enabling Security Bulletin Notifications in GKE clusters.
Enable Security Bulletin Notifications when creating or updating GKE clusters. For details, see https://cloud.google.com/kubernetes-engine/docs/concepts/cluster-notifications#securitybulletin
Require that Shielded Nodes remain enabled. Shielded GKE Nodes provide strong, verifiable node identity and integrity to increase the security of GKE nodes. For details, see https://cloud.google.com/kubernetes-engine/docs/how-to/shielded-gke-nodes
constraints/container.managed.enableShieldedNodes
Google Kubernetes Engine
Require enabling Workload Identity Federation for GKE.
Enable Workload Identity Federation for GKE when creating or updating clusters. For details, see https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity.
Disable project-wide SSH keys from accessing Dataflow Worker VMs.
constraints/dataflow.managed.blockProjectSshKeys
Dataflow
Disable public IPs
Disable the use of public IPs on Dataflow Worker VMs.
constraints/dataflow.managed.disableUsePublicIps
Discovery Engine
Restrict allowed data sources for data connectors
This constraint defines the allowed data sources for data connectors. When enforced, only the allowed data sources can be used for data connectors in projects with VPC Service Controls (VPC-SC) enabled or projects in the enforcedProjects list. For more information, see https://docs.cloud.google.com/gemini/enterprise/docs/connectors/configure-allowed-data-sources.
This constraint defines the allowed egress fully qualified domain names (FQDNs) for data connectors. When enforced, only URLs with an allowed FQDN can be used for data connectors in projects with VPC Service Controls (VPC-SC) enabled, or projects in the enforcedProjects list. For more information, see https://docs.cloud.google.com/gemini/enterprise/docs/connectors/configure-allowed-egress-fqdns.
This constraint defines the set of allowed domains that email addresses added to Essential Contacts can have. By default, email addresses with any domain can be added to Essential Contacts. The allowedDomains list must specify one or more domains of the form @example.com. If this constraint is enforced, only email addresses with a suffix matching one of the entries from the list of allowed domains can be added in Essential Contacts. This constraint has no effect on updating or removing existing contacts.
Restrict allowed policy members in IAM allow policies
This constraint defines the organization principal sets that can be granted IAM roles in your organization. Specifying an organization principal set allows all identities that are associated with that organization (including Workspace accounts, Workspace groups, service accounts, workforce pool identities, workload pool identities, and service agents) to be granted roles in your organization. Your organization principal set is not automatically allowed, and must be included as an allowed principal set. You can specify individual members using the principal type prefix (for example, `user:` or `serviceAccount:` to grant them and associated aliases roles in your organization. Enforcing this constraint can block folder resource creation due to automatic Folder Admin and Folder Editor role grants, and can block project resource creation due to automatic Owner role grants.
constraints/iam.managed.allowedPolicyMembers
Identity and Access Management
Block service account API key bindings
When enforced, disables creation of API Keys bound to service accounts, unless the API Key's API targets are non-empty and exclusively limited to the allowedServices.
This boolean constraint disables the creation of service accounts where this constraint is set to `True`. By default, service accounts can be created by users based on their Cloud IAM roles and permissions.
This boolean constraint disables the feature that allows uploading public keys to service accounts where this constraint is set to `True`. By default, users can upload public keys to service accounts based on their Cloud IAM roles and permissions.
Prevent privileged basic roles for default service accounts
When this constraint is enforced, it prevents anyone from granting the Editor role (roles/editor) or the Owner role (roles/owner) to the Compute Engine and App Engine default service accounts, at any time. To learn more about default service accounts, see https://cloud.google.com/iam/help/service-accounts/default. Enforcing this constraint prevents the default service accounts from automatically being granted the Editor role (roles/editor). This might cause permission issues for services that use these service accounts. To learn which roles to grant to each service account, see https://cloud.google.com/iam/help/service-accounts/troubleshoot-roles-default.
Disables Subscription Single Message Transforms (SMTs)
Do not configure or modify this policy. This constraint is automatically configured during Assured Workloads onboarding and is only intended for advanced regulatory control for Assured Workloads. When this boolean constraint is enforced, Pub/Sub Subscriptions cannot set Single Message Transforms (SMTs).
Do not configure or modify this policy. This constraint is automatically configured during Assured Workloads onboarding and is only intended for advanced regulatory control for Assured Workloads. When this boolean constraint is enforced, Pub/Sub Topics cannot set Single Message Transforms (SMTs).
When enforced, this constraint requires the IAM invoker check to be enabled on Cloud Run services. If this constraint is not enforced, you can set the service.invoker_iam_disabled field (v2), or the run.googleapis.com/invoker-iam-disabled annotation (v1) on Cloud Run services to True. Setting service.invoker_iam_disabled to True only affects deployment of new revisions that use this field or annotation set to True. It's also possible to achieve a similar result by granting the run.routes.invoke permission to allUsers. For more information, see https://cloud.google.com/run/docs/securing/managing-access#make-service-public and https://cloud.google.com/run/docs/securing/security.
constraints/run.managed.requireInvokerIam
Spanner
Denied editions for Spanner instances
This constraint, when enforced, restricts the Spanner editions that a Spanner instance can use. By default, a Spanner instance can use any Spanner edition.
The deniedEditions list must specify one or more of the following Spanner editions:
STANDARD
ENTERPRISE
ENTERPRISE_PLUS
If an edition is specified, Spanner instances using that edition can't be created or updated where this constraint is enforced.
Restrict Authorized Networks on Cloud SQL instances
This constraint restricts creating/updating SQL Instance with Authorized Networks. This constraint is not retroactive; Cloud SQL instances with existing Authorized Networks will still work even after this constraint is enforced. By default, Authorized Networks can be added to Cloud SQL instances.
This constraint restricts configuring public IP on Cloud SQL instances where this constraint is set to `True`. This constraint is not retroactive; Cloud SQL instances with existing public IP enabled will continue to work even after this constraint is enforced. By default, public IP can be enabled on Cloud SQL instances.
constraints/sql.managed.restrictPublicIp
Cloud Storage
Restrict bucket retention policy duration
This list constraint defines the set of durations for retention policies that can be set on Cloud Storage buckets. By default, if no organization policy is specified, a Cloud Storage bucket can have a retention policy of any duration. The list of allowed durations must be specified as a positive integer value greater than zero, representing the retention policy in seconds. Any insert, update, or patch operation on a bucket in the organization resource must have a retention policy duration that matches the constraint. Enforcement of this constraint is not retroactive. When a new organization policy is enforced, the retention policy of existing buckets remains unchanged and valid.
This constraint defines the allowable retention durations for soft delete policies set on Cloud Storage buckets where this constraint is enforced. Any insert, update, or patch operation on a bucket where this constraint is enforced must have a soft delete policy duration that matches the constraint. When a new organization policy is enforced, the soft delete policy of existing buckets remains unchanged and valid. By default, if no organization policy is specified, a Cloud Storage bucket can have a soft delete policy of any duration.
This list constraint defines the modes of access allowed to Vertex AI Workbench notebooks and instances where enforced. The allow or deny list can specify multiple users with the service-account mode or single-user access with the single-user mode. The access mode to be allowed or denied must be listed explicitly.
Supported prefix: is:
constraints/ainotebooks.accessMode
Vertex AI Workbench
Disable file downloads on new Vertex AI Workbench instances
This boolean constraint, when enforced, prevents the creation of Vertex AI Workbench instances with the file download option enabled. By default, the file download option can be enabled on any Vertex AI Workbench instance.
constraints/ainotebooks.disableFileDownloads
Vertex AI Workbench
Disable root access on new Vertex AI Workbench user-managed notebooks and instances
This boolean constraint, when enforced, prevents newly created Vertex AI Workbench user-managed notebooks and instances from enabling root access. By default, Vertex AI Workbench user-managed notebooks and instances can have root access enabled.
constraints/ainotebooks.disableRootAccess
Vertex AI Workbench
Disable terminal on new Vertex AI Workbench instances
This boolean constraint, when enforced, prevents the creation of Vertex AI Workbench instances with the terminal enabled. By default, the terminal can be enabled on Vertex AI Workbench instances.
constraints/ainotebooks.disableTerminal
Vertex AI Workbench
Restrict environment options on new Vertex AI Workbench user-managed notebooks
This list constraint defines the VM and container image options a user can select when creating new Vertex AI Workbench user-managed notebooks. The options to be allowed or denied must be listed explicitly. The expected format for VM instances is ainotebooks-vm/PROJECT_ID/IMAGE_TYPE/CONSTRAINED_VALUE. Replace IMAGE_TYPE with image-family or image-name. Examples: ainotebooks-vm/deeplearning-platform-release/image-family/pytorch-1-4-cpu, ainotebooks-vm/deeplearning-platform-release/image-name/pytorch-latest-cpu-20200615. The expected format for container images will be ainotebooks-container/CONTAINER_REPOSITORY:TAG. Examples: ainotebooks-container/gcr.io/deeplearning-platform-release/tf-gpu.1-15:latest, ainotebooks-container/gcr.io/deeplearning-platform-release/tf-gpu.1-15:m48.
Supported prefix: is:
constraints/ainotebooks.environmentOptions
Vertex AI Workbench
Require automatic scheduled upgrades on new Vertex AI Workbench user-managed notebooks and instances
This boolean constraint, when enforced, requires that newly created Vertex AI Workbench user-managed notebooks and instances have an automatic upgrade schedule set. The automatic upgrade schedule can be defined by using the notebook-upgrade-schedule metadata flag to specify a cron schedule for the automatic upgrades. For example: --metadata=notebook-upgrade-schedule="00 19 * * MON".
This boolean constraint, when enforced, restricts public IP access to newly created Vertex AI Workbench notebooks and instances. By default, public IPs can access Vertex AI Workbench notebooks and instances.
constraints/ainotebooks.restrictPublicIp
Vertex AI Workbench
Restrict VPC networks on new Vertex AI Workbench instances
This list constraint defines the VPC networks a user can select when creating new Vertex AI Workbench instances where this constraint is enforced. By default, a Vertex AI Workbench instance can be created with any VPC networks. The allowed or denied list of networks must be identified in the form: under:organizations/ORGANIZATION_ID, under:folders/FOLDER_ID, under:projects/PROJECT_ID, or projects/PROJECT_ID/global/networks/NETWORK_NAME.
This list constraint defines the set of generative AI models and features allowed to be used in Vertex AI APIs. The values of the allowlist should follow the format model_id:feature_family. For example, publishers/google/models/text-bison:predict. This list constraint only restricts access to Google proprietary generative AI models, and doesn't affect third-party proprietary models or open source models. The constraint vertexai.allowedModels can be used to define access to a broader set of models including Google proprietary models, third-party proprietary models, and open source models. By default, all models can be used in Vertex AI APIs.
This list constraint defines the set of models and features allowed to be used in Vertex AI APIs. The values of the allowlist should follow the format "model_id:feature_family", for example "publishers/google/models/gemini-1.0-pro:predict". By default, all models can be used in Vertex AI APIs.
This list constraint defines the set of managed partner model's advanced features allowed to be used in Vertex AI APIs. The values of the allowlist should follow the format "publishers/publisher_id/models[/model_id:feature_family]", for example "publishers/anthropic/models/claude-sonnet-4:web_search" or "publishers/anthropic/models/claude-sonnet-4" or "publishers/anthropic". By default, all advanced features of the managed partner models are blocked in Vertex AI APIs.
Supported prefix: is:
constraints/vertexai.allowedPartnerModelFeatures
Vertex AI
Disable Grounding with Google Search in generative AI APIs
This list constraint defines the set of grounding sources allowed or denied for use with Vertex AI generative APIs. By default, all grounding sources are allowed. Valid values are: GoogleMaps, VertexAiSearch, VertexRagStore, EnterpriseWebSearch, ExternalApiSimpleSearch, ExternalApiElasticSearch, UrlContext and ParallelAiSearch.
This list constraint defines the set of App Engine Standard legacy runtimes (Python 2.7, PHP 5.5 and Java 8) allowed for deployments past End of Support. App Engine Standard legacy runtimes will reach End of Support on Jan 30, 2024. Generally, attempts to deploy applications using legacy runtimes after this date will be blocked. See App Engine Standard runtime support schedule. Setting this constraint to “Allow” unblocks App Engine Standard deployments for the legacy runtime(s) that you specify until the Runtime Deprecation Date. Setting this constraint to “Allow All” unblocks App Engine Standard deployments for all legacy runtime(s) until the Runtime Deprecation Date. Runtimes that have reached End of Support do not receive routine security and maintenance patches. We strongly encourage you to upgrade your applications to use a Generally Available runtime version.
This boolean constraint, when enforced, will disable users from using BigQuery Omni to process data on Amazon Web Services where this constraint is enforced.
This boolean constraint, when enforced, will disable users from using BigQuery Omni to process data on Microsoft Azure where this constraint is enforced.
This list constraint defines the allowed Cloud Build integrations for performing Builds through receiving webhooks from services outside Google Cloud. When this constraint is enforced, only webhooks for services whose host matches one of the allowed values will be processed. By default, Cloud Build processes all webhooks for projects that have at least one LIVE trigger.
This boolean constraint, when enforced, prevents Cloud Deploy from adding Cloud Deploy identifier labels to deployed objects. By default, labels identifying Cloud Deploy resources are added to deployed objects during release creation.
This list constraint defines the allowed ingress settings for deployment of a Cloud Function (1st gen). When this constraint is enforced, functions will be required to have ingress settings that match one of the allowed values. By default, Cloud Functions can use any ingress settings. Ingress settings must be specified in the allowed list using the values of the IngressSettings enum. The enum has a default value of INGRESS_SETTINGS_UNSPECIFIED. The enum must be changed to another value before you can use it in an organization policy. For Cloud Functions (2nd gen) use the constraint constraints/run.allowedIngress.
This list constraint defines the allowed VPC Connector egress settings for deployment of a Cloud Function (1st gen). When this constraint is enforced, functions will be required to have VPC Connector egress settings that match one of the allowed values. By default, Cloud Functions can use any VPC Connector egress settings. VPC Connector egress settings must be specified in the allowed list using the values of the VpcConnectorEgressSettings enum. The default value of the enum, VPC_CONNECTOR_EGRESS_SETTINGS_UNSPECIFIED, is not supported, and including it in a policy results in an error. For Cloud Functions (2nd gen) use the constraint constraints/run.allowedVPCEgress.
This boolean constraint enforces setting a VPC Connector when deploying a Cloud Function (1st gen). When this constraint is enforced, functions will be required to specify a VPC Connector. By default, specifying a VPC Connector is not required to deploy a Cloud Function.
This list constraint defines the set of allowed Cloud Function Generations that can be used to create new Function resources. Valid values are: 1stGen, 2ndGen.
This list constraint defines the Cloud KMS key types which may be created under a given hierarchy node. When this constraint is enforced, only KMS key types specified within this org policy may be created within the associated hierarchy node. Configuring this org policy will also impact the protection level of import jobs and key versions. By default, all key types are allowed. Valid values are: SOFTWARE, HSM, HSM_SINGLE_TENANT, EXTERNAL, EXTERNAL_VPC. Deny policies are disallowed.
This boolean constraint, when enforced, only allows the destruction of key versions that are in the disabled state. By default, key versions that are in the enabled state and key versions that are in the disabled state can be destroyed. When this constraint is enforced, it applies to both new and existing key versions.
This list constraint defines the minimum destroy scheduled duration in days that the user can specify when creating a new key. No keys with destroy scheduled duration lower than this value may be created after the constraint is enforced. By default, the minimum destroy scheduled duration for all keys is 1 day, except in the case of import-only keys for which it is 0 days. Only one allowed value can be specified in the format in:1d, in:7d, in:15d, in:30d, in:60d, in:90d, or in:120d. For example, if constraints/cloudkms.minimumDestroyScheduledDuration is set to in:15d, then users can create keys with destroy scheduled duration set to any value higher than 15 days, such as 16 days or 31 days. However, users cannot create keys with destroy scheduled duration lower than 15 days, such as 14 days. For each resource in the hierarchy, the minimum destroy scheduled duration may inherit, replace, or be merged with the parent's policy. When the resource's policy is merged with the parent's policy, the effective value of minimum destroy scheduled duration at the resource is the lowest between that value specified at the resource's policy and the parent's effective minimum destroy scheduled duration. For example, if an organization has minimum destroy scheduled duration of 7 days and in a child project the policy is set to 'Merge with parent' with a value of in:15d, then the effective minimum destroy scheduled duration at the project is 7 days.
This list constraint defines the list of target types, such as App Engine HTTP, HTTP, or Pubsub, allowed for Cloud Scheduler jobs. By default, all job targets are allowed. Valid values are: APPENGINE, HTTP, PUBSUB.
Supported prefix: is:
constraints/cloudscheduler.allowedTargetTypes
Cloud SQL
Restrict Authorized Networks on Cloud SQL instances
This boolean constraint restricts adding Authorized Networks for unproxied database access to Cloud SQL instances where this constraint is enforced. This constraint is not retroactive, Cloud SQL instances with existing Authorized Networks will still work even after this constraint is enforced. By default, Authorized Networks can be added to Cloud SQL instances.
constraints/sql.restrictAuthorizedNetworks
Cloud SQL
Disable diagnostic and administrative access pathways in Cloud SQL to meet compliance requirements.
Do not configure or modify this policy. This constraint is automatically configured during Assured Workloads onboarding and is only intended for advanced regulatory control for Assured Workloads. When this boolean constraint is enforced, certain aspects of supportability will be impaired and all access paths for diagnostics and other customer support use cases that do not meet advanced sovereignty requirements for Assured Workloads will be disabled.
Do not configure or modify this policy. This constraint is automatically configured during Assured Workloads onboarding and is only intended for advanced regulatory control for Assured Workloads. When this boolean constraint is enforced, certain aspects of supportability will be impaired and provisioned resources will strictly follow advanced sovereignty requirements for Assured Workloads. This policy is retroactive in that it will apply to existing projects, but it will not affect resources that have already been provisioned; ie. modifications to the policy will only be reflected in resources created after the policy is modified.
This boolean constraint restricts configuring Public IP on Cloud SQL instances where this constraint is enforced. This constraint is not retroactive, Cloud SQL instances with existing Public IP access will still work even after this constraint is enforced. By default, Public IP access is allowed to Cloud SQL instances.
This boolean constraint, when enforced, turns off Google Cloud Marketplace for all users under the organization. By default, public marketplace access is turned on for the organization. This policy only works when the Private Marketplace is enabled (https://docs.cloud.google.com/marketplace/docs/governance/enable-private-marketplace). Important: For the most optimal experience, we strongly recommend that you use the marketplace user access restrictions feature, as described in https://docs.cloud.google.com/marketplace/docs/governance/strict-user-access to prevent unauthorized use of the marketplace in your organization, instead of doing so via this organization policy.
This list constraint defines the set of services allowed for marketplace organizations, and can only include values from the list below:
PRIVATE_MARKETPLACE
IAAS_PROCUREMENT
If the IAAS_PROCUREMENT is in the allowed value list, the IaaS procurement governance experience is enabled for all products. By default, the IaaS procurement governance experience is turned off. The IAAS_PROCUREMENT policy works independently from the Request Procurement governance capability, which is specifically for SaaS products listed on Cloud Marketplace.
Note: The PRIVATE_MARKETPLACE value is no longer supported and using it has no effect. To turn on Google Private Marketplace, you must follow the instructions at https://docs.cloud.google.com/marketplace/docs/governance/enable-private-marketplace.
This list constraint defines the allowed encryption settings for new VLAN Attachments. By default, VLAN Attachments are allowed to use any encryption settings. Set IPSEC as the allowed value to enforce creating encrypted VLAN attachments only.
This boolean constraint, when enforced, disables the creation of or update to any Google Compute Engine resources involved in IPv6 usage. By default, anyone with appropriate Cloud IAM permissions can create or update Google Compute Engine resources with IPv6 usage in any projects, folders, and organizations. If set, this constraint will have higher priority than other IPv6 org constraints including disableVpcInternalIpv6, disableVpcExternalIpv6, and disableHybridCloudIpv6.
This boolean constraint, when enforced, disables the creation of new global Cloud Armor security policies, and the addition or update of rules to existing global Cloud Armor security policies. This constraint doesn't restrict the removal of rules or the removal, description, or listing of global Cloud Armor security policies. Regional Cloud Armor security policies are unaffected by this constraint. All global and regional security policies that exist prior to the enforcement of this constraint remain in effect. By default, you can create or update Cloud Armor security policies in any organization, folder, or project.
This boolean constraint disables creation of global load balancing products. When enforced, only regional load balancing products without global dependencies can be created. By default, creation of global load balancing is allowed.
constraints/compute.disableGlobalLoadBalancing
Compute Engine
Disable Creation of global self-managed SSL Certificates
This boolean constraint, when enforced, disables creation of global self-managed SSL Certificates. Creation of google-managed or regional self-managed certificates is not disabled by this constraint. By default, you can create global self-managed SSL Certificates in any organization, folder, or project.
This boolean constraint disables global serial port access to Compute Engine VMs belonging to the organization, project, or folder where the constraint is enforced. By default, customers can enable serial port access for Compute Engine VMs on a per-VM or per-project basis using metadata attributes. Enforcing this constraint will disable global serial port access for Compute Engine VMs, regardless of the metadata attributes. Regional serial port access is not affected by this constraint. To disable all serial port access, use the compute.disableSerialPortAccess constraint instead.
constraints/compute.disableGlobalSerialPortAccess
Compute Engine
Disable Guest Attributes of Compute Engine metadata
This boolean constraint disables Compute Engine API access to the Guest Attributes of Compute Engine VMs belonging to the organization, project, or folder where this constraint is enforced. By default, the Compute Engine API can be used to access Compute Engine VM guest attributes.
This boolean constraint, when enforced, disables the creation of, or updates to, hybrid cloud resources including Interconnect Attachments and Cloud VPN gateways with a stack_type of IPV4_IPV6 or IPV6_ONLY, or a gatewayIpVersion of IPv6. If enforced on a Cloud Router resource, the ability to create IPv6 Border Gateway Protocol (BGP) sessions and the ability to enable IPv6 route exchange over IPv4 BGP sessions are disabled. By default, anyone with appropriate Cloud IAM permissions can create or update hybrid cloud resources with stack_type of IPV4_IPV6 in projects, folders, and organizations.
Do not configure or modify this policy. This constraint is automatically configured during Assured Workloads onboarding and is only intended for advanced regulatory control for Assured Workloads. This boolean constraint, when enforced, will disable the GetSerialPortOutput and GetScreenshot APIs that access VMs serial port output and capture screenshots from VM UIs.
This boolean constraint restricts whether a user can create Internet Network Endpoint Groups (NEG) with a type of INTERNET_FQDN_PORT and INTERNET_IP_PORT. By default, any user with appropriate IAM permissions can create Internet NEGs in any project.
This boolean constraint disables hardware-accelerated nested virtualization for all Compute Engine VMs belonging to the organization, project, or folder where this constraint is set to True. By default, hardware-accelerated nested virtualization is allowed for all Compute Engine VMs running on Intel Haswell or newer CPU platforms.
This list constraint defines the set of Private Service Connect endpoint types for which users cannot create forwarding rules. When this constraint is enforced, users will be blocked from creating forwarding rules for the Private Service Connect endpoint type. This constraint is not retroactively enforced. By default, forwarding rules can be created for any Private Service Connect endpoint type. The allowed/denied list of Private Service Connect endpoints must come from the list below:
GOOGLE_APIS
SERVICE_PRODUCERS
Using GOOGLE_APIS in the allowed/denied list will restrict the creation of Private Service Connect forwarding rules for accessing Google APIs. Using SERVICE_PRODUCERS in the allowed/denied list will restrict the creation of Private Service Connect forwarding rules for accessing services in another VPC network.
This boolean constraint disables serial port access to Compute Engine VMs belonging to the organization, project, or folder where this constraint is enforced. By default, customers can enable serial port access for Compute Engine VMs on a per-VM or per-project basis using metadata attributes. Enforcing this constraint will disable serial port access for Compute Engine VMs, regardless of the metadata attributes.
This boolean constraint disables serial port logging to Stackdriver from Compute Engine VMs belonging to the organization, project, or folder where this constraint is being enforced. By default, serial port logging for Compute Engine VMs is disabled, and can be selectively enabled on a per-VM or per-project basis using metadata attributes. When enforced, this constraint disables serial port logging for new Compute Engine VMs whenever a new VM is created, as well as preventing users from changing the metadata attribute of any VMs (old or new) to True. Disabling serial port logging can cause certain services that rely on it, such as Google Kubernetes Engine clusters, to not function correctly. Before you enforce this constraint, verify that the products in your project do not rely on serial port logging.
This boolean constraint disables the SSH-in-browser tool in the Cloud Console for VMs that use OS Login and App Engine flexible environment VMs. When enforced, the SSH-in-browser button is disabled. By default, using the SSH-in-browser tool is allowed.
This boolean constraint, when enforced, disables the creation of or update to subnetworks with a stack_type of IPV4_IPV6 and ipv6_access_type of EXTERNAL. By default, anyone with appropriate Cloud IAM permissions can create or update subnetworks with stack_type of IPV4_IPV6 in any projects, folders, and organizations.
This boolean constraint, when enforced, disables the creation of or update to subnetworks with a stack_type of IPV4_IPV6 and ipv6_access_type of INTERNAL. By default, anyone with appropriate Cloud IAM permissions can create or update subnetworks with stack_type of IPV4_IPV6 in any projects, folders, and organizations.
constraints/compute.disableVpcInternalIpv6
Compute Engine
Enable settings required for compliance memory protection workloads
Do not configure or modify this policy. This constraint is automatically configured during Assured Workloads onboarding and is only intended for advanced regulatory control for Assured Workloads. This constraint controls settings required to eliminate potential access paths to VM core memory. When enforced it limits the ability to access VM core memory by disabling access pathways and restricts internal data collection when an error occurs.
This boolean constraint, when enforced, disables the fail-open behavior on server-side failures for regions.list, regions.get, and projects.get methods. That means that if the quota information is unavailable, these methods fail when the constraint is enforced. By default, these methods succeed on server-side failures and display a warning message when the quota information is unavailable.
This boolean constraint, when enforced, enables VM Manager (OS Config) on all new projects. All VM instances created in new projects will have VM Manager enabled. On new and existing projects, this constraint prevents metadata updates that disable VM Manager at the project or instance level. By default, VM Manager is disabled on Compute Engine projects.
This boolean constraint, when enforced, enables OS Login on all newly created Projects. All VM instances created in new projects will have OS Login enabled. On new and existing projects, this constraint prevents metadata updates that disable OS Login at the project or instance level. By default, the OS Login feature is disabled on Compute Engine projects.
This boolean constraint, when enforced, requires that all new Compute Engine VM instances use Shielded disk images with Secure Boot, vTPM, and Integrity Monitoring options enabled. Secure Boot can be disabled after creation, if desired. Existing running instances will continue to work as usual. By default, Shielded VM features do not need to be enabled in order to create Compute Engine VM instances. Shielded VM features add verifiable integrity and exfiltration resistance to your VMs.
This list constraint defines the set of target SSL proxies and target HTTPS proxies that are allowed to use the default SSL policy. By default, all target SSL proxies and target HTTPS proxies are allowed to use the default SSL policy. When this constraint is enforced, new target SSL proxies and target HTTPS proxies will be required to specify an SSL policy. Enforcement of this constraint is not retroactive. Existing target proxies that use the default SSL policy are not affected. The allowed/denied list of target SSL proxies and target HTTPS proxies must be identified in the form:
This list constraint defines the set of predefined policies that can be enforced for VPC Flow logs. By default VPC Flow logs may be configured with any settings in each subnet. This constraint enforces enabling flow logs for all subnetworks in scope with a required minimum sampling rate. Specify one or more of the following valid values:
This list constraint defines the set of subnetworks that are allowed to use Cloud NAT. By default, all subnetworks are allowed to use Cloud NAT. The allowed/denied list of subnetworks must be identified in the form: under:organizations/ORGANIZATION_ID, under:folders/FOLDER_ID, under:projects/PROJECT_ID, or projects/PROJECT_ID/regions/REGION_NAME/subnetworks/SUBNETWORK_NAME.
This list constraint limits backend bucket and backend service resources that a urlMap resource can attach to. This constraint does not apply to backend buckets and backend services within the same project as the urlMap resource. By default, a urlMap resource in one project can reference compatible backend buckets and backend services from other projects in the same organization as long as the user has compute.backendService.use, compute.regionBackendServices.use or compute.backendBuckets.use permission. We recommend not using this constraint with the compute.restrictSharedVpcBackendServices constraint to avoid conflicts. Projects, folders, and organization resources in allowed or denied lists affect all backend buckets and backend services underneath them in the resource hierarchy. Only projects, folders, and organization resources can be included in the allowed or denied list, and must be specified in the form:
This list constraint defines the set of Compute Engine networks that are allowed to use Dedicated Interconnect. By default, networks are allowed to use any type of Interconnect. The allowed/denied list of networks must be identified in the form: under:organizations/ORGANIZATION_ID, under:folders/FOLDER_ID, under:projects/PROJECT_ID, or projects/PROJECT_ID/global/networks/NETWORK_NAME.
This list constraint defines the set of load balancer types which can be created for an organization, folder, or project. Every load balancer type to be allowed or denied must be listed explicitly. By default, creation of all types of load balancers is allowed. The list of allowed or denied values must be identified as the string name of a load balancer, and can only include values from the list below:
INTERNAL_TCP_UDP
INTERNAL_HTTP_HTTPS
GLOBAL_INTERNAL_MANAGED_HTTP_HTTPS
GLOBAL_INTERNAL_MANAGED_TCP_PROXY
REGIONAL_INTERNAL_MANAGED_TCP_PROXY
EXTERNAL_NETWORK_TCP_UDP
EXTERNAL_TCP_PROXY
EXTERNAL_SSL_PROXY
EXTERNAL_HTTP_HTTPS
EXTERNAL_MANAGED_HTTP_HTTPS
GLOBAL_EXTERNAL_MANAGED_HTTP_HTTPS
GLOBAL_EXTERNAL_MANAGED_TCP_PROXY
GLOBAL_EXTERNAL_MANAGED_SSL_PROXY
REGIONAL_EXTERNAL_MANAGED_TCP_PROXY
To include all internal or all external load balancer types, use the in: prefix followed by INTERNAL or EXTERNAL. For example, allowing in:INTERNAL will allow all load balancer types from the above list that include INTERNAL. For more information about restricting load balancer types, see https://docs.cloud.google.com/load-balancing/docs/org-policy-constraints.
The deny list of this list constraint defines the set of services that require all new resources to be created with Confidential Computing enabled. By default, new resources are not required to use Confidential Computing. While this list constraint is enforced, Confidential Computing cannot be disabled throughout the lifecycle of the resource. Existing resources will continue to work as usual. The denied list of services must be identified as the string name of an API, and can only include explicitly denied values from the list below. Explicitly allowing APIs is not currently supported. Explicitly denying APIs not in this list will result in an error. List of supported APIs: [compute.googleapis.com, container.googleapis.com]
This list constraint defines the set of Compute Engine networks that are allowed to use Partner Interconnect. By default, networks are allowed to use any type of Interconnect. The allowed/denied list of networks must be identified in the form: under:organizations/ORGANIZATION_ID, under:folders/FOLDER_ID, under:projects/PROJECT_ID, or projects/PROJECT_ID/global/networks/NETWORK_NAME.
This list constraint defines the organizations, folders, and projects that can connect to service attachments within a producer's organization or project. The allowed or denied lists must be identified in the following form: under:organizations/ORGANIZATION_ID, under:folders/FOLDER_ID, or under:projects/PROJECT_ID. By default, all connections are allowed.
This list constraint defines which service attachments Private Service Connect consumers can connect to. The constraint blocks the deployment of Private Service Connect endpoints or backends based on the organization, folder, or project resource of the service attachment that the endpoints or backends refer to. The allowed or denied lists must be identified in the following form: under:organizations/ORGANIZATION_ID, under:folders/FOLDER_ID, or under:projects/PROJECT_ID. By default, all connections are allowed.
This list constraint defines the type of protocol forwarding rule objects with target instance that a user can create. When this constraint is enforced, new forwarding rule objects with target instance are limited to internal and/or external IP addresses, based on the types specified. The types to be allowed or denied must be listed explicitly. By default, creation of both internal and external protocol forwarding rule objects with target instance are allowed. The list of allowed or denied values can only include values from the list below:
This list constraint defines the set of shared VPC Backend Services that eligible resources can use. This constraint does not apply to resources within the same project. By default, eligible resources can use any shared VPC Backend Services. The allowed/denied list of Backend Services must be specified in the form: under:organizations/ORGANIZATION_ID, under:folders/FOLDER_ID, under:projects/PROJECT_ID, projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_NAME or projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_NAME. This constraint is not retroactive.
This list constraint defines the set of Shared VPC host projects that projects at or below this resource can attach to. By default, a project can attach to any host project in the same organization, thereby becoming a service project. Projects, folders, and organizations in allowed/denied lists affect all objects underneath them in the resource hierarchy, and must be specified in the form: under:organizations/ORGANIZATION_ID, under:folders/FOLDER_ID, or projects/PROJECT_ID.
This list constraint defines the set of Shared VPC subnetworks that eligible resources can use. This constraint does not apply to resources within the same project. By default, eligible resources can use any shared VPC subnetwork. The allowed/denied list of subnetworks must be specified in the form: under:organizations/ORGANIZATION_ID, under:folders/FOLDER_ID, under:projects/PROJECT_ID, or projects/PROJECT_ID/regions/REGION/subnetworks/SUBNETWORK-NAME. Note that forwarding rules that are used for Private Service Connect endpoints aren't restricted by this constraint.
This list constraint defines the set of VPC networks that are allowed to be peered with the VPC networks belonging to this project, folder, or organization. Each peering end is required to have peering permission. By default, a Network Admin for one network can peer with any other network. The allowed/denied list of networks must be identified in the form: under:organizations/ORGANIZATION_ID, under:folders/FOLDER_ID, under:projects/PROJECT_ID, or projects/PROJECT_ID/global/networks/NETWORK_NAME.
This list constraint defines the set of valid IP addresses that can be configured as VPN peer IPs. By default, any IP can be a VPN peer IP for a VPC network. The allowed/denied list of IP addresses must be specified as valid IP addresses in the form: IP_V4_ADDRESS or IP_V6_ADDRESS.
When enforced, newly created projects will use Zonal DNS as default. By default, this constraint is set to False and newly created projects will be using the default DNS type.
This list constraint defines the set of projects that are allowed to create and own shared reservations in the org. A shared reservation is similar to a local reservation, except that instead of being consumable by only owner projects, they can be consumed by other Compute Engine projects in the resource hierarchy. The list of projects allowed to access the shared reservation must be of the form: projects/PROJECT_NUMBER or under:projects/PROJECT_NUMBER.
This boolean constraint skips the creation of the default network and related resources during Google Cloud Platform Project resource creation where this constraint is enforced. By default, a default network and supporting resources are automatically created when creating a Project resource.
constraints/compute.skipDefaultNetworkCreation
Compute Engine
Compute Storage resource use restrictions (Compute Engine disks, images, and snapshots)
This list constraint defines a set of projects that are allowed to use Compute Engine's storage resources. By default, anyone with appropriate Cloud IAM permissions can access Compute Engine resources. When using this constraint, users must have Cloud IAM permissions, and they must not be restricted by the constraint to access the resource. Projects, folders, and organizations specified in allowed or denied lists must be in the form: under:projects/PROJECT_ID, under:folders/FOLDER_ID, under:organizations/ORGANIZATION_ID.
This list constraint defines the set of projects that can be used for image storage and disk instantiation for Compute Engine. By default, instances can be created from images in any project that shares images publicly or explicitly with the user. The allowed/denied list of publisher projects must be strings in the form: projects/PROJECT_ID. If this constraint is active, only images from trusted projects will be allowed as the source for boot disks for new instances.
This list constraint defines the set of VM instances that can enable IP forwarding. By default, any VM can enable IP forwarding in any virtual network. VM instances must be specified in the form: under:organizations/ORGANIZATION_ID, under:folders/FOLDER_ID, under:projects/PROJECT_ID, or projects/PROJECT_ID/zones/ZONE/instances/INSTANCE-NAME. This constraint is not retroactive.
This list constraint defines the set of Compute Engine VM instances that are allowed to use external IPv4 addresses. This constraint doesn't restrict the use of IPv6 addresses. By default, all VM instances are allowed to use external IPv4 and IPv6 addresses. The allowed/denied list of VM instances must be identified by the VM instance name, in the form: projects/PROJECT_ID/zones/ZONE/instances/INSTANCE
This boolean constraint, when enforced, disables turning on Identity-Aware Proxy on global resources. Enabling IAP on regional resources is not restricted by this constraint. By default, enabling IAP on global resources is allowed.
constraints/iap.requireGlobalIapWebDisabled
Google Kubernetes Engine
Disable diagnostic administrative access pathways in GKE.
Do not configure or modify this policy. This constraint is automatically configured during Assured Workloads onboarding and is only intended for advanced regulatory control for Assured Workloads. When this boolean constraint is enforced, all access paths for diagnostics and other customer support use cases that do not comply with Assured Workloads requirements will be disabled.
This list constraint defines a set of remotes that repositories in the Dataform project can communicate with. To block communication with all remotes, set the value to Deny all. This constraint is retroactive, and blocks communication for existing repositories that violate it. Entries should be links to trusted remotes, in the same format as provided in Dataform. By default, repositories in Dataform projects can communicate with any remote.
By default, Datastream connection profiles can be created with public or private connectivity methods. If the boolean constraint for this organization policy is enforced, then only private connectivity methods (for example, VPC peering) can be used to create connection profiles.
This list constraint defines the set of domains that email addresses added to Essential Contacts can have. By default, email addresses with any domain can be added to Essential Contacts. The allowed/denied list must specify one or more domains of the form @example.com. If this constraint is active and configured with allowed values, only email addresses with a suffix matching one of the entries from the list of allowed domains can be added in Essential Contacts. This constraint has no effect on updating or removing existing contacts.
This boolean constraint, when enforced, allows organization policy administrators to ensure that only contacts assigned at the organization or folder level can receive security notifications. Specifically, enforcing this constraint blocks project owners and contact administrators from creating or updating an Essential Contact with a notification_category_subscriptions field that contains either the SECURITY or ALL category, if the contact also has a project resource as a parent.
This boolean constraint, when enforced, requires Firestore imports and exports to use the Firestore Service Agent. By default, Firestore imports and exports may use the App Engine service account. Firestore will stop using the App Engine service account for imports and exports in the future and all accounts will need to migrate to the Firestore Service Agent, after which time this constraint will no longer be necessary.
This boolean constraint, when enforced, disables Cloud Logging for the Cloud Healthcare API. Audit logs aren't affected by this constraint. Cloud Logs generated for the Cloud Healthcare API before the constraint is enforced are not deleted and can still be accessed.
This list constraint defines the set of service accounts that can be granted OAuth 2.0 access tokens with a lifetime of up to 12 hours. By default, the maximum lifetime for these access tokens is 1 hour. The allowed/denied list of service accounts must specify one or more service account email addresses.
This list constraint defines the organization principal sets and Google Workspace customer IDs whose principals can be added to IAM policies. By default, all user identities are allowed to be added to IAM policies. Only allowed values can be defined in this constraint, denied values are not supported. All domains associated with a Google Workspace account or the principal set listed in the allowed_values will be allowed by the organization policy. All other domains will be blocked by the organization policy. You do not need to add the google.com customer ID to this list in order to interoperate with Google services. Adding google.com allows sharing with Google employees and non-production systems, and should only be used for sharing data with Google employees.
This boolean constraint, when enforced, prevents you from exempting additional principals from audit logging. This constraint does not affect any audit-logging exemptions that existed before you enforced the constraint.
When enforced, service accounts can only be deployed (using ServiceAccountUser role) to jobs (vms, functions, etc) running in the same project as the service account.
This boolean constraint disables the creation of service accounts where this constraint is enforced. By default, service accounts can be created by users based on their Cloud IAM roles and permissions.
This boolean constraint, when enforced, disables the creation of service account external keys and Cloud Storage HMAC keys. By default, service account external keys can be created by users based on their Cloud IAM roles and permissions.
This boolean constraint disables the feature that allows uploading public keys to service accounts where this constraint is enforced. By default, users can upload public keys to service accounts based on their Cloud IAM roles and permissions.
This boolean constraint, when enforced, requires that all new GKE clusters have Workload Identity disabled at creation time. Existing GKE clusters with Workload Identity already enabled will continue to work as usual. By default, Workload Identity can be enabled for any GKE cluster.
This list constraint defines the maximum duration allowed for service account key expiry. By default, created keys never expire. The allowed duration is specified in hours, and must come from the list below. Only one allowed value can be specified, and denied values are not supported. Specifying a duration not in this list will result in an error.
1h
8h
24h
168h
336h
720h
1440h
2160h
To enforce this constraint, you must set it to replace the parent policy in the Cloud Console, or set inheritFromParent=false in the policy file if using the gcloud CLI. This constraint can't be merged with a parent policy. Enforcement of the constraint is not retroactive and will not change pre-existing keys.
This list constraint defines the response taken if Google detects that a service account linked key is exposed publicly. Keys that are monitored include long-lived service account keys and API keys that are bound to a service account. If not set, defaults to the behavior described for DISABLE_KEY. The allowed values are DISABLE_KEY and WAIT_FOR_ABUSE. Values not explicitly part of this list cannot be used. Only one allowed value can be specified, and denied values are not supported. Allowing the DISABLE_KEY value automatically disables any publicly exposed service account key, and creates an entry in the audit log. Allowing the WAIT_FOR_ABUSE value opts out of this protection, and does not disable exposed service account keys automatically. However, Google Cloud may disable exposed service account keys if they are used in ways that adversely affect the platform, but makes no promise to do so. To enforce this constraint, set it to replace the parent policy in the Google Cloud Console, or set inheritFromParent=false in the policy file if using the gcloud CLI. This constraint can't be merged with a parent policy.
Supported prefix: is:
constraints/iam.serviceAccountKeyExposureResponse
Identity and Access Management
Allowed AWS accounts that can be configured for workload identity federation in Cloud IAM
This constraint determines what VPC Service Controls modes can be set when provisioning a new Anthos Service Mesh Managed Control Plane. Valid values are "NONE" and "COMPATIBLE".
Supported prefix: is:
constraints/meshconfig.allowedVpcscModes
VM Manager
VM Manager - Restrict inline script and output file usage
This boolean constraint, when set to 'True', enforces compliance with Assured Workloads requirements by restricting the creation or modification of VM Manager resources that use inline scripts or binary output files. Specifically, the 'script' and 'output_file_path' fields within the OSPolicyAssignment and PolicyOrchestrator resources must remain empty.
This boolean constraint, when enforced, sets MessageStoragePolicy::enforce_in_transit to true for all new Pub/Sub topics at creation time. This ensures that Customer Data transits only within the allowed regions specified in the message storage policy for the topic.
This boolean constraint restricts the set of users that can remove a Shared VPC host project lien without organization-level permission where this constraint is enforced. By default, any user with the permission to update liens can remove a Shared VPC host project lien. Enforcing this constraint requires that permission be granted at the organization level.
constraints/compute.restrictXpnProjectLienRemoval
Resource Manager
Restrict removal of Cross Project Service Account liens
This boolean constraint, when ENFORCED, prevents users from removing a Cross Project Service Account lien without organization-level permission. By default, any user with the permission to update liens can remove a Cross Project Service Account lien. Enforcing this constraint requires that permission to be granted at the organization level.
This list constraint, when enforced on an organization resource, defines the set of Google Cloud resources that are returned in list and search methods for users in the domain of the organization where this constraint is enforced. This can be used to limit what resources are visible in various parts of the Cloud Console, such as the Resource Picker, Search, and Manage Resources page. Note that this Constraint is only ever evaluated at the Organization level. Values specified in allow/deny lists must be in the form: under:organizations/ORGANIZATION_ID.
This list constraint acts as a check to verify that a project with a service enabled is eligible for cross-organization move. A resource with a supported service enabled must have this constraint enforced and that supported service included in the allowed values to be eligible for a cross-organization move. The current list of allowed values for supported services that can be used is:
SHARED_VPC
This constraint provides an additional control on top of constraints/resourcemanager.allowedExportDestinations. This list_constraint is empty by default and will not block cross organization moves unless a supported service is enabled on the resource to be exported. This constraint allows more fine-grained control over resources using features that require more caution when being moved to another organization. By default, a resource with a supported service enabled cannot be moved across organizations.
This list constraint defines the set of external Organizations to which resources can be moved, and denies all moves to all other Organizations. By default, resources cannot be moved between Organizations. If this constraint is applied to a resource, the resource can be moved only to Organizations that are explicitly allowed by this constraint. Moves within an Organization are not governed by this constraint. The move operation will still require the same IAM permissions as normal resource moves. Values specified in allow/deny lists must be in the form: under:organizations/ORGANIZATION_ID.
This list constraint defines the set of external organizations from which resources can be imported, and denies all moves from all other organizations. By default, resources cannot be moved between organizations. If this constraint is applied to a resource, imported resources directly under this resource must be explicitly allowed by this constraint. Moves within an organization or from outside an organization into an organization aren't governed by this constraint. The move operation will still require the same IAM permissions as normal resource moves. Values specified in allow/deny lists must be in the form: under:organizations/ORGANIZATION_ID.
This list constraint defines the set of Binary Authorization policy names that are allowed to be specified on a Cloud Run resource. To allow/disallow a default policy, use the value default. To allow/disallow one or more custom platform policies, the resource ID of each such policy must be added separately.
This list constraint defines the allowed ingress settings for Cloud Run services. When this constraint is enforced, services will be required to have ingress settings that match one of the allowed values. Existing Cloud Run services with ingress settings that violate this constraint can continue to be updated until the service's ingress settings are changed to comply with this constraint. Once a service complies with this constraint the service can only use ingress settings allowed by this constraint. By default, Cloud Run services can use any ingress settings. The allowed list must contain supported ingress settings values, which are all, internal, and internal-and-cloud-load-balancing.
This list constraint defines the allowed VPC egress settings to be specified on a Cloud Run resource. When this constraint is enforced, Cloud Run resources are required to be deployed with a Serverless VPC Access connector or with Direct VPC egress enabled, and VPC egress settings are required to match one of the allowed values. By default, Cloud Run resources can set VPC egress settings to any supported value. The allowed list must contain supported VPC egress settings values, which are private-ranges-only and all-traffic.
For existing Cloud Run services, all new revisions must comply with this constraint. Existing services with revisions serving traffic that violate this constraint can continue to migrate traffic to revisions that violate this constraint. Once all traffic for a service is served by revisions compliant with this constraint, all subsequent traffic migrations must only migrate traffic to revisions that comply with this constraint.
This boolean constraint, when enforced, prevents the default App Engine and Compute Engine service accounts that are created in your projects from being automatically granted any IAM role on the project when the accounts are created. By default, these service accounts automatically receive the Editor role when they are created. To learn about default service accounts, see https://docs.cloud.google.com/iam/help/service-accounts/default. To learn which roles to grant instead of the Editor role, see https://docs.cloud.google.com/iam/help/service-accounts/troubleshoot-roles-default.
This list constraint defines the set of allowed Cloud Build Worker Pools for performing Builds using Cloud Build. When this constraint is enforced, builds will be required to build in a Worker Pool that matches one of the allowed values. By default, Cloud Build can use any Worker Pool. The allowed list of Worker Pools must be of the form:
This list constraint defines the set of locations where location-based Google Cloud resources can be created. Important: The information on this page does not describe Google Cloud Platform's data location commitments for Customer Data (as defined in the agreement under which Google has agreed to provide Google Cloud Platform services and as described in the Google Cloud Platform Services Summary at https://docs.cloud.google.com/terms/services) to its customers. For the list of Google Cloud Platform services for which Customer Data location may be selected by customers, see Google Cloud Platform Services with Data Residency at https://docs.cloud.google.com/terms/data-residency. By default, resources can be created in any location. For a full list of supported services, see https://docs.cloud.google.com/organization-policy/reference/restrict-locations-supported-services. Policies for this constraint can specify multi-regions such as asia and europe, regions such as us-east1 or europe-west1 as allowed or denied locations. Allowing or denying a multi-region does not imply that all included sub-locations should also be allowed or denied. For example, if the policy denies the us multi-region (which refers to multi-region resources, like some storage services), resources can still be created in the regional location us-east1. On the other hand, the in:us-locations group contains all locations within the us region, and can be used to block every region. We recommend using value groups to define your policy. You can specify value groups, collections of locations that are curated by Google to provide a simple way to define your resource locations. To use value groups in your organization policy, prefix your entries with the string in:, followed by the value group. For example, to create resources that will only be physically located within the US, set in:us-locations in the list of allowed values. If the suggested_value field is used in a location policy, it should be a region. If the value specified is a region, a UI for a zonal resource may pre-populate any zone in that region.
This list constraint defines which projects may be used to supply Customer-Managed Encryption Keys (CMEK) when creating resources. Setting this constraint to Allow (i.e. only allow CMEK keys from these projects) ensures that CMEK keys from other projects cannot be used to protect newly created resources. Values for this constraint must be specified in the form of under:organizations/ORGANIZATION_ID, under:folders/FOLDER_ID, or projects/PROJECT_ID. Supported services that enforce this constraint are:
aiplatform.googleapis.com
alloydb.googleapis.com
apigee.googleapis.com
artifactregistry.googleapis.com
backupdr.googleapis.com
bigquery.googleapis.com
bigquerydatatransfer.googleapis.com
bigtable.googleapis.com
cloudfunctions.googleapis.com
cloudscheduler.googleapis.com
cloudtasks.googleapis.com
composer.googleapis.com
compute.googleapis.com
contactcenterinsights.googleapis.com
container.googleapis.com
dataflow.googleapis.com
dataform.googleapis.com
datafusion.googleapis.com
dataplex.googleapis.com
dataproc.googleapis.com
dialogflow.googleapis.com
discoveryengine.googleapis.com
documentai.googleapis.com
eventarc.googleapis.com
file.googleapis.com
firestore.googleapis.com
gkebackup.googleapis.com
integrations.googleapis.com
logging.googleapis.com
looker.googleapis.com
lustre.googleapis.com
netapp.googleapis.com
notebooks.googleapis.com
observability.googleapis.com
pubsub.googleapis.com
redis.googleapis.com
run.googleapis.com
secretmanager.googleapis.com
securesourcemanager.googleapis.com
securitycenter.googleapis.com
spanner.googleapis.com
speech.googleapis.com
sqladmin.googleapis.com
storage.googleapis.com
tpu.googleapis.com
workstations.googleapis.com
Enforcement of this constraint may grow over time to include additional services. Use caution when applying this constraint to projects, folders, or organizations where a mix of supported and unsupported services are used. Setting this constraint to Deny or Deny All is not permitted. Enforcement of this constraint is not retroactive. Existing CMEK Google Cloud resources with KMS CryptoKeys from disallowed projects must be reconfigured or recreated manually to ensure enforcement.
This list constraint defines the set of Google Cloud API endpoints that can be used to access resources in an organization, folder, or project. This constraint can be used to block access to Google Cloud resources through global API endpoints, enforcing that locational or regional endpoints be used. For example, specifying bigquery.googleapis.com in this policy's denylist will cause requests to bigquery.googleapis.com/... to fail but requests to {location}-bigquery.googleapis.com/... succeed. By default, access to all Google Cloud API endpoints is allowed. The denied list of endpoints must come from the list below. Trying to save the denied list with other values will fail. For more information, including the list of valid constraint values, please refer to the Restrict endpoint usage user guide.
This list constraint defines which services require Customer-Managed Encryption Keys (CMEK). Setting this constraint to Deny (i.e. deny resource creation without CMEK) requires that, for the specified services, newly created resources must be protected by a CMEK key. Supported services that can be set in this constraint are:
aiplatform.googleapis.com
alloydb.googleapis.com
apigee.googleapis.com
artifactregistry.googleapis.com
backupdr.googleapis.com
bigquery.googleapis.com
bigquerydatatransfer.googleapis.com
bigtable.googleapis.com
cloudfunctions.googleapis.com
cloudscheduler.googleapis.com
cloudtasks.googleapis.com
composer.googleapis.com
compute.googleapis.com
contactcenterinsights.googleapis.com
container.googleapis.com
dataflow.googleapis.com
dataform.googleapis.com
datafusion.googleapis.com
dataplex.googleapis.com
dataproc.googleapis.com
dialogflow.googleapis.com
discoveryengine.googleapis.com
documentai.googleapis.com
eventarc.googleapis.com
file.googleapis.com
firestore.googleapis.com
gkebackup.googleapis.com
integrations.googleapis.com
logging.googleapis.com
looker.googleapis.com
lustre.googleapis.com
netapp.googleapis.com
notebooks.googleapis.com
observability.googleapis.com
pubsub.googleapis.com
redis.googleapis.com
run.googleapis.com
secretmanager.googleapis.com
securesourcemanager.googleapis.com
securitycenter.googleapis.com
spanner.googleapis.com
speech.googleapis.com
sqladmin.googleapis.com
storage.googleapis.com
storagetransfer.googleapis.com
tpu.googleapis.com
workstations.googleapis.com
Setting this constraint to Deny All is not permitted. Setting this constraint to Allow is not permitted. Enforcement of this constraint is not retroactive. Existing non-CMEK Google Cloud resources must be reconfigured or recreated manually to ensure enforcement.
This constraint defines the set of Google Cloud resource services that can be used within an organization, folder, or project, such as compute.googleapis.com and storage.googleapis.com. By default, all Google Cloud resource services are allowed. For more information, see https://docs.cloud.google.com/organization-policy/restrict-services.
This list constraint defines the set of TLS cipher suites that can be used to access resources in an organization, folder, or project where this constraint is enforced. By default, all TLS cipher suites are allowed. TLS cipher suites can be specified as an allowlist or a denylist and must be identified using their names. For example, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_AES_128_GCM_SHA256.You can also specify value groups, collections of cipher suites that are curated by Google to provide a simple way to define the constraint. To use value groups in your organization policy, prefix your entries with the string in:, followed by the value group. For example, in:CNSA-2.0-recommended-ciphers. This constraint is only applied to requests using TLS. It will not be used to restrict unencrypted requests. For more information, please refer to the Restrict TLS Cipher Suites user guide.
This constraint defines the set of TLS versions that cannot be used on the organization, folder, or project where this constraint is enforced, or any of that resource's children in the resource hierarchy. By default, all TLS versions are allowed. TLS versions can only be specified in the denied list, and must be identified in the form TLS_VERSION_1 or TLS_VERSION_1_1. This constraint is only applied to requests using TLS. It will not be used to restrict unencrypted requests. For more information, see https://docs.cloud.google.com/docs/security/compliance/restrict-tls-versions.
This boolean constraint, when enforced, disables turning on Identity-Aware Proxy on regional resources. Enabling IAP on global resources is not restricted by this constraint. By default, enabling IAP on regional resources is allowed.
This list constraint restricts the set of services and their APIs that can be enabled on this resource. By default, all services are allowed. The denied list of services must come from the list below. Explicitly enabling APIs via this constraint is not currently supported. Specifying an API not in this list will result in an error.
Enforcement of this constraint is not retroactive. If a service is already enabled on a resource when this constraint is enforced, it will remain enabled.
Supported prefix: is:
constraints/serviceuser.services
Spanner
Enable advanced service control for compliance workloads
Do not configure or modify this policy. This constraint is automatically configured during Assured Workloads onboarding and is only intended for advanced regulatory control for Assured Workloads. When this boolean constraint is enforced, certain aspects of supportability will be impaired and provisioned resources will strictly follow advanced sovereignty requirements for Assured Workloads. This policy will apply to existing projects, but it will not affect resources that have already been provisioned; ie. modifications to the policy will only be reflected in resources created after the policy is modified.
Do not configure or modify this policy. This constraint is automatically configured during Assured Workloads onboarding and is only intended for advanced regulatory control for Assured Workloads. This boolean constraint, when enforced, prevents the creation of spanner instances using multi region instance config unless a location is selected. Cloud Spanner today does not yet support selecting location, so all multi regions will be disallowed. In the future, Spanner will provide the functionality for users to select a location for multi regions. Enforcement of this constraint is not retroactive. Spanner instances that have been already created will be unaffected.
When Detailed Audit Logging Mode is enforced, both the request and response are included in Cloud Audit Logs. Changes to this feature may take up to 10 minutes to reflect. This Org Policy is highly encouraged in coordination with Bucket Lock when seeking compliance with standards such as SEC Rule 17a-4(f), CFTC Rule 1.31(c)-(d), and FINRA Rule 4511(c). This policy is currently only supported in Cloud Storage.
Secure your Cloud Storage data from public exposure by enforcing public access prevention. This governance policy prevents existing and future resources from being accessed via the public internet by disabling and blocking ACLs and IAM permissions that grant access to allUsers and allAuthenticatedUsers. Enforce this policy on the entire organization (recommended), specific projects, or specific folders to ensure no data is publicly exposed. This policy overrides existing public permissions. Public access will be revoked for existing buckets and objects after this policy is enabled. For more details on the effects of changing enforcement of this constraint on resources, please see: https://docs.cloud.google.com/storage/docs/public-access-prevention.
The constraint defines the set of authentication types that would be restricted from accessing any storage resources under the organization in Cloud Storage. Supported values are USER_ACCOUNT_HMAC_SIGNED_REQUESTS, SERVICE_ACCOUNT_HMAC_SIGNED_REQUESTS, and RSA_SIGNED_REQUESTS. Use in:ALL_HMAC_SIGNED_REQUESTS to include user account and service account HMAC signed requests. Use in:ALL_SIGNED_REQUESTS to include HMAC and RSA signed requests.
This list constraint defines the set of durations for retention policies that can be set on Cloud Storage buckets. By default, if no organization policy is specified, a Cloud Storage bucket can have a retention policy of any duration. The list of allowed durations must be specified as a positive integer value greater than zero, representing the retention policy in seconds. Any insert, update, or patch operation on a bucket in the organization resource must have a retention policy duration that matches the constraint. Enforcement of this constraint is not retroactive. When a new organization policy is enforced, the retention policy of existing buckets remains unchanged and valid.
This boolean constraint, when enforced, explicitly denies HTTP (unencrypted) access to all storage resources. By default, the Cloud Storage XML API allows unencrypted HTTP access. Note that the Cloud Storage JSON API, gRPC, and Cloud console only allow encrypted HTTP access to Cloud Storage resources.
constraints/storage.secureHttpTransport
Cloud Storage
Cloud Storage - soft delete policy retention duration in seconds
This constraint defines the allowable retention durations for soft delete policies set on Cloud Storage buckets where this constraint is enforced. Any insert, update, or patch operation on a bucket where this constraint is enforced must have a soft delete policy duration that matches the constraint. When a new organization policy is enforced, the soft delete policy of existing buckets remains unchanged and valid. By default, if no organization policy is specified, a Cloud Storage bucket can have a soft delete policy of any duration.
This boolean constraint requires buckets to use uniform bucket-level access where this constraint is set to True. Any new bucket in the Organization resource must have uniform bucket-level access enabled, and no existing buckets in the organization resource can disable uniform bucket-level access. Enforcement of this constraint is not retroactive: existing buckets with uniform bucket-level access disabled continue to have it disabled. The default value for this constraint is False. Uniform bucket-level access disables the evaluation of ACLs assigned to Cloud Storage objects in the bucket. Consequently, only IAM policies grant access to objects in these buckets.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2026-06-09 UTC."],[],[]]
