GCP IAM setup: where access to resources breaks
GCP IAM setup rarely starts with design — usually access is granted "by eye" so the task works today.
Project-level basic roles spread permissions across the entire hierarchy: folders, nested projects, and resources inherit them silently, and a couple of months later no one can say who has access to the storage with customer data.
A separate line of problems is contractors and service accounts.
An external contractor is given a key "for the duration of the work," the key is not revoked, and permissions accumulate behind it: first read, then write, then an administrative role "for debugging." Excessive permissions on such accounts are the most common path to a leak, because the key lives in someone else's repository or in a chat.
The picture is made worse by the fact that no one conducts access audits regularly. A permissions review shows dozens of assignments that have never been revoked: former employees, test accounts, forgotten integrations.
Each such assignment expands the blast radius — compromising one account opens not just one function, but the entire perimeter.
The principle of least privilege looks obvious, but it requires work: distribute roles across levels, separate administrative and day-to-day permissions, move service accounts into separate ones, add access separation in the cloud by environment. Below we break down how this is closed — from inventory to ongoing control.
What role-based access setup gives
Access in the cloud rarely breaks on its own — it breaks because it was granted situationally: for a task, "until we figure it out," by copying someone else's role.
A managed role model instead ties permissions to work groups and a specific resource, rather than to a person's account, and lives as code — changes undergo review and remain in history.
The reference point when designing such a scheme is Google Cloud and its recommendations on the principle of least privilege. Below are four effects that the customer sees in the first weeks after moving the project to this scheme.
Speed of granting and access lifetime
A new engineer gets permissions in minutes: they are added to a group, the group is already linked to the needed role — no back-and-forth approvals, and the set of permissions is predictable.
For temporary tasks, we issue time-bound access: the binding is valid until the needed date and is removed automatically; no forgotten "for a couple of days" invitations remain.
Fewer excessive permissions — fewer classes of failures
The share of extra permissions falls: instead of broad project-level roles, we grant roles on a specific resource, and the person sees exactly what they work with.
This removes an entire class of failures when an accidental change or deletion affects someone else's service, and incident analysis follows the log: you can see who acted, when, and with what permissions.
Access schemes: comparison of approaches and modes
The access model in the cloud is made up of layers: inheritance from organization to project, bindings to individual resources, roles for people and separately for services.
The choice of scheme determines what exactly ends up in the log, how long access revocation takes upon termination, and how easy it is to understand who is entitled to sensitive data.
Options and their boundaries
| Option | When it fits | Limitations |
|---|---|---|
| Basic roles | Sandboxes, personal projects, quick start | Permissions for the entire project, audit won't show who used what |
| Custom roles | Production projects with real data | The set of roles must be versioned, otherwise it diverges from practice |
| Groups and federation with corporate directory | Multiple teams, a single employee directory | Depends on directory data quality; termination is not synchronized immediately |
| Service accounts | Applications, builds, scheduled jobs | Long-lived keys leak; resource binding is more reliable than a key file |
| Temporary access on request | Incident investigations, one-off work, support | Mandatory expiration-based revocation and issuance log are required |
How this combines
Schemes do not compete — in a production environment they are combined. People get access through groups from the corporate directory, applications through service accounts with resource binding, exceptions are issued temporarily and removed upon expiration.
Basic roles remain only in isolated projects where there is no shared data and no external integrations.
Before implementation, we build a map of actual permissions: it shows which permissions come by inheritance, which bindings duplicate each other, and where access is held by all employees at once. Then the scheme can be changed in stages without stopping service operations.
Implementation stages: from permissions audit to handover
Uncontrolled access in the cloud grows faster than the team can notice it: service accounts with broad roles, keys that no one revoked, permissions granted "temporarily" and left forever.
Therefore, GCP IAM setup is a sequence of stages with a fixed target model before the first change in the production perimeter, not editing policies in the console on request.
Audit and target model
- Permission inventory. We export all role bindings by projects and resources, including those inherited from the organization: who got access to what and through what — together with service accounts and external domains.
- Separation of duties. We determine which roles each team actually needs and which permissions it should not have: model first, then granting.
- Access scheme. We fix the target model: organization policies, groups as the unit for granting a role to a person instead of personal bindings.
Verification and migration
- Role and policy setup. We assemble configuration as code: custom roles only where existing ones are insufficient, access conditions by the needed attributes.
- Testing scenarios on a test perimeter. We run the teams' real tasks — deployment, reading logs, working with secrets — and make sure the new access does not break them, while excessive access is revoked without causing failure.
- Migrating the production perimeter. We switch step by step, with rollback of a specific binding, not the entire model.
- Regulations and documentation handover. Rules for granting and revoking access, the approval procedure, the role scheme, and instructions for on-call staff remain with the team, not in a chat.
What the team has after implementation
Along with access, we hand over artifacts by which it is subsequently granted, checked, and revoked without our involvement.
Everything is stored in the same repository where the infrastructure is described: a role change undergoes review and enters history, rather than settling in someone's chat.
Access model and its description
- "Role — service" matrix: for each service, the minimum sufficient set of roles is specified, along with the rationale for why exactly that one.
- Role inheritance map: where access is granted at the organization level, where at the folder level, where at the project level, and which exceptions override inheritance.
- Access policies as code: conditions, prohibitions on granting permissions outside a group, rules for service accounts.
- Service account scheme with binding to workloads and a list of keys that are not created manually.
Regulations and operations
- Access granting regulation: who approves, for what term the permission is issued, what happens upon its expiration.
- Revocation procedure when changing a role or when an engineer leaves — including checking that permissions did not remain at the organization level.
- Logging setup: administrative actions and policy changes are written to the general audit with export to log storage.
- Instructions for on-call staff: analysis of the typical failure "access is gone, but it used to be there" and the procedure for checking inheritance.
- Checklist for onboarding a new engineer and a short note on which roles must not be granted under any circumstances.
Documentation is tied to configuration: if a policy changes in code, the instruction is updated in the same commit. A month later, the team works with access independently, and we connect on a targeted basis — to analyze complex cases and review permissions.
Case: how excessive permissions were removed in a project
The client came with a story familiar to almost any project in Google Cloud: over several years, several contractor teams received access to the environment, and permissions were granted "temporarily." The terms ended, but the permissions remained — some service account keys were issued for tasks that had long been closed.
Where we started
We exported policies at the organization, folder, and project levels and consolidated them into a single picture. Out of 140 accounts, 38 had the owner or editor role, although only nine needed to write to prod.
Temporary access accounted for 60%, and almost none had either an end date or an owner obligated to revoke them. Administrative operations were logged, but no one read the logs.
Then access was distributed across three layers: basic roles at the organization level, working roles on folders and projects, service roles precisely on specific resources.
Temporary access was moved to issuance with a time condition and a mandatory owner: the term expires — access is not extended automatically but enters a confirmation queue. Contractors were left only with their own perimeter, with session recording and a separate term.
What happened to the metrics
Number of accounts with broad permissions: 38 → 9. Unreturned temporary access — zero instead of 60%. Issuing new access decreased from two to three days of correspondence to a few hours using a template with a ready set of roles.
There were no access incidents in the following period, and attempts to go outside the perimeter are recorded by an alert on the same day.
How basic roles differ from custom roles
Basic roles — owner, editor, viewer — act on a broad scope and are inherited down the hierarchy: assign at the organization or folder, and permissions spread to all projects inside.
Editor allows writing to almost all services, changing the network and access rules, deleting data; viewer allows reading everything, including other people's datasets and configuration.
For a sandbox this is convenient, but in a production perimeter such a role is almost always broader than a specific engineer needs.
Predefined roles are assembled for a specific service and describe the task more precisely — often a ready-made role is sufficient, and there is no point in manually assembling dozens of permissions: make a mistake in one and you get an extra permission.
A custom role is justified when no ready-made one fits in composition: you need access only to read objects in storage and write to one dataset, without the right to change cloud policies and grant access to others.
Such a role is assembled from individual permissions and bound in the cloud policy to a specific resource — access is granted to the group as a whole, not to each engineer personally.
The cost of a custom role is its maintenance: the set of permissions must be stored in version control and reviewed along with the platform.
Predefined roles receive new permissions automatically, custom ones do not, and a forgotten role quietly breaks automation months later when the service adds a new resource type.
The working criterion: basic roles for owners and sandboxes, a ready-made service role for day-to-day tasks, a custom one when the ready-made one gives excessive permissions or they are insufficient.
Common doubts about access management
Doubts before starting are usually the same: will prod stop, will the contractor have access forever, and who will own the settings after management handover.
These are legitimate concerns — a permissions review affects live services, and an error in a role binding does not appear immediately, but through access denial for a running service.
That is why we start with inventory in read-only mode: we collect the resource tree, role bindings, and actual permission usage from audit logs. Then we reduce excess in stages, starting with non-production perimeters, and maintain reversibility at every step.
Will a permissions review break running services?
First, read-only: a map of bindings and actual accesses from audit logs. We make changes one logical block at a time, starting with environments where there is no production load, with verification after each step. If a service starts getting denied, the previous binding is restored with one operation.
Will the contractor's access remain forever?
No. Access is issued to separate accounts with a term limit and revoked automatically upon expiration. Work inside projects goes through temporary privilege elevation, not through a permanent role, and all actions are logged.
Will there be downtime when changing access and handing over management?
Roles and bindings are described as code and stored in the repository, so any change is reversible.
Management handover is transferring ownership of groups and policies to your team plus a short instruction on typical operations; we perform the switchover without interrupting running service accounts.
Let's discuss the access task: what we need from you
To estimate the scope of work based on facts rather than guesses, we need the project's source data. Below is the minimum list — if something is not at hand, write that as well: we will suggest where to look at it and how to record it.
- Composition of projects and organizations: what environments exist, how many there are, and how they are connected to each other.
- Access matrix: who and which resources should have access — teams, contractors, automation.
- Service accounts and keys: where they are used, who the owner is, what can be revoked without downtime.
- Security constraints: regulator and security service requirements, environment separation, retention periods for access logs.
- Current rules and exceptions: what is configured now and which permissions were granted "temporarily" but remained forever.
- Change windows: when it is acceptable to restructure roles and permissions without affecting work processes.
Based on this data, we conduct an audit of current permissions, assemble a target role model with the principle of least privilege, and prepare an implementation plan — with a change order, checks, and rollback points. Then we return with an estimate of the scope of work and stage-by-stage timelines.
You can discuss the task even before everything is assembled: we will clarify part of the source data together so as not to delay the start. Describe the situation in free form — we will return with an estimate and a plan.