Lion Cipher Lab

Give your services cryptographic identities with SPIFFE and SPIRE (workload identity, no shared secrets)

• Identity & Access Management
• Advanced
• ~60-75 min
• Free · no account required

Why it matters

Think about how one piece of software proves who it is to another today. A billing service that needs to call the payments API, a batch job that reads from the database, a microservice that talks to five other microservices -- overwhelmingly they authenticate with a LONG-LIVED SHARED SECRET: an API key, a password, or a token that a human generated once and pasted into a config file, an environment variable, a Kubernetes Secret, or a CI/CD variable. That model is quietly broken. The secret is long-lived, so it is worth stealing; it is copied into many places, so it leaks (into git history,…

What you'll learn

• what WORKLOAD IDENTITY is and why services authenticating to each other with long-lived shared secrets (API keys, passwords baked into config) is the problem it solves
• the SPIFFE model in plain terms: the SPIFFE ID (a spiffe:// URI naming a workload), the SVID (the signed identity document that proves it -- an X.509 cert or a JWT), the trust domain, and the Workload API
• how SPIRE implements it: a SPIRE Server acting as the certificate authority holding registration entries, and SPIRE Agents on each node doing node attestation then workload attestation
• running SPIRE for real and free on your own machine: start the server, generate a join token, attest the agent, and watch the trust get bootstrapped
• creating a registration entry that binds a SPIFFE ID to a workload SELECTOR (the current user's Unix UID) so only the right process can fetch that identity
• fetching an issued X.509 SVID with `spire-agent api fetch x509` and reading its short time-to-live off the certificate with openssl -- proving the identity is ephemeral and auto-rotated
• the judgment: WHEN workload identity is worth it (many services, zero-trust, mTLS everywhere) versus WHEN it is overkill (a single app), and WHY it beats hand-managed certs or a shared secret
• how SPIRE feeds mTLS and a service mesh (Istio, Envoy SDS) as the 'do it better' production path

Steps in this lab

1. The problem: services still authenticate with shared secrets
2. The idea: give each workload a cryptographic identity instead
3. The four SPIFFE words: SPIFFE ID, SVID, trust domain, Workload API
4. How SPIRE issues identity: server, agent, and two kinds of attestation
5. Get SPIRE onto your machine (free, local)
6. Start the SPIRE Server (your certificate authority)
7. Node attestation: generate a join token and start the agent
8. Bind an identity to a real process: create a registration entry
9. Fetch the SVID over the Workload API and see it appear
10. Read the SVID with openssl: prove it is short-lived
11. Judgment: when workload identity is worth it, and when it is overkill
12. Do it better: SPIRE into mTLS and a service mesh, then clean up

Open the full interactive lab →