Skip to content
TrustPlane

Cross-cluster calls

A caller in another Kubernetes cluster — another EKS account, another trust domain, another organization’s infrastructure — often ends up holding a static API key for the service it needs to call. TrustPlane Auth removes that key: the remote workload is accepted as a configured trusted source, and every request it makes carries its own verifiable proof.

In the current release, cross-cluster acceptance is software/JWKS-style policy acceptance unless SPIFFE federation is explicitly deployed and configured. There is no auto-enrollment path in v0.1.

How a cross-cluster caller is accepted

Section titled “How a cross-cluster caller is accepted”
flowchart LR
  N["Workload in another cluster"] -->|"signed request"| A["Acme TrustPlane adapter"]
  A -->|"allowed by route policy"| O["Orders API"]
  A --> T["Trusted source<br/>issuer key + allowed_sources"]

You add the remote workload as a source rule on the route: its issuer, trust domain, subject selector, and required key binding. The caller signs each request — for example GET /orders — and the adapter verifies the signature, request binding, audience, route, replay, freshness, and source rule before anything reaches the upstream. For the concrete source-rule JSON and an automation-runner walkthrough, see Agentic workflows; the generic key-generation and signing command flow is in Local development.

What is live today

Section titled “What is live today”
Scenario Current posture
Another Kubernetes cluster without SPIFFE federation Supported as software/JWKS-style acceptance
EKS-hosted automation Supported as software/JWKS-style acceptance
Cross-cluster SPIFFE federation Future unless you explicitly deploy and operate federation
Control-managed trust anchor enrollment Future

Why this still matters

Section titled “Why this still matters”

The remote cluster’s workload does not hold an API key for Orders. It signs each request, and the proof is bound to method, path, audience, route, body hash, and replay state. A copied request or a leaked credential store does not grant standing access.

The upstream still owns business authorization. TrustPlane Auth does not decide which customer, tenant, invoice, or order the remote caller may access after the request is verified.

Where this goes next

Section titled “Where this goes next”

TrustPlane Control is the future governance layer for managing many Auth deployments. It is not a hot-path dependency for each request. The future cross-organization path can include:

  • Control-managed trust anchor enrollment
  • OIDC/JWKS source onboarding
  • SPIFFE federation where both sides deploy it intentionally
  • revocation feeds
  • audit and governance workflows

Those features improve lifecycle management. They do not change the core request-time rule: the adapter must be able to verify the caller, proof, and route policy locally.

Next steps

Section titled “Next steps”