Throughout this course we have been leaving loose ends, and they are all the same loose end. In 03-01 we wrote a firewall rule allowing SSH from the IAP range, and we said the firewall does not distinguish between people: making sure "only Marta and Lucía can get in" is solved somewhere else. In 02-02 we limited Lucía to the exportaciones/ prefix of the bucket with a condition we never explained. In 02-05 we bound the GKE pods to a service account with no key files. In 03-03 we said that invalidating the cache requires a role that is best not handed around. That somewhere else, that condition and that role are IAM.

IAM is the system that answers a single question, asked millions of times a day in every project: can this identity perform this action on this resource? It is, without exaggeration, the most important service in Google Cloud. A badly sized VM costs money; a badly granted permission costs the company. And it is also the service most people configure wrongly, almost always in the same way: giving Editor to everybody so that things work and promising themselves they will tidy it up later.

In this lesson you are going to build AlpinaShop's real permission model: you will understand the identity + role + resource equation, you will know why permissions are granted to groups and never to people, you will create a custom role for Lucía, you will design the complete access matrix for Marta, Dani and Lucía across the four projects, you will understand service accounts and why a downloaded JSON key is a time bomb, you will learn to restrict access with conditions, to diagnose why somebody cannot do something, and to publish internal applications and open SSH sessions with no VPN thanks to IAP.

Warning. Permission design has security and, depending on the sector, regulatory implications. What follows is a solid, applicable teaching model, but before taking into production an access scheme governing personal or financial data, it must be reviewed by a security and compliance professional.

1. The IAM equation: identity + role + resource
2. Permissions, roles and policies: the three objects to tell apart
3. Types of identity
4. Google groups: the decision that simplifies everything most
5. Types of role: basic, predefined and custom
6. A real custom role: "catalogue analyst" for Lucía
7. Inheritance down the hierarchy and the effective policy
8. AlpinaShop's access design
9. Service accounts: identities for software
10. Impersonation and short-lived credentials
11. JSON keys: why they are the problem and what to use instead
12. IAM conditions: access limited in time and by resource
13. Diagnosis: policy-troubleshooter, effective policy and Recommender
14. Least privilege and separation of duties, step by step
15. IAP: SSH with no public IP and internal applications with no VPN

The whole of IAM boils down to one sentence:

An allow policy binds who (identity) with what they can do (role) on where (resource).

Three immediate consequences of this model:

• Everything is denied by default. An identity with no bindings can do absolutely nothing. You do not have to "remove" permissions: you have to grant them.
• The policy is attached to the resource, not to the person. There is no such thing as "Lucía's permissions"; there is "the policy of the alpinashop-datos project", in which Lucía appears. That is why you have to know where to look.
• Permissions are additive and are inherited downwards. A role granted on the produccion folder applies to every project inside it. And unless you use deny policies, nothing takes away what has been granted higher up.

Permissions correspond almost one to one with API calls. When the console tells you "you do not have permission to perform this action", what is missing is a specific permission; the work consists of finding which role contains it.

That second command is pure gold: it turns "I need to be able to invalidate the CDN cache" into "I need roles/compute.loadBalancerAdmin" without searching the documentation.

In IAM jargon, an identity is called a principal and is written with a prefix indicating its type:

The two forms of federation deserve to be told apart properly, because they get confused:

• Workforce Identity Federation — for people who already have an identity with an external provider (Microsoft Entra ID, Okta, any OIDC/SAML). It lets employees sign in to Google Cloud with their corporate credentials without creating Google accounts. It is configured at organization level.
• Workload Identity Federation — for external machines and processes: a GitHub Actions pipeline, a Kubernetes cluster outside Google, a workload in another cloud. The external process presents its own token (for example, the OIDC token GitHub issues for each run) and Google exchanges it for temporary credentials of a service account.

This second one is today the correct answer to "how do I deploy from GitHub without uploading a JSON key to the repository?". We will see it applied in 06-01, but it is worth knowing it exists from now on, because it eliminates the worst risk in this lesson at the root.

It is tempting to grant permissions directly to people. It is also the decision that makes access ungovernable within a year. Compare:

The rule, with no practical exceptions:

Roles are granted to groups. People are added to groups. A user: binding in a project's policy is a design smell: either it is temporary and carries an expiry condition, or it is wrong.

AlpinaShop's groups are created in Google Workspace (or Cloud Identity, which is free for this use) and must have names that say what they are, not who is in them:

One important nuance: IAM does not create or manage groups. Groups live in Cloud Identity / Workspace and IAM merely references them. Membership management is done by the identity administrator, who may be a different person from the cloud administrator. Far from being a drawback, that is a healthy separation of duties.

Why the basic ones are an anti-pattern, with specifics rather than dogma:

• roles/editor includes the ability to create service accounts and grant yourself permissions through them in many scenarios, as well as to modify or delete practically any resource in the project. It is a privilege escalation waiting to happen.
• roles/owner adds the ability to modify the IAM policy: whoever has it can give themselves and anyone else everything else, and take it away from you.
• All three predate the existence of most services. When Google launches a new product, its permissions are automatically folded into editor. In other words, your users' permissions grow without anyone deciding anything.
• They break any audit: "who can delete the production database?" is answered with a list of twenty people.

A reasonable exception: in a personal lab project, roles/owner for yourself. In alpinashop-prod, never.

The predefined ones are the answer 90 % of the time. They are grouped by service and usually come in three flavours: viewer (read), user/developer (use), admin (manage). Find them like this:

In alpinashop-datos, Lucía needs to be able to:

• Query the catalogue tables and run queries.
• Read the exports from the bucket, but not write or delete.
• See the state of the instances so she knows whether a report failed because the VM was stopped, but not stop or start them.

No predefined role says exactly that. roles/viewer would give her read access to the whole project, including the IAM policies and the network configurations. This is the textbook case for a custom role.

First, discover which permissions exist and which can be used in a custom role:

Now the role, in a YAML file that must live in the infrastructure repository, because a role is code:

Five things to know about custom roles that are only learned by suffering them:

1. bigquery.jobs.create is the forgotten permission. Without it, Lucía sees the tables but any query fails. Reading data and running jobs are different permissions.
2. stage can be ALPHA, BETA, GA or DISABLED. Setting DISABLED is the way to switch a role off without deleting it, useful for checking whether anybody depended on it.
3. They are created in a project or in an organization, not in a folder. If several projects are going to use the role, create it at organization level (--organization=ORG_ID); otherwise it gets duplicated.
4. You maintain them. When Google adds a new permission to a service, the predefined roles pick it up by themselves; your custom role does not. Review them periodically.
5. Start by copying a predefined role and removing, rather than starting from scratch: gcloud iam roles copy --source=roles/bigquery.dataViewer --destination=... --dest-project=....

AlpinaShop's hierarchy, which you defined in 01-04:

A resource's effective policy is the union of the policies of all its ancestors plus its own. Consequences:

• A role granted at the organization applies to all four projects and to all their resources. That is why there are very few things that should be granted there.
• You cannot subtract by inheriting. If somebody has roles/editor on the produccion folder, there is no way of "taking it away" in alpinashop-prod with an allow policy. The only tool that subtracts is deny policies (gcloud iam policies), which are evaluated before the allow ones and always win; they are the exception, not the everyday mechanism, and they are covered alongside governance at scale in 07-07.
• The practical rule: grant at the lowest level that solves the problem. If the permission is only needed on a bucket, grant it on the bucket, not on the project.

Many resources accept a policy of their own. Compare the granularity:

This is the outcome of the design exercise, and the one you should be able to justify line by line:

Read it carefully, because the interesting decisions are the ones that do not appear:

• Nobody has owner in alpinashop-prod. Not even Marta. Administering production's IAM policy is done through an explicit temporary elevation (section 12), not with a permanent role.
• Dani cannot modify production. He can look — metrics, logs, instance state — because he needs to diagnose incidents, and he can get in over SSH via IAP to debug. But he cannot deploy by hand: changes go in through the alpinashop-cicd pipeline (06-01). That is not distrust, it is traceability: every change in production has a commit behind it.
• Marta is owner in alpinashop-dev. The development environment gets broken and rebuilt; friction adds nothing there.
• Lucía has absolutely nothing in production. Her data reaches alpinashop-datos through replication and export. If she needed to read directly from the alpinashop-pedidos-replica-informes replica, the permission would be roles/cloudsql.client on that specific instance, with a condition, and not a project-level role.
• Billing is viewed at organization level, not project level, because cost questions are cross-cutting (07-05).
• roles/iam.securityReviewer allows reading every IAM policy without being able to modify any. It is the right role for auditing and for answering "who has access to what?".

Applied with gcloud, the design is written like this:

--condition=None is mandatory when the policy already contains conditional bindings; without it, gcloud asks interactively and the loop stops.

A service account is an identity that belongs to the application, not to a person. It has an email of the form [email protected] and it is two things at once, which is disconcerting at first:

• An identity: roles are granted to it, as to a user.
• A resource: it has its own IAM policy, which says who can use it.

That second facet is the one almost nobody sees at first and the one that explains half of all permission errors.

AlpinaShop's service accounts so far, and why there are several and not one:

One service account per workload. Not one per project, not one per team. When a credential is compromised, the blast radius is exactly that of that workload. And when you review the logs, you know who did what with no ambiguity.

Two specific warnings:

• Never use the default Compute Engine service account. It is created automatically, it comes with roles/editor on the project and every VM uses it unless you say otherwise. In other words: any code on any VM can do almost anything in the project. Create your own and assign it explicitly in the instance template.
• roles/iam.serviceAccountUser on a service account is more powerful than it looks. It allows launching resources as that identity, and therefore inheriting its permissions. Granting it on a powerful account amounts to granting those permissions.

The correct way for a person to run something with a service account's permissions is not to download its key: it is to impersonate it. Google issues a short-lived token — typically one hour — and there is no credentials file to steal.

And for the Python client libraries, impersonation also works with no keys:

The advantages over a downloaded key are worth listing, because this is the argument you will have to make to somebody:

• It expires by itself. An hour later it is worthless.
• It leaves a trail. The audit logs record that lucia@ impersonated sa-informes-nocturnos, so the action has a human owner.
• It is revoked by removing a role, not by chasing files across the team's laptops.
• It chains well: one process can impersonate another account if the policy allows it, forming auditable chains.

Related, and very useful from an organizational point of view: Privileged Access Manager allows granting temporary elevations with approval and automatic expiry — "Marta needs to be an IAM administrator in production for two hours to fix this" — without anybody holding that role permanently. It is the modern answer to "nobody has owner in production, but somebody has to be able to fix it at 3 in the morning".

This command exists, it works, and you should treat it as the last resort:

That file contains an RSA private key that never expires and that authenticates the service account from anywhere on the internet. No second factor, no network restriction, no expiry. What happens next is always the same story: it ends up in a Git repository, in a Slack channel, in a .env copied to three laptops, or in a container image published to a registry.

Alternatives, in order of preference:

If you end up in the last row, at least:

And block key creation preventively with the organization policy constraint constraints/iam.disableServiceAccountKeyCreation, which is explained in 07-07. It is one of the three or four measures with the best effort/risk ratio on the whole platform.

A conditional binding only grants the role if a CEL expression is satisfied. It serves two very practical purposes.

Case 1: temporary access. An external consultant needs to see production logs for a week:

This eliminates access debt by construction: the permission withdraws itself, even if nobody remembers. It is the correct way of granting any exceptional access.

Case 2: access limited by resource. This is the condition we left pending in 02-02, the one restricting Lucía to the exportaciones/ prefix:

Other attributes available in the expressions:

Limitations to know about before designing on top of this:

• Not every service supports conditions on resource.name. Cloud Storage, Compute Engine, Secret Manager and BigQuery do, to varying degrees; others ignore the attribute and the condition is never satisfied, leaving the person with no access and you confused. Always check it in the specific service's documentation.
• Conditions cannot be used with basic roles.
• They complicate diagnosis. A person with the right role and a condition that is not satisfied sees exactly the same error as a person without the role. That is why the next section exists.

Any cloud administrator's most frequent question is "why can't this user do this?". There is a tool that answers it directly:

The answer is not a yes or a no: it is the list of every binding examined across the whole hierarchy, with the verdict on each one and the reason. There you can see whether the role is missing, whether it is there but in the wrong project, or whether it is there with a condition that is not satisfied. It is the difference between diagnosing and guessing.

The other three tools in the kit:

Command 3 is the one that really answers "what access does this person have?" before an offboarding or an audit. Number 2 only looks at one project; number 3 sweeps the organization, folders, projects and resources.

IAM Recommender closes the loop: it analyses ninety days of real usage and proposes removing permissions nobody has exercised.

Two common-sense caveats about these recommendations: there are permissions used once a year — the accounting close process, restoring a backup — and ninety days of analysis do not see them. Review before applying, and apply first to service accounts, where the usage pattern is far more stable than a person's.

Least privilege: each identity has exactly the permissions it needs, not one more. In practice it is a procedure, not a virtue:

1. Start from zero. Never from Editor with the intention of trimming; that trimming never arrives.
2. Let it fail. Run the real job and note which permission each error demands.
3. Translate the permission into a role with gcloud iam roles list --filter="includedPermissions:...".
4. Grant the smallest predefined role that contains it; if it is still too big, a custom role.
5. Grant it at the lowest possible level: resource before project, project before folder.
6. Review after three months with Recommender and with search-all-iam-policies.

Separation of duties: no single identity can complete a critical chain on its own. Applied to AlpinaShop:

And the corollary that is already in section 8's table: nobody is a permanent owner of production. When it is needed, they are elevated temporarily, with a reason and with an expiry.

Identity-Aware Proxy applies IAM to application access, not just to the API. It is the bridge between what you learned about networking in 03-01 and what you have just learned about identity. Its idea is zero trust: authorisation depends on who you are, not where you are.

It has two uses, and at AlpinaShop we use both.

Use 1: TCP forwarding for SSH. You already wrote the fw-allow-ssh-iap rule allowing port 22 only from 35.235.240.0/20. What was missing was the permission:

Here at last is the answer to the exercise left pending in 03-01: "only Marta and Lucía can get in over SSH" is implemented with roles/iap.tunnelResourceAccessor and roles/compute.osLogin, not with a firewall rule. The firewall opens the door to the IAP range; IAM decides who walks through it. And if we wanted Lucía to reach only the reporting VM and not the catalogue ones, it would be a conditional binding on resource.name.

Use 2: publishing internal applications with no VPN. Marta wants the internal reporting dashboard to be reachable from home, with no VPN, only for authorised staff. The traditional solution would be a VPN; IAP's consists of putting the dashboard behind an external load balancer and enabling IAP on its backend service:

The flow of a request:

Three details that make this genuinely secure:

• The application never sees unauthenticated traffic. IAP filters first.
• IAP injects the identity into signed headers (X-Goog-IAP-JWT-Assertion), which the application must validate cryptographically. If you just read the email from a header without verifying the signature, anyone who can reach the backend directly can impersonate whoever they like.
• For that very reason, the firewall must still stop anyone reaching the backend around the load balancer: IAP does not replace the network rules from 03-01, it complements them.

And it combines naturally with what comes next: Cloud Armor (03-05) filters by reputation and patterns before IAP asks for credentials, so that automated traffic does not even reach the sign-in screen.

• Granting roles/editor "to make it work". It is the most expensive mistake in the ecosystem. Spend fifteen minutes finding the right predefined role.
• Giving permissions to people instead of to groups. It works for the first month and becomes impossible to audit within the first year.
• Using the default Compute Engine service account. It ships with roles/editor and is inherited by every VM that does not say otherwise.
• Downloading JSON keys. They do not expire, they have no second factor and they end up in Git. Impersonation or Workload Identity Federation, almost always.
• Forgetting that a service account is also a resource. "It has the right roles but cannot use it" almost always means serviceAccountUser or serviceAccountTokenCreator is missing from the account's policy.
• Granting at the organization what is only needed in one project. It is inherited downwards and cannot be subtracted.
• Believing that an inherited permission can be "removed" with another binding. Permissions are additive; only deny policies subtract (07-07).
• Conditions on services that do not support them. The binding is created without error and never works. Verify the service's support.
• Confusing authentication with authorisation. gcloud auth login says who you are; IAM says what you can do. A permission error is not fixed by authenticating again.
• Applying the Recommender's recommendations blindly. Ninety days do not see an annual process.
• Forgetting --condition=None in scripts. The command sits waiting for interactive input and the loop hangs.
• Tip: manage IAM as code. Terraform (06-07) for the bindings, versioned YAML for the custom roles. A permission granted by hand in the console is a permission nobody will remember the reason for.
• Tip: document every exception in the condition's own description. Your six-months-from-now self will thank you.

Dani tries to update the MIG's template in alpinashop-prod from his laptop and gets PERMISSION_DENIED: compute.instanceGroupManagers.update. Write the diagnostic sequence and decide what to do. Bear in mind the access matrix from section 8 before answering "grant him the role".

Lucía's batch process runs every night on alpinashop-informes-1 and must:

• Read the alpinashop-pedidos-replica-informes replica through the Auth Proxy.
• Write a CSV file to gs://alpinashop-catalogo/exportaciones/<date>/.
• Load that file into a BigQuery table in the alpinashop-datos project.
• Read the replica's password from Secret Manager.
• It must not be able to delete anything, nor read the catalogue images, nor see other secrets.

Design the complete solution: service account, roles (predefined or custom), conditions and at which level of the hierarchy each thing is granted. Write the commands.

An external consultancy will carry out a security audit for two weeks, from 1 to 15 September 2026. They need to read the network configurations, the IAM policies and the load balancer logs of alpinashop-prod, but they must not see customer data or modify anything. Design the access and justify each decision.

Solution 1

Diagnosis:

Expected result: Dani belongs to gcp-desarrollo@, which in alpinashop-prod only has read roles. The permission is in roles/compute.instanceGroupManagerAdmin and in roles/compute.admin.

What to do: do not grant it to him. The matrix in section 8 is a deliberate separation-of-duties decision: changes in production go in through the pipeline, with a commit, a review and traceability. Granting him the role would fix the symptom and destroy the property that makes the system trustworthy.

The correct answers, in order:

1. Deploy through the pipeline (06-01): the change is made in the repository, reviewed, and applied by sa-despliegue, which does have the role in alpinashop-prod.
2. If it is a genuine emergency, a temporary elevation with Privileged Access Manager, or failing that a conditional binding with an expiry of hours and a description explaining the incident:

3. If Dani needs this every week, what is failing is not the permissions but the pipeline. Fix the pipeline.

Solution 2

The key decisions and why:

• objectCreator instead of objectAdmin. It allows creating objects but not deleting or overwriting them. It meets the "delete nothing" requirement by construction, not by trust.
• The prefix condition stops the process writing into productos/ even if it had a programming bug. And since it has no objectViewer, it cannot read the images either.
• The secret is granted at secret level. roles/secretmanager.secretAccessor on the project would give access to every secret, including the payment gateway's key.
• cloudsql.client goes in alpinashop-prod, which is where the instance lives, even though the service account belongs to alpinashop-datos. An identity from one project can hold roles in another; it is completely normal.
• No JSON key. The VM carries the account assigned to it and the Python libraries detect it on their own.
• A custom role adds nothing here: the predefined ones, narrowed with conditions and applied to the right resource, are already tight enough. Do not create custom roles if a well-placed predefined one solves the case.

Solution 3

The justification:

• A group of their own, even for three outside people. They are added to and removed from the group, and the policy is not touched.
• An expiry on every binding. Access disappears by itself on the 16th. This is the canonical use of conditions and it avoids the classic "the consultant still has access two years later".
• roles/iam.securityReviewer allows reading the IAM policies without being able to modify them: exactly what an audit needs.
• roles/compute.networkViewer instead of roles/compute.viewer: they see the network, the firewall rules and the load balancer, but not the instance metadata, which can contain sensitive information.
• No role over data. No cloudsql.viewer, no storage.objectViewer, no bigquery.dataViewer: they can audit the database's configuration without reading a single customer row. If they needed to see data, the data protection officer would have to be involved and anonymised data would probably be enough.
• No access to alpinashop-dev or alpinashop-datos, unless the audit's scope requires it in writing.
• In addition, check in 07-07 that data access audit logs are enabled during the period, so that there is a record of what the consultancy queried.

IAM has stopped being the place you go to "give permissions" and has become the design that holds up everything else. You have internalised the equation identity + role + resource = allow policy, with its three properties: everything is denied by default, the policy is attached to the resource, and permissions are inherited downwards and cannot be subtracted. You tell permission, role, binding and policy apart, and you know how to translate a PERMISSION_DENIED into the role that resolves it with gcloud iam roles list --filter="includedPermissions:...".

You know the types of identity — users, groups, service accounts and the two federations, Workforce for people and Workload for machines — and you have adopted the rule that most simplifies long-term operation: roles are granted to groups and people move between groups. You know why Owner, Editor and Viewer are an anti-pattern (they grow by themselves, they allow escalation, they ruin auditing) and you have built AlpinaShop's real design: gcp-infra@, gcp-desarrollo@, gcp-datos@, gcp-facturacion@ and gcp-seguridad@ with different roles in each of the four projects, with nobody being owner of production. You have created the analistaCatalogo custom role for Lucía in versioned YAML, with the bigquery.jobs.create permission that almost everybody forgets.

You have understood the dual nature of service accounts — identity and resource at the same time — the rule of one per workload, and why the default Compute Engine account must never be used. You know how to impersonate accounts with --impersonate-service-account to obtain credentials that expire in an hour and leave a trail, and you have the ordered list of alternatives to the downloaded JSON key, which is the worst credential in existence: it does not expire, it has no second factor and it ends up in Git. You have limited access in time and by resource prefix with CEL conditions, finally resolving Lucía's restriction to exportaciones/ that was left pending in 02-02. And you have the four diagnostic tools: policy-troubleshoot for "why can't they", get-iam-policy for the snapshot, asset search-all-iam-policies for sweeping the whole organization before an offboarding, and the Recommender for trimming what nobody uses.

Finally, IAP has closed the circle between network and identity: the fw-allow-ssh-iap rule from 03-01 opens the door to the 35.235.240.0/20 range, and roles/iap.tunnelResourceAccessor decides who walks through it; and Lucía's reporting dashboard can be published on the internet with no VPN because IAP requires a corporate identity and a second factor before the request reaches the backend.

But IAM protects against whoever has an identity. It says nothing about the anonymous visitor crawling the catalogue at a thousand requests per second to copy the prices, nor about the one trying ten thousand passwords against the sign-in form, nor about the one injecting ' OR 1=1-- into the search box. That traffic reaches the load balancer with no identity at all and has to be filtered before, at the edge. In the next lesson, 03-05, Cloud Armor, we put an application firewall in front of the global load balancer: rules by IP and geography, protection against the OWASP Top 10, rate limiting against brute force, the indispensable preview mode so you do not block your own customers, and the pol-catalogo-web policy applied to bs-catalogo-web just in time for the autumn campaign.