All Bridges/AWS to GCP Data Engineering Bridge/Security, Governance & IAM

AWS ➔ GCP Deep Dive

•Security, Governance & IAM

AWS Identity and Access Management (IAM) ➔ Google Cloud IAM & Service Accounts

From AWS IAM JSON policies & STS roles to Google Cloud's resource hierarchy & Service Accounts.

The 30-Second Mental Model Shift

In AWS IAM, authorization is identity-centric: you craft detailed JSON policies specifying exact API actions (`s3:GetObject`, `redshift:ExecuteStatement`) and attach them to Users or Roles. In Google Cloud IAM, authorization is resource-hierarchy-centric: permissions are grouped into Roles (e.g. `roles/bigquery.dataViewer`) and bound to Principals at the Organization, Folder, Project, or Resource level. Machine authentication relies on Service Accounts and Workload Identity Federation rather than STS assume role.

1. Architectural Mechanism Comparison

AWS (What You Know)

Source

AWS Identity and Access Management (IAM)

Identity-centric security system evaluating JSON policies (`Effect: Allow/Deny, Action, Resource, Condition`). Workloads assume IAM Roles to obtain temporary credentials (`ASIA...`) via AWS STS.

Key Architecture Strengths:

Explicit Deny takes absolute precedence over all Allow statements.
Granular condition keys (e.g. `aws:PrincipalOrgID`, `aws:SecureTransport`).
Permission Boundaries enforce ceilings on delegated role creation.

GCP (How It Works)

Mastery Target

Google Cloud IAM & Service Accounts

Resource-hierarchy-centric security model. Permissions inherit downward (Organization ➔ Folder ➔ Project ➔ Resource). Predefined or custom Roles are bound to Principals via IAM Policy Bindings.

Why Google Cloud Built It This Way:

Unified resource hierarchy: Permissions cascade predictably down the folder/project tree.
Workload Identity Federation: Keyless authentication for external workloads (GitHub Actions, AWS, on-prem).
Service Account Impersonation: Ephemeral short-lived token generation without downloading long-lived JSON keys.

2. Interactive Terminology & Concept Bridge

Interactive Concept Bridge: Terminology & Architectural Mapping

Click any concept below to see how your AWS knowledge directly maps into GCP.

Mapping Deep Dive

Similar Mechanism

⚡ Direct cognitive shortcut

AWS (What You Know)

AWS IAM Role & STS AssumeRole

Identity with temporary credentials assumed by users, EC2 instances, or external entities.

GCP (How It Works)

GCP Service Account Impersonation & Workload Identity Federation

Service Accounts acting as identities for applications; impersonated without static keys.

The Architectural Mental Shortcut:

Both deliver short-lived temporary credentials. GCP's Workload Identity Federation allows external AWS or GitHub identities to impersonate Service Accounts keylessly.

3. Visual Architecture Pipeline (Google Cloud IAM & Service Accounts)

IAM Mental Model: Policy = Principal (“Who”) + Role (“What”) + Resource (“Where”)

Click any section below or run the simulation to see how Google Cloud evaluates IAM policy bindings.

1. Principal (“Who”)

Bind

2. Role (“What”)

Apply

3. Resource (“Where”)

💡 Analogy: Like a job title or access pass (e.g. 'Warehouse Inspector Pass') that lists exactly which doors you are permitted to open.

Authorization

Component Inspector

2. The Role ('WHAT' they can do)

Predefined & Custom Roles (Collections of Exact Permissions)

A Role is a collection of fine-grained permissions (e.g. `storage.objects.get`, `bigquery.jobs.create`). Predefined roles are curated by Google, while Custom roles provide surgical least-privilege control.

Under the Hood:

•Predefined roles (e.g. `roles/bigquery.dataViewer`) maintained and updated automatically by Google.
•Custom roles let you bundle exact permissions to enforce strict least-privilege compliance.
•Primitive roles (`Owner`, `Editor`, `Viewer`) are legacy anti-patterns to avoid in production.

Key Benchmark Metrics:

Role Types

Predefined & Custom

Least-privilege

Primitive Roles

Avoid in Prod

Overly broad

4. Side-by-Side Code, CLI & Terraform Translator

Side-by-Side Code & Syntax Translator

AWS Syntax

# AWS IAM: Attach Managed Policy to Role
aws iam attach-role-policy \
  --role-name DataEngineerRole \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

GCP Equivalent

# Google Cloud IAM: Add IAM Policy Binding to Project
gcloud projects add-iam-policy-binding prod-analytics-101 \
  --member='user:engineer@company.com' \
  --role='roles/storage.objectViewer'

Code Translation Notes:GCP grants roles to principals at the project level via `add-iam-policy-binding` with declarative member types (`user:`, `serviceAccount:`, `group:`).

5. Paradigm Shift Gotchas: Traps to Avoid in GCP

Gotcha #1

high

Default Compute Engine Service Account Privilege Trap

The Trap:

An AWS engineer launching a GCE VM might not realize the default service account (`PROJECT_NUMBER-compute@developer.gserviceaccount.com`) has nearly unrestricted access across the entire project!

How to Avoid It:

Never run production workloads on the default Compute service account. Always create dedicated least-privilege service accounts and disable or restrict default service account creation via Organization Policy.

Gotcha #2

high

Downloading Service Account JSON Keys Is an Anti-Pattern

The Trap:

In AWS, developers frequently downloaded IAM User access keys. In GCP, downloading service account JSON keys for CI/CD pipelines creates identical security vulnerabilities.

How to Avoid It:

Use **Workload Identity Federation** (for GitHub Actions, GitLab, Jenkins, AWS) or Service Account Impersonation to deliver short-lived, keyless OIDC tokens.

Gotcha #3

medium

Resource Hierarchy Permissions Are Union-Additive

The Trap:

If a user is granted `roles/viewer` at the Folder level, an administrator CANNOT remove or deny that role on a child Project inside that folder. Permissions in GCP IAM are strictly additive.

How to Avoid It:

Grant broad roles only at the lowest necessary level (Project or Resource level), using Folder/Org levels only for universal compliance readers or organization policies.

6. Test Your Mental Model

Quick Knowledge Check: Test Your GCP Mental Model

Solidify your cross-cloud understanding with instant feedback.

1An engineer wants to authenticate a GitHub Actions CI/CD deployment pipeline to Google Cloud without storing long-lived JSON keys. What is the recommended GCP solution?

2Why should production workloads NOT use the default Compute Engine service account?

3If a user is granted `roles/bigquery.admin` at the Google Cloud Folder level, how can an administrator revoke that permission for a specific Project inside that folder?

Back to AWS to GCP Data Engineering Bridge Open Full Google Cloud IAM & Service Accounts Guide