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 request acceptance can use configured software/JWKS-style sources. Control also supports enrollment through a validated generic OIDC JWKS Trust Anchor Source when the remote workload supplies an accepted proof. This page does not establish an end-to-end cross-cluster enrollment or SPIFFE federation deployment.

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 Trust Anchor enrollment Available for supported proof profiles; verify the remote workload’s exact source revision, policy and target activation

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 current governance plane for managed Auth deployments. It is not a hot-path dependency for each request. A cross-organization rollout needs separate review of:

  • the supported Control Trust Anchor proof profile and enrollment policy;
  • exact issuer, subject and route constraints for the remote caller;
  • publication, target acknowledgement, revocation and Audit evidence;
  • SPIFFE federation only where both sides explicitly deploy and verify it.

Those governance steps 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”