Skip to content
TrustPlane

Kubernetes with SPIFFE

When your caller is a Kubernetes workload in the same cluster as SPIRE, you can gate passport issuance on verified workload identity instead of a configured software key. TrustPlane Auth puts a broker sidecar next to the caller pod: the caller asks the broker for a request-bound passport, the broker verifies the caller through the SPIRE Workload API, then issues the passport and proof.

The protected API still sees the same adapter decision model: public trust material, route policy, request proof, and replay protection.

Deployment shape

Section titled “Deployment shape”
flowchart LR
  subgraph Pod["Caller pod"]
    W["Workload container"]
    B["TrustPlane broker sidecar"]
    W -->|"Unix socket"| B
  end
  B -->|"SPIRE Workload API socket"| S["SPIRE agent"]
  W -->|"request + passport + proof"| A["TrustPlane adapter"]
  A -->|"verified only"| O["Orders API"]

Only the broker sidecar needs access to the SPIRE Workload API socket. The application container does not need to mount or read that socket directly.

Follow the issuance flow

Section titled “Follow the issuance flow”
sequenceDiagram
  participant W as Workload container
  participant B as Broker sidecar
  participant S as SPIRE Workload API
  participant A as Adapter

  W->>B: issue GET /orders over pod-local Unix socket
  B->>S: Fetch and verify X.509-SVID
  S-->>B: spiffe://example.local/ns/orders/sa/orders-caller
  B-->>W: passport + transcript-v1 proof stamped attested_workload
  W->>A: GET /orders + passport + proof
  A->>A: Verify broker issuer key, route policy, replay, binding

Write the route source rule

Section titled “Write the route source rule”
{
  "issuer": "https://issuer.acme.example/spire",
  "trust_domain": "example.local",
  "subject_prefix": "spiffe://example.local/ns/orders/sa/",
  "required_key_binding": "attested_workload",
  "provenance_policy": {
    "profile": "trustplane-spiffe-spire-k8s-v1",
    "required_spiffe_trust_domain": "example.local",
    "required_posture": "spiffe_svid_verified"
  }
}

attested_workload means the broker verified workload identity through an X.509-SVID before issuance. It does not mean the broker signing key is hardware-bound, enclave-backed, or non-exportable.

Know the live boundary

Section titled “Know the live boundary”
Topic Current status
Same-cluster SPIFFE/SPIRE Live when SPIRE is deployed and the broker is configured for the Workload API
Workload API exposure Broker sidecar only
SVID type X.509-SVID path
Per-request verifier behavior Verifier trusts the broker issuer key from local bundle material
Cross-cluster SPIFFE federation Not currently supported unless explicitly deployed outside this default flow
Hardware-bound broker key Not implied

This is the live same-cluster SPIFFE story: workload identity gates broker issuance, and the adapter verifies the resulting passport and proof locally.

Next steps

Section titled “Next steps”