Preventative controls for acceptable resource configurations

Last reviewed 2023-12-20 UTC

We recommend that you define policy constraints that enforce acceptable resource configurations and prevent risky configurations. The blueprint uses a combination of organization policy constraints and infrastructure-as-code (IaC) validation in your pipeline. These controls prevent the creation of resources that don't meet your policy guidelines. Enforcing these controls early in the design and build of your workloads helps you to avoid remediation work later.

Organization policy constraints

The Organization Policy service enforces constraints to ensure that certain resource configurations can't be created in your Google Cloud organization, even by someone with a sufficiently privileged IAM role.

The blueprint enforces policies at the organization node so that these controls are inherited by all folders and projects within the organization. This bundle of policies is designed to prevent certain high-risk configurations, such as exposing a VM to the public internet or granting public access to storage buckets, unless you deliberately allow an exception to the policy.

The following table introduces the organization policy constraints that are implemented in the blueprint:

Organization policy constraint	Description
`compute.disableNestedVirtualization`	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.
`compute.disableSerialPortAccess`	IAM roles like `compute.instanceAdmin` allow privileged access to an instance's serial port using SSH keys. If the SSH key is exposed, an attacker could access the serial port and bypass network and firewall controls. This constraint prevents serial port access.
`compute.disableVpcExternalIpv6`	External IPv6 subnets can be exposed to unauthorized internet access if they are poorly configured. This constraint prevents the creation of external IPv6 subnets.
`compute.requireOsLogin`	The default behavior of setting SSH keys in metadata can allow unauthorized remote access to VMs if keys are exposed. This constraint enforces the use of OS Login instead of metadata-based SSH keys.
`compute.restrictProtocolForwardingCreationForTypes`	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.
`compute.restrictXpnProjectLienRemoval`	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 the project lien on these projects.
`compute.setNewProjectDefaultToZonalDNSOnly`	A legacy setting for global (project-wide) internal DNS is not recommended because it reduces service availability. This constraint prevents the use of the legacy setting.
`compute.skipDefaultNetworkCreation`	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.
`compute.vmExternalIpAccess`	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.
`essentialcontacts.allowedContactDomains`	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.
`iam.allowedPolicyMemberDomains`	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 can allow additional domains.
`iam.automaticIamGrantsForDefaultServiceAccounts`	By default, default service accounts are automatically granted overly permissive roles. This constraint prevents the automatic IAM role grants to default service accounts.
`iam.disableServiceAccountKeyCreation`	Service account keys are a high-risk persistent credential, and in most cases a more secure alternative to service account keys can be used. This constraint prevents the creation of service account keys.
`iam.disableServiceAccountKeyUpload`	Uploading service account key material can increase risk if key material is exposed. This constraint prevents the uploading of service account keys.
`sql.restrictAuthorizedNetworks`	Cloud SQL instances can be exposed to unauthenticated internet access if the instances are configured to use authorized networks without a Cloud 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.
`sql.restrictPublicIp`	Cloud SQL instances can be exposed to unauthenticated internet access if the instances are created with public IP addresses. This constraint prevents public IP addresses on Cloud SQL instances.
`storage.uniformBucketLevelAccess`	By default, objects in Cloud Storage can be accessed through legacy Access 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 `iam.allowedPolicyMemberDomains` constraint. This constraint enforces that access can only be configured through IAM uniform bucket-level access, not legacy ACLs.
`storage.publicAccessPrevention`	Cloud Storage buckets can be exposed to unauthenticated internet access if misconfigured. This constraint prevents ACLs and IAM permissions that grant access to `allUsers` and `allAuthenticatedUsers`.

These policies are a starting point that we recommend for most customers and most scenarios, but you might need to modify organization policy constraints to accommodate certain workload types. For example, a workload that uses a Cloud Storage bucket as the backend for Cloud CDN to host public resources is blocked by storage.publicAccessPrevention, or a public-facing Cloud Run app that doesn't require authentication is blocked by iam.allowedPolicyMemberDomains. In these cases, modify the organization policy at the folder or project level to allow a narrow exception. You can also conditionally add constraints to organization policy by defining a tag that grants an exception or enforcement for policy, then applying the tag to projects and folders.

For additional constraints, see available constraints and custom constraints.

Pre-deployment validation of infrastructure-as-code

The blueprint uses a GitOps approach to manage infrastructure, meaning that all infrastructure changes are implemented through version-controlled infrastructure-as-code (IaC) and can be validated before deploying.

The policies enforced in the blueprint define acceptable resource configurations that can be deployed by your pipeline. If code that is submitted to your GitHub repository does not pass the policy checks, no resources are deployed.

For information on how pipelines are used and how controls are enforced through CI/CD automation, see deployment methodology.

What's next

Read about deployment methodology (next document in this series)