IAM & Workload Identity

Workload Identity lets Kubernetes workloads act as Google service accounts without exported keys. zop.dev provisions the service accounts, custom roles, and bindings that give clusters and workloads exactly the access they need.

Cluster accounts, custom roles, namespace identities

Five cluster service accounts with keys (cloud_monitoring, cluster_autoscaler, karpenter, sql_proxy, wildcard_dns_solver), three custom IAM roles, about 16 IAM bindings, seven project-level role grants at bootstrap, and per-namespace Workload Identity service accounts.

Access tiers and per-workload Pub/Sub accounts

user_access admins/editors/viewers; artifact_users; per-workload pubsub_editor accounts.

The iam type covers accounts and role grants

The provisioner API exposes an iam resource type covering service accounts and role grants.

Two identity models, one cluster

Application workloads get the modern model: per-namespace Workload Identity service accounts, where a pod proves who it is through the cluster’s OIDC trust and no key ever exists to steal, expire, or rotate. The platform’s own components still carry exported keys: the 5 cluster service accounts for cloud_monitoring, cluster_autoscaler, karpenter, sql_proxy, and wildcard_dns_solver. Those 5 keys are the static credentials in the design: they belong in the rotation inventory, and they are the honest answer to “is everything here keyless?”. Everything application-facing is; five platform components are not.

Custom roles instead of primitive ones

The 3 custom IAM roles exist because Google’s primitive roles (editor, viewer) grant far more than any component needs. A custom role names the exact permissions a component uses, which does two things: it shrinks what a compromised credential is worth, and it documents intent. The role definition is a readable statement of what the autoscaler or the DNS solver is supposed to touch. The roughly 16 bindings wire those roles to their accounts at the right scopes.

The bootstrap grants set the ceiling

The 7 project-level role grants made at bootstrap define what the platform itself may do in the project, and every later provision operates inside that ceiling. For an auditor, this is the right place to start: review those 7 grants and you have reviewed the platform’s maximum authority, before reading anything else.

IAM costs nothing and gates everything

None of this bills a cent. Accounts, roles, and bindings are all free, at any quantity. The absence of cost pressure is exactly why identity sprawl happens; the per-namespace scoping and named custom roles are the structure that keeps “free” from becoming “unaccountable.”