Give every workload a short-lived identity

Security starts by removing service-account keys, then layers node integrity, admission, secret delivery, sandboxing and policy evidence.

How does a Pod authenticate?

Workload Identity Federation exchanges a Kubernetes token for a short-lived Google credential.

Who may call the API?

IAM authenticates; Kubernetes RBAC authorizes Kubernetes verbs.

What may run?

Binary Authorization and policy can reject untrusted deployments.

How far can compromise spread?

Shielded nodes, Sandbox and least privilege reduce the blast radius.

Give every workload a short-lived identity

Security orientation is easiest to understand by separating the Kubernetes contract from the Google Cloud implementation. GKE security combines Google Cloud IAM with Kubernetes identities and controls. The most important baseline is avoiding long-lived keys inside Pods. 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 get serviceaccount -A`. 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: Identity, authorization and network reachability are separate layers; passing one does not imply the others. The safe habit is to verify quotas, regional availability and feature support against current Google Cloud documentation before rollout. The credential flow comes first.