Skip to content
TrustPlane

Use cases

TrustPlane Auth secures machine-to-machine access across these scenarios. The pattern is the same each time: Acme protects one Orders API behind a single adapter, and each kind of trusted caller — a local script, a VM, a Kubernetes workload, an external automation runner — is described as reviewed data, not adapter code. The adapter checks the request proof, the route, and the route’s allowed_sources before the request reaches the upstream.

flowchart LR
  L["Local software caller"] --> A["TrustPlane adapter"]
  E["EC2 software caller"] --> A
  K["Kubernetes SPIFFE caller"] --> A
  N["External EKS/n8n automation"] --> A
  A -->|"verified only"| O["Orders API"]
  A --> P["Route policy<br/>allowed_sources"]
  A --> T["Trust material<br/>public keys / anchors"]

The trust anchor is how the verifier knows who is allowed to sign requests. For a software/JWKS-style caller, that means a configured issuer key. For a same-cluster SPIFFE/SPIRE caller, that means a broker that verifies the caller’s X.509-SVID before issuing. Either way, the verifier consumes local public trust material and route policy — and the upstream API still owns business authorization. TrustPlane Auth decides whether this caller presented a valid proof for this method/path/route under an allowed source; it does not replace the upstream’s user, tenant, or role checks.

Local development

Section titled “Local development”

Start with the smallest shape: a local integration script or partner caller that signs each request with a software key. Acme publishes the caller’s public key into trust material and allows that source on the route — no API key or static bearer token is ever shared. This is the fastest way to see a non-bearer signed request accepted end to end, and the same command flow underpins every software/JWKS-style source in the other scenarios. Develop and test with software keys

Non-Kubernetes hosts

Section titled “Non-Kubernetes hosts”

TrustPlane Auth is not Kubernetes-only. An EC2-hosted service, VM, or edge process can call the same protected route as a configured software/JWKS-style source, with a subject prefix such as aws:ec2:us-east-1: separating EC2-style callers from other sources in route policy. The page is explicit about the boundary: this proves a configured software source signed the request, not that AWS cryptographically attested the instance. Accept callers outside Kubernetes

Kubernetes with SPIFFE

Section titled “Kubernetes with SPIFFE”

For same-cluster Kubernetes workloads, a TrustPlane broker sidecar verifies the caller’s X.509-SVID through the SPIRE Workload API before issuing a request-bound passport stamped attested_workload. Only the sidecar touches the Workload API socket; the application container never does. Workload identity gates issuance, and the adapter still verifies everything locally. Gate issuance on SPIFFE workload identity

Cross-cluster callers

Section titled “Cross-cluster callers”

A workload in another Kubernetes cluster — or another trust domain entirely — can be accepted as a configured trusted source without static bearer tokens. Today that is software/JWKS-style policy acceptance; cross-cluster SPIFFE federation and Control-managed trust anchor enrollment are the future lifecycle path, and neither changes the request-time rule that the adapter verifies everything locally. Trust callers from other clusters

Agentic workflows

Section titled “Agentic workflows”

Automation platforms and agentic runtimes — an n8n worker, an EKS-hosted workflow system — can call protected APIs without holding an API key for them. The runner signs each request, and the proof is bound to method, path, audience, route, body hash, and replay state, so the workflow’s credential store no longer contains standing access to the Orders API. Remove bearer tokens from automation

Brownfield APIs

Section titled “Brownfield APIs”

Existing APIs get the same protection without rebuilds. Because trust is data, not code, you onboard a brand-new client to an already-protected route by publishing merged trust material — the adapter image, Deployment, and Service stay exactly the same. The full tutorial walks from trustplane gen-key through bundle merge-source to verified before/after behavior. Protect existing APIs and add clients without redeploying

Section titled “Related pages”