Skip to content
TrustPlane

Auth Sites

An Auth Site is Control’s record of a place where TrustPlane Auth runs — a verified hostname with a fleet, a distribution target, and a registered target key. The Auth Sites screen is where you govern each site’s connection to Control: whether it is verified, connected, and serving the promoted policy, plus the site record’s recovery publication and lifecycle actions. Service-principal work — clients, keys, route grants — is deliberately kept on its own screen; see “What this screen can change” below.

The screen requires a selected environment and fleet; without both it shows an “Environment and fleet required” notice. If the site list cannot be read, “Auth sites not loaded” appears instead of partial content.

Check your capacity

Section titled “Check your capacity”

The “Auth Site capacity” panel shows the tenant-wide allowance: a badge with current usage against the allowed maximum (or just the count used when no limit is enforced), plus the Feature and Limit names, the Tenant capacity scope, the Viewed context (environment and fleet), and whether Pending verification sites consume capacity.

When the allowance is reached, the panel says so and points you at safely tombstoning an eligible unused site to release capacity. When capacity is available, it reminds you that Auth Site creation remains guarded by the onboarding workflow — this inventory view does not start another creation flow. A “Sites consuming the allowance” table lists each consuming site with Site, Status, Environment, Fleet, and ID. If Control does not return the capacity contract, the panel shows “Auth Site capacity unavailable”.

Read the site inventory

Section titled “Read the site inventory”

Four metrics summarize the fleet: Sites (total), Verified (ownership verified), Active (lifecycle active), and Needs attention (stale, failed, or degraded).

The “Auth site state” table lists every site with columns: Site, Lifecycle (status badge), Ownership (verification badge — “verified” or “pending”), Target (the distribution target ID, or “not registered”), Last seen, and Detail (an “Inspect” link that selects the site).

Selection is deliberate: with more than one site in the fleet, an “Auth Site selection required” notice asks you to pick the exact site — no site is inferred from display order. If the requested site is outside the current environment and fleet, “Selected Auth Site is out of scope” appears and no other site is substituted. If Control returns no sites for the fleet, the screen says “No Auth sites returned”.

Inspect distribution readiness

Section titled “Inspect distribution readiness”

Selecting a site opens a detail panel headed by an overall readiness badge:

  • Serving promoted policy — every check passes.
  • Target registration required — no distribution target is registered.
  • Action required — lifecycle, ownership, target key, or delivery mode needs attention.
  • Distribution degraded, Propagating policy, or Initializing distribution — the activation aggregate or instance quorum is not settled yet.

Metrics show Lifecycle, Ownership, Activation state, and Instance quorum (activated versus expected instances). Beneath them, a “Readiness checks” table lists each check with its state (Ready/Blocked badge) and operator guidance:

  • Site lifecycle — the site must be active before serving protected traffic.
  • Ownership — DNS ownership verification must be complete.
  • Distribution target — a target must be registered for this site.
  • Signed target M2M — an active public target key must be registered.
  • Pull delivery — Auth initiates outbound Control requests; managed profiles use pull delivery.
  • Activation aggregate — the authoritative site activation state.
  • Instance quorum — expected Auth replicas must be activated.

An “Advanced diagnostics” section adds the site key, distribution target, target and promoted target configuration versions, promoted bundle and bundle set IDs, registered instances, offline lease deadline, last pull and last reload times, the observed trust and policy digests, and a sanitized agent error code. If site detail cannot be read, “Auth Site detail unavailable” appears.

Review target and acknowledgement state

Section titled “Review target and acknowledgement state”

The “Bootstrap handoff” panel for the selected site shows how the site is wired to Control and what it has acknowledged. It contains public identifiers and signed artifact references only — never the Auth target private key, a Kubernetes Secret value, or Control credentials.

Its fields cover the site identity and scope (site, environment/fleet, distribution target), key material references (Target public key registration status and fingerprint, Control signing key filename and fingerprint, Signer issuer/kid/algorithm, Trust root version), endpoints (Control API, External Auth authority), policy scope (Protected surfaces, Policy APIs, Audiences), and distribution state (Target configuration version, Promoted bundle, Acknowledgement and consistency status, Instance quorum, Lease deadline, Last pull / reload). Kubernetes Secret name and data-key references are shown for the signing public key and the target private key — references only, never values. A collapsible “Signing-key rotation evidence” section shows rotation state and predecessor/successor key fingerprints when rotation data exists.

When bootstrap artifacts are ready and the full environment, fleet, and site scope is selected, the panel offers downloads of the Control signing public key and the bootstrap package, proxied through the same-origin BFF with the selected scope retained, plus a copy button that fetches the signing public key verbatim. Otherwise the panel explains why: artifacts not yet published, a trust-root mismatch to resolve in Control, or incomplete download scope. A “Safe bootstrap handoff JSON” block renders the sanitized handoff for copying, alongside a trust-root fingerprint copy action.

A “Managed Auth release configuration” section appears only when Control returns a validated release descriptor with digest-pinned image references, a verified chart reference, and concrete non-secret Secret references; it then shows descriptor metadata and Helm values guidance. Until then, that guidance is intentionally withheld and the panel says so.

What this screen can change

Section titled “What this screen can change”

This screen performs no service-principal mutations. Client, key, and route-grant changes live in Client Vault. The only actions here are:

  • Publish safe recovery version — creates a normal signed Control publication for the selected site’s distribution target. It does not edit cache files or bypass activation checks; Auth replicas pull and acknowledge it independently.
  • Danger zone lifecycle actions — deactivate, reactivate, or logically delete the Control Auth Site record. Each action requires typing the site hostname or key to confirm, and is enabled only when Control reports it eligible; blockers are listed with action, code, count, and detail. These actions only change the Control record — they never delete Kubernetes PVCs, Secrets, StatefulSets, Ingresses, DNS, upstream applications, or customer data, and logical deletion retains the Control audit history.

Next steps

Section titled “Next steps”