Workload identity, not IP

Cryptographic identity that follows the workload.

The keystone of workload zero trust is giving every service a strong, verifiable identity that is independent of its network location. Once a workload can prove who it is, encryption and authorization can be based on that identity rather than on spoofable, ephemeral IPs.

Identity, not IP

In a dynamic cluster, IP addresses churn as pods reschedule and can be spoofed, so any policy pinned to IPs is both brittle and weak. A workload identity is a cryptographic credential — a certificate or token — that names the service itself, so it travels with the workload wherever it runs and is verified rather than assumed. This is the difference between "traffic from 10.1.2.3 is allowed" (fragile, spoofable) and "traffic proven to be from the payments API is allowed" (stable, verifiable). Everything else in zero trust — mTLS, authorization policy, federation — builds on this foundation.

# Instead of "I am at this IP", a workload proves "I am this service":
#
#   IP-based (fragile):   allow from 10.1.2.3/32        ← churns, spoofable
#   identity-based:       allow from spiffe://acme.internal/ns/prod/sa/payments
#
# The identity is carried in a short-lived certificate the workload presents;
# the verifier checks the signature, not the source address.

Why this unlocks everything

Strong workload identity is the enabler for the rest of the course. mTLS uses it so each side of a connection proves who it is. Authorization policy uses it to allow calls by "which service", surviving pod rescheduling because it matches identity not IP. Federation uses it to authenticate workloads across clusters and organizations. And short-lived, auto-rotated identity credentials mean a leaked one expires fast. The standard that defines this identity — SPIFFE — and the runtime that issues it — SPIRE — are the subject of the next section, and the meshes later in the course consume exactly this identity model.