Preventative controls for acceptable resource configurations
We recommend that you define policy constraints that enforce acceptableresource configurations and prevent risky configurations. The blueprint uses acombination of organization policy constraints and infrastructure-as-code (IaC)validation in your pipeline. These controls prevent the creation of resourcesthat don't meet your policy guidelines. Enforcing these controls early in thedesign and build of your workloads helps you to avoid remediation work later.
Organization policy constraints
TheOrganization Policyservice enforces constraints to ensure that certain resource configurationscan't be created in your Google Cloud organization, even by someone with asufficiently privileged IAM role.
The blueprint enforces policies at the organization node so that these controlsare inherited by all folders and projects within the organization. This bundleof policies is designed to prevent certain high-risk configurations, such asexposing a VM to the public internet or granting public access to storagebuckets, unless you deliberately allow an exception to the policy.
The following table introduces theorganization policy constraintsthat are implemented in the blueprint:
| Organization policy constraint | Description |
|---|---|
| Nested virtualization on Compute Engine VMs can evade monitoring and other security tools for your VMs if poorly configured. This constraint prevents the creation of nested virtualization. |
| IAM roles like |
| External IPv6 subnets can be exposed to unauthorized internet access if they are poorly configured. This constraint prevents the creation of external IPv6 subnets. |
| The default behavior of settingSSH keys in metadata can allow unauthorized remote access to VMs if keys are exposed. This constraint enforces the use ofOS Login instead of metadata-based SSH keys. |
| VM protocol forwarding for external IP addresses can lead to unauthorized internet egress if forwarding is poorly configured. This constraint allows VM protocol forwarding for internal addresses only. |
| Deleting a Shared VPC host project can be disruptive to all the service projects that use networking resources. This constraint prevents accidental or malicious deletion of the Shared VPC host projects by preventing the removal of theproject lien on these projects. |
| A legacy setting forglobal (project-wide) internal DNS is not recommended because it reduces service availability. This constraint prevents the use of the legacy setting. |
| A default VPC network and overly permissive default VPC firewall rules are created in every new project that enables the Compute Engine API. This constraint skips the creation of the default network and default VPC firewall rules. |
| By default, a VM is created with an external IPv4 address that can lead to unauthorized internet access. This constraint configures an empty allowlist of external IP addresses that the VM can use and denies all others. |
| By default,Essential Contacts can be configured to send notifications about your domain to any other domain. This constraint enforces that only email addresses in approved domains can be set as recipients for Essential Contacts. |
| By default,allow policies can be granted to any Google Account, including unmanaged accounts, and accounts belonging to external organizations. This constraint ensures that allow policies in your organization can only be granted to managed accounts from your own domain. Optionally, you canallow additional domains. |
| By default,default service accounts are automatically granted overly permissive roles. This constraint prevents the automatic IAM role grants to default service accounts. |
| Service account keys are a high-risk persistent credential, and in most cases amore secure alternative to service account keys can be used. This constraint prevents the creation of service account keys. |
| Uploading service account key material can increase risk if key material is exposed. This constraint prevents the uploading of service account keys. |
| Cloud SQL instances can be exposed to unauthenticated internet access if the instances are configured to useauthorized networks without aCloud SQL Auth Proxy. This policy prevents the configuration of authorized networks for database access and forces the use of the Cloud SQL Auth Proxy instead. |
| Cloud SQL instances can be exposed to unauthenticated internet access if the instances are created with public IP addresses. This constraint preventspublic IP addresses on Cloud SQL instances. |
| By default, objects in Cloud Storage can be accessed through legacyAccess Control Lists (ACLs) instead of IAM, which can lead to inconsistent access controls and accidental exposure if misconfigured. Legacy ACL access is not affected by the |
| Cloud Storage buckets can be exposed to unauthenticated internet access if misconfigured. This constraint prevents ACLs and IAM permissions that grant access to |
These policies are a starting point that we recommend for most customers andmost scenarios, but you might need to modify organization policy constraints toaccommodate certain workload types. For example, a workload that uses aCloud Storage bucket as the backend for Cloud CDN to hostpublic resources is blocked bystorage.publicAccessPrevention, or apublic-facing Cloud Run app that doesn't require authentication isblocked byiam.allowedPolicyMemberDomains. In these cases, modify theorganization policy at the folder or project level to allow a narrow exception.You can alsoconditionally add constraints to organization policyby defining a tag that grants an exception or enforcement for policy, thenapplying the tag to projects and folders.
For additional constraints, seeavailable constraints andcustom constraints.
Pre-deployment validation of infrastructure-as-code
The blueprint uses a GitOps approach to manage infrastructure, meaning that allinfrastructure changes are implemented through version-controlledinfrastructure-as-code (IaC) and can be validated before deploying.
Thepolicies enforced in the blueprintdefine acceptable resource configurations that can be deployed by your pipeline.If code that is submitted to your GitHub repository does not pass the policychecks, no resources are deployed.
For information on how pipelines are used and how controls are enforced throughCI/CD automation, seedeployment methodology.
What's next
- Read aboutdeployment methodology(next document in this series)
Except as otherwise noted, the content of this page is licensed under theCreative Commons Attribution 4.0 License, and code samples are licensed under theApache 2.0 License. For details, see theGoogle Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2025-05-15 UTC.