Day 1: The Workload Identity Problem

Phase 4 · August 5, 2026

Agenda (2–3 hours)

• Read (45 min): SPIFFE overview doc (spiffe.io/docs/latest/spiffe-about/overview); SPIRE concepts page
• Think (45 min): Map your provisioning service's credential landscape
• Challenge (60 min): Write a credential inventory for your team's service

The Problem Static Credentials Create

A Lambda function needs to call ACM PCA to issue a cert.
How does it authenticate?

Option A: Static secret

• Store an API key or certificate in Secrets Manager
• Lambda retrieves it at startup
• Rotated manually (quarterly? never?)
• If extracted from memory, valid for months

Option B: IAM role

• Lambda assumes an IAM role automatically
• AWS STS handles rotation
• But: only works inside AWS; no portable identity for cross-cloud or peer-to-peer mTLS

Option C: Workload identity (SPIFFE)

• Short-lived X.509 cert issued based on what the process is
• Automatically rotated (hourly)
• Portable: works for mTLS, cross-cloud, service mesh

Why Static Certs Fail at Scale

The provisioning service you're building issues certs to devices.
But what credentials does it use to authenticate to the CA?

The Workload Identity Insight

Classical PKI answers: "Is this a valid cert signed by a trusted CA?"

Workload identity answers: "Is this the specific workload I expect, running in the
expected environment, with the expected authorization?"

The difference:

• Classical: certificate = machine identity (hostname, IP)
• SPIFFE: certificate = workload identity (service name, team, environment)

A SPIFFE ID looks like:

spiffe://example.org/ns/prod/sa/provisioning-service
          └──────────────────┬────────────────────────┘
                       URI-SAN in X.509 cert

This is the Subject Alternative Name in an ordinary X.509 cert — just with a spiffe:// URI instead of a DNS name.

Before SPIFFE: The Credential Bootstrapping Problem

To give a workload a cert, you need to prove who it is first.
But to prove who it is, it needs some credential.
This is the bootstrapping problem.

SPIRE solves it by delegating to attestation — using facts about the
runtime environment that an attacker can't easily forge:

• AWS: the Instance Identity Document (signed by AWS)
• Kubernetes: the Pod Service Account Token (signed by the API server)
• Hardware: a TPM attestation

These facts establish identity without a pre-shared secret.

Relevance to Your Provisioning Service

Your service (Amazon Leo Secure Comms provisioning):

• Issues X.509 device certs for satellite terminals
• Runs as a Lambda function (or coordinating service)
• Calls ACM PCA or internal CA as a downstream dependency
• Currently authenticates to downstream services via IAM role (inside AWS)

SPIFFE's value here:

• If your service ever needs to do mTLS with peer services (not just AWS APIs), SPIFFE gives each peer a portable, rotatable identity
• Short-lived SVIDs shrink the HNDL window vs. long-lived static certs
• When PQC certs arrive, SPIRE's CA is one place to upgrade for all workloads at once

Challenge Assignment

Write a credential inventory for your provisioning service:

Fill in the blanks based on what you know or can infer.
For each row marked High risk: how would SPIFFE change the picture?
Save as spiffe-analysis.md in your notes.

Resources

• spiffe.io/docs/latest/spiffe-about/overview
• SPIFFE spec: github.com/spiffe/spiffe (README + spec/ folder)
• CNCF blog: "Solving the Bottom Turtle — SPIFFE/SPIRE explained"