The Identity Stack, Episode 13
EP12: Entra ID + Linux → EP13
TL;DR
- Zero Trust means “never trust, always verify” — identity is verified continuously, not just at login time; network location provides no implicit trust
- Human identity (users) and workload identity (services, pods, jobs) are separate problems — LDAP/Kerberos/OIDC solve the human side; SPIFFE/SPIRE solve the workload side
- SPIFFE (Secure Production Identity Framework For Everyone) defines a standard for workload identity — a SPIFFE ID is a URI like
spiffe://corp.com/ns/prod/sa/payments-svc - SPIRE (SPIFFE Runtime Environment) issues short-lived X.509 SVIDs (SPIFFE Verifiable Identity Documents) to workloads — certificates that rotate automatically, every hour
- mTLS (mutual TLS) is how workloads prove identity to each other — both sides present certificates; no passwords, no API keys
- The evolution:
/etc/passwd(1970) → NIS → LDAP → Kerberos → SAML → OIDC → SPIFFE/SPIRE — the problem has always been the same; the trust boundary keeps moving outward
The Big Picture: From /etc/passwd to Zero Trust
1970s /etc/passwd ← trust: the local machine
One machine, one user list
1984 NIS / Yellow Pages ← trust: the local network
Centralized, but cleartext, flat
1993 LDAP ← trust: the directory server
Hierarchical, scalable, encrypted (eventually)
1988 Kerberos ← trust: the KDC
Tickets instead of passwords, network-wide
2002 SAML ← trust: the IdP assertion
Identity crosses the internet
2014 OIDC / OAuth2 ← trust: the JWT signature
API-native, mobile-native, developer-native
2017 SPIFFE / SPIRE ← trust: the workload certificate
Automated identity for services, not humans
2026 Zero Trust ← trust: nothing, verify everything
Continuous verification, short-lived credentials,
device posture, behavioral signals
EP01 of this series started with the chaos of per-machine /etc/passwd. This episode — EP13 — closes the loop: from that chaos to a model where identity is verified continuously, credentials expire in hours not years, and the network provides no implicit trust.
The Assumption That Zero Trust Rejects
Traditional security assumed: if you’re on the internal network, you’re trusted. A VPN user was treated as equivalent to someone at a desk in the office. A service running on the same Kubernetes node as another service was implicitly trusted.
That assumption broke in practice:
- Compromised VPN credentials gave attackers full internal access
- Lateral movement after initial compromise was easy — once inside, everything trusted you
- Perimeter-based security had no visibility into east-west traffic (service-to-service)
Zero Trust inverts the model: the network provides no trust. Every access request is verified — user or service, internal or external, first request or hundredth. Trust is dynamic, contextual, and short-lived.
Human Zero Trust: Continuous Verification
For human users, Zero Trust extends OIDC and Conditional Access:
Short-lived tokens. Access tokens expire in 1 hour (OIDC standard). Refresh tokens are revocable. A user who is terminated can have their refresh tokens revoked in Entra ID — the next time their app tries to use the refresh token, it fails. The maximum blast radius of a stolen token is bounded by its lifetime.
Device posture. The device the user authenticates from is part of the identity assertion. Conditional Access can require: device is managed (Intune-enrolled), device is compliant (no malware, full-disk encryption enabled, OS patched). A valid user credential from an unmanaged device is denied.
Behavioral signals. Entra ID Identity Protection and similar systems analyze login patterns — unusual location, impossible travel (login from Mumbai, then New York 5 minutes later), unfamiliar device. High-risk sign-ins trigger step-up authentication or are blocked automatically.
Privileged Access Management (PAM). For privileged operations (production shell access, AD admin), Zero Trust adds time-bounded just-in-time access:
Request: "I need admin access to db01.corp.com for 2 hours to investigate an incident"
Approval: Manager approves via Slack/email/ticketing system
Grant: Temporary role assignment or password checkout from the PAM vault
Access: User SSHes with a one-time or time-limited credential
Expire: Credential automatically revoked after 2 hours
Audit: Full session recording available for review
CyberArk, BeyondTrust, and HashiCorp Vault implement this model. Vault’s SSH Secrets Engine issues short-lived SSH certificates:
# Request a signed SSH certificate (valid 30 minutes)
vault ssh \
-role=prod-admin \
-mode=ca \
-mount-point=ssh-client-signer \
[email protected]
# Vault issues a certificate signed by the server's trusted CA
# sshd on db01 trusts that CA — no authorized_keys needed
# Certificate expires in 30 minutes — no cleanup required
Workload Identity: The Non-Human Problem
Services don’t have passwords they can type. A microservice calling another microservice needs to prove its identity — but you can’t give a Kubernetes pod a static API key (it’ll be in a config file, in a git repo, or in a crash dump within 6 months).
Workload identity solves this with short-lived, automatically rotated certificates — the service’s identity is its certificate, issued by a trusted CA, expiring in minutes to hours.
Traditional: Zero Trust:
payments-svc → orders-svc payments-svc → orders-svc
Authentication: API key Authentication: mTLS (X.509 cert)
"Bearer sk_live_abc123" cert: spiffe://corp.com/ns/prod/sa/payments-svc
Rotation: manual (rarely done) Rotation: automatic, every hour
Revocation: change the key Revocation: cert expires; new cert issued
Audit: "API key was used" Audit: "spiffe://payments-svc → spiffe://orders-svc"
SPIFFE: The Standard
SPIFFE (Secure Production Identity Framework For Everyone) defines what a workload identity looks like. The core concept is the SPIFFE ID — a URI in the format:
spiffe://<trust-domain>/<workload-path>
Examples:
spiffe://corp.com/ns/prod/sa/payments-svc
spiffe://corp.com/region/us-east/service/auth-api
spiffe://corp.com/k8s/cluster-prod/namespace/payments/pod/payments-svc-abc123
The trust domain (corp.com) is the organizational boundary. The path is the workload identifier — typically encoding namespace, service account, or cluster information.
A SPIFFE ID is embedded in an SVID (SPIFFE Verifiable Identity Document) — either an X.509 certificate (X.509-SVID) or a JWT (JWT-SVID). The X.509-SVID is the standard form: the SPIFFE ID appears in the certificate’s Subject Alternative Name (SAN) field.
X.509 Certificate (SVID):
Subject: CN=payments-svc
SAN: URI=spiffe://corp.com/ns/prod/sa/payments-svc
Validity: 1 hour
Issuer: SPIRE Intermediate CA
Signed by: corp.com trust bundle
Any service that has the corp.com trust bundle (the CA certificate chain) can verify that a certificate with spiffe://corp.com/... in the SAN was issued by the authorized CA for that trust domain.
SPIRE: The Runtime
SPIRE (SPIFFE Runtime Environment) is the reference implementation that issues SVIDs to workloads.
SPIRE Server
├── Node attestation: verifies the identity of the node/VM
│ (AWS instance identity document, GCP service account, k8s node SA)
└── Workload attestation: verifies the identity of the process
(Kubernetes SA, Unix UID/GID, Docker container labels)
│
│ issues X.509 SVIDs (short-lived, auto-rotated)
▼
SPIRE Agent (runs on every node)
│
│ SPIFFE Workload API (Unix socket)
▼
Workload (your service)
→ gets its own certificate
→ gets the trust bundle (CA certs of trusted domains)
→ uses cert for mTLS with other services
The workload fetches its identity via the Workload API socket — no environment variables, no file mounts. The SPIRE Agent pushes new certificates before the old ones expire. Rotation is transparent to the workload.
# On a node with SPIRE Agent running:
# Fetch the SVID for the current workload
spire-agent api fetch x509 \
-socketPath /run/spire/sockets/agent.sock
# Output shows:
# SPIFFE ID: spiffe://corp.com/ns/prod/sa/payments-svc
# Certificate: (PEM)
# Trust bundle: (PEM of issuing CA chain)
# Expires: 2026-04-27T02:00:00Z (1 hour from now)
mTLS: Both Sides Show ID
Mutual TLS (mTLS) is what makes SPIFFE useful operationally. In standard TLS, only the server presents a certificate — the client just verifies it. In mTLS, both sides present certificates. Both sides verify the other’s certificate against the trust bundle.
payments-svc → orders-svc connection:
TLS handshake:
payments-svc presents: spiffe://corp.com/ns/prod/sa/payments-svc cert
orders-svc presents: spiffe://corp.com/ns/prod/sa/orders-svc cert
Both verify:
• cert signed by trusted CA (the corp.com SPIRE CA)
• cert not expired
• SPIFFE ID in SAN matches what's expected
After handshake: encrypted channel, both sides verified
Authorization: orders-svc checks its policy:
"is spiffe://corp.com/ns/prod/sa/payments-svc allowed to call /api/orders?"
Service meshes (Istio, Linkerd, Consul Connect) implement mTLS transparently — the application doesn’t handle certificates; the sidecar proxy does. In Istio’s case, Citadel (now istiod) acts as the SPIFFE-compatible CA, issuing certificates to envoy sidecars. The application code doesn’t change.
Open Policy Agent: Authorization After Identity
Zero Trust separates identity from authorization. Once you know who the caller is (SPIFFE ID, OIDC token, user cert), a policy engine decides what they can do.
OPA (Open Policy Agent) is the standard for this:
# opa-policy.rego
package authz
# payments-svc can read orders; nothing else can write orders
allow {
input.caller == "spiffe://corp.com/ns/prod/sa/payments-svc"
input.method == "GET"
startswith(input.path, "/api/orders")
}
default allow = false
The service checks OPA on each request: “caller=X wants to do Y to Z — allowed?” OPA evaluates the policy and returns a decision. The policy is version-controlled, tested, and deployed independently of the service.
⚠ Common Misconceptions
“Zero Trust means no trust.” Zero Trust means trust is earned dynamically through verification, not granted by network location. A verified user with a valid, compliant device and MFA is trusted — for the scope and duration of the verified session. The “zero” refers to implicit trust, not trust itself.
“SPIFFE replaces OIDC.” SPIFFE is for workload (service) identity. OIDC is for human (user) identity. They complement each other — a service has a SPIFFE identity; a user has an OIDC identity; the authorization layer accepts both.
“mTLS is complex to implement.” With a service mesh (Istio, Linkerd), mTLS is transparent — the sidecar handles it. Without a service mesh, the application needs to use the SPIFFE Workload API. The complexity is real but manageable, especially compared to the alternative of static API keys.
Framework Alignment
| Domain | Relevance |
|---|---|
| CISSP Domain 5: Identity and Access Management | Zero Trust extends IAM to workloads (SPIFFE) and continuous verification (short-lived tokens, device posture) — it’s the current frontier of identity architecture |
| CISSP Domain 3: Security Architecture and Engineering | The separation of identity (SPIFFE ID), authentication (mTLS), and authorization (OPA) is a clean architectural decomposition that scales to complex multi-service environments |
| CISSP Domain 4: Communications and Network Security | mTLS encrypts and authenticates every service-to-service connection — it eliminates the assumption that east-west traffic on the internal network is safe |
| CISSP Domain 1: Security and Risk Management | Zero Trust is a risk management posture — it accepts that perimeter breach is inevitable and limits blast radius through continuous verification and least-privilege |
Key Takeaways
- Zero Trust rejects network-based implicit trust — every request is verified regardless of source
- Human identity: short-lived OIDC tokens, device posture checks, Conditional Access, JIT privileged access (Vault, CyberArk)
- Workload identity: SPIFFE IDs in X.509 certificates, issued by SPIRE, rotated automatically every hour — no static API keys
- mTLS lets services verify each other’s identity at the TLS layer — service meshes (Istio, Linkerd) implement it transparently
- OPA handles authorization after identity is established — who you are ≠ what you can do
- The series arc:
/etc/passwd→ NIS → LDAP → Kerberos → SAML → OIDC → SPIFFE/SPIRE — the problem has always been “how do you know who someone is, at scale, without trusting the network?” The answer keeps getting better.
What does identity look like at your organization — still static API keys and shared service accounts, or moving toward SPIFFE and short-lived credentials? 👇
The Identity Stack: From LDAP to Zero Trust — 13 episodes complete.
