Organization policies in GCP - Deep Dive

Overview - Organization policies

What is it?

Organization policies in Google Cloud Platform (GCP) are rules that control what actions users and resources can perform across the entire organization or specific projects. They help set boundaries and guardrails to keep cloud resources safe and compliant. These policies apply to all projects and resources under an organization, ensuring consistent governance. Think of them as the rules everyone in a company must follow when using shared tools.

Why it matters

Without organization policies, cloud resources could be misused or misconfigured, leading to security risks, unexpected costs, or compliance failures. They prevent mistakes like accidentally opening sensitive data to the public or creating resources in unauthorized regions. This keeps the cloud environment safe, predictable, and aligned with company rules, saving time and money.

Where it fits

Before learning organization policies, you should understand basic GCP concepts like projects, resources, and Identity and Access Management (IAM). After mastering organization policies, you can explore advanced governance tools like Access Context Manager and Security Command Center to strengthen cloud security.

Mental Model

Core Idea

Organization policies are company-wide rules that set limits on what cloud resources and users can do, ensuring safe and consistent use.

Think of it like...

Imagine a library where the organization policies are the library rules everyone must follow, like no food allowed, books must be returned on time, and certain rooms are off-limits. These rules keep the library safe and orderly for all visitors.

┌───────────────────────────────┐
│        Organization            │
│  ┌───────────────┐            │
│  │ Organization  │            │
│  │   Policies    │            │
│  └───────────────┘            │
│        │                      │
│  ┌───────────────┐            │
│  │   Projects    │            │
│  │  (Resources)  │            │
│  └───────────────┘            │
│        │                      │
│  ┌───────────────┐            │
│  │   Users &     │            │
│  │ Permissions   │            │
│  └───────────────┘            │
└───────────────────────────────┘

Build-Up - 7 Steps

1

Foundation

What are Organization Policies

Concept: Introduction to organization policies as rules that control cloud resource behavior.

Organization policies are like rules set by a company to control how cloud resources can be used. They apply to all projects and resources under the organization. For example, a policy might say 'No virtual machines can be created outside the US region.' These rules help keep the cloud environment safe and consistent.

Result

You understand that organization policies set limits on cloud resource actions across the organization.

Knowing that organization policies act as guardrails helps you see how cloud environments stay secure and compliant.

2

Foundation

Hierarchy of GCP Resources

Concept: Understanding the structure of organization, folders, projects, and resources where policies apply.

GCP resources are organized in a hierarchy: Organization at the top, then folders, projects, and finally resources like virtual machines or storage buckets. Organization policies set at the top apply downwards, affecting all child resources unless overridden. This structure helps apply rules broadly or narrowly.

Result

You see how policies set at the organization level affect all projects and resources beneath.

Understanding the resource hierarchy clarifies how policies cascade and enforce rules consistently.

3

Intermediate

Types of Organization Policies

🤔Before reading on: do you think organization policies only block actions or can they also allow specific actions? Commit to your answer.

Concept: Organization policies can restrict or allow specific behaviors using constraints and rules.

There are two main types of organization policies: 'list constraints' and 'boolean constraints.' List constraints specify allowed or denied values, like allowed regions or machine types. Boolean constraints are simple yes/no rules, like whether external IPs are allowed. These policies give flexible control over cloud usage.

Result

You learn that organization policies can both restrict and allow specific resource behaviors.

Knowing the types of constraints helps you design precise rules that fit your organization's needs.

4

Intermediate

Applying and Inheriting Policies

🤔Before reading on: do you think a policy set on a project can override one set on the organization? Commit to your answer.

Concept: Policies set at higher levels apply to lower levels, but lower levels can override or tighten rules within limits.

Policies set at the organization level apply to all projects and resources below. However, folders and projects can set their own policies to override or add restrictions, but they cannot relax a policy set higher up. For example, if the organization disallows external IPs, a project cannot allow them. This ensures consistent enforcement.

Result

You understand how policies cascade and how overrides work within the hierarchy.

Understanding inheritance prevents misconfigurations and ensures policies are enforced as intended.

5

Intermediate

Common Constraints Examples

Concept: Familiarize with typical constraints used in organization policies.

Some common constraints include: restricting VM creation to certain regions, disabling public IP addresses, preventing service account key creation, and controlling API enablement. These constraints help enforce security, compliance, and cost controls across the organization.

Result

You recognize practical examples of organization policies in action.

Seeing real constraints helps you relate policies to everyday cloud management challenges.

6

Advanced

Policy Evaluation and Enforcement

🤔Before reading on: do you think organization policies are checked only when resources are created, or also when they are updated? Commit to your answer.

Concept: Organization policies are evaluated during resource creation and updates to enforce rules continuously.

When you create or update a resource, GCP checks the applicable organization policies to ensure compliance. If a policy is violated, the action is blocked. This continuous enforcement prevents drift from company rules. Policies are stored and managed centrally, and evaluation happens in real-time during API calls.

Result

You understand that policies actively block disallowed actions at creation and update times.

Knowing policies enforce rules in real-time helps you trust that cloud resources stay compliant.

7

Expert

Advanced Policy Management and Exceptions

🤔Before reading on: do you think organization policies can have exceptions or temporary overrides? Commit to your answer.

Concept: Advanced policy management includes setting exceptions, using policy inheritance carefully, and integrating with other governance tools.

While organization policies enforce strict rules, you can manage exceptions by setting policies at lower levels with tighter restrictions or using IAM roles for temporary access. Combining policies with tools like Access Context Manager allows context-aware access. Understanding policy conflicts and audit logs helps troubleshoot enforcement issues. Experts also automate policy deployment using Infrastructure as Code.

Result

You gain insight into managing complex policy scenarios and integrating governance tools.

Mastering advanced policy management prevents accidental lockouts and supports flexible governance.

Under the Hood

Organization policies are stored as configuration objects in GCP's centralized policy service. When a user or system attempts to create or modify a resource, the GCP control plane queries the policy service to check applicable constraints based on the resource's location in the hierarchy. The policy evaluation engine merges policies from organization, folder, and project levels, applying the strictest rules. If the action violates any constraint, the API call is rejected before resource creation or update.

Why designed this way?

This design centralizes governance, ensuring consistent enforcement across all resources without relying on individual project owners. It balances flexibility and control by allowing overrides only to tighten restrictions, preventing accidental policy weakening. The hierarchical model reflects real-world organizational structures, making policies intuitive to manage. Alternatives like decentralized policies risk inconsistent enforcement and security gaps.

┌───────────────────────────────┐
│       Policy Service          │
│  ┌─────────────────────────┐  │
│  │  Stores Organization     │  │
│  │  Policies and Constraints│  │
│  └────────────┬────────────┘  │
│               │               │
│  ┌────────────▼────────────┐  │
│  │ Policy Evaluation Engine │  │
│  └────────────┬────────────┘  │
│               │               │
│  ┌────────────▼────────────┐  │
│  │  GCP Control Plane APIs  │  │
│  └────────────┬────────────┘  │
│               │               │
│  ┌────────────▼────────────┐  │
│  │  Resource Creation/Update│ │
│  └─────────────────────────┘  │
└───────────────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do organization policies allow projects to completely override organization-level restrictions? Commit to yes or no.

Common Belief: Projects can override and relax any organization-level policy restrictions.

Reality: Projects can only add stricter restrictions but cannot relax or remove organization-level policies.

Why it matters: Believing projects can relax policies leads to security gaps and inconsistent enforcement across the organization.

Quick: Are organization policies only checked when resources are created? Commit to yes or no.

Common Belief: Organization policies are only enforced during resource creation, not updates.

Reality: Policies are enforced both during creation and updates to prevent policy violations at any time.

Why it matters: Assuming policies only apply at creation can cause resources to drift into non-compliance after updates.

Quick: Can organization policies grant permissions like IAM roles? Commit to yes or no.

Common Belief: Organization policies can grant permissions to users or services.

Reality: Organization policies only restrict resource behaviors; permissions are managed separately via IAM.

Why it matters: Confusing policies with permissions can cause misconfigurations and failed access controls.

Quick: Do organization policies automatically fix violations they detect? Commit to yes or no.

Common Belief: Organization policies automatically correct or fix resource violations.

Reality: Policies only block disallowed actions; they do not fix existing violations automatically.

Why it matters: Expecting automatic fixes can lead to unmanaged non-compliant resources and security risks.

Expert Zone

1

Some constraints allow specifying 'allowed values' or 'denied values,' but mixing both in the same policy can cause conflicts that require careful resolution.

2

Policy inheritance means that a restrictive policy at the organization level cannot be undone at lower levels, but lower levels can add further restrictions, creating a cumulative effect.

3

Audit logs for policy violations provide critical insights but require proper setup and interpretation to troubleshoot enforcement issues effectively.

When NOT to use

Organization policies are not suitable for granting fine-grained user permissions; use IAM roles for that. Also, for dynamic access control based on user context or device security, use Access Context Manager instead. Avoid using organization policies for temporary exceptions; instead, manage those with IAM or service accounts.

Production Patterns

In production, organizations use organization policies to enforce security baselines like disabling public IPs and restricting regions. They automate policy deployment using Infrastructure as Code tools like Terraform. Policies are combined with IAM and Access Context Manager for layered security. Regular audits and monitoring of policy violations help maintain compliance.

Connections

Identity and Access Management (IAM)

Complementary governance tools managing permissions vs. resource restrictions

Understanding organization policies alongside IAM clarifies the difference between who can do actions (IAM) and what actions are allowed on resources (policies).

Corporate Compliance Frameworks

Organization policies implement technical controls to enforce compliance rules

Knowing how policies enforce compliance helps bridge the gap between legal requirements and technical cloud controls.

Traffic Laws

Both set rules to control behavior for safety and order

Seeing organization policies like traffic laws helps appreciate how rules prevent chaos and accidents in complex systems.

Common Pitfalls

#1 Trying to relax an organization-level policy at the project level.

Wrong approach:

gcloud resource-manager org-policies allow --project=my-project --constraint=compute.disableExternalIp --allowed-values='*'

Correct approach:

gcloud resource-manager org-policies deny --project=my-project --constraint=compute.disableExternalIp

Root cause:

Misunderstanding that lower levels can only add restrictions, not remove or relax higher-level policies.

#2 Confusing organization policies with IAM permissions and trying to grant access via policies.

Wrong approach:

Setting an organization policy to allow a user to create VMs by adding them to the policy.

Correct approach:

Granting the user the 'compute.instanceAdmin' IAM role on the project or organization.

Root cause:

Mixing up resource behavior restrictions (policies) with user permissions (IAM).

#3 Assuming organization policies fix existing resource violations automatically.

Wrong approach:

Expecting that enabling a policy to deny public IPs will remove existing public IPs from VMs.

Correct approach:

Manually identifying and updating existing resources to comply with the policy, or using automation scripts.

Root cause:

Believing policies are self-healing rather than preventive controls.

Key Takeaways

Organization policies in GCP set company-wide rules that control what cloud resources can do, ensuring security and compliance.

These policies apply hierarchically, with organization-level rules cascading down and lower levels able only to add restrictions, not relax them.

Organization policies differ from IAM; policies restrict resource behaviors, while IAM manages who can perform actions.

Policies are enforced in real-time during resource creation and updates, blocking disallowed actions immediately.

Advanced use includes combining policies with other governance tools and automating policy management for consistent cloud security.

Practice

1. What is the main purpose of an Organization Policy in Google Cloud?

easy

A. To set rules that apply to all projects in a company

B. To create virtual machines automatically

C. To monitor network traffic in real-time

D. To manage billing accounts for users

Solution

1. Step 1: Understand the role of organization policies

   Organization policies define rules that apply across all projects and resources in a company to keep them safe and compliant.

2. Step 2: Compare options with the purpose

   Only To set rules that apply to all projects in a company describes setting rules across all projects, which matches the purpose of organization policies.

3. Final Answer:

   To set rules that apply to all projects in a company -> Option A

4. Quick Check:

   Organization policies control rules = A [OK]

Hint: Organization policies set company-wide rules, not individual tasks [OK]

Common Mistakes:

• Confusing organization policies with billing or monitoring
• Thinking policies create resources automatically
• Assuming policies manage user accounts directly

2. Which of the following is the correct way to specify a constraint in an organization policy YAML file?

easy

A. constraint -> gcp.resourceLocations

B. constraint = gcp.resourceLocations

C. constraint: gcp.resourceLocations

D. constraint() gcp.resourceLocations

Solution

1. Step 1: Recall YAML syntax for key-value pairs

   YAML uses colon (:) to assign values to keys, like key: value.

2. Step 2: Identify correct constraint syntax

   constraint: gcp.resourceLocations uses constraint: gcp.resourceLocations, which is valid YAML syntax for specifying a constraint.

3. Final Answer:

   constraint: gcp.resourceLocations -> Option C

4. Quick Check:

   YAML key-value uses colon = C [OK]

Hint: YAML uses colon for key-value pairs, not equals or arrows [OK]

Common Mistakes:

• Using equals sign (=) instead of colon (:)
• Using arrows (->) or parentheses incorrectly
• Confusing YAML with programming language syntax

3. Given this organization policy snippet:

constraint: constraints/compute.disableSerialPortAccess
listPolicy:
  deniedValues:
  - "true"

What is the effect of this policy?

medium

A. It enables serial port access on all projects

B. It allows serial port access on compute instances

C. It disables all compute instances

D. It denies serial port access on compute instances

Solution

1. Step 1: Understand the constraint meaning

   The constraint constraints/compute.disableSerialPortAccess controls serial port access on compute instances ("true" disables access, "false" allows it).

2. Step 2: Interpret the deniedValues list

   Setting deniedValues: ["true"] denies the value "true", which disables serial port access on compute instances.

3. Final Answer:

   It denies serial port access on compute instances -> Option D

4. Quick Check:

   deny "true" disables access = A [OK]

Hint: Denying 'true' disables serial port access [OK]

Common Mistakes:

• Thinking deniedValues means allowed values
• Confusing serial port access with instance shutdown
• Assuming the policy enables the feature

4. You wrote this organization policy YAML:

constraint: constraints/compute.disableSerialPortAccess
listPolicy:
  deniedValues:
    - true

But it does not work as expected. What is the likely error?

medium

A. The constraint name is incorrect

B. The denied value should be a string "true", not boolean true

C. The listPolicy block is missing required fields

D. YAML does not support lists under deniedValues

Solution

1. Step 1: Check the deniedValues data type

   Organization policies expect deniedValues as strings, so "true" must be quoted.

2. Step 2: Identify the error cause

   Using unquoted true is boolean in YAML, causing the policy to fail or behave unexpectedly.

3. Final Answer:

   The denied value should be a string "true", not boolean true -> Option B

4. Quick Check:

   Denied values must be strings in YAML [OK]

Hint: Always quote boolean values as strings in organization policies [OK]

Common Mistakes:

• Not quoting boolean values in YAML
• Assuming constraint names are wrong without checking
• Thinking lists are not allowed under deniedValues

5. Your company wants to restrict all projects to only create resources in these regions: us-central1 and europe-west1. Which organization policy configuration achieves this?

hard

A. constraint: constraints/gcp.resourceLocations
listPolicy:
allowedValues:
- "us-central1"
- "europe-west1"

B. constraint: constraints/gcp.resourceLocations
listPolicy:
deniedValues:
- "notin:us-central1"
- "notin:europe-west1"

C. constraint: constraints/gcp.resourceLocations
listPolicy:
deniedValues:
- "us-central1"
- "europe-west1"

D. constraint: constraints/gcp.resourceLocations
listPolicy:
allowedValues:
- "in:us-central1"
- "in:europe-west1"

Solution

1. Step 1: Understand the constraint for resource locations

   The constraints/gcp.resourceLocations controls allowed regions for resource creation.

2. Step 2: Identify correct allowedValues format

   Allowed values should list region names as strings without prefixes like "in:"; constraint: constraints/gcp.resourceLocations listPolicy: allowedValues: - "us-central1" - "europe-west1" correctly lists "us-central1" and "europe-west1".

3. Step 3: Eliminate incorrect options

   The configuration with "in:us-central1" uses invalid prefixes. Configurations using deniedValues do not restrict to only those regions: one attempts to deny outside the regions (wrong syntax and logic), the other denies the desired regions (allowing others).

4. Final Answer:

   constraint: constraints/gcp.resourceLocations listPolicy: allowedValues: - "us-central1" - "europe-west1" -> Option A

5. Quick Check:

   AllowedValues list regions as strings without prefixes = D [OK]

Hint: AllowedValues list regions as plain strings, no prefixes [OK]

Common Mistakes:

• Using prefixes like 'in:' in allowedValues
• Using deniedValues instead of allowedValues
• Misunderstanding constraint syntax for regions