Cloud IAM and Security

Cloud IAM (Identity and Access Management) controls who can do what with which GCP resources. Before diving into IAM itself, you need to understand the resource hierarchy — because permissions flow through it.

Resource Hierarchy

GCP organises resources in a four-level hierarchy:

1. Organisation: The root node, tied to a Google Workspace or Cloud Identity domain. Represents the entire company.
2. Folder: Optional grouping layer — use folders for departments, teams, or environments (e.g., Production, Development).
3. Project: The fundamental unit of organisation in GCP. All resources belong to a project. Projects have a name, ID, and number. Billing is managed at the project level.
4. Resource: Individual GCP services — VMs, buckets, databases, etc.

Policy inheritance: An IAM policy applied at a higher level is inherited by all resources below it. For example, granting a role at the Organisation level applies to every project and resource in the organisation.

IAM Principals

An IAM principal is who receives access. Types:

• Google Account: Individual user (e.g., user@gmail.com)
• Service Account: An identity for applications, VMs, or automated processes
• Google Group: A collection of accounts — easiest way to manage access for a team
• Cloud Identity domain: All users in an organisation
• allUsers / allAuthenticatedUsers: Public access (use carefully)

IAM Roles

Roles are collections of permissions. You assign a role to a principal on a resource.

Basic Roles (formerly Primitive)

Very broad — avoid in production:

• Viewer: Read-only access to all resources in the project
• Editor: Read + write access to all resources
• Owner: Full control including IAM and billing

Predefined Roles

Fine-grained, service-specific roles maintained by Google. Examples:

• roles/compute.instanceAdmin.v1 — Manage Compute Engine instances
• roles/storage.objectViewer — Read Cloud Storage objects
• roles/bigquery.dataEditor — Read and write BigQuery datasets

Custom Roles

You define exactly which permissions to include. Use when predefined roles are too broad. Only available at Organisation or Project level.

Service Accounts

Service accounts are special IAM identities used by applications, VMs, and services (not humans). Best practices:

• Create a dedicated service account per application with only the permissions it needs
• Avoid using the default Compute Engine service account — it has broad Editor permissions
• Use Workload Identity Federation (for GKE) to bind Kubernetes service accounts to GCP service accounts — avoids long-lived key files
• Never store service account key files in source code or container images

IAM Conditions

IAM conditions allow you to add attribute-based access control — e.g., grant access only between certain hours, only from certain IP ranges, or only to resources with specific tags. Useful for time-limited access or environment-based restrictions.

Audit Logs and Policy Analysis

• Cloud Audit Logs: Admin Activity, Data Access, and System Event logs. Essential for compliance and security investigation.
• IAM Policy Analyzer: Lets you query "who has access to what resource?" — helps audit and troubleshoot permissions.
• IAM Recommender: Suggests reducing overly broad roles based on actual usage patterns.