7.1 Cloud IAM Hierarchy, Custom Roles & Service Accounts

Cloud IAM Hierarchy, Custom Roles & Service Accounts

Core Security Principle: Cloud Identity and Access Management (IAM) is the foundational authorization control plane in Google Cloud. IAM answers the fundamental question: Who (Principal) can perform What action (Permission/Role) on Which resource (Resource Hierarchy)? Architecting enterprise-grade Google Cloud environments requires mastering least-privilege role design, service account lifecycle management, short-lived credential governance, and deterministic access enforcement via IAM Conditions and IAM Deny Policies.

---

Cloud IAM Core Architecture & The Authorization Model

Google Cloud IAM authorizes access by binding Principals to Roles on specific Resources. Standard IAM policies are strictly additive (Allow-based): a principal's effective permissions on a resource are the union of all role bindings granted directly on that resource plus all bindings inherited from parent nodes in the resource hierarchy.

+-----------------------------------------------------------------------------------------+
|                                 CLOUD IAM ACCESS EQUATION                               |
|                                                                                         |
|       WHO                      WHAT                       WHICH                         |
|   +-----------+          +---------------+          +---------------+                   |
|   | Principal |  =====>  |   IAM Role    |  =====>  |   Resource    |                   |
|   +-----------+          +---------------+          +---------------+                   |
|   - Google Account       - Collection of            - Organization                      |
|   - Google Group           fine-grained             - Folder                            |
|   - Service Account        permissions              - Project                           |
|   - Cloud Identity/        (e.g., storage.          - Resource (Bucket, VM,             |
|     Workspace Domain         objects.get)             BigQuery Dataset)                 |
+-----------------------------------------------------------------------------------------+

IAM Principal Types

1. Google Account (Individual User): Represents a specific developer or employee identified by an email address (user:alice@example.com).
2. Google Group: A collection of Google Accounts and service accounts identified by a single email address (group:devops-engineers@example.com). Enterprise Best Practice: Always grant IAM roles to Google Groups rather than individual users to streamline onboarding, offboarding, and quarterly access reviews.
3. Service Account: A special Google account representing a non-human workload, application, or virtual machine (serviceAccount:app-backend@project-id.iam.gserviceaccount.com).
4. Cloud Identity / Google Workspace Domain: Represents all virtual identities created within an enterprise directory (domain:example.com).
5. Special Identifiers: allAuthenticatedUsers (any authenticated Google account worldwide) and allUsers (anyone on the public internet). In enterprise environments, access by these identifiers should be strictly blocked by Organization Policies.

IAM Policy Structure

An IAM policy is represented as a JSON or YAML document containing an array of bindings, optional auditConfigs, and a policy version (Version 3 is required for IAM Conditions and Deny Policies):

{
  "version": 3,
  "bindings": [
    {
      "role": "roles/storage.objectViewer",
      "members": [
        "group:analytics-team@example.com"
      ],
      "condition": {
        "title": "business_hours_only",
        "description": "Grant access only during business hours",
        "expression": "request.time.getHours('America/New_York') >= 9 && request.time.getHours('America/New_York') <= 17"
      }
    }
  ],
  "etag": "BwW12345678="
}

---

IAM Role Categories & Custom Role Lifecycle

Google Cloud categorizes IAM roles into three distinct tiers based on granularity, lifecycle management, and architectural intent.

+-----------------------------------------------------------------------------------------+
|                                    IAM ROLE TIERS                                       |
+-----------------------------------------------------------------------------------------+
|  1. PRIMITIVE (LEGACY) ROLES                                                            |
|     - Owner, Editor, Viewer (roles/owner, roles/editor, roles/viewer)                   |
|     - Coarse-grained, historic roles that grant sweeping permissions across all APIs.  |
|     - STRICTLY PROHIBITED in production enterprise deployments.                         |
+-----------------------------------------------------------------------------------------+
|  2. PREDEFINED ROLES                                                                    |
|     - Granular, service-specific roles managed and maintained directly by Google.       |
|     - Examples: roles/storage.objectAdmin, roles/compute.networkAdmin,                  |
|       roles/bigquery.dataViewer.                                                        |
|     - Automatically updated by Google when new API features are released.              |
+-----------------------------------------------------------------------------------------+
|  3. CUSTOM ROLES                                                                        |
|     - User-defined collections of specific permissions (service.resource.verb).         |
|     - Created only when predefined roles grant excessive permissions.                   |
|     - Can be created ONLY at the ORGANIZATION or PROJECT level (NOT Folder level).     |
+-----------------------------------------------------------------------------------------+

Comprehensive Role Comparison Matrix

Custom Role Lifecycle Management

Custom roles pass through four distinct lifecycle stages:

1. ALPHA: Experimental role under active development; may change without notice.
2. BETA: Testing phase with broader team validation.
3. GA (General Availability): Production-ready custom role with stable permission sets.
4. DEPRECATED: Marked for sunset. Existing bindings continue functioning, but new bindings are discouraged.

[!CAUTION] Custom Role Folder Limitation: In Google Cloud, Custom Roles can be created only at the Organization level or Project level. You cannot define a custom role at the Folder level. To reuse a custom role across multiple projects across an enterprise, you must author the custom role at the Organization root node (organizations/[ORG_ID]/roles/[ROLE_ID]).

---

Service Account Architecture & Lifecycle Management

A Service Account is both a Principal (an identity that can be granted roles to access resources) and a Resource (an entity that other users can manage, impersonate, or attach to compute workloads).

+-----------------------------------------------------------------------------------------+
|                               SERVICE ACCOUNT TAXONOMY                                  |
+-----------------------------------------------------------------------------------------+
|  1. USER-MANAGED SERVICE ACCOUNTS                                                       |
|     - Format: [sa-name]@[project-id].iam.gserviceaccount.com                            |
|     - Created by cloud administrators for dedicated microservices and applications.     |
|     - Up to 100 per project by default (quota expandable).                             |
+-----------------------------------------------------------------------------------------+
|  2. DEFAULT SERVICE ACCOUNTS                                                            |
|     - Compute Engine Default: [project-number]-compute@developer.gserviceaccount.com    |
|     - App Engine Default: [project-id]@appspot.gserviceaccount.com                     |
|     - Automatically granted the primitive Editor (roles/editor) role upon creation.    |
|     - HAZARD: Must be stripped of Editor or disabled in production environments.       |
+-----------------------------------------------------------------------------------------+
|  3. GOOGLE-MANAGED SERVICE ACCOUNTS (SERVICE AGENTS)                                   |
|     - Format: service-[project-number]@[service].iam.gserviceaccount.com                |
|     - Created automatically by Google when services (KMS, Cloud SQL, GKE) are enabled.  |
|     - Automatically assigned specific predefined Service Agent roles.                  |
+-----------------------------------------------------------------------------------------+

Service Account Roles: Managing the Service Account as a Resource

To allow developers or workloads to utilize a service account, administrators grant roles on the service account resource itself:

• Service Account User (roles/iam.serviceAccountUser): Allows a developer to attach the service account to a Compute Engine VM, Cloud Run service, or Cloud Function during deployment.
• Service Account Token Creator (roles/iam.serviceAccountTokenCreator): Allows a principal to impersonate the service account and generate short-lived OAuth 2.0 access tokens, OIDC tokens, and signed URLs.
• Service Account Admin (roles/iam.serviceAccountAdmin): Authorizes creating, updating, listing, and deleting service accounts.

---

Service Account Key Governance vs. Short-Lived Credentials

User-managed service accounts support generating external RSA private keys (JSON key files). These static keys represent one of the most critical security vulnerabilities in cloud computing.

+-----------------------------------------------------------------------------------------+
|                    SERVICE ACCOUNT KEYS vs. SHORT-LIVED CREDENTIALS                     |
+-----------------------------------------------------------------------------------------+
|  USER-MANAGED STATIC KEYS (.JSON)       |  SHORT-LIVED CREDENTIALS / FEDERATION         |
|  -------------------------------------  |  -------------------------------------------  |
|  - Valid for up to 10 years (static).   |  - Valid for 1 hour (configurable up to 12h). |
|  - Frequent exfiltration via GitHub git |  - No private keys generated or stored.       |
|    commits, CI/CD logs, and laptops.    |  - Cryptographically exchanged via STS.       |
|  - Requires complex manual rotation.    |  - Automated, non-repudiable audit logging.   |
|  - BLOCKED by Organization Policy.      |  - RECOMMENDED ENTERPRISE STANDARD.           |
+-----------------------------------------------------------------------------------------+

Key Governance Best Practices

1. Enforce Organization Policy Constraints: Block static key generation organization-wide using constraints/iam.disableServiceAccountKeyCreation and constraints/iam.disableServiceAccountKeyUpload.
2. Eliminate Keys in CI/CD: Migrate external CI/CD platforms (GitHub Actions, GitLab CI/CD, Jenkins) to Workload Identity Federation.
3. Eliminate Keys on GKE: Migrate Kubernetes container pods to GKE Workload Identity.
4. Audit Stale Keys: If legacy keys exist, use Cloud Asset Inventory and Security Command Center (SCC) to detect keys older than 90 days and enforce automated rotation pipelines.

---

Attribute-Based Access Control: IAM Conditions

IAM Conditions enable conditional role bindings based on contextual request attributes, resource attributes, and temporal constraints using Common Expression Language (CEL).

+-----------------------------------------------------------------------------------------+
|                                 IAM CONDITION TYPES                                     |
+-----------------------------------------------------------------------------------------+
|  1. TEMPORAL (TIME-BOUNDED) ATTRIBUTES                                                  |
|     - request.time: Enforces access windows, maintenance intervals, or expiration.      |
|     - Example: request.time < timestamp("2026-09-01T00:00:00Z")                        |
+-----------------------------------------------------------------------------------------+
|  2. RESOURCE ATTRIBUTES                                                                 |
|     - resource.name: Restricts role to specific prefix or resource hierarchy path.      |
|     - resource.type: Restricts role to specific service resource kinds.                 |
|     - resource.tagValue: Restricts role to resources tagged with specific key/values.   |
|     - Example: resource.name.startsWith("projects/_/buckets/corp-finance-")            |
+-----------------------------------------------------------------------------------------+
|  3. CONTEXT-AWARE ACCESS LEVELS                                                         |
|     - Evaluates Access Context Manager (ACM) perimeter levels (IP, device state).       |
|     - Example: "accessPolicies/12345/accessLevels/Corporate_Office_Only" in            |
|       request.auth.access_levels                                                        |
+-----------------------------------------------------------------------------------------+

Common CEL Condition Expressions in Enterprise Architectures

// Scenario A: Time-limited emergency access window
request.time >= timestamp("2026-08-25T00:00:00Z") &&
request.time < timestamp("2026-08-25T04:00:00Z")

// Scenario B: Storage Object Admin restricted strictly to 'dev-' bucket prefix
resource.type == "storage.googleapis.com/Bucket" &&
resource.name.startsWith("projects/_/buckets/dev-")

// Scenario C: BigQuery access granted only if dataset is tagged 'data-tier=internal'
resource.hasTag('1234567890/data-tier', 'internal')

---

Deterministic Governance: Policy Inheritance & IAM Deny Policies

In standard Cloud IAM, permissions are strictly additive: if a user is granted roles/storage.admin at the Organization level, that permission cannot be revoked or filtered out at a child Folder or Project level. To provide absolute preventative guardrails, Google Cloud provides IAM Deny Policies (iam.denyPolicies).

+-----------------------------------------------------------------------------------------+
|                       IAM EVALUATION LOGIC: DENY OVERRIDES ALLOW                        |
|                                                                                         |
|               +--------------------------------------------------+                      |
|               | Incoming API Request (Principal + Verb + Target) |                      |
|               +--------------------------------------------------+                      |
|                                        |                                                |
|                                        v                                                |
|                       +----------------------------------+                              |
|                       | Is there a matching DENY policy? |                              |
|                       +----------------------------------+                              |
|                                  /               \                                      |
|                            YES  /                 \  NO                                 |
|                                v                   v                                    |
|                      +-----------------+   +----------------------------------+         |
|                      | ACCESS DENIED   |   | Is there a matching ALLOW policy |         |
|                      | (Immediate Stop)|   | (Direct or Inherited)?           |         |
|                      +-----------------+   +----------------------------------+         |
|                                                       /               \                 |
|                                                 YES  /                 \  NO            |
|                                                     v                   v               |
|                                           +-----------------+   +-----------------+     |
|                                           | ACCESS GRANTED  |   | ACCESS DENIED   |     |
|                                           +-----------------+   +-----------------+     |
+-----------------------------------------------------------------------------------------+

Key Characteristics of IAM Deny Policies

1. Deny Precedes Allow: Deny policies are evaluated before Allow policies. If any Deny policy matches the principal, permission, and target resource, access is immediately blocked regardless of any Allow bindings at any level in the hierarchy.
2. Hierarchy Independence: An IAM Deny policy set at the Organization root prevents even a project Owner from executing the denied action on resources inside their own project.
3. Policy Structure:
   • deniedPrincipals: Principals subject to the restriction (supports wildcards, groups, service accounts).
   • deniedPermissions: Fine-grained IAM permissions (e.g., storage.googleapis.com/buckets.delete). Supports wildcard matching (e.g., *delete).
   • denialCondition: Optional CEL condition for conditional denial.
   • exceptionPrincipals: Whitelisted security administrator principals exempt from the deny rule.

Deny Policies vs. Organization Policies vs. IAM Allow Bindings

---

Concrete Architectural Scenario: Financial Enterprise IAM Hardening

Scenario Profile

• Organization: Global Fintech Corporation operating under PCI-DSS and SOC 2 Type II compliance.
• Challenges:
  1. Developers were granted the primitive Editor role on development projects, allowing unauthorized network modifications.
  2. Compute Engine workloads were running with the Compute Engine Default Service Account.
  3. Contractors require Cloud Storage access to specific staging buckets during business hours, but must never be allowed to delete buckets or objects anywhere across the organization.

Solution Blueprint

1. Strip Primitive Roles & Enforce Custom Roles: Enforce an Organization Policy blocking primitive roles. Author an Organization-level custom role FintechDeveloper containing curated compute and container verbs, replacing roles/editor.
2. Decommission Default Service Accounts: Deploy user-managed service accounts (sa-payments-engine@...) with the exact predefined roles needed (roles/datastore.user). Revoke Editor from the Compute Engine default service account and enforce constraints/iam.disableServiceAccountKeyCreation at the root.
3. Conditional Contractor Access with Global Deny Guardrails:
   • Create an IAM Allow binding granting roles/storage.objectViewer to group:contractors@example.com on the staging project with an IAM Condition restricting request.time to Monday–Friday 08:00–18:00 UTC.
   • Attach an IAM Deny Policy at the Organization root specifying deniedPrincipals: ["principalSet://goog/group/contractors@example.com"] and deniedPermissions: ["storage.googleapis.com/buckets.delete", "storage.googleapis.com/objects.delete"] to guarantee zero deletion capability across all corporate projects.

---

[!IMPORTANT] Exam Watch: On the Google Cloud Architect exam, whenever an organizational security requirement states that certain principals must never perform an action (e.g., delete buckets or modify logs) regardless of what local project admins configure, the answer is IAM Deny Policies. If a question asks how to reuse a Custom Role across multiple folders and projects, remember that custom roles cannot be created at the Folder level—they must be created at the Organization level.