Skip to content
TrustPlane

Helm chart

Before you apply anything to a cluster, you should be able to see exactly what will be created. The deployment chart renders an Auth adapter, Service, NetworkPolicy, optional protected mock API, optional caller with broker sidecar, and bundle mounts — and it renders cleanly without a live cluster, so you can inspect every resource first.

Render locally

Section titled “Render locally”
Terminal window
helm template tp-auth charts/trustplane-oss-auth --namespace trustplane-auth
./scripts/render-chart.sh

Expected output includes an adapter Deployment, adapter Service, adapter NetworkPolicy, and no public broker Service. The broker, when used, is a pod-local sidecar.

Template shape

Section titled “Template shape”
flowchart TB
  subgraph NS["Namespace: trustplane-auth"]
    ADd["Deployment/trustplane-adapter"]
    ADs["Service/trustplane-adapter"]
    NPa["NetworkPolicy/trustplane-adapter"]
    MKd["Deployment/mock-api (optional)"]
    MKs["Service/mock-api (ClusterIP)"]
    NPm["NetworkPolicy/mock-api"]
    CLd["Deployment/caller (+ broker sidecar, optional)"]
  end
  ADd --> ADs
  ADd -. egress .-> MKs
  MKd --> MKs

Set the key values

Section titled “Set the key values”

Adapter behavior:

adapter:
  port: 8081
  upstream: http://127.0.0.1:8080
  audience: example-api
  trustDomain: example.invalid
  routeId: example.route
  routePolicyMode: route-id
  proofMode: transcript-v1
  requiredKeyBinding: software

Signed bundle mounts:

bundle:
  mountDirectory: /etc/trustplane
  trustBundleMountPath: /etc/trustplane/trustplane-bundle.json
  policyBundleMountPath: /etc/trustplane/trustplane.policy.bundle.json
  policyBundleFreshnessWindow: 5s
  trustBundle:
    configMapName: ""
    secretName: ""
    key: trustplane-bundle.json
  policyBundle:
    configMapName: ""
    secretName: ""
    key: trustplane.policy.bundle.json

The chart mounts bundle object names; it does not create live bundle data. Create, review, sign, and mount bundle objects through an environment-appropriate process before the adapter starts.

Control-signed bundle files can also be mounted from externally-created Secrets:

controlBundles:
  enabled: true
  trustMaterialSecretName: trustplane-control-trust-material
  trustMaterialSecretKey: trust-material.signed.json
  policyBundleSecretName: trustplane-control-policy-bundle
  policyBundleSecretKey: policy-bundle.signed.json
  signingPublicKeySecretName: trustplane-control-signing-public-key
  signingPublicKeySecretKey: control-signing-public-key
  mountPath: /var/run/trustplane/control-bundles

This mode keeps verification local to Auth and does not make Control a request-time dependency. See Control-signed bundles for details and limits.

Control-signed bundle file consume requires adapter image v0.1.0-rc.2 or later; the current v0.2.2 adapter image supports it.

Immutable adapter artifact:

Use the adapter image only with the pinned version and digest from Install & artifacts. Do not use latest.

image:
  repository: ghcr.io/trustplane-dev/trustplane-auth-adapter
  tag: v0.2.2
  digest: sha256:9e66feae80dfcd5f33b77c4b20968ebb5efbf9d7eb216c2cef2e4df66129e356

Replay safety:

replicaCount: 1
replay:
  store: memory
  multiReplica: false
  redis:
    addr: ""

Security context defaults:

podSecurityContext:
  runAsNonRoot: true
  runAsUser: 65532
  fsGroup: 65532
  seccompProfile:
    type: RuntimeDefault
securityContext:
  allowPrivilegeEscalation: false
  capabilities:
    drop: [ALL]
  readOnlyRootFilesystem: true
  runAsNonRoot: true
networkPolicy:
  enabled: true

Optional external entrypoint:

service:
  type: ClusterIP

Use an external Service, ingress, or gateway only when the environment has the right TLS, authorization, and upstream isolation controls.

Pick an example profile

Section titled “Pick an example profile”

Example values are non-secret and render-only:

Profile Purpose
adapter-only-values.yaml Adapter in front of an existing upstream, signed bundles mounted read-only.
values.yaml Adapter plus internal mock API for local or review environments.
spiffe-m2m-values.yaml Caller with broker sidecar and SPIFFE/SPIRE workload identity profile.
policy.bundle.multi-route.example.json One adapter protecting multiple business routes.

Enable the broker sidecar

Section titled “Enable the broker sidecar”

The broker sidecar is disabled by default. When enabled, it should run only inside the caller pod, communicate over a pod-local Unix socket, and use explicit workload-identity configuration. The chart should still render no broker Service and no host-level socket.

broker:
  sidecar:
    enabled: true
    image:
      repository: <your-registry>/trustplane-auth-broker
      tag: <your-build-tag>
      digest: sha256:<your-build-digest>
    spiffeProfile: trustplane-spiffe-spire-k8s-v1
    keyBinding: attested_workload

A broker container image is not a published release artifact: build the broker from the TrustPlane Auth source tree (make build) and publish it to your own registry before enabling the sidecar. Caller-side broker IPC v1 support is available in the 0.2.2 SDKs.

Next steps

Section titled “Next steps”