Identity and Access Management in Google Cloud: Who Can Do What, Where and Why
A complete, plain-English guide to Google Cloud IAM: how principals, roles, permissions, allow and deny policies, the resource hierarchy, service accounts, federation and conditions work together to give people and workloads exactly the access they need and nothing more.
Imagine a large office building with hundreds of rooms: server rooms, finance offices, supply closets, a lobby and a roof. Different people need different keys. The receptionist needs the lobby but not the server room. An engineer needs the server room but not payroll. A cleaner needs a master key for a few hours at night but not forever. A building manager who hands out keys carelessly invites trouble, and one who hands out too few keys frustrates everyone. Identity and Access Management, or IAM, is the key system for Google Cloud. It answers three questions for every action: who is asking, what are they trying to do, and on which resource? In this guide we start from the first idea and build up to the design choices that keep a cloud environment both usable and safe.
1What Is IAM?
Before looking at roles and policies, let us understand the idea behind access management.
The one-sentence definition
IAM in Google Cloud is the system that lets you control who (the identity) has what access (the role) to which resource. You grant people, groups, applications and external identities specific permissions on specific resources, and Google Cloud checks those grants every time anyone tries to do something.
Authentication versus authorization
Two words are often confused. Authentication answers “who are you?” and proves identity, for example by signing in with a password and a second factor. Authorization answers “what are you allowed to do?” and decides whether a proven identity may perform an action. IAM is mainly about authorization, although it works closely with the sign-in systems that handle authentication.
At an airport, showing your passport at the counter is authentication: it proves who you are. Your boarding pass is authorization: it decides which gate you may enter and which flight you may board. Having a valid passport does not let you walk onto any airplane.
The core sentence of IAM
flowchart LR
A[Principal: Who] --> B[Role: What Permissions]
B --> C[Resource: Where]
C --> D[Allow Policy Binding]
IAM itself is free to use, but the choices you make in it shape your security, your audit trail and how much effort administration takes. Features and role names evolve, so confirm details in current Google Cloud documentation.
2Why IAM Matters So Much
Many serious cloud incidents begin not with clever hacking, but with access that was too broad, too old or poorly tracked.
Limiting the Blast Radius
If an account is compromised, narrow permissions limit how much damage an attacker can do.
Preventing Mistakes
People cannot accidentally delete what they cannot touch.
Meeting Compliance
Regulations require controlled, reviewable and auditable access to sensitive data.
Enabling Teams Safely
Good IAM lets teams move quickly in their own areas without waiting for central approval for everything.
Accountability
Audit logs tie each action to an identity, so you know who did what.
Shared Passwords and Root Accounts
Everyone uses the same powerful login. Nobody knows who did what, and nobody can be removed cleanly.
Individual Accounts, Broad Rights
Each person has an account, but most hold wide administrator rights for convenience.
Role-Based Access
Access is granted through roles that match job functions, and permissions are reviewed.
Least Privilege and Just-in-Time
Access is as narrow as possible, conditions limit when and where it applies, and elevated access is temporary.
3Core Concepts and Vocabulary
A handful of terms appear in every IAM conversation. Learn them once and the rest becomes much easier.
Principal
An identity that can be granted access, such as a person, a group, a service account or an external identity.
Permission
A single allowed action on a type of resource, named in a service, resource and verb pattern, such as viewing a storage object.
Role
A named collection of permissions. You grant roles to principals; you do not grant individual permissions directly.
Allow Policy
A list of bindings attached to a resource that says which principals have which roles on it.
Binding
One line of an allow policy connecting a role to one or more principals, optionally with a condition.
Resource Hierarchy
The tree of organization, folders, projects and resources through which policies are inherited.
Service Account
A special identity for applications and workloads rather than people.
Condition
An extra rule that makes a grant apply only in certain situations, such as a time window or a resource name pattern.
Deny Policy
A policy that blocks specified principals from using specified permissions, overriding allows.
Organization Policy
A separate control that restricts what can be done with resources, regardless of who is doing it.
Think of a hotel. A guest (principal) is given a key card programmed with a job title such as “guest of room 410” (role), which opens specific doors (permissions). The card works on certain floors (resources). The hotel’s house rules, such as “no visitors after midnight”, apply to everyone regardless of their key (organization policy).
| Question | IAM Concept That Answers It |
|---|---|
| Who is asking? | Principal |
| What may they do? | Role and its permissions |
| On what? | Resource in the hierarchy |
| Under what circumstances? | Conditions |
| What is never allowed? | Deny policies and organization policies |
| Who did it? | Audit logs |
4Principals: Who Can Be Granted Access
Access is always granted to a principal. Choosing the right kind of principal is the first design decision.
Google Account or Managed User
An individual person’s identity, from a consumer account or, preferably, a managed account in your organization’s directory.
Google Group
A collection of people managed in one place. Granting access to a group applies to all current and future members.
Domain
All users in a Workspace or Cloud Identity domain. Broad, and usually best avoided for sensitive resources.
Service Account
An identity for software, such as an application, build pipeline or virtual machine.
Workforce Identity Federation Principals
External people, such as employees signing in through your corporate identity provider, mapped into Google Cloud without separate accounts.
Workload Identity Federation Principals
External applications, such as pipelines running in other clouds, recognized by Google Cloud without long-lived keys.
Special Public Identifiers
Identifiers meaning “everyone on the internet” or “anyone signed in with a Google identity”. Extremely broad and risky.
Granting access to a group is like giving a key to a department rather than to each person. When someone joins the department, they automatically get the key; when they leave, the key disappears. You manage membership in one place, not in hundreds of locks.
Why Prefer Groups
- Join and leave processes are handled in one place
- Policies stay short and readable
- Access reviews focus on group membership
- Roles map cleanly to job functions
- Fewer individual grants to forget or miss
Why Avoid Individual Grants
- People change roles and old grants linger
- Policies become long and hard to audit
- Departures leave orphaned access
- Inconsistent access among similar people
- Harder to prove least privilege
Granting a role to “all authenticated users” or “all users”, thinking it means “everyone in my company”. It means anyone on the internet or anyone with any Google identity. Use groups or your domain instead, and review any public grants carefully.
5Roles and Permissions
Roles are the unit you actually grant. Understanding the three kinds of roles is essential for least privilege.
Permissions: the smallest unit
A permission represents one allowed action, such as creating a virtual machine or reading a secret. Permissions follow a naming pattern of service, resource type and verb, which makes them readable. You do not grant permissions to people directly. Instead, permissions are bundled into roles.
The three kinds of roles
| Kind | Description | When to Use |
|---|---|---|
| Basic roles | The original broad roles: Owner, Editor and Viewer, which cover almost all services | Rarely in production; fine for quick personal experiments |
| Predefined roles | Fine-grained roles created and maintained by Google for specific services and jobs | The default choice for most grants |
| Custom roles | Roles you define by choosing permissions yourself | When no predefined role fits and you need tighter control |
Why basic roles are risky
The Editor role can change nearly every resource in a project, and Owner can additionally manage access and billing. These roles contain thousands of permissions, far more than most people need. Using them for routine work breaks least privilege, so predefined roles are strongly preferred.
Viewer-Style Predefined Roles
Allow reading a particular service’s resources without changing anything.
User-Style Predefined Roles
Allow using a service, such as running queries or invoking functions, without managing its settings.
Admin-Style Predefined Roles
Allow full management of one service, still without power over unrelated services.
Custom Role
A hand-chosen set of permissions, such as “start and stop machines but never delete them”.
A basic role is like a master key that opens every door in a building. A predefined role is a key cut for one department. A custom role is a key you cut yourself for a very specific closet. The fewer doors a key opens, the less harm a lost key can do.
Problem
Granting the basic Editor or Owner role to developers, applications or service accounts because it “just works”.
Why It’s Harmful
These roles carry far more permissions than needed. A single leaked credential or mistaken command can affect nearly everything in a project.
Correct Approach
Grant predefined roles for the specific services needed, use custom roles where gaps exist, and use the recommender tools to trim unused permissions.
Before creating a custom role, look hard for a predefined role that fits. Custom roles need ongoing maintenance, because when services add new permissions, you must decide whether to update the role.
6The Resource Hierarchy and Inheritance
Where you grant a role matters as much as which role you grant. Policies flow downward through the hierarchy.
The tree of resources
Google Cloud organizes resources in a hierarchy. At the top sits the organization, which represents a company. Beneath it are optional folders, used to group projects by team, environment or business unit. Projects hold the actual resources, such as virtual machines, buckets and databases. An allow policy can be attached at any level, and it applies to everything below that level.
flowchart TD
O[Organization] --> F1[Folder: Engineering]
O --> F2[Folder: Finance]
F1 --> P1[Project: Web App Production]
F1 --> P2[Project: Web App Development]
F2 --> P3[Project: Reporting]
P1 --> R1[Resources: VMs, Buckets, Databases]
P2 --> R2[Resources]
P3 --> R3[Resources]
How inheritance works
If you grant a role on a folder, the principal has that role on every project and resource inside the folder. The effective access at any resource is the combination of policies set on the resource itself and on all of its ancestors. Allow policies are additive: a grant higher up cannot be removed by a lower-level allow policy. To block something inherited, you use deny policies or other guardrails, not another allow.
Collect Policies Up the Tree
The system gathers allow policies on the resource and on its project, folder and organization.
Combine the Grants
All grants that apply to the principal are merged, since allow policies add up.
Apply Denies and Boundaries
Deny policies and any access boundaries are checked and can override the allows.
Check Conditions
Conditional grants apply only if their conditions are met in the request.
Decide
If an applicable allow remains and nothing denies it, the action is permitted. Otherwise it is refused.
Think of a building with a main entrance, floors and rooms. A pass to the whole building opens every floor and room. A pass to the third floor opens its rooms only. Passes add up, so someone holding both can open both areas, and removing the floor pass does not remove the building pass.
Organization
Use for company-wide roles held by very few people, such as security reviewers and organization administrators.
Folder
Use for team or environment-wide access, such as read access for an operations group across many projects.
Project
The most common level for granting teams access to their own work.
Individual Resource
Use for fine-grained cases, such as one bucket or one secret that only a specific identity should read.
Granting a broad role at the organization or a high folder because it is quicker than granting it at the right project. The access then spreads to every current and future project beneath it. Grant at the lowest level that does the job.
7Allow Policies in Depth
An allow policy is the document that records who has which role. Knowing how it is structured demystifies much of IAM.
What an allow policy contains
An allow policy is attached to a resource and contains a list of bindings. Each binding links one role to a list of principals, and may carry a condition. The policy also holds a version number and a tag used to prevent two administrators from overwriting each other’s changes at the same time. Because a policy is replaced as a whole, tools read the current policy, modify it and write it back.
| Part of the Policy | Purpose |
|---|---|
| Binding | Connects one role to one or more principals |
| Members or principals list | The identities receiving the role |
| Role | The permissions being granted |
| Condition (optional) | Limits when the binding applies |
| Version | Indicates features such as conditions are in use |
| Concurrency tag | Prevents conflicting simultaneous edits |
Propagation and consistency
When you change a policy, the change is not always visible everywhere instantly. IAM is designed to be consistent, but it can take a short time, often minutes at most, for a change to apply or for removed access to stop working fully. In an urgent revocation, plan for this short delay and also revoke credentials and sessions where necessary.
sequenceDiagram
participant U as User or Workload
participant S as Google Cloud Service
participant I as IAM
U->>S: Request to perform an action
S->>I: Is this principal allowed this permission on this resource?
I->>I: Evaluate allow policies, denies, boundaries and conditions
I-->>S: Decision: allowed or denied
S-->>U: Perform the action or return permission denied
Manage Policies as Code
Define access in version-controlled configuration so changes are reviewed, tracked and repeatable.
Avoid Manual Edits in Production
Console clicks leave drift that no one remembers. Prefer automated, reviewed changes.
Mind the Policy Size Limits
Policies have limits on the number of bindings and principals, which is another reason to use groups.
When troubleshooting “permission denied”, remember there may be several layers: the allow policy, a deny policy, an organization policy, a service perimeter or a network rule. The Policy Troubleshooter tool can explain which layer blocked a request.
8Deny Policies and Principal Access Boundaries
Allow policies only add access. Sometimes you need to draw lines that cannot be crossed.
Deny policies
A deny policy lists principals and permissions that are blocked, and can include exceptions. Deny rules take precedence over allow rules, regardless of where the allow was granted. They are useful for guardrails such as “no one except the security team may delete audit log sinks”, even if some project administrator has a broad role that would otherwise permit it.
Principal access boundaries
A principal access boundary policy limits the set of resources that certain principals are even eligible to access. It is a way of saying “these service accounts may only ever be used within these projects”, regardless of what roles they are granted. This helps contain the impact of stolen identities and accidental over-grants.
| Control | What It Does | Typical Example |
|---|---|---|
| Allow policy | Grants roles to principals on resources | Give a team read access to a project |
| Deny policy | Blocks specific permissions for chosen principals, overriding allows | Prevent deletion of critical resources except by a break-glass group |
| Principal access boundary | Limits which resources a principal can use at all | Restrict a contractor group to a few projects |
| Organization policy | Limits what can be done to resources, for everyone | Disallow external IP addresses on virtual machines |
Allow policies are the keys you hand out. Deny policies are “do not enter” signs that apply even to key holders. A principal access boundary is a fence around the part of the campus that a visitor badge is valid in. Organization policies are the building rules that bind everyone, such as “no open flames”.
flowchart TD
R[Access Request] --> D{Denied by a Deny Policy?}
D -->|Yes| X[Request Denied]
D -->|No| B{Within Principal Access Boundary?}
B -->|No| X
B -->|Yes| A{Allowed by an Allow Policy and Conditions?}
A -->|No| X
A -->|Yes| OK[Request Allowed]
Writing deny rules so broadly that they block automation or break-glass emergency access. Always include a carefully controlled exception for emergency use, and test deny rules before enforcing them widely.
9IAM Conditions
Sometimes a role should apply only under certain circumstances. Conditions add that precision.
What conditions can do
A condition is a rule attached to a role binding. The binding is active only when the condition is true for the request. Conditions can check things such as the current time, the name or type of the resource, tags on the resource and some attributes of the request. They let you express ideas like “this contractor has this role until the end of the month” or “this group can manage only resources whose names begin with a team prefix”.
Temporary Access
Grant a role that expires automatically on a given date, so forgotten access disappears on its own.
Time-Window Access
Allow access only during working hours or maintenance windows.
Resource-Scoped Access
Limit a role to resources whose names or types match a pattern, giving fine control inside one project.
Tag-Based Access
Grant access based on tags on resources, such as environment or data sensitivity, so access follows the label.
A conditional grant is like a visitor badge that reads “valid Tuesday between 9 and 5, third floor only”. The badge exists, but the building’s doors check the extra rules every time it is used.
Advantages of Conditions
- Access expires without manual cleanup
- Finer control inside a project
- Fewer separate projects needed just to separate access
- Access that follows tags and naming standards
Trade-offs
- Policies become harder to read and audit
- Not every service and resource type supports every condition
- Complex conditions are easy to get subtly wrong
- Troubleshooting needs good tooling
Support for conditions varies by service and resource type, so check the documentation for the services you use before designing around them. Keep conditions simple and well documented, and test them with the troubleshooting tools.
10Service Accounts: Identities for Workloads
Software needs to call Google Cloud too. Service accounts are how applications get identities and permissions.
What a service account is
A service account is an identity that belongs to an application or workload rather than a person. It has its own email-style identifier and can be granted roles like any principal. A virtual machine, a Cloud Run service or a build pipeline can run as a service account and receive credentials automatically, so code never needs to store a password.
User-Managed Service Accounts
Created by you for specific workloads. The recommended kind, with one account per workload or purpose.
Default Service Accounts
Created automatically by some services, often with broad permissions. Better replaced with dedicated accounts.
Service Agents
Google-managed identities that services use internally to act on your resources, such as to read your buckets for a managed service.
Two roles to understand carefully
| Ability | What It Allows | Why It Is Sensitive |
|---|---|---|
| Act as or attach a service account | Run a workload using that service account’s identity | The workload gains all of that account’s permissions, so this is effectively access to them |
| Create tokens for or impersonate a service account | Obtain short-lived credentials representing that account | Whoever can impersonate gains the account’s power, so control it tightly |
| Create keys for a service account | Download long-lived credentials | Keys can be copied and leaked, and live until revoked |
How workloads obtain credentials
Attach the Service Account
You choose a service account when creating a virtual machine, service or job.
Platform Provides Credentials
The environment supplies short-lived tokens to code through a metadata service, with no secret files.
Client Libraries Pick Them Up
Google libraries automatically find and use these credentials, a feature called application default credentials.
Tokens Expire and Refresh
Credentials are temporary and renew automatically, limiting the value of a stolen token.
A service account is like a uniform for a role. A delivery robot (workload) puts on the “warehouse-picker” uniform and gains the keys that uniform carries. The robot is given the uniform by the building (the platform) rather than carrying a hand-written note that could be copied.
Problem
Creating downloadable service account keys, storing them in code repositories, build systems or laptops, and sharing one account across many applications.
Why It’s Harmful
Keys are long-lived secrets that leak easily and are hard to track. A shared account means one compromised application exposes everything that account can reach.
Correct Approach
Attach service accounts to workloads, use short-lived credentials and impersonation, use workload identity federation for outside systems, and give each workload its own narrowly scoped account.
Leaving workloads on the default service account with its broad permissions. Create a dedicated service account for each workload, grant it only the roles it needs and replace defaults wherever possible.
11Federation: Workforce and Workload Identity
Not every person or application lives inside Google Cloud. Federation lets outside identities in without copying secrets or creating duplicate accounts.
Workforce Identity Federation
Workforce Identity Federation lets your employees and partners sign in with your existing identity provider, such as a corporate directory, and access Google Cloud with short-lived credentials. You create a workforce pool, map attributes from the provider to Google Cloud, and grant roles to pool principals. People keep a single sign-in, and you avoid creating and synchronizing separate cloud accounts.
Workload Identity Federation
Workload Identity Federation lets applications running outside Google Cloud, such as in another cloud, on-premises or in a hosted pipeline, access Google Cloud resources without service account keys. The workload presents a credential issued by its own environment, and Google Cloud exchanges it for a short-lived token, based on rules you define about which external identities are trusted.
Workload identity on Kubernetes
For Google Kubernetes Engine, workload identity features allow individual Kubernetes service accounts to be mapped to Google Cloud identities, so each application in a cluster gets its own permissions instead of sharing the permissions of the underlying machines.
flowchart LR
E[External Workload or Pipeline] --> T1[Present Its Own Identity Token]
T1 --> P[Workload Identity Pool and Provider Rules]
P --> S[Security Token Exchange]
S --> T2[Short-Lived Google Cloud Access Token]
T2 --> R[Google Cloud Resources]
| Need | Best Option | Why |
|---|---|---|
| Employees using corporate sign-in | Workforce Identity Federation | One sign-in, no duplicate accounts |
| Pipelines or apps in other clouds | Workload Identity Federation | No long-lived keys |
| Apps on Google Kubernetes Engine | Workload identity for GKE | Per-application identity and permissions |
| Apps on Compute Engine or Cloud Run | Attached service account | Automatic short-lived credentials |
| Local developer testing | Impersonation with the developer’s own identity | No downloaded keys; tied to a real person |
Write federation trust rules narrowly. For example, trust only a specific repository and branch of a hosted pipeline, not every pipeline from that provider. Loose trust rules can let anyone on the provider’s platform act as your workload.
12Organization Policies: Guardrails for Everyone
IAM controls who can act. Organization policies control what actions are permitted at all.
What Organization Policy does
The Organization Policy Service lets you set constraints on resources across your hierarchy, regardless of who is acting. Constraints are rules such as “virtual machines may not have external IP addresses”, “resources may only be created in these regions” or “service account keys may not be created”. Policies are inherited down the hierarchy like IAM policies, and can be tuned at folders or projects where exceptions are justified.
Block Service Account Key Creation
Prevents long-lived keys, pushing teams toward safer credential methods.
Restrict Resource Locations
Keeps data and workloads within approved regions for residency rules.
Disable External IP Addresses
Stops virtual machines being exposed directly to the internet.
Restrict Sharing to Your Domains
Prevents granting access to identities outside approved domains.
Require Secure Defaults
Enforce settings such as secure boot or uniform bucket-level access.
| Aspect | IAM | Organization Policy |
|---|---|---|
| Focus | Who can do what | What can be done to resources at all |
| Applies to | Specific principals | Everyone in the scope, including administrators |
| Typical example | Give a team access to a bucket | Forbid public buckets anywhere |
| Managed by | Many teams, within their areas | Central security or platform team |
IAM is the list of who holds which keys. Organization policy is the building code: it says no one, key or not, may prop a fire door open or store flammable materials in the corridor.
New organizations may receive secure-by-default organization policies, such as restrictions on service account key creation. Check which constraints are enforced in your organization and understand their effect before relying on workarounds.
13Least Privilege in Practice: Recommender, Analyzer and Troubleshooter
Granting too much is easy. Tools help you find excess access and fix it with evidence.
IAM Recommender
Looks at what permissions a principal has actually used over a period and suggests removing or replacing roles that grant far more than were used.
Policy Analyzer
Answers questions such as “who can access this resource?” or “what can this person access?”, including through inheritance and groups.
Policy Troubleshooter
Explains why a request was allowed or denied, showing which policies applied.
Policy Simulator
Shows how a proposed policy change would affect past access, before you apply it.
Cloud Asset Inventory
Lists resources and their access policies across the organization, with history, for audits and searches.
Audit Logs
Record administrative changes and, when enabled, data access, showing who did what.
A least-privilege improvement cycle
Start with Predefined Roles
Grant narrow, job-specific roles instead of basic roles from the beginning.
Observe Real Usage
Let some time pass so usage data builds up.
Review Recommendations
Look at suggestions for replacing broad roles with narrower ones.
Simulate Changes
Test the effect of removals against past activity.
Apply and Monitor
Make the change, watch for denied requests and adjust if needed.
Applying every recommendation blindly. Rarely used but critical permissions, such as those for annual or disaster recovery tasks, may not appear in recent usage. Review suggestions with the people who own the workload.
14Privileged Access and Just-in-Time Elevation
Powerful access is dangerous when held all the time. Temporary elevation shrinks the window of risk.
The standing access problem
Many administrators hold powerful roles permanently, even though they use them rarely. If their accounts are compromised, attackers inherit this power. Just-in-time access flips the model: people hold ordinary access by default and request elevated access only when needed, for a limited time, with a reason and sometimes an approval.
Privileged Access Manager
Privileged Access Manager is a Google Cloud capability for granting time-limited, auditable elevated access. Administrators define entitlements describing which roles can be requested, by whom, for how long and whether approval is needed. Grants expire automatically, and every request and approval is recorded.
sequenceDiagram
participant E as Engineer
participant P as Privileged Access Manager
participant A as Approver
participant G as Google Cloud Resource
E->>P: Request elevated role with reason
P->>A: Ask for approval
A-->>P: Approve
P->>G: Grant temporary role
E->>G: Perform privileged task
P->>G: Revoke role when time expires
Smaller Attack Window
Compromised accounts have limited power most of the time.
Clear Accountability
Each elevation has a reason, an approver and a time range.
Automatic Cleanup
Access ends without anyone needing to remember to remove it.
Emergency Access Pathway
A controlled “break-glass” route for incidents, with heavy logging and alerts.
Keep a small number of highly protected break-glass accounts for emergencies, protect them with strong authentication, alert on any use and test them regularly so they work when truly needed.
15Designing an Organization-Wide Access Model
At scale, IAM is less about individual grants and more about a repeatable design.
Layers of a good design
Identity Foundation
A central directory, single sign-in, strong multi-factor authentication and a clear join, move and leave process.
Group Structure
Groups that map to job functions and environments, such as “payments developers” and “production operators”.
Hierarchy Design
Folders that mirror teams and environments so policies can be applied at the right level.
Role Standards
An approved catalog of predefined and custom roles for each function.
Guardrails
Organization policies, deny policies and boundaries that no team can bypass.
Workload Identity Standards
Dedicated service accounts, no keys, and federation for external systems.
Monitoring and Review
Audit logs, alerts on risky changes and regular access reviews.
flowchart TD
ID[Central Identity Provider and MFA] --> GR[Groups by Job Function]
GR --> RB[Role Bindings at Folder and Project Level]
RB --> RES[Resources]
GUARD[Org Policies, Deny Policies, Boundaries] --> RES
WL[Service Accounts and Federation for Workloads] --> RES
RES --> LOG[Audit Logs and Alerts]
LOG --> REV[Access Reviews and Recommender]
REV --> RB
Separation of duties
Some actions should require two different people, so no single account can cause or hide serious harm. For example, the people who can change security configuration should differ from those who deploy applications, and those who can alter audit logs should differ from those whose activity is being audited. IAM roles, folders and separate projects make this separation practical.
Inventory and Classify
Know what resources and data you have and how sensitive each is.
Define Roles Per Function
Decide what each job truly needs, using predefined roles where possible.
Build Groups and Grant to Groups
Bind roles to groups at folder or project level.
Add Guardrails
Apply organization policies and denies for things that must never happen.
Automate as Code
Manage IAM in version-controlled configuration with review and testing.
Review Regularly
Run access reviews, act on recommendations and update the design as needs change.
16Monitoring, Auditing and Troubleshooting
A well-designed IAM setup still needs watching, and permission errors still need solving.
What to watch
Policy Changes
Alerts when sensitive roles are granted, especially owner-like roles and role administration.
Service Account Key Creation
New keys are a strong risk indicator and should be rare or blocked.
Impersonation and Token Use
Unexpected impersonation of powerful accounts deserves investigation.
Denied Requests
Spikes may signal misconfiguration or probing by an attacker.
Public Access Grants
Any grant to everyone on the internet should trigger review.
Dormant and Over-Privileged Identities
Unused accounts and permissions that were never exercised.
Common “permission denied” causes
| Symptom | Likely Cause | What To Check |
|---|---|---|
| Denied even though the role looks right | Role granted at the wrong resource or not yet propagated | Where the grant sits, and wait a few minutes |
| Denied for a workload only | Workload runs as a different service account than expected | Which identity the workload actually uses |
| Denied only from certain contexts | A condition, network control or perimeter is blocking | Conditions and service perimeter settings |
| Can read but not write | Role includes only viewing permissions | Permissions included in the role |
| Cannot deploy using a service account | Missing ability to attach or act as that account | Permission to use the service account |
| Denied despite broad allow | A deny policy, boundary or organization policy applies | Deny policies and organization constraints |
| API disabled error | Service not enabled in the project | Whether the API is enabled |
Resist the urge to “just grant Editor to see if it works”. Use the troubleshooter to find the exact missing permission and grant the narrowest role that includes it. The extra minute saves long-term risk.
17IAM Compared with Related Controls
IAM is one layer in a larger set of protections. Knowing the neighbors avoids using the wrong tool.
| Control | What It Protects | How It Differs from IAM |
|---|---|---|
| IAM | Access to Google Cloud resources and APIs | Based on who the caller is and what role they hold |
| Organization Policy | Configuration of resources | Limits what can be done by anyone |
| VPC Service Controls | Data exfiltration from supported services | Perimeters around services regardless of identity |
| Firewall rules | Network traffic to and from machines | Based on addresses, ports and tags, not user identity |
| Identity-Aware Proxy | Access to web applications and some services | Applies identity and context checks at the application entrance |
| OS Login | Access to virtual machines by SSH | Uses IAM roles to control who can sign in to machines |
| Secret Manager | Storing sensitive values | Uses IAM to control who can read each secret |
| Cloud KMS | Encryption keys | Uses IAM to control who can use or manage keys |
Defense in depth is like protecting a house with a locked front door (IAM), a fence around the property (perimeters), house rules (organization policy), a security camera (audit logs) and a safe for jewelry (key management). No single layer is enough, and each covers weaknesses of the others.
flowchart TD
Q1{What are you protecting?} --> A[Who may call APIs and manage resources: IAM]
Q1 --> B[What configurations are allowed at all: Organization Policy]
Q1 --> C[Data leaving trusted boundaries: VPC Service Controls]
Q1 --> D[Network traffic: Firewall Rules]
Q1 --> E[Access to a web app: Identity-Aware Proxy]
18Design Patterns and Anti-patterns
Patterns capture what experienced teams repeatedly find works; anti-patterns capture what goes wrong.
Helpful patterns
Groups for People, Dedicated Accounts for Workloads
People receive access only through groups that map to job functions. Every application has its own service account with narrowly chosen roles, and no downloadable keys are created.
Environment Separation with Folders
Development, staging and production live in different folders or projects with different policies. Developers have broad access in development and read-only or just-in-time access in production.
Central Security Guardrails
The security team applies organization policies and deny policies at the top of the hierarchy, so every project inherits protections no matter who creates it.
Just-in-Time Production Access
Engineers hold no standing administrator rights in production. They request time-limited elevation with a reason, and approvals and sessions are logged.
Federated Pipelines Without Keys
Build pipelines in other platforms authenticate through workload identity federation, scoped to specific repositories and branches, and receive short-lived tokens.
IAM as Code with Review
All access changes go through version-controlled configuration, code review and automated checks, giving a complete history and consistent environments.
Anti-patterns to avoid
Problem
One giant project for everything, with many teams sharing broad roles.
Why It’s Harmful
Access cannot be separated sensibly, mistakes spread widely and audit trails become muddled.
Correct Approach
Use separate projects and folders per team and environment, with tailored roles.
Problem
Granting roles to individual users directly and never reviewing them, so access accumulates as people move between teams.
Why It’s Harmful
People keep old permissions, creating invisible risk, and departing staff may retain access.
Correct Approach
Grant through groups, tie membership to job function and run regular access reviews.
Problem
Relying on a few shared administrator accounts for day-to-day work.
Why It’s Harmful
Actions cannot be traced to a person, credentials are shared widely and removing someone’s access is messy.
Correct Approach
Use individual identities with strong authentication, and reserve shared break-glass accounts for emergencies with alerts.
Problem
Letting anyone who can deploy a workload attach any service account, including powerful ones.
Why It’s Harmful
A developer with limited rights can run code as a highly privileged account, effectively escalating their own power.
Correct Approach
Restrict who may use or attach powerful service accounts, and grant that ability only for the specific accounts needed.
19Advantages, Disadvantages and Real-World Uses
An honest view of strengths, limits and where teams apply IAM in practice.
Advantages
- One consistent model across all Google Cloud services
- Fine-grained predefined roles and optional custom roles
- Hierarchy and inheritance for scalable administration
- Conditions, denies and boundaries for precise control
- Keyless identity options for workloads and workforce
- Built-in analysis tools and audit logging
- No charge for using core IAM
Disadvantages / Trade-offs
- A large catalog of roles and permissions takes time to learn
- Inheritance can hide where access really comes from
- Several layers of control make troubleshooting harder
- Custom roles need ongoing maintenance
- Policy size limits require thoughtful use of groups
- Design mistakes at the hierarchy level are costly to reverse
Real-world examples
A Startup Growing Up
A small startup begins with a few people holding the basic Editor role in one project. As the team grows, it moves to groups, splits development and production into separate projects, replaces service account keys with attached identities and adds alerts on risky changes.
A Bank with Strict Segregation
A bank separates platform, security and application teams, applies deny policies on audit configuration, uses just-in-time access for production and reviews entitlements quarterly with evidence from audit logs.
A SaaS Company with Many Pipelines
A company with hundreds of repositories uses workload identity federation so each pipeline receives short-lived credentials scoped to its own project, eliminating thousands of stored keys.
A Contractor Engagement
An external firm gets access through a group limited to specific projects, with conditions that expire the access on the contract end date and boundaries preventing use elsewhere.
A Data Platform Team
A data team grants analysts read access to curated datasets, while raw sensitive datasets are limited to a small group with tag-based conditions and detailed data access logging.
20Best Practices and Common Mistakes
A short checklist to carry into every IAM design and review.
Best Practices
- Apply least privilege: narrowest role, at the lowest level, for the shortest time
- Prefer predefined roles over basic roles, and custom roles only when needed
- Grant to groups, not individuals, and keep group membership clean
- Use dedicated service accounts per workload and avoid keys
- Use federation for external people and workloads
- Add guardrails with organization policies, deny policies and boundaries
- Use just-in-time elevation and protected break-glass accounts
- Manage IAM as code with review and testing
- Enable audit logs, alert on risky changes and review access regularly
- Separate duties and separate environments by project or folder
Common Mistakes
- Using Owner or Editor everywhere
- Granting to individuals and never revisiting
- Downloading and sharing service account keys
- Leaving workloads on default service accounts
- Granting broad access at the organization level
- Public grants made by accident
- Ignoring recommender suggestions and audit alerts
- Skipping documentation of why access exists
21Frequently Asked Questions
A permission is one allowed action on a resource type. A role is a named bundle of permissions. You grant roles to principals, not individual permissions.
They contain a huge number of permissions across almost all services, far beyond what most people or applications need. Predefined roles give narrower, safer access.
A grant on an organization, folder or project applies to everything beneath it. Effective access is the combination of grants on the resource and all of its ancestors, so grant at the lowest suitable level.
Not with another allow policy, because allows add up. To block inherited access you use deny policies, access boundaries or other guardrails.
It is an identity for an application or workload. You need one whenever software, such as a virtual machine, a service or a pipeline, must call Google Cloud APIs.
Avoid them where possible. Prefer attached service accounts, impersonation, workload identity federation and workload identity on Kubernetes, which use short-lived credentials.
IAM controls who can do what. Organization Policy controls what can be done to resources at all, regardless of who is doing it, such as restricting regions or external addresses.
Use a conditional grant with an expiry time, or just-in-time elevation through Privileged Access Manager, so the access ends automatically.
Use Policy Analyzer and Cloud Asset Inventory to see who can access a resource, including through groups and inheritance, and audit logs to see who actually did what.
IAM changes can take a short time to propagate. Wait a few minutes before concluding that the grant failed, and use the troubleshooter if the problem persists.
Use workforce identity federation for people signing in with a corporate identity provider, and workload identity federation for external applications and pipelines.
Group memberships, high-privilege roles, service account permissions and keys, public grants, recommender suggestions and audit alerts for risky changes.
22Summary and Key Takeaways
Google Cloud IAM answers who can do what on which resource. Principals, mainly groups for people and dedicated service accounts for workloads, receive roles, which are bundles of permissions. Grants are recorded in allow policies attached at any level of the resource hierarchy and inherited downward. Deny policies, principal access boundaries, conditions and organization policies add precision and guardrails, while federation and short-lived credentials remove the need for long-lived keys. Tools such as the recommender, policy analyzer, troubleshooter and audit logs help you move toward least privilege and prove it, and just-in-time elevation keeps powerful access temporary. The best IAM designs are planned early, expressed as code, reviewed regularly and layered with other controls. Because roles, features and limits evolve, confirm details in current Google Cloud documentation.
Key Takeaways
- Who, what, where — IAM connects a principal to a role on a resource, and every request is checked against policies before it is allowed.
- Least privilege first — prefer predefined roles over Owner and Editor, grant at the lowest suitable level, and trim unused access with recommender tools.
- Groups for people, dedicated accounts for workloads — avoid individual grants and shared or default service accounts.
- Avoid long-lived keys — use attached service accounts, impersonation and workload or workforce identity federation with short-lived credentials.
- Understand the hierarchy — allow policies are inherited and additive, so use deny policies, boundaries and organization policies to draw firm lines.
- Make power temporary and visible — use conditions, just-in-time elevation, protected break-glass accounts, audit logs and alerts on risky changes.
- Treat IAM as a designed system — separate duties and environments, manage access as code, review regularly and layer it with other security controls.