Appendix B

IAM Role Reference

Scope. Every predefined IAM role this book grants, grouped by function, with the sections that grant it, plus a catalog of recommended custom roles. It is an index into the book, not a survey of the role catalog. Prerequisites. Chapter 3 for the IAM model, role types, and custom role mechanics. Verified against. Google Cloud console and API surface as of 2026-09, Cloud SDK 583.0.0; every role ID verified against the predefined role reference and every custom-role permission against its service reference page; see sources at end.

Google publishes over nineteen hundred predefined roles. This book grants 131 of them, and those are what follows — each with a short statement of what it grants and the sections that use it, so a role encountered in a policy can be traced back to the chapter that explains why it is there. Roles absent from this appendix are absent from the book; that is not a judgment about them.

Every identifier here is verified against the role reference. §3.9 owns predefined roles as a concept, §3.12 owns custom roles, and §3.11 owns the least-privilege method these tables serve — this appendix repeats none of it.

B.1 Administrative Roles §

Roles that administer the hierarchy itself — the organization node, folders, projects, billing, and IAM policy. These are the grants that create and destroy the structures every other role operates inside, so they belong to named groups at the organization and never to a workload identity.

The basic roles are the exception this section has to name and not use. §3.10 covers all six — the legacy trio and the three newer ones whose launch stage it records — and the reason none of them is granted anywhere in this book. They are omitted from the table below because the table is a list of grants and they are never granted; §33.4 carries the query that finds them in an existing estate.

B.2 Security Roles §

Roles for the security estate: key management, secrets, data protection, and Security Command Center. The split that matters throughout is between administering a key or secret and using one — an application needs the use half and never the administration half.

Note that roles/secretmanager.secretVersionManager rotates versions without secretmanager.versions.access, so rotation automation never needs to read the payload it replaces.

B.3 Network Roles §

Network roles are the smallest group in this appendix, and that is a finding rather than an omission: most of the book's network control surface is organization policy (Appendix C), firewall policy, and VPC Service Controls, almost none of which is granted through a network IAM role.

The one grant that appears constantly is roles/compute.networkUser, which is how a service project consumes a Shared VPC subnet (§5.27). Scope it to the specific subnetwork, never to the host project.

B.4 Compute Roles §

Compute Engine, Cloud Run, and Cloud Storage — the roles attached to workloads and to the people who operate them. The recurring hazard is the administrative form of each: roles/compute.admin, roles/run.admin, and roles/storage.admin each carry setIamPolicy for their surface, so granting one to an operator hands them the ability to widen their own access.

roles/storage.legacyBucketOwner predates uniform bucket-level access and appears here because §11.9 treats it as something to find and remove, not something to grant.

B.5 GKE Roles §

GKE roles divide along the boundary between the cluster as a Google Cloud resource and the objects inside it. roles/container.clusterViewer is enough to obtain credentials; what happens after that is decided by Kubernetes RBAC (§9.13). Granting roles/container.admin to reach the Kubernetes API is the common over-grant, and roles/container.developer is usually what was meant.

roles/stackdriver.resourceMetadata.writer keeps a legacy product name in its identifier; the product is Cloud Monitoring, and the role belongs to the node service account set (§9.31).

B.6 Database Roles §

Database roles separate instance administration from data access, and both from the connection itself. For Cloud SQL the connection grant is roles/cloudsql.client and IAM database authentication adds roles/cloudsql.instanceUser (§12.7); neither implies the ability to read a backup or change a flag.

An application should hold the client and user roles and nothing else. roles/cloudsql.admin includes deletion of the instance.

B.7 Logging Roles §

Logging, monitoring, and the transport between them. The distinction the estate depends on is roles/logging.viewer against roles/logging.privateLogViewer: the first excludes Data Access log entries, which is what makes it safe to grant broadly, and the second includes them (§17.2).

roles/logging.logWriter and roles/monitoring.metricWriter are workload grants that belong on service accounts, including the GKE node service account (§9.31), not on people.

B.8 CI/CD Roles §

Registry, build, deploy, and the impersonation roles that let a pipeline act without a key. roles/iam.workloadIdentityUser is what a federated external identity holds (§4.3); roles/iam.serviceAccountTokenCreator mints tokens for an already-authenticated principal; roles/iam.serviceAccountUser only attaches an account to a resource. They are routinely confused and grant different things.

roles/iam.serviceAccountKeyAdmin appears because the estate forbids the keys it manages — constraints/iam.managed.disableServiceAccountKeyCreation makes it inert (§31.4), and it is listed so the grant is recognized when found.

B.9 Recommended Custom Roles §

§3.12 owns the custom role model — the per-organization cap, the fact that custom roles can be created at an organization or a project but not at a folder, permission support levels, and the maintenance burden that makes a custom role a liability as well as a control. This section is the catalog only.

The convention is fixed: custom role IDs are rc.<domain><Action>, defined at the organization so one definition serves every project (§2.10). Each role below exists because the narrowest predefined alternative grants something the task does not need — usually deletion, usually setIamPolicy. The permission counts are given rather than the full lists; the lists are recorded in this unit's research notes with the reference page each permission was verified against.

Where the gap is widest, and why these are worth the maintenance:

• rc.kmsKeyDestroyer — roles/cloudkms.admin is create, destroy, and set-IAM-policy in one grant. Destruction is the least reversible action in the estate and belongs behind Privileged Access Manager (§3.27).
• rc.computeInstanceOperator — The on-call grant. roles/compute.instanceAdmin.v1 adds creation and deletion (§3.36).
• rc.buildTriggerRunner — roles/cloudbuild.builds.editor lets the runner rewrite the steps it is about to execute.
• rc.evidenceCollector — An auditor needs breadth without any write. No predefined role spans asset, SCC, and org policy read (§29.2).
• rc.firewallAuditor — roles/compute.networkViewer omits firewall policy resources, which is the object of the audit (§33.9).

rc.deployReleaser (§3.12) is defined in Chapter 3 as the worked example and is not repeated here. A proposed rc.secretRotator was rejected during this appendix's preparation: roles/secretmanager.secretVersionManager already adds, disables, destroys, and rotates versions without granting secretmanager.versions.access, so the custom role would have carried no privilege the predefined one lacks.

Pitfall. A custom role is not automatically narrower than a predefined one. Copying a predefined role and editing it — the console's default offer — usually produces a role with the same breadth and none of the maintenance Google performs when a service adds permissions (§3.12).

Sources §

• https://cloud.google.com/iam/docs/roles-overview (last validated 2026-09-04)
• https://cloud.google.com/iam/docs/roles-permissions (last validated 2026-09-04)