Run a managed Auth Site

At the end of this guide, your Auth Site serves a private sample API through one HTTPS hostname. An unsigned request is denied; a client with the exact GET /tutorial/echo grant receives the response, and Control Audit records the decision. Control publishes signed policy; Auth enforces it locally on every request.

flowchart LR
  C["TrustPlane Control<br/>site, policy, signed bundle"] -->|signed configuration| A["Auth Site<br/>local verification"]
  W["Client workload<br/>signed request"] --> A
  A -->|allowed request only| P["Private sample API"]
  A -->|decision evidence| C

Key	Created or held by	Purpose
Auth Site distribution target	Customer’s deployment	Auth agent authenticates its signed pull to Control. Only its public half is registered in Control.
Control artifact signer	Control	Signs configuration; Auth pins its public half before loading bundles.
Client signing key	Customer’s workload	Signs API requests after a narrow client grant. Only its public half goes to Client Vault.

Before you start

Owner	Prerequisite
Organization owner	Owner-authorized Control organization, workspace/environment and fleet; active eligibility for a new Auth Site and one free tenant-wide site slot.
DNS owner	A real Auth hostname, access to its authoritative DNS zone for Control’s TXT ownership proof and the later Auth edge record.
Cluster operator	Reviewed Kubernetes context, a dedicated namespace, NetworkPolicy enforcement, retained storage, a private sample upstream, and HTTPS ingress with a valid certificate. Chapter 3 gives the tested EKS shape and its required substitutions.
Client owner	A persistent Ed25519 key kept outside Control, plus a client authorized only for the documented read operation.

The tenant admin can complete the Control sequence without a super-admin: stage the narrow client and grant, publish and promote a signed package, then download the site’s public signer key before starting Auth. Chapter 2 explains the first-start sequence. Kubernetes, DNS and certificate changes still require the normal rights for the customer’s infrastructure.

Follow the chapters

1. Register an Auth Site and verify its DNS ownership.
2. Generate the distribution target key, register its public half, and prepare the first protected endpoint.
3. Render, install and activate Auth with a private upstream.
4. Create or confirm the client, persistent signing key and narrow grant.
5. Send a signed request and correlate its Control Audit decision. 5.1. Call the same route with the released Python SDK.
6. Rotate and revoke a client key with an exact-target check.

Validated configuration

The isolated existing-tenant exercise on 12–14 October 2026 used CLI v0.2.5, adapter image v0.2.5, Helm chart 0.2.2 with controlDistribution.adapterVersion: v0.2.5, and Python SDK 0.2.3. Check current artifacts and digests and your site’s release descriptor before using them. The tested configuration covers one new site in an existing tenant; verify your own account and infrastructure prerequisites before installation.

Each chapter includes an optional video alongside the complete written procedure. The local developer smoke is a separate localhost exercise; it does not register a Control site or create Control Audit evidence.