Users, Services & Workloads
Humans aren't the only principals. Services and workloads need identity too.
By the end of this lesson, choose the right identity model for humans, services, and dynamic workloads.
Three kinds of principals dominate enterprise systems: users (humans, interactive, few, long-lived), services (long-running processes with static identities), and workloads (ephemeral instances — pods, functions, jobs — created and destroyed constantly). Each needs identity, but the credential lifecycle is completely different.
Different lifecycles, different credentials
- Users authenticate with passkeys/MFA and hold sessions.
- Services use managed, rotated keys.
- Workloads receive short-lived tokens issued by the platform at runtime.
flowchart TB user["User: passkey/MFA, session"] service["Service: managed key, rotated"] workload["Workload: short-lived token from platform"]
This is where the abstraction starts leaking.
The 'service account with a password in a config file' is the most common non-human identity anti-pattern. Machine identities now vastly outnumber human ones, and they rarely have MFA, rotation, or offboarding. Attackers know this.
You know what happens. Now see why it works.
Treating a workload like a user (static long-lived credential) means a leaked pod secret is valid forever. Workload identity (SPIFFE, cloud IAM roles) issues short-lived, automatically-rotated credentials tied to the workload's platform-attested identity, so a leak expires in minutes.
Orphaned service account
- Trigger
- A service account outlives the service, team, or project that created it.
- Symptom
- A high-privilege credential nobody owns, monitors, or rotates.
- Blast radius
- Whatever the account can access — often broad, because service accounts are over-permissioned.
- Mitigation
- Inventory non-human identities; short-live and attest workload credentials; tie accounts to owners.
Deep dive: Privilege Escalation
Why is a static secret worse for a Kubernetes pod than for a human?
Pods are created and destroyed constantly and at scale, so static secrets sprawl and can't be rotated per-instance; a leaked one is valid indefinitely. Workload identity issues short-lived, per-instance credentials instead.