Workload Identity and Mutual TLS
By Richard Augenti
Give each service a cryptographic identity, enforce mTLS between them, and confirm that an unidentified workload on the same network is refused rather than trusted.
Free to browse. Takes about 60 minutes once you start.
Lab Overview
The payments platform's internal API trusts anyone who presents a shared bearer token. That token is the same for every caller, it gets passed around in config, and it has leaked to a rogue workload with no business calling the API at all.
In this lab you call the API as the rogue workload to prove the problem, then replace the shared token with mutual TLS based on SPIFFE workload identity - so each workload proves who it is with a certificate, and the rogue one is refused rather than trusted. A shared secret authenticates the secret; mTLS authenticates the workload.
The certificates are X.509 SVIDs, exactly the form SPIFFE and SPIRE issue to workloads, with the identity carried in the certificate's URI SAN. Everything is pure Python and runs locally on your lab machine.
What to Expect
- Environment: a single Ubuntu machine you connect to over SSH, with the API, the workloads and all certificates already in place. No cluster required.
- Access: SSH credentials are generated for your session and shown in the workspace. They are destroyed when the lab ends.
- Self-contained: certificates are issued locally for the lab. No external identity provider or certificate authority is contacted.
- Progress: your work is not saved. If the lab expires or you quit, the machine and everything on it is destroyed.
What are hands-on labs?
A lab is a real environment, not a simulation. You get a live machine with the tooling already installed, a task taken from production work, and root access to take it apart. Nothing is mocked, nothing is multiple choice. It either works or it doesn't.
Real tooling
The same commands you would run at work, on a machine that is already set up for them. No screenshots, no sandboxed toy version.
Break it freely
Everything is disposable. When the clock runs out the environment is destroyed with everything in it, so there is no reason to be careful.
Useful on Monday
Built by engineers who run these systems in production. Skills you can apply to your own stack the same week, not exam preparation.