← Week 3: Integration and Application

Day 21: Phase 4 Final Challenge — spiffe-demo + Written Fit Analysis

Phase 4 · August 25, 2026

← Week 3: Integration and Application

Agenda (3 hours)

  • Complete spiffe-demo (90 min): All subcommands working, code clean
  • Finalize spiffe-analysis.md (60 min): All 6 sections complete
  • Phase 4 reflection (30 min): What changed in your mental model?
← Week 3: Integration and Application

spiffe-demo Final Binary Spec

spiffe-demo
├── make-svid <spiffe-id>   -- Generate a test SVID (Day 3); print cert info
├── fetch [--live]          -- Fetch from Workload API or use simulated SVID (Day 4)
├── jwt-parse <token>       -- Parse a JWT-SVID and print claims (Day 5)
├── inspect [--live]        -- Full SvidInfo table (Day 16)
├── validate <cert.pem>     -- Run all 6 SVID validation checks (Day 17)
├── tls-server              -- mTLS server using live SVID (Day 18)
├── tls-client              -- mTLS client using live SVID (Day 18)
└── svid-exchange --name    -- Two-service SVID exchange (Day 14)

Run with --live when SPIRE is running; simulated mode otherwise.
All subcommands must compile cleanly on stable Rust.

← Week 3: Integration and Application

Final Binary: Cargo.toml

[package]
name = "spiffe-demo"
version = "0.1.0"
edition = "2021"

[dependencies]
spiffe   = { version = "0.6", features = ["rustls"] }
rustls   = "0.23"
tokio    = { version = "1", features = ["full"] }
clap     = { version = "4", features = ["derive"] }
rcgen    = "0.13"
x509-parser = "0.16"
pem      = "3"
aws-lc-rs = "1"        # for any PQC key generation if needed

[dev-dependencies]
tempfile = "3"
← Week 3: Integration and Application

spiffe-analysis.md Completion Checklist

  • [ ] §1 Credential Inventory — all credentials with risk ratings
  • [ ] §2 SPIFFE ID Design — SPIFFE IDs for service components
  • [ ] §3 Federation Design — topology for internal / partner / device peers
  • [ ] §4 SPIFFE vs. Classical PKI — comparison table filled in for your service
  • [ ] §5 SPIRE Deployment Architecture — server count, upstream CA, HA plan
  • [ ] §6 Fit Analysis and Recommendation — adopt/partial/defer with rationale

Final check: read §6 aloud. Could you say this in a 5-minute design discussion
with your tech lead and have it land clearly?

← Week 3: Integration and Application

Phase 4 in One Sentence Per Week

Complete these:

  • Week 1: "SPIFFE solves the workload bootstrapping problem by _______________."
  • Week 2: "SPIRE issues SVIDs after _______________ attestation confirms that
    the workload is _______________ running on _______________ infrastructure."
  • Week 3: "For my provisioning service, SPIFFE's highest-value use case
    is _______________, and its main limitation is _______________."
← Week 3: Integration and Application

What You've Built: Phase 4 Deliverables

mob_learning/
├── spiffe-demo/                   ← Rust binary: 8 subcommands
│   ├── docker/                    ← SPIRE deployment (Docker Compose)
│   └── src/                       ← svid.rs, validate.rs, tls.rs, jwt.rs
└── spiffe-analysis.md             ← 6-section fit analysis

spiffe-demo proves you can work with SPIFFE identity at the library level
(SVID generation, validation, mTLS) and with a real SPIRE deployment.

spiffe-analysis.md proves you can evaluate a production system against your
specific service context — not just "SPIFFE is good" but "here's where it helps
and where it doesn't, for Amazon Leo specifically."

← Week 3: Integration and Application

Phase 4 Reflection

Four questions:

  1. What was most surprising about SPIFFE/SPIRE?
  2. What is still fuzzy? (one concept you couldn't confidently explain to a colleague)
  3. How does this change your mental model of the provisioning service?
  4. If you had to ship one thing from this phase in your first week back — what would it be?
    (A proposal, a prototype, a conversation with your tech lead?)

Write answers anywhere. These calibrate Phase 5 and the integration project.

← Week 3: Integration and Application

Looking Ahead: Phase 5 (Aug 26–Sep 16)

HSM + AWS Private CA

You now understand classical PKI (Phase 1), PQC migration (Phase 3),
and workload identity (Phase 4).

Phase 5 addresses the hardware layer: how are CA private keys protected,
what PKCS#11 is and how it works, and how ACM Private CA fits into your
team's architecture as a managed CA service.

This is where the HSM gaps you've been noting throughout Phases 3 and 4
(CloudHSM PQC support, ACM PCA ML-DSA support) become concrete.

← Week 3: Integration and Application

Resources

  • spiffe crate examples: github.com/spiffe/spiffe-rs/tree/main/examples
  • SPIRE quickstart: spiffe.io/docs/latest/try/getting-started-linux-macos-x
  • "Solving the Bottom Turtle" book: free at spiffe.io/book — read Chapters 1–7