IAM gets you to the cluster; RBAC limits what you can do inside it

Google identities authenticate through GKE. Kubernetes subjects such as users and groups then match RoleBindings or ClusterRoleBindings for API verbs and resources.

Layer	Question	Shopwave pattern
Cloud IAM	May this principal obtain cluster credentials or use GKE APIs?	Platform group receives the minimum container roles
Kubernetes RBAC	May this subject get, list, patch or delete this resource?	Team groups bind to namespace Roles
Workload IAM	May this Pod call a Google Cloud API?	Kubernetes ServiceAccount principal gets one narrow IAM role
Audit	Who attempted the action and what decided it?	Cloud Audit Logs plus Kubernetes audit evidence

Use groups for humans, service accounts for automation, and never solve a namespace problem with cluster-admin.

IAM and RBAC is easiest to understand by separating the Kubernetes contract from the Google Cloud implementation. IAM controls Google Cloud resources and access to GKE operations, while Kubernetes RBAC controls verbs on Kubernetes resources. GKE represents Google user identities and supported groups as Kubernetes subjects. The Kubernetes objects stay familiar, but GKE supplies controllers, infrastructure and safe defaults around them. This is why a team can move from an on-premises cluster without rewriting every workload, while still needing to redesign networking, identity and operational ownership for the cloud environment.

A useful inspection step is `kubectl auth can-i create deployments -n checkout --as=user@example.com`. Read the output as evidence, not as a ritual: first confirm the desired object exists, then look at status conditions, events and the Google Cloud resource it represents. In production, capture the expected result in a runbook or automated check so an operator can distinguish slow reconciliation from a configuration error.

Production gotcha: A broad IAM role and a broad ClusterRoleBinding compound each other; review both sides when investigating privilege. The safe habit is to verify quotas, regional availability and feature support against current Google Cloud documentation before rollout. Node and image trust form the next layer.