When working in Google Cloud Platform (GCP), controlling who can do what is crucial.
That’s where Cloud IAM (Identity and Access Management) comes in.
IAM lets you define who has access, what they can do, and which resources they can access — across your entire Google Cloud environment.
Let’s break it down step-by-step 👇
☁️ What is Cloud IAM?
IAM stands for Identity and Access Management.
It’s the system that helps you authenticate users and authorize actions in GCP.
In short:
IAM = Identity (Who) + Role (What they can do) + Resource (Where they can do it)
👤 Who Are Identities (Principals) in GCP?
In Google Cloud, an identity (also called a principal or member) represents who is requesting access.
Here are the main types:
| Type | Description |
|---|---|
| Google Accounts | Individual user accounts (like user@gmail.com) |
| Service Accounts | Non-human accounts used by apps or services |
| Google Groups | Group of users managed together |
| Google Workspace Accounts | Corporate or organizational accounts |
| Cloud Identity Domain | Identity managed without Gmail or Workspace |
So, every access request in GCP comes from one of these identities.
🧩 What is Access?
Access is granted by assigning Roles — and roles contain Permissions.
For example:
| Role | Permissions |
| ----------------- | -------------------------------------------------- |
| **Compute Admin** | Can create, update, delete VM instances |
| **Storage Admin** | Can create, read, and delete Cloud Storage buckets |
Each permission allows performing a specific operation on a resource.
⚙️ What are IAM Permissions?
Permissions are the most granular level of IAM — the actions that can be performed.
Example permissions:
- compute.instances.create → Create a VM instance
- compute.instances.list → List all instances
- compute.instances.start → Start a VM
- compute.instances.stop → Stop a VM
💡 Permissions are always grouped inside a Role — you can’t assign a single permission directly to a user.
🧱 What are IAM Roles?
A Role is a collection of permissions.
When you grant a role to a user, you’re granting all the permissions contained in that role.
Example:
- Compute Admin Role → Can create, delete, and modify VMs
- Storage Admin Role → Can manage storage buckets and objects
Roles are what you assign to users, service accounts, or groups to control access.
🧭 Types of IAM Roles
There are three types of IAM roles in Google Cloud:
1️⃣ Basic Roles (Primitive Roles)
These are the original, broad roles that apply across all GCP services:
| Role | Access Type | Description |
|---|---|---|
| Owner | 🔑 Full Access | Complete control over all resources (can manage billing, IAM, etc.) |
| Editor | ✏️ Edit + View | Can view and modify resources but not manage IAM |
| Viewer | 👁️ View Only | Read-only access across all services |
🧠 Example:
When you create a new GCP account, your email automatically gets the Owner role.
⚠️ Important:
Assigning these roles to multiple users is not recommended for production, because they give too much access.
❌ Avoid using Basic Roles in production setups.
✅ Use Predefined or Custom roles instead.
2️⃣ Predefined Roles
These are ready-made roles created and maintained by Google.
They offer fine-grained access control — limited only to specific services or tasks.
Examples:
- roles/compute.admin → Full access to Compute Engine
- roles/compute.viewer → Read-only access to Compute Engine
- roles/compute.networkAdmin → Manage networking components only
Each predefined role serves a specific purpose.
This gives you the principle of least privilege — granting only what’s necessary.
3️⃣ Custom Roles
You can create your own roles by combining specific permissions that suit your needs.
🧰 When to Create Custom Roles?
When no predefined role fits your exact access requirements.
For example, if you want a role that can start and stop VMs but cannot delete them, you can create a custom role with:
- compute.instances.start
- compute.instances.stop
Custom roles help you maintain tight security control while keeping flexibility.
🔑 IAM Management Summary
| Concept | Description |
|---|---|
| Identity (Principal) | Who is requesting access |
| Role | What they can do |
| Permission | The individual action allowed |
| Resource | Where they can perform the action |
💡 In Summary
| Type | Description | Best Practice |
|---|---|---|
| Basic Roles | Broad access across all services | ❌ Avoid in production |
| Predefined Roles | Fine-grained, Google-managed | ✅ Recommended |
| Custom Roles | Your own permission sets | ✅ Use when needed |
🚀 Key Takeaways
- IAM = Who (Identity) + What (Role) + Where (Resource)
- Roles group permissions — that’s what you assign to users.
- Use Predefined and Custom roles for secure and scalable setups.
- Avoid Basic Roles for production environments.
🔍 Example Use Case
Goal: Give a DevOps engineer permission to manage VMs but not networks or billing.
✅ Assign roles/compute.admin
❌ Don’t assign roles/owner (too broad)
🧠 Wrap-Up
Google Cloud IAM is your security gatekeeper.
It ensures that every identity has the right access, at the right level, and nothing more.
Once you master IAM roles and permissions, managing access in multi-project, multi-team environments becomes easy and secure. 🔒
🌟 Thanks for reading! If this post added value, a like ❤️, follow, or share would encourage me to keep creating more content.
— Latchu | Senior DevOps & Cloud Engineer
☁️ AWS | GCP | ☸️ Kubernetes | 🔐 Security | ⚡ Automation
📌 Sharing hands-on guides, best practices & real-world cloud solutions
Top comments (0)