Examples overview
Acme protects one Orders API. The trusted callers are not all the same:
- a local integration script with a public-key/JWKS-style source
- a non-Kubernetes EC2 service using a software signing key
- a same-cluster Kubernetes workload with SPIFFE/SPIRE
- an external automation runner, such as EKS/n8n, accepted through configured trust material
- future callers enrolled through stronger federation and governance paths
TrustPlane Auth keeps the adapter in one place and moves caller trust into reviewed data. The
adapter checks the request proof, the route, and the route's allowed_sources before the request
reaches the upstream.
The simple model
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. The verifier still consumes local public trust material and route policy.
Example map
| Caller shape | Trust anchor today | Live in v0.1.0-rc.1? | What it proves | What it does not prove |
|---|---|---|---|---|
| Local software/JWKS caller | Configured issuer public key and route allowed_sources | Yes | A non-bearer signed request can be accepted without an API key | Hardware binding, managed enrollment, or cloud attestation |
| EC2/non-Kubernetes caller | Software/JWKS-style issuer key with an EC2-shaped subject prefix | Yes | Non-Kubernetes sources can be accepted by policy | AWS Instance Identity Document, Nitro attestation, or hardware-bound signing |
| Same-cluster Kubernetes SPIFFE/SPIRE caller | Broker sidecar verifies X.509-SVID through SPIRE Workload API | Yes, when SPIRE is deployed and configured | Workload identity can gate broker issuance as attested_workload | Broker signing key hardware binding or cross-cluster federation by default |
| Cross-cluster Kubernetes/EKS/n8n caller | Software/JWKS-style configured source today | Yes as configured software/JWKS acceptance | External automation can be trusted without static bearer tokens | Control Plane auto-enrollment or default SPIFFE federation |
| Future cross-cluster SPIFFE federation / Control-managed enrollment | Federation, governance, revocation, audit, and managed trust-anchor lifecycle | Future | Central lifecycle management across many Auth deployments | A hot-path Control dependency for each request |
Storyline
Start with Acme protecting GET /orders. The route policy says which source rules are allowed:
local software, EC2 software, same-cluster SPIFFE, and external automation. Each source has its
own issuer, trust domain, subject selector, and minimum signer class.
The upstream Orders 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.
Where to go next
- Software/JWKS caller - local or external public-key flow.
- EC2/non-Kubernetes caller - what EC2-style software acceptance means.
- Same-cluster SPIFFE/SPIRE - broker sidecar with X.509-SVID checks.
- Cross-cluster and n8n - current external automation story and future path.
- Route policy map - how one adapter protects many routes.