Example deployment

You’ve rendered the chart and reviewed the values — now walk the whole flow: render, sign, mount, deploy, verify, and refresh. This page describes a provider-neutral way to run the adapter in front of a real upstream. It is not a live operations runbook and it does not include cloud credentials, cluster access instructions, cluster names, registry names, or raw infrastructure addresses.

Example only

Use this as a shape for review: render, sign, mount, deploy, verify, and refresh. Adapt it to your own platform controls before operating it in production.

Topology

flowchart LR
  CI["CI job<br/>(manual or reviewed)"] -->|"render + apply chart"| K
  subgraph K["Kubernetes or equivalent runtime"]
    subgraph AppNS["application boundary"]
      AD["trustplane-adapter"]
      BND["signed trust + policy bundles"]
      UP["existing upstream service"]
    end
    AD -->|"verified only"| UP
    AD --> BND
  end

Example deployment inputs:

Input	Example value
Namespace	trustplane-auth
Release	trustplane-auth
Adapter image	immutable adapter artifact from a trusted registry
Upstream	internal service URL owned by your environment
Service type	internal by default; expose through ingress or gateway when needed
Replay store	memory for one replica; shared replay store for multiple replicas
Bundles	signed trust and policy bundle objects mounted read-only

Step 1 — Prepare signed bundles

Build or update trust material and the policy bundle, review the resulting files, then sign them:

trustplane bundle sign \
  --trust-material trust-material.json \
  --out trust-material.signed.json \
  --signer-issuer local://bundle-signer \
  --kid bundle-signing-key-1 \
  --private-key "$BUNDLE_SIGNING_PRIVATE_KEY_B64URL"

trustplane bundle sign \
  --policy-bundle trustplane.bundle.json \
  --out trustplane.bundle.signed.json \
  --signer-issuer local://bundle-signer \
  --kid bundle-signing-key-1 \
  --private-key "$BUNDLE_SIGNING_PRIVATE_KEY_B64URL"

Keep signing keys out of git, logs, screenshots, issue trackers, and docs. Public docs should show placeholder variable names only.

Step 2 — Render before apply

./scripts/render-chart.sh
helm template trustplane-auth charts/trustplane-oss-auth --namespace trustplane-auth

Review the rendered Deployment, Service, NetworkPolicy, security context, replay configuration, and read-only bundle mounts before applying anything.

Step 3 — Mount the signed bundle objects

Create platform-native objects for the signed trust material and signed policy bundle. The chart should reference those object names and mount them read-only. Avoid embedding live bundle content directly in public docs or public workflow logs.

Step 4 — Deploy the adapter

Apply the chart through your normal reviewed deployment path. The adapter owns the verification boundary; the protected upstream should not be reachable directly by untrusted callers.

Step 5 — Verify the protected route

A valid signed request should allow. These cases should deny:

Case	Expected result
Missing passport or proof	deny
Unknown key	deny
Wrong audience	deny
Wrong route or path	deny
Duplicate replay	deny
Stale signed bundle for a fail-closed route	deny
Signer class below route policy	deny

Health endpoints prove the adapter is alive, but they do not prove the protected route contract. Use a business route with transcript-v1 request binding for the real acceptance proof.

Step 6 — Refresh without rebuild

To add or remove a client, produce reviewed replacement trust material and policy bundle files, sign them, update the mounted bundle objects, and roll or refresh the adapter so it reads the new files. The adapter image and upstream code should not change for a trust-material update.

Next steps

• Bundle refresh — the full add/remove/revoke lifecycle without rebuilding infrastructure.