The big picture

In the cloud, almost every identity is a machine. It may be a running app, a nightly build or a service in a service mesh. Each one now has an identity that is short-lived and can be checked. None holds a password to steal.

The story you just lived

Kai's app started and tried to read one file. The cloud asked: who are you, and what may you do? That is cloud identity 101: principals, roles and policies. Assuming a role gives temporary credentials, not a permanent key.

Priya deleted the long-lived key from her pipeline. Workload identity federation let the build prove itself with a signed token. It got one-hour credentials back.

Services in one system got SPIFFE identities and SVIDs. Both ends check each other in mutual TLS.

A few stubborn secrets stayed. Secrets management and rotation covers them. Keep them in a secrets manager. Prefer dynamic secrets. Rotate with an overlap window.

Across accounts and clouds, one account trusts exactly one named principal from the other. A condition shuts out the confused deputy. That is cross-account and cross-cloud trust.

Under all of it ran least privilege for machines. Bot A held only the verb and noun its job needed, not admin:*.

Last came Kubernetes identity. Every pod runs as a ServiceAccount with a bound token that dies with the pod. RBAC bindings, kept to one namespace, decide what it may do. Reading Secrets or creating pods can be admin in disguise.

Back to the three machines

The delivery robot got its own named pass, and the gate checks it every time. The midnight payroll script fetches its password from a vault, and the password changes often. The build pipeline shows a signed token and gets a pass for one hour. All three hold only the power their job needs. A leaked copy of any of them is worth little.

The threads that tie it together

Where these ideas go next

See the non-human identity big picture, agent registries and identity across microservices.

Ready to prove it? The cheat sheet & pop quiz is your next stop.