GCP Organization Policies: 4 Key Controls Explained

Google Cloud Platform provides organization policies as a centralized way to enforce compliance, security, and governance requirements across your entire resource hierarchy. These policies cascade from the organization level down through folders and projects, creating consistent guardrails that prevent configuration drift and unauthorized access patterns. Among the many available policies, four stand out as particularly important for security-conscious organizations: compute.resourceLocations, iam.allowedPolicyMemberDomains, compute.vmExternalIpAccess, and compute.requireOsLogin.

Each of these GCP organization policies addresses a distinct aspect of cloud governance. Geographic data residency requirements affect where resources can be created. Identity management controls determine who can access your cloud environment. Network security policies govern how virtual machines connect to the internet. Authentication mechanisms control how users access compute instances. Together, these policies form a comprehensive framework for maintaining security posture and regulatory compliance across your Google Cloud environment.

Understanding GCP Organization Policies

Before examining specific policies, you need to understand how organization policies work in Google Cloud. Unlike IAM permissions that control who can perform actions, organization policies define what actions are allowed regardless of who attempts them. A policy applied at the organization level automatically applies to all folders and projects beneath it unless explicitly overridden at a lower level. This inheritance model ensures that critical security requirements remain enforced even as your cloud environment grows and changes.

The four policies we will examine operate independently but often work together to create a secure cloud environment. A regional bank might use compute.resourceLocations to keep data within specific geographic boundaries, iam.allowedPolicyMemberDomains to ensure only corporate identities access resources, compute.vmExternalIpAccess to prevent unauthorized internet exposure, and compute.requireOsLogin to eliminate static SSH keys. Each policy solves a different problem, yet they complement each other in building a defense-in-depth security strategy.

compute.resourceLocations: Geographic Resource Boundaries

The compute.resourceLocations organization policy restricts where resources can be created within Google Cloud. This constraint affects compute instances, persistent disks, Cloud Storage buckets, BigQuery datasets, and numerous other services. When you enable this policy, you specify allowed or denied locations using region codes, and GCP blocks any attempt to create resources outside those boundaries.

A pharmaceutical research company operating under European data protection regulations might configure this policy to allow only europe-west1, europe-west4, and europe-north1 regions. Any developer attempting to launch a Compute Engine instance in us-central1 would receive an error, even if they have the necessary IAM permissions to create instances. The policy operates as a hard constraint that prevents the action entirely.

This policy addresses data residency requirements that appear in regulations like GDPR, which requires that certain categories of data remain within EU borders. Healthcare organizations dealing with patient records, financial institutions managing customer data, and government agencies handling sensitive information all face geographic restrictions on where data can be stored and processed. The compute.resourceLocations policy provides technical enforcement of these legal requirements.

To configure this policy, you can use the Google Cloud Console or the gcloud command line tool. Here is an example that restricts resources to European regions:

gcloud resource-manager org-policies set-policy \
  --organization=YOUR_ORG_ID \
  compute.resourceLocations \
  --allowed-values=in:eu-locations

You can also specify individual regions rather than using predefined location groups. The policy supports both allow lists and deny lists, giving you flexibility in how you define geographic boundaries. A multinational agricultural monitoring company might deny specific regions where it has no operations while allowing all others, rather than maintaining a long list of permitted locations.

iam.allowedPolicyMemberDomains: Identity Domain Restrictions

The iam.allowedPolicyMemberDomains policy controls which identity domains can be granted IAM permissions in your organization. When enabled, this constraint ensures that only users from specified domains can appear in IAM policies. A company with the domain acmelogistics.com can configure this policy to block any attempt to grant permissions to users from external domains like personal Gmail accounts or partner organizations.

This policy prevents a common security risk where developers accidentally grant permissions to external identities. A freight logistics company might have a developer who intends to share access with a colleague at jane@acmelogistics.com but mistakenly grants permissions to jane@gmail.com instead. Without domain restrictions, this personal account would receive access to company resources. With iam.allowedPolicyMemberDomains configured, the policy assignment fails immediately with a clear error message.

The policy affects all IAM bindings across your organization, including project-level permissions, service account assignments, and resource-specific access controls. When you attempt to add a member from an unauthorized domain to any IAM policy, Google Cloud blocks the operation. This enforcement extends to service accounts as well. You can restrict which domains are allowed to create service accounts or which external service accounts can be granted permissions in your projects.

A telehealth platform handling patient video consultations would configure this policy to allow only its corporate domain and specific partner domains for third-party integrations. Here is how you would configure the policy to allow only two domains:

gcloud resource-manager org-policies set-policy \
  --organization=YOUR_ORG_ID \
  iam.allowedPolicyMemberDomains \
  --allowed-values=healthplatform.com,trustedpartner.com

This policy becomes particularly important for organizations that use Google Workspace alongside GCP. Without domain restrictions, anyone with a Google account could potentially be added to IAM policies. The constraint ensures that access remains limited to corporate identities that can be managed, audited, and revoked through your identity provider.

compute.vmExternalIpAccess: External IP Control

The compute.vmExternalIpAccess policy determines whether Compute Engine instances can be assigned external IP addresses. By default, GCP allows any instance to receive a public IP address, making it directly accessible from the internet. This policy lets you block external IPs entirely, allow them only for specific instances, or require approval before assignment.

A payment processor handling credit card transactions would typically block external IPs on all production instances. Application servers, databases, and internal services operate entirely on private IP addresses within VPC networks. Only specific jump hosts or bastion servers receive external IPs for administrative access, and these are carefully controlled through the policy. This configuration prevents accidental exposure of internal services to the internet.

The policy works by evaluating instance labels when compute instances are created or modified. You define which instances can have external IPs by specifying label key-value pairs in the policy configuration. An instance without the required labels cannot receive an external IP address, even if the API request explicitly requests one. This approach gives you fine-grained control while maintaining flexibility for legitimate use cases.

Consider a mobile game studio that needs external IPs for game servers that players connect to directly, but wants to block external IPs on database instances, analytics systems, and development environments. The policy configuration would look like this:

gcloud resource-manager org-policies set-policy \
  --organization=YOUR_ORG_ID \
  compute.vmExternalIpAccess \
  --allowed-values=projects/PROJECT_ID/zones/ZONE/instances/INSTANCE_NAME

You can also use a deny-all approach combined with exceptions. Set the policy to block all external IPs by default, then override it at the project or folder level for specific workloads that require internet accessibility. This approach implements a security principle of least privilege, where capabilities must be explicitly granted rather than implicitly available.

The policy integrates with Cloud NAT for outbound internet connectivity. Instances without external IPs can still access the internet for software updates, API calls to external services, and other outbound traffic through Cloud NAT. This configuration provides the security benefits of private addressing while maintaining necessary internet connectivity.

compute.requireOsLogin: Centralized VM Authentication

The compute.requireOsLogin policy mandates that all Compute Engine instances use OS Login rather than traditional SSH key management. OS Login integrates Google Cloud IAM with Linux user management, eliminating the need to distribute and maintain SSH keys across your fleet of virtual machines. When this policy is enabled, users authenticate to instances using their Google Cloud identity, and their access is governed by IAM roles.

Traditional SSH access requires generating key pairs and distributing public keys to instances through metadata or configuration management tools. This approach creates several security challenges. Keys may be shared among team members, making audit trails unclear. Departing employees leave keys scattered across instances. Keys never expire unless manually rotated. A climate modeling research institute with hundreds of compute instances running simulations would face significant operational overhead managing SSH keys manually.

OS Login solves these problems by tying instance access directly to IAM permissions. When a researcher needs to access a compute instance, you grant them the roles/compute.osLogin role for that project or specific instance. When they connect via SSH, GCP authenticates their identity, creates a temporary user account on the instance, and grants appropriate permissions based on their IAM roles. When the researcher leaves the organization, revoking their IAM access immediately removes their ability to access any instances.

The policy can enforce OS Login across your entire organization with a single configuration:

gcloud resource-manager org-policies set-policy \
  --organization=YOUR_ORG_ID \
  compute.requireOsLogin \
  --enforce

OS Login supports two-factor authentication when combined with Google Cloud Identity. A financial trading platform processing millions of transactions daily would require 2FA for all instance access, adding an additional security layer beyond password-based authentication. Users authenticate with their corporate credentials plus a time-based token from their mobile device before gaining shell access to instances.

The policy also enables detailed audit logging. Every SSH connection generates Cloud Audit Logs entries showing who accessed which instance at what time and what commands they executed. For compliance purposes, a hospital network managing patient data systems can demonstrate exactly who accessed specific servers and when, meeting requirements for HIPAA and similar regulations.

Implementation in Google Cloud Platform

These GCP organization policies are configured through the Organization Policy Service, accessible via the Google Cloud Console, gcloud CLI, or REST API. In the console, navigate to the IAM & Admin section and select Organization Policies. Each policy appears in the list with its current enforcement status. You can apply policies at the organization level to affect all resources, or at folder and project levels for more granular control.

Policy inheritance follows the resource hierarchy from organization to folders to projects. A policy set at the organization level applies to all child resources unless overridden. Some policies support inheritance overrides, letting you relax restrictions for specific projects while maintaining strict defaults elsewhere. A solar farm monitoring company might enforce strict external IP blocking at the organization level but allow exceptions for a specific project that hosts customer-facing dashboards.

When conflicts occur between policies at different hierarchy levels, the evaluation follows GCP's policy inheritance rules. For boolean constraints like compute.requireOsLogin, enforcement at any level in the hierarchy takes precedence. For list constraints like compute.resourceLocations, the most specific policy wins. Understanding these inheritance rules is critical for designing policy hierarchies that balance security with operational flexibility.

Comparison and Relationships

These four organization policies address different dimensions of cloud governance, and they work best when implemented together as part of a comprehensive security strategy.

Policy	Controls	Primary Use Case	Affected Services
compute.resourceLocations	Geographic location of resources	Data residency compliance	Compute, Storage, BigQuery, most GCP services
iam.allowedPolicyMemberDomains	Identity domains in IAM policies	Prevent external identity access	All IAM policies across GCP
compute.vmExternalIpAccess	External IP address assignment	Limit internet exposure	Compute Engine instances
compute.requireOsLogin	VM authentication method	Centralized access control	Compute Engine instances

The policies are not mutually exclusive. A video streaming service would likely implement all four: restricting content servers to specific regions for performance and licensing reasons, limiting IAM access to company employees, blocking external IPs on backend systems while allowing them on edge caches, and requiring OS Login for administrative access to all instances.

Some policies reinforce each other. Combining compute.vmExternalIpAccess with compute.requireOsLogin creates a strong access control model. External IPs are blocked on application instances, forcing administrators to connect through bastion hosts. OS Login on those bastion hosts ensures that only authorized users with current IAM permissions can establish connections. This layered approach makes unauthorized access significantly more difficult.

Choosing the Right Policies for Your Organization

Your choice of which policies to implement depends on your regulatory requirements, security posture, and operational model. Organizations in heavily regulated industries typically need all four policies. A municipal transit system collecting ridership data would face both data residency requirements and strict access controls, making geographic restrictions, domain controls, external IP blocking, and OS Login all necessary.

Start by identifying your compliance requirements. If regulations mandate data residency, compute.resourceLocations becomes essential. If you need to demonstrate control over who can access your environment, iam.allowedPolicyMemberDomains and compute.requireOsLogin provide audit trails and centralized management. If you need to minimize attack surface, compute.vmExternalIpAccess prevents unnecessary internet exposure.

Consider your operational maturity as well. Implementing compute.requireOsLogin requires training teams on the new authentication flow and updating connection procedures. Blocking external IPs requires establishing Cloud NAT for outbound connectivity and configuring load balancers or Cloud CDN for inbound traffic. A startup with a small team might implement these policies gradually as the organization grows, while an established enterprise might implement all policies from the start.

Certification Exam Considerations

Organization policies appear frequently on Google Cloud certification exams, including the Professional Cloud Architect and Professional Security Engineer certifications. Exam questions often present scenarios where you must choose appropriate policies to meet specific requirements. Understanding the difference between these four policies helps you identify which policy solves which problem.

Exam scenarios might describe a healthcare provider that needs to ensure patient data remains in specific countries, prevent contractors from granting access to external identities, and eliminate SSH key management. Recognizing that this requires compute.resourceLocations, iam.allowedPolicyMemberDomains, and compute.requireOsLogin respectively demonstrates your understanding of how these policies map to real-world requirements.

Building Comprehensive Governance

These GCP organization policies form the foundation of cloud governance in Google Cloud Platform. Geographic restrictions ensure compliance with data residency regulations. Domain controls prevent unauthorized external access. External IP policies limit internet exposure and reduce attack surface. OS Login centralizes authentication and creates detailed audit trails. Each policy addresses a specific governance requirement, yet together they create a secure, compliant, and manageable cloud environment.

Implementing these policies requires careful planning and testing. Start with non-production environments to understand how policies affect your workflows. Document exceptions and the business justification for each one. Review policies regularly as your security requirements and operational practices evolve. With proper implementation, organization policies become powerful tools that enforce governance automatically across your entire Google Cloud infrastructure, reducing risk while enabling teams to work efficiently within secure boundaries.