View all study notes here

---

Resource & Organization Hierarchy

Google Cloud Resource Structure

Google Cloud resources are organized hierarchically. This logical layout directly dictates how Identity & Access Management (IAM) roles and Organization Policies cascade down to individual resources.

Structural Components

• Organization
  • The absolute root node of the hierarchy.
  • Linked to a single Google Workspace or Cloud Identity account.
  • Deleting the Organization node is effectively irreversible.
    • Treat it as permanent infrastructure.
• Folders
  • Purely organizational constructs.
  • Logical building blocks used to group projects, isolate environments (Prod, Dev, QA), or map corporate business units.
  • Folders can be nested up to 4 levels deep.
  • Folders themselves do not incur billing.
• Projects
  • The base organizing entity where all actual cloud work happens.
  • All billable cloud resources must belong to an active project.
  • Each project has a globally unique Project ID (immutable once set), a Project Name (mutable), and a numeric Project Number (auto-assigned by Google).
  • Deleting a project places it in a 30 day recovery window before permanent destruction.
• Resources
  • GCP service instances (e.g., Compute Engine VMs, Cloud Storage buckets, BigQuery datasets).
  • Resources can only belong to one project or parent container at a time.

Policy Inheritance Rules

• !! Policy inheritance is strictly additive downward.
  • Permissions granted at a higher level automatically apply to all child resources.
• Access controls can only be expanded as you move down the hierarchy, they can never be subtracted.
• To reduce an over-privileged user, you cannot block at a lower level, you must remove the binding at the level it was granted.
  • If a principal is granted Storage Admin at the Folder level, that permission cannot be blocked or stripped at the child Project level.
• Policy Troubleshooter tool in the GCP console diagnoses exactly why a principal can or cannot access a specific resource.

Hierarchy Blueprint Types

Organizations generally organize folders using one of three structural patterns depending on their operational goals:

Environment-Oriented

Prioritizes the life cycle stages of application software. Folders are explicitly separated into Development, Staging, and Production tiers.

• Pros: Simplifies securing production assets via strict, isolated IAM controls applied at the Production folder boundary.
• Cons: Hard to calculate the total cost of ownership (TCO) for a single application spanning multiple environment folders.
• Best For: Enterprises requiring strict compliance and tight guardrails around sensitive production datasets.

Functional / Departmental-Oriented

Mirrors the organization’s business units. Folders represent distinct corporate arms (e.g., Finance, Marketing, Engineering).

• Pros: Aligns with corporate cost centres, fiscal budgets, and internal engineering ownership lines.
• Cons: Requires duplicating the internal environment lifecycle structure (Prod/Dev/QA) inside every department’s folder.
• Best For: Highly decentralized companies where business departments operate autonomously with independent IT budgets.

Granular Access-Oriented

A highly segmented design centred around the risk profile of data or regulatory compliance domains. Folders are structured by classifications like High-Risk, Low-Risk, or Public.

• Pros: Enforces unyielding data handling and compliance guardrails regardless of which team owns the project.
• Cons: Imposes massive operational complexity and can make daily resource discovery difficult for developers.
• Best For: Highly regulated industries (FinTech, Healthcare, Defence) subject to strict legal audits.

Operational Metadata: Labels vs. Tags

Attribute	Labels	Tags
Primary Focus	Finance, Billing, & Asset Tracking	Security, Networking, & Governance
Scope	Attached directly and locally to individual resources.	Centrally managed at the Organization or Folder level.
Enforcement	Open string key-value pairs (env:prod).	Strongly typed, predefined key-value pairs (environment:dev).
Core Integration	Forwards directly to Cloud Billing BigQuery exports for micro-allocating infrastructure spend.	Acts as conditional variables in IAM Policies, Org Policies, and VPC Firewall Rules.

• !! Key Distinction:
  • Labels are for cost attribution and reporting.
  • Tags are for enforcing access and security policy.
  • You cannot use a Label as a condition in an IAM policy; you must use a Tag.

---

Enterprise Governance & Identity Management

Organization Policies

While IAM manages who can touch things, Organization Policies manage what anyone can do, regardless of their identity.

• Provides centralized, guardrail-level governance enforcing configuration constraints across resources.
• Constraints: The underlying rule configurations driving the policy.
  • List Constraints: Evaluates configurations against an explicit allow or deny list of values.
  • Boolean Constraints: Switches a specific platform behaviour cleanly On or Off.
• Examples of policy constraints:
  • Enforcing a blanket ban on public external IP assignments for all VMs across the organization.
  • Restricting cloud resource deployment exclusively to specified geographic regions (e.g., us-east1).
  • Preventing service account key downloads entirely.
• !! Organization Policies can use Tags to conditionally alter rules based on resource environment or data tier (e.g., enforce stricter rules on resources tagged environment:production).
• Policies are inherited downward through the hierarchy in the same additive pattern as IAM.
• Exception: The roles/orgpolicy.policyAdmin can set a Policy Override at a lower level using inheritFromParent: false, which allows child nodes to selectively opt out (only if the constraint allows it).

Org Policy vs. IAM

\	Organization Policy	IAM Policy
Controls	What can be configured (resource config)	Who can access resources (identity)
Example	“No VM in this org may have an external IP”	“This service account can read this bucket”
Bypass?	No, even Owner role cannot bypass Org Policy	Can be overridden by higher level IAM grant
Primary Use	Compliance mandates, blanket tech restrictions	Day-to-day access control

IDaaS & Directory Integration

• Cloud Identity
  • Google’s native Identity as a Service (IDaaS) platform used to provision and govern users, groups, and core credentials across the GCP ecosystem.
  • Free tier available.
  • Paid tiers unlock Mobile Device Management (MDM) and advanced security features.
• Google Cloud Directory Sync (GCDS)
  • A tool handling one-way synchronization from on-premises Active Directory (AD) or LDAP systems into Cloud Identity.
  • GCDS reads from the on-premises identity provider and writes to Google.
  • It never syncs corporate passwords or pushes cloud changes back into on-premises infrastructure.
  • Authentication itself is handled separately, typically via SAML 2.0 federation back to on-premises AD FS, so passwords remain on-premises.
• Managed Service for Microsoft Active Directory (Managed AD)
  • A fully managed, highly available Google Cloud service running native Microsoft Active Directory domain controllers.
  • Purpose-built to support cloud-hosted, AD-dependent Windows workloads (e.g., apps needing Kerberos, LDAP, or Group Policy).
  • Avoids the operational overhead of self-managing domain controllers on Compute Engine.

---

IAM Principals, Roles, & Workload Identity

Core IAM Concepts

• IAM Principal
  • An identity profile that can be authorized to receive permissions on a Google Cloud resource.
  • Types of principals: individual Users (Google accounts), Groups, Service Accounts, Google Workspace Domains, and allUsers / allAuthenticatedUsers (public access flags).
• IAM Policy
  • A collection of bindings, where each binding maps a Role to one or more Principals.
  • Policies are attached to resources (project, folder, org, or individual resources).
• Service Account
  • A specialized identity profile intended for non-human workloads, automated pipelines, and applications authenticating against Google Cloud APIs.
  • A Service Account can act as both a Principal (being granted roles on resources) and a Resource (having IAM policies placed on it to control who can impersonate it).
• Principle of Least Privilege
  • Grant identities only the absolute bare minimum permissions necessary to execute their specific job duties.

IAM Role Classification

1. Primitive Roles (Owner, Editor, Viewer)
   • Legacy roles offering sweeping administrative access; inherited from before GCP had fine-grained control.
   • Highly discouraged for production environments. Use only for rapid prototyping or sandbox environments.
   • Owner grants full control including IAM policy modification.
     • Extremely high blast radius.

Primitive Role Name	Permissions
browser	Read access to browse the resource hierarchy, including folders, organizations, and IAM policies. This role doesn’t include permission to view resources within a project.
viewer	Permissions for read-only actions that do not affect state, such as viewing (but not modifying) existing resources or data.
editor	All viewer permissions, plus permissions for actions that modify state, such as changing existing resources.
owner	All editor permissions and permissions for the following actions: • Manage roles and permissions for a project and all resources within the project. • Set up billing for a project.

2. Predefined Roles (e.g., roles/storage.objectViewer)
   • Granular, job-tailored permission sets managed and dynamically updated by Google.
   • The recommended default for daily access configuration.
   • Google adds new permissions to predefined roles as services evolve.
     • Your bindings automatically expand.
3. Custom Roles
   • Tailored permission sets explicitly created by enterprise admins when predefined roles are too broad.
   • !! Critical Constraint: Custom roles cannot be applied at the Folder level. They are restricted exclusively to Project or Organization level assignment.
   • Require manual maintenance.
     • When GCP launches new permissions, they are not automatically added to Custom Roles.

IAM Conditions

• Enforces advanced, context-aware security logic by binding roles conditionally based on explicit runtime attributes.
• Common condition attributes:
  • Time-based: Only allow storage access during designated business hours.
  • Resource-based: Grant access only to resources with a specific Tag value (e.g., environment:dev).
  • Request type: Restrict a role to read-only operations only.
• Conditions are embedded directly within IAM policy bindings, they do not require a separate policy resource.

Modern Authentication Patterns

Workload Identity Federation

The standard security pattern for allowing external workloads (e.g., AWS EC2, GitHub Actions runners, on-premises servers) to securely query GCP resources without sharing long-lived credentials.

• Uses native OIDC or SAML 2.0 trust handshakes to safely exchange an external cloud identity token for a short-lived, auto-expiring GCP access token.
• Completely eliminates the security risk of generating, downloading, and manually rotating long-lived service account JSON key files.
• How it works:
  1. External workload authenticates with its own identity provider (e.g., AWS STS, GitHub OIDC endpoint).
  2. It presents that credential to Google’s Security Token Service (STS).
  3. STS validates the token against a configured Workload Identity Pool and issues a short-lived GCP access token.
  4. The workload uses that token to call GCP APIs, no service account key ever touches disk.

Service Account Security Best Practices

• Never download service account JSON keys to developer machines or store in code repositories.
  • Prefer Workload Identity Federation or gcloud iam service-accounts generate-access-token for short-lived tokens.
• roles/iam.serviceAccountTokenCreator
  • Allows a principal to impersonate a service account (generate short-lived tokens on its behalf). Distinct from:
• roles/iam.serviceAccountUser
  • Allows a principal to run workloads as a service account (attach it to a VM or Cloud Run job).
• Restrict who can impersonate service accounts.
  • Impersonation chains are a common privilege escalation attack vector.
• Prefer attaching service accounts directly to compute resources (VMs, Cloud Run, GKE pods) rather than passing credentials manually.