Day 20: Fit Analysis — Where SPIRE Helps and Hurts Your Provisioning Service

Phase 4 · August 24, 2026

Agenda (2–3 hours)

• No new reading — synthesize what you know
• Write (120 min): Complete spiffe-analysis.md fit analysis
• Review (60 min): Read it as if you were your tech lead

Phase 4 Full Concepts Inventory

Rate each: ✓ solid / ~ partial / ✗ need review

Week 1 — The SPIFFE Model

• [ ] Workload identity bootstrapping problem
• [ ] SPIFFE ID structure (spiffe://trust-domain/path, constraints)
• [ ] X.509-SVID requirements (URI SAN, EKU, short validity, empty subject)
• [ ] Trust domain and trust bundle semantics
• [ ] Workload API — socket, gRPC, streaming response, no auth needed
• [ ] JWT-SVIDs — sub, aud, exp, alg, use cases
• [ ] Federation — when needed, bundle endpoint, static vs. dynamic

Phase 4 Full Concepts Inventory (continued)

Week 2 — SPIRE Internals

• [ ] SPIRE three-tier architecture (server / agent / workload)
• [ ] Node attestation — IID (AWS), PSAT (k8s), join token (dev)
• [ ] Workload attestation — unix (UID/path/sha256), docker (labels), k8s (ns/sa)
• [ ] Selector AND/OR semantics
• [ ] SPIRE CA options — self-signed, UpstreamAuthority (aws_pca), disk
• [ ] SPIRE server HA — shared PostgreSQL, multiple instances

Week 3 — Integration

• [ ] Lambda gap — no persistent agent; OIDC bridge pattern
• [ ] spiffe Rust crate — WorkloadApiClient, X509Source, SpiffeId types
• [ ] SVID validation — 6 required checks from spec
• [ ] mTLS with SVIDs — SvidCertResolver, SpiffeVerifier, hot rotation
• [ ] PQC + SPIFFE intersection — HNDL window, migration automation
• [ ] Fit analysis for provisioning service

The Fit Analysis Framework

A good fit analysis answers three questions:

1. Where does SPIFFE/SPIRE solve a real problem my team has?

• Credential bootstrapping for long-running services?
• mTLS between internal services without static cert management?
• Cross-team or cross-org identity federation?
• PQC migration automation via short-lived SVIDs?

2. Where does SPIFFE/SPIRE add complexity without proportional benefit?

• Lambda functions (no agent, IAM already handles AWS-internal auth)
• Device certificates (satellite terminals, embedded hardware)
• AWS-to-AWS service calls (IAM SigV4 is simpler and equally secure)

3. What is the operational cost?

• SPIRE server HA deployment and maintenance
• Agent management on compute nodes
• Registration entry management (per workload, per environment)
• Trust bundle rotation and federation maintenance

Mapping SPIFFE to Your Team's Workflow

Your provisioning service pattern:

Client device ──request──► Lambda ──calls──► ACM PCA
                                  ──reads──► DynamoDB
                                  ──logs──►  CloudWatch

SPIFFE coverage:

Client device        → NO (embedded hardware, no SPIRE agent)
Lambda ← IAM SigV4  → COVERED (no SPIFFE needed for AWS-API calls)
Lambda → ACM PCA    → COVERED (IAM SigV4, not SPIFFE)
Lambda ← peer svc   → MAYBE (if cross-team mTLS needed)
peer → peer mTLS    → YES (SPIFFE shines here)

The honest assessment: for a pure Lambda + AWS services stack,
SPIFFE's value is marginal unless you have non-AWS peers needing mTLS.

Where SPIFFE Would Have Highest ROI

Rank these scenarios from highest to lowest SPIFFE ROI for your service:

High ROI:

• Long-running microservices (not Lambda) doing peer mTLS
• Multi-cloud or hybrid deployment (AWS + on-prem data center)
• Cross-team or cross-org service calls that need portable identity

Medium ROI:

• Fargate-based services (agent as sidecar — supported but complex)
• Internal services in the same VPC that currently use static certs

Low ROI:

• Pure Lambda → AWS APIs (IAM handles it natively)
• Device certificate provisioning (embedded hardware can't run SPIRE agent)

Challenge Assignment

Complete the final section of spiffe-analysis.md:

Section 6: Fit Analysis and Recommendation (2 pages max)

Structure:

## 6. SPIFFE/SPIRE Fit Analysis: Leo Provisioning Service

### 6.1 Problems SPIFFE Solves Well (for this service)
<list, with reasoning>

### 6.2 Where IAM/Classical PKI Is Sufficient (and SPIFFE adds burden)
<list, with reasoning>

### 6.3 Operational Cost Assessment
<SPIRE server ops, entry management, Lambda gap>

### 6.4 Recommendation
<adopt / partial / defer — with concrete first step if adopt/partial>

### 6.5 Conditions That Would Change the Recommendation
<"If we move to EKS, recommendation changes to X because Y">
<"If we get a cross-team mTLS requirement, recommendation changes to...">

Quality bar: good enough to present in a 30-min team design review.

Resources

• Your spiffe-analysis.md from Days 1–19
• Your pqc-migration-roadmap.md from Phase 3
• "The Bottom Turtle" book Chapter 7: "SPIFFE in Production"
• CNCF case studies: search "SPIFFE SPIRE production" on cncf.io