7.3 Organization Policies, Tags & Resource Governance

Organization Policies, Tags & Resource Governance

Architectural Guardrail: Enterprise governance in Google Cloud separates identity authorization (IAM) from structural resource constraints (Organization Policies). While IAM governs who is authorized to perform an operation, the Organization Policy Service establishes immutable guardrails dictating how cloud resources can be configured. Effective enterprise architects design hierarchical governance frameworks using Organization Policies, centrally managed Resource Tags, and Cloud Asset Inventory to enforce compliance, sovereignty, and data security at scale.

---

The Google Cloud Resource Hierarchy

The Google Cloud resource hierarchy provides the structural foundation for access control, policy inheritance, and billing aggregation. It consists of four distinct levels:

+-----------------------------------------------------------------------------------------+
|                               GOOGLE CLOUD RESOURCE HIERARCHY                           |
|                                                                                         |
|                            +------------------------------+                             |
|                            |      ORGANIZATION ROOT       |                             |
|                            |     (Domain: example.com)    |                             |
|                            +------------------------------+                             |
|                                           |                                             |
|                    +----------------------+----------------------+                      |
|                    |                                             |                      |
|                    v                                             v                      |
|     +------------------------------+              +------------------------------+      |
|     |      PRODUCTION FOLDER       |              |      DEVELOPMENT FOLDER      |      |
|     +------------------------------+              +------------------------------+      |
|                    |                                             |                      |
|        +-----------+-----------+                                 v                      |
|        |                       |                  +------------------------------+      |
|        v                       v                  |      PROJECT: sandbox-dev    |      |
| +-------------+         +-------------+           +------------------------------+      |
| | PROJECT:    |         | PROJECT:    |                          |                      |
| | core-pay-pr |         | core-data-pr|                          v                      |
| +-------------+         +-------------+           +------------------------------+      |
|        |                       |                  | Resources: Compute VMs,      |      |
|        v                       v                  | GCS Buckets, BigQuery Tables |      |
| Resources: VMs,         Resources: GCS,           +------------------------------+      |
| GKE, Cloud SQL          BigQuery, Dataproc                                              |
+-----------------------------------------------------------------------------------------+

Hierarchy Structural Primitives

1. Organization Root Node: Represents the enterprise customer (e.g., example.com), created automatically via Cloud Identity or Google Workspace. Managed by the Organization Administrator (roles/resourcemanager.organizationAdmin).
2. Folders: Organizational containers nested up to 10 levels deep. Folders represent business units (Finance, Retail), geographic regions (EMEA, APAC), or lifecycle environments (Production, Staging, Development).
3. Projects: The fundamental operational and quota boundary in Google Cloud. All cloud resources must belong to exactly one project. Projects serve as the two-way boundary for:
   • Billing: Links resources to a Cloud Billing Account.
   • API Quotas & Networks: Bounds API rate limits and VPC hosting.
4. Resources: The actual service instances instantiated within projects (Compute Engine VMs, Cloud Storage buckets, BigQuery datasets, Cloud SQL databases).

---

Organization Policy Service: Constraints & Guardrails

The Organization Policy Service configures centralized, declarative guardrails across the entire resource hierarchy. Unlike IAM policies, Organization Policies apply to all users and automated processes—even Project Owners and Organization Admins cannot violate an enforced constraint.

+-----------------------------------------------------------------------------------------+
|                         ORGANIZATION POLICY CONSTRAINT TYPES                            |
+-----------------------------------------------------------------------------------------+
|  1. BOOLEAN CONSTRAINTS                                                                 |
|     - Binary toggles that enforce or disallow specific resource behaviors.              |
|     - Evaluated as enforced: true or enforced: false.                                   |
+-----------------------------------------------------------------------------------------+
|  2. LIST CONSTRAINTS                                                                    |
|     - Allow or Deny lists that restrict specific strings, projects, regions, or prefixes|
|     - Evaluated with allowedValues, deniedValues, allowAll: true, or denyAll: true.     |
+-----------------------------------------------------------------------------------------+

Critical Enterprise Organization Policy Constraints

---

Policy Inheritance Rules: Merge, Replace, Inherit & Reset

When Organization Policies are defined at multiple levels in the hierarchy (e.g., at the Organization root and on a child Folder), Google Cloud evaluates the effective policy using deterministic inheritance rules.

+-----------------------------------------------------------------------------------------+
|                           POLICY INHERITANCE EVALUATION PATH                            |
|                                                                                         |
|   [ Organization Root Policy ]  ===>  Allowed: [ projects/corp-images ]                 |
|                 |                                                                       |
|                 v                                                                       |
|   [ Folder: Analytics Team ]    ===>  inheritFromParent: true (MERGE)                   |
|                 |                     Allowed: [ projects/analytics-images ]            |
|                 |                     Result: [ corp-images, analytics-images ]         |
|                 v                                                                       |
|   [ Project: Strict PCI ]       ===>  inheritFromParent: false (REPLACE)                |
|                                       Allowed: [ projects/pci-certified-images ]        |
|                                       Result: [ pci-certified-images ONLY ]             |
+-----------------------------------------------------------------------------------------+

Inheritance Operators for List Constraints

1. Merge (inheritFromParent: true): The child policy inherits all allowed/denied values from the parent node and unions them with its own local values. This is the standard pattern for expanding allowed service lists in child business units.
2. Replace (inheritFromParent: false): The child policy completely ignores parent rules and evaluates its own list of values in isolation. Useful for isolated compliance silos requiring stricter subsets.
3. Reset (reset: true): Clears all inherited and local rules, reverting the policy at that specific hierarchy node back to the default constraint behavior defined by Google Cloud.
4. Allow All / Deny All: Explicitly sets allowAll: true or denyAll: true on the list constraint, bypassing specific value lists.

---

Centrally Managed Resource Tags vs. Resource Labels

A critical architectural distinction exists between Resource Labels and Resource Tags.

+-----------------------------------------------------------------------------------------+
|                       RESOURCE LABELS vs. CENTRALLY MANAGED TAGS                        |
+-----------------------------------------------------------------------------------------+
|  RESOURCE LABELS                        |  RESOURCE TAGS (Cloud Resource Manager)       |
|  -------------------------------------  |  -------------------------------------------  |
|  - Simple key-value string metadata.    |  - First-class Organization resources.        |
|  - Defined directly on resources.       |  - Managed via central RBAC (Tag Admin).     |
|  - NOT centrally governed.              |  - Attached via TagBindings; INHERITED down   |
|  - Any user with write permissions      |    the resource hierarchy.                    |
|    can alter or delete labels.          |  - Project owners CANNOT modify tags without  |
|  - Used for Billing export filters,     |    central Tag User permissions.              |
|    scripts, and reporting.              |  - Used for CONDITIONAL IAM and CONDITIONAL   |
|  - CANNOT be evaluated by Org Policies. |    ORGANIZATION POLICIES.                     |
+-----------------------------------------------------------------------------------------+

Architectural Comparison Matrix

Tag-Based Conditional Organization Policy Example

An architect can enforce a global constraint blocking public IPs (constraints/compute.vmExternalIpAccess), but define a tag condition rule: If the Compute Engine instance or its parent project is attached with Tag env = dmz, allow external IP allocation.

---

Real-Time Governance: Cloud Asset Inventory (CAI)

Cloud Asset Inventory (CAI) is a fully managed metadata index that provides real-time visibility, search, and historical analysis of all Google Cloud resources and IAM policies across the entire organization hierarchy.

+-----------------------------------------------------------------------------------------+
|                            CLOUD ASSET INVENTORY CAPABILITIES                           |
+-----------------------------------------------------------------------------------------+
|  1. REAL-TIME ASSET FEEDS                                                               |
|     - Streams resource and IAM policy change events directly to Cloud Pub/Sub.          |
|     - Enables automated Event-Driven Security remediation pipelines (Cloud Functions).  |
+-----------------------------------------------------------------------------------------+
|  2. TIME-TRAVEL HISTORICAL ANALYSIS (Up to 35 Days)                                     |
|     - Queries exact resource configurations and IAM policies at any past timestamp.     |
|     - Critical for post-incident forensics and compliance audit evidence.               |
+-----------------------------------------------------------------------------------------+
|  3. EFFECTIVE IAM POLICY ANALYSIS                                                       |
|     - Evaluates full inheritance trees, Google Groups, and IAM Conditions.              |
|     - Directly answers: "Who has access to this BigQuery dataset and through what role?"|
+-----------------------------------------------------------------------------------------+
|  4. BULK EXPORT SNAPSHOTS                                                               |
|     - Dumps complete organization metadata snapshots into BigQuery or Cloud Storage.    |
|     - Powers enterprise security dashboards and SQL-based compliance queries.           |
+-----------------------------------------------------------------------------------------+

Cloud Asset Inventory in Compliance Operations

• Auditing Over-Privileged Identities: CAI's IAM policy analyzer traces all effective access paths to critical resources, uncovering shadow admin privileges inherited through nested Google Groups.
• Automated Misconfiguration Remediation: When a developer accidentally opens a Cloud Storage bucket to allUsers, CAI emits a real-time Pub/Sub message. A subscriber Cloud Function consumes the event, verifies the violation, and immediately reverts the bucket ACL within seconds.

---

Concrete Architectural Scenario: Multi-Tier Sovereign Cloud Governance

Scenario Profile

• Enterprise: European Healthcare Conglomerate hosting sensitive patient records in Google Cloud.
• Compliance Mandates:
  1. GDPR Data Sovereignty: Zero patient data or compute resources may exist outside European Union regions.
  2. Golden OS Image Enforcement: All Compute Engine virtual machines must boot exclusively from corporate hardened images hosted in projects/corp-hardened-images.
  3. Conditional Ingress: Public IP addresses are prohibited by default, but allowed on instances explicitly tagged by Network Security Admins with network-zone = external-dmz.
  4. Compliance Forensics: Must maintain full point-in-time configuration records for 35 days to support regulatory inspections.

Solution Blueprint

1. Data Sovereignty Constraint: Attach constraints/gcp.resourceLocations at the Organization root with allowedValues: ["in:eu-locations"] to systematically block resource creation in US or APAC regions.
2. Trusted Images Constraint: Attach constraints/compute.trustedImageProjects at the Organization root with allowedValues: ["projects/corp-hardened-images"].
3. Centrally Governed Tagging & Conditional Public IP Policy:
   • Create a centralized Resource Tag network-zone with values internal and external-dmz. Grant roles/resourcemanager.tagUser strictly to the Network Security Team.
   • Apply constraints/compute.vmExternalIpAccess (Deny all) at the Org root, with a conditional override rule evaluating resource.hasTag('12345/network-zone', 'external-dmz') to permit public IPs only on certified perimeter proxies.
4. Cloud Asset Inventory Continuous Compliance:
   • Enable Cloud Asset Inventory real-time feeds publishing IAM and resource changes to a Pub/Sub topic.
   • Export daily asset inventory snapshots to BigQuery for SQL-driven compliance reporting, and use CAI historical time-travel queries to satisfy European auditor inspections.

---

[!IMPORTANT] Exam Watch: On the Google Cloud Architect exam, understand the clear division between Organization Policies and IAM: Organization Policies restrict resource configurations (e.g. regions, image sources, public IPs), while IAM restricts principals. When a scenario requires allowing exceptions to Organization Policies for specific teams, use Resource Tags (not labels!) to create conditional policy rules. For compliance questions requiring point-in-time asset and IAM state reconstruction up to 35 days in the past, the answer is Cloud Asset Inventory.