GCP Organization Policies for Security Enforcement: How to Block Dangerous Configurations Across All Projects Without Breaking Developer Workflows

Organization Policies follow the GCP resource hierarchy: Organization > Folder > Project. A policy applied at the organization level inherits down through all folders and projects unless explicitly overridden at a lower level. Inheritance can be modified in two ways:

Merge: Policies at lower levels are merged with inherited policies. Useful for list constraints where a child scope needs additional entries beyond the parent.

Replace: The child policy replaces the inherited policy entirely. Use this when a specific project needs different constraints (e.g., a security research sandbox that needs capabilities blocked at the org level).

For security enforcement, the recommended pattern is:

• Apply non-negotiable controls at the organization level with no child-level overrides permitted
• Structure folder hierarchy to separate production, non-production, and sandbox environments
• Apply additional constraints at the production folder level
• Allow sandbox projects to override select constraints for experimentation

The compute.restrictPublicIP constraint at the organization level will block public IP assignment for every VM in every project. If your non-production teams need public IPs for testing, apply this constraint only at the production folder, not the organization level.

Start with these seven constraints for immediate security impact:

1. storage.publicAccessPrevention (Enforced) Prevents GCS buckets from being configured with allUsers or allAuthenticatedUsers access, regardless of bucket IAM settings. This is the single most impactful constraint for preventing accidental data exposure. Apply at organization level.

2. compute.skipDefaultNetworkCreation (Enforced) Prevents the creation of the default VPC network in new projects. The default VPC has pre-configured firewall rules that allow unrestricted SSH and RDP ingress. Blocking default VPC creation forces teams to create explicitly configured networks.

3. compute.restrictPublicIP (Denied for all) Blocks assignment of external IP addresses to VM instances. Apply at the production folder. Teams that need public endpoints should use load balancers with Cloud Armor, not direct VM public IPs.

4. iam.disableServiceAccountKeyCreation (Enforced) Prevents creation of user-managed service account keys. Service account keys are a significant credential leak risk. Workloads should use Workload Identity Federation or attached service accounts instead. Apply at organization level with a documented exception process for legacy integrations.

5. iam.disableWorkloadIdentityClusterCreation Not the constraint you want to block, but the opposite: enforce iam.workloadIdentityConfig on GKE clusters. Apply via a custom constraint if your organization uses GKE.

6. gcp.resourceLocations (in: [us-locations] or specific region list) Restricts resource creation to approved geographic regions. Critical for data residency compliance (GDPR, data sovereignty requirements). Apply at the organization level with folder-level overrides for teams with approved multi-region workloads.

7. compute.requireShieldedVm (Enforced) Requires all new VM instances to use Shielded VM features (Secure Boot, vTPM, Integrity Monitoring). Reduces firmware-level attack surface. Apply at the production folder level.

Organization Policy constraints apply to resource creation and modification actions. They do NOT retroactively affect existing resources. A bucket that already has allUsers access will not become private when you enable storage.publicAccessPrevention. However, any attempt to create a new bucket with public access or modify an existing bucket to add public access will be blocked.

To apply a constraint at the organization level:

# Get your organization ID
gcloud organizations list

# Enable storage.publicAccessPrevention at org level
gcloud resource-manager org-policies enable-enforce \
    storage.publicAccessPrevention \
    --organization=YOUR_ORG_ID

# Verify the policy is applied
gcloud resource-manager org-policies describe \
    storage.publicAccessPrevention \
    --organization=YOUR_ORG_ID

For list constraints (like gcp.resourceLocations), you must set allowed values:

gcloud resource-manager org-policies set-policy \
    --organization=YOUR_ORG_ID \
    /tmp/resource-locations-policy.yaml

Where the policy YAML contains:

constraint: constraints/gcp.resourceLocations
listPolicy:
  allowedValues:
    - in:us-locations
    - in:europe-locations

Before applying any new constraint, audit existing resources for non-compliance:

# Find all GCS buckets with public access before applying the constraint
gcloud asset search-all-resources \
    --scope=organizations/YOUR_ORG_ID \
    --asset-types=storage.googleapis.com/Bucket \
    --query="iamPolicy.bindings.members:allUsers" \
    --format="table(name, location)"

Address existing non-compliant resources before applying the Deny constraint, or they will persist in a non-compliant state that cannot be updated without fixing the configuration first.

GCP supports custom organization policy constraints that evaluate conditions on resource properties not covered by predefined constraints. Custom constraints are written in CEL (Common Expression Language) and can enforce fine-grained configuration requirements.

Example: Require all Cloud SQL instances to have automated backups enabled:

name: organizations/YOUR_ORG_ID/customConstraints/custom.sqlBackupEnabled
resourceTypes:
  - sqladmin.googleapis.com/Instance
methodTypes:
  - CREATE
  - UPDATE
condition: "resource.settings.backupConfiguration.enabled == true"
actionType: ALLOW
displayName: "Require Cloud SQL automated backup"
description: "All Cloud SQL instances must have automated backup enabled."

Create the custom constraint:

gcloud org-policies set-custom-constraint /tmp/sql-backup-constraint.yaml

Then create an organization policy that enforces it:

gcloud resource-manager org-policies set-policy \
    --organization=YOUR_ORG_ID \
    /tmp/sql-backup-policy.yaml

Custom constraints are available for Compute Engine, GKE, Cloud Run, Cloud SQL, Bigtable, and several other services. Check the custom constraint documentation for supported resource types before writing a constraint for an unsupported service.

Always test new organization policy constraints in a sandbox folder before applying them at the organization level. The pattern:

Step 1: Create a test folder and project

gcloud resource-manager folders create \
    --display-name="Policy Testing Sandbox" \
    --organization=YOUR_ORG_ID

gcloud projects create policy-test-project-$(date +%Y%m) \
    --folder=SANDBOX_FOLDER_ID

Step 2: Apply the constraint to the test folder only

gcloud resource-manager org-policies enable-enforce \
    storage.publicAccessPrevention \
    --folder=SANDBOX_FOLDER_ID

Step 3: Attempt to create a non-compliant resource and verify it is blocked

# Attempt to create a bucket with public access (should be blocked)
gsutil mb gs://test-public-bucket-$(date +%s)
gsutil iam ch allUsers:objectViewer gs://test-public-bucket-$(date +%s)
# Expected: AccessDeniedException due to org policy

Step 4: Verify compliant resource creation still works

# Create a bucket without public access (should succeed)
gsutil mb gs://test-private-bucket-$(date +%s)
# Expected: success

Step 5: Roll out to production folder, then organization After testing confirms the constraint blocks non-compliant actions without affecting compliant workflows, apply to the production folder, monitor for 2 weeks, then apply at the organization level.

For iam.disableServiceAccountKeyCreation, the testing phase is especially important. Teams may have CI/CD pipelines or legacy integrations that create service account keys programmatically. Identify and migrate these before enforcing the constraint organization-wide.