Skip to content
TrustPlane

Deployment overview

You want to protect an existing API without touching its code. The deployment pattern is simple: place trustplane-adapter in front of the API and let it verify every request before forwarding. The enforced traffic flow is caller → gateway/ingress → Auth adapter → upstream API: the gateway places traffic on the adapter, and only the adapter reaches the upstream. The upstream stays unchanged while the adapter enforces passports, transcript-v1 request proof, route policy, replay protection, source rules, signer class, bundle freshness, and stable audit outcomes.

flowchart LR
  EXT["Caller<br/>(configured issuer key)"] -->|"passport + transcript-v1 proof"| SVC["Gateway / ingress"]
  SVC -->|"protected routes only"| AD["trustplane-adapter"]
  AD -->|"verified only"| UP["Existing upstream API<br/>(unchanged)"]
  AD --> BND["Mounted signed trust + policy bundles<br/>(read-only)"]
  AD -.->|"only approved egress"| UP

Know the artifact boundary

Section titled “Know the artifact boundary”
Artifact Owns
Runtime binaries CLI, adapter, broker, local demos, and acceptance checks.
Deployment package Helm chart shape, example values, and deployment safety rails.
Public docs Product, adopter, deployment, and reference guidance.

Deployment examples explain the shape and safety rails; they are not a live operations credential store. For brownfield gateway and ingress placement, see Gateway integration patterns.

What an adapter deployment needs

Section titled “What an adapter deployment needs”
  • An adapter process or container.
  • A protected upstream URL reachable only through the intended boundary.
  • Signed trust material containing allowed issuer keys.
  • A signed trustplane-bundle-v1 policy bundle containing routes, allowed sources, signer-class requirements, freshness policy, and optional provenance/context constraints.
  • Replay storage appropriate for the replica count. A single local/demo adapter can use memory; multi-replica deployments need a shared replay store.
  • Read-only bundle mounts and a way to refresh those files without rebuilding the adapter image.

Operate by these principles

Section titled “Operate by these principles”
  • Adapter is stable infrastructure. New clients and route policy changes are bundle publishes, not image rebuilds.
  • Signed bundles are the production-style default. Unsigned bundle skeletons are local development artifacts only.
  • Replay state must match topology. Multi-replica adapters need a shared replay store so a consumed jti is consumed everywhere.
  • The upstream boundary matters. Upstreams may trust forwarded X-TrustPlane-* headers only when untrusted callers cannot bypass the adapter or forge adapter-to-upstream traffic.
  • No committed secrets. Credentials, signing keys, live bundle contents, and signed request logs do not belong in version control or documentation.

Harden the runtime

Section titled “Harden the runtime”
flowchart TB
  subgraph Pod["Adapter runtime"]
    A["trustplane-adapter"]
  end
  A --> NP["egress policy:<br/>upstream + required platform services only"]
  A --> RO["signed bundle mounts:<br/>read-only"]
  IMG["immutable adapter artifact"] --> A

Recommended defaults:

  • Run as a non-root user.
  • Use a read-only root filesystem where the platform supports it.
  • Drop unnecessary capabilities.
  • Mount trust and policy bundles read-only.
  • Keep the adapter as the only network path to the protected upstream — see Network hardening for the enforcing NetworkPolicies and verification checks.
  • Use TLS, ingress, WAF, or gateway controls appropriate to the environment.

The deployment pages intentionally avoid provider-specific live cluster details: they give you a shape to review and adapt to your own platform controls.

Next steps

Section titled “Next steps”