Here is a problem you probably have and have not named. Your job runs on a managed service. The cloud gives it an IAM role. Your internal services want something else: a certificate or token your own systems issued. So someone pastes a long-lived credential into the job config, and it stays there for years.
Netflix described how it solved this for Spark on Amazon EMR using workload attestation. A job proves which AWS role it holds with a pre-signed STS request, a control plane vouches for which job it is with a signed claim, and an identity service issues a short-lived internal certificate only if both agree. You do not need Netflix's size to copy it. You need a signing key, a small exchange service and the will to stop handing out static secrets.
How does Netflix's workload attestation work?
The design is laid out in a Netflix Tech Blog post by Dhruv Pratap, published on 25 September 2026, and covered by InfoQ on 21 October.
Netflix's internal identity system is Metatron, a private PKI that issues short-lived X.509 certificates for mutual TLS. Spark jobs on EMR start with only an AWS execution role, but they need a Metatron identity to read encrypted columns, check table ACLs and hold long interactive sessions.
Jobs run as a Data Project, Netflix's unit of data ownership, and each Data Project maps one to one to a dedicated IAM role. With tens of thousands of projects expected, those roles are spread deterministically across a pool of AWS accounts.
The flow has three steps:
The control plane, the only service allowed to launch Spark jobs, validates the request, resolves the IAM role and signs a payload naming the application identity, role and environment. The payload travels in the job config.
A Spark plugin in the driver uses the execution role to sign, but not send, an
sts:GetCallerIdentityrequest. It sends that pre-signed request and the signed payload to the identity service.The identity service sends the pre-signed request to STS to learn which role signed it, checks the control plane's signature and confirms the two match. Then it issues the certificate.
Neither claim is trusted alone. The payload can be copied and replayed. The STS answer says nothing about which job is running. Together they are hard to fake.
Which parts can a smaller team copy?
Most of it. The STS trick is not new. HashiCorp Vault's AWS IAM auth method has used signed GetCallerIdentity requests for years, so if you run Vault you already have half of this. SPIFFE and SPIRE give you a standard identity format and attestors for the major clouds. What Netflix adds is the second claim from its own platform.
That second claim is the part worth stealing. A role tells you where code runs. It does not reliably tell you which workload it is. Netflix deliberately avoided deriving identity from role or session names, which the team considered fragile. If your scheduler, CI system or job launcher signs a small statement about what it launched, you bind identity to intent instead of guessing from naming conventions.
Keep the signer scarce. Netflix lets exactly one service hold that signing key. If five systems can sign claims, you have five things to audit and you will forget about at least one.
Do you need short-lived certificates?
Yes. The design works because nothing it issues lives long. Netflix does not publish its certificate lifetimes, but the driver re-attests on a timer well before expiry, and executors that outlive their credentials are replaced rather than renewed. Certificates sit in a temporary directory only the process owner can read and are deleted on exit.
Pratap's point is that attestation must be something you can repeat, not a one-time bootstrap. Plenty of teams get this wrong. They build a clever first-boot identity flow, then let the result live for a year.
Where it gets expensive
Fan-out. A Spark job can run many executors. If each one attests, you get a burst of STS calls and identity service requests, and rate limits get in the way. Netflix has the driver attest once and pass credentials to executors over Spark's authenticated, AES-GCM encrypted RPC.
That keeps load flat, but the driver becomes a second trust boundary holding credentials for everyone. The post says little about how that boundary is hardened beyond the RPC protections. At smaller scale you may prefer per-process attestation and accept the extra calls. Decide on purpose.
The design also leans on things you may not have, such as Spark 3's plugin interface as a hook. Netflix's advice is to hook the layer you still control, the runtime, plugin or entrypoint, rather than the host.
Where to start
Pick one workload that carries a static credential to an internal service. Give it a dedicated role. Have whatever launches it sign a claim. Put a small exchange service in front of your CA or token issuer that checks both. Make the output expire in hours.
Then do the next one. After a month in which long-lived keys leaked from LiteLLM, Railway and OpenCode, every static secret you retire is one fewer to rotate at 2am.
Quick answers
What is workload attestation?
It is a way for a running workload to prove what it is before receiving credentials. Netflix checks an AWS-verified role and a signed control plane claim, then issues a short-lived certificate.
How does Netflix verify a Spark job's AWS identity?
The Spark driver signs, but does not send, an sts:GetCallerIdentity request. Netflix's identity service sends it to AWS STS and reads which IAM role signed it.
Can smaller teams copy Netflix's approach?
Yes. Use a dedicated role per workload, have your launcher sign a claim, check both in a small exchange service and issue credentials that expire in hours.
