Skip to main content

Same-cluster SPIFFE/SPIRE

For Kubernetes workloads in the same cluster, TrustPlane Auth can put 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.

Shape​

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.

Issuance flow​

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.

Live boundary​

Topicv0.1.0-rc.1 story
Same-cluster SPIFFE/SPIRELive when SPIRE is deployed and the broker is configured for the Workload API
Workload API exposureBroker sidecar only
SVID typeX.509-SVID path
Per-request verifier behaviorVerifier trusts the broker issuer key from local bundle material
Cross-cluster SPIFFE federationFuture unless explicitly deployed outside this default flow
Hardware-bound broker keyNot implied

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

For the capability details, see Broker & attested_workload.