GCP Basics · Module 02

IAM & Security – Roles, Service Accounts, Federation, Org Policy and Secrets

Grant least privilege with IAM roles and allow policies, give workloads service accounts instead of keys, let GitHub Actions in with Workload Identity Federation, set guardrails with organization policies, and keep secrets and keys in Secret Manager and Cloud KMS.

Practice interactively →

What you will learn

• Grant basic, predefined and custom roles to principals at the right level of the hierarchy
• Create service accounts, attach them to resources and use impersonation instead of keys
• Set up Workload Identity Federation for a CI/CD pipeline
• Enforce guardrails with organization policy constraints
• Store secrets in Secret Manager and manage encryption keys with Cloud KMS

Lessons

1. IAM: Principals, Roles and Allow Policies

   An allow policy binds roles to principals on a resource; roles are basic, predefined or custom sets of permissions, and grants are inherited down the hierarchy.

2. Service Accounts, Impersonation and Keys

   Workloads run as service accounts; attach them to resources, let people impersonate them for short-lived tokens, and avoid downloadable keys.

3. Workload Identity Federation for CI/CD

   Let GitHub Actions, AWS or any OIDC/SAML identity get short-lived Google Cloud credentials without service account keys, filtered by attribute conditions.

4. Organization Policy Constraints

   Organization policies restrict what can be configured (no external IPs, allowed regions, no SA keys) for everyone below the node, regardless of their IAM roles.

5. Secret Manager and Cloud KMS

   Store passwords and API keys as versioned secrets with IAM-controlled access, and use Cloud KMS keys (CMEK) when you must control the encryption of your data.