Trust Anchors

Workloads need a way to prove who they are before Control issues them a client key. The Trust Anchors screen is where you govern that first step of workload identity: register the sources Control uses to validate external workload proofs, move them through their lifecycle, bind them to enrollment policies, and generate the enrollment command a workload runs.

Only public verification metadata is entered on this screen. Private keys, raw proofs, tokens, routes, grants, scopes, caller-selected subjects, and provider checkout state are not accepted.

The lifecycle claims ladder

Everything on this screen sits somewhere on one ordered ladder, and each rung is a strictly stronger claim than the rung before it:

flowchart LR
  D["Draft"] --> V["Validated"] --> A["Active"] --> P["Enrollment<br/>policy"] --> E["Enrollment"] --> K["Derived<br/>key"] --> R["Runtime propagation<br/>/ readiness"]

Keep the claims distinct when you read this screen or report status: “selectable in the UI”, “valid configuration”, “active”, “derived key issued”, and “production-ready” are five different claims, and none of them implies the next. A source kind can be selectable in the create wizard without being a supported enrollment path; a validated draft has correct public metadata but accepts no enrollments; an active source still needs an enrollment policy before any workload can enroll; an issued derived key does not mean the runtime side has propagated and is ready; and none of these rungs, on its own, makes a profile production-ready. For the per-profile truth about which source kinds are supported, see Trust Anchor source availability.

Capacity follows the ladder: drafts and failed sources do not consume an automated capacity slot; activating and active sources do (the full counting rules are in Watch automated source capacity below).

Select your context

Trust Anchor Sources are constrained to the selected environment, fleet, and one exact existing Auth Site. Until you pick all three in the context chooser, the screen shows a notice instead of source data, and it refuses a site that sits outside the selected environment and fleet.

The Selected Auth Site panel confirms your context: the site’s display name and ID, its distribution mode, and its target activation state. If the site uses static or manual signed-bundle distribution, the panel warns that manual approval and distribution are required — the screen never infers automatic enrollment activation from general site readiness.

Watch automated source capacity

The Automated source capacity panel shows how many automated source slots this site is using against its allowance. Capacity is counted only for activating, active, suspended, live derived-key, or retiring automated sources — drafts, failed sources, retired sources, manual public keys, and revisions do not consume a slot.

The panel reports four figures: Used, Available, Included at this site (each included Auth Site has one included automated slot), and Allocated add-on slots (commercially organization-level, allocated to this exact site only).

Review the source inventory

The Exact-site Trust Anchor Sources table lists every source at the selected site with these columns:

Column	What it shows
Source	Display name and source ID
Kind / profile	The source profile, such as OIDC JWKS or SPIFFE JWT-SVID
Lifecycle	Lifecycle status badge (draft, active, suspended, retired, and so on)
Active revision	The exact validated revision ID
Safe fingerprint	The safe public-material verification fingerprint
Validation / refresh	Validation status and refresh health
Policy / keys	Policy count and derived-key counts (total and active)
Enrollment decision	The last enrollment’s decision or compatibility status
Runtime activation	Runtime activation status or target activation state
Detail	An Inspect link that opens the exact source

If the site has no sources, the screen prompts you to create an automated source or use Client Vault for a manual public key.

Create a source draft

The Create Trust Anchor Source wizard accepts a source kind, a display name, and the public verification metadata that kind requires. Creating a source requires Trust Anchor administration permission and produces a draft — it does not consume capacity or accept enrollments yet.

Available source kinds and their verification inputs:

Manual Client Vault public key — manual keys stay in Client Vault. They do not create an automated source, do not consume an automated slot, and do not use this wizard; the screen links to Client Vault instead.
OIDC JWKS — issuer, JWKS URI, and audience. Paste only public issuer and JWKS coordinates, never a token.
CI OIDC — issuer, JWKS URI, and audience for CI-issued OIDC workload identities.
SPIFFE JWT-SVID — JWT-SVID issuer, trusted JWKS URI, SPIFFE trust domain, and audience. TA-G1 supports SPIFFE JWT-SVID only; SPIFFE X.509 SVID is not currently supported.
Kubernetes service account OIDC — OIDC issuer, an optional public JWKS URI override, and audience.
AWS EC2 instance identity — AWS partition or provider identity, AWS account, region, and the public AWS signing certificate (PEM) used to verify the exact IID document. TA-G1 EC2 identity is operator-approved; STS and SigV4 proof profiles are not currently supported.
GCP instance identity — provider identity, GCP project, and audience.
Azure instance identity — you first choose the immutable Azure proof mode for the source revision. managed_identity_jwt takes Azure issuer, JWKS URI, expected audience, tenant ID, and an optional subscription ID. imds_attested_document takes only the public Azure IMDS trust-root certificate (PEM) plus optional tenant and subscription IDs. The proof mode is stored with the source revision, and enrollment commands cannot switch between the two.

Do not paste a signed assertion, bearer token, raw proof, private key, or secret. PEM fields accept public verification certificates and trust roots only.

Appearing in this wizard is only the first rung of the claims ladder: every kind above is selectable, but selectable does not mean supported. Check Trust Anchor source availability for which profiles are supported before you plan a rollout on one of them.

Validate and activate the source

Inspect the draft you created to move it through its lifecycle: draft → validate → activate. The Selected source panel shows the source’s lifecycle status, profile and active revision, validation status, detected verifier scope, safe verification fingerprint, refresh health, policy count, derived-key counts, enrollment decision and compatibility status, runtime activation, and a safe failure reason when validation fails.

Four lifecycle actions are available with Trust Anchor administration permission:

Validate — asks Control to validate the source’s public metadata. Disabled once the source is active.
Activate — activates the source after Control reports a valid revision and entitlement. Disabled once active.
Suspend — available only while the source is active or activating.
Retire — available unless the source is already retired, retiring, or legacy-unscoped.

Suspend and retire are guarded: you must type suspend or retire into the lifecycle confirmation field before the matching button enables. Activate a source only after Control reports a valid revision, a safe fingerprint, and a detected verifier scope that matches what you intended.

Create an enrollment policy

An enrollment policy binds one exact source revision to one existing client in this Auth Site. The resulting derived key inherits that client’s protected-resource authorization — no routes, grants, scopes, access modes, or caller-supplied identity are configured here. Manual Client Vault keys do not use enrollment policies.

The policy form takes:

Source and its read-only source revision — the exact active validated revision.
Existing client — selected from the clients already in this site.
Approval — Automatic or Operator required. AWS EC2 instance identity is always operator-approved in TA-G1.
Maximum key lifetime — in seconds, between 60 and 2,592,000.
Policy selectors — kind-specific fields such as OIDC subject, CI organization and repository, SPIFFE trust domain and ID, Kubernetes namespace and service account, or cloud account, project, and tenant identifiers.
Verified identity binding — exact fields derived by Control’s verifier, compared at enrollment time. Verified subject is required. These are comparison values, not proof input: the browser never supplies a token, signed document, or caller-selected subject.

The Exact-site enrollment policies table lists each policy with its source, source revision, client, verified identity binding, approval mode, and an Inspect link. Inspecting a policy also shows the read-only Inherited protected-resource authorization table — the protected surfaces, APIs, methods and paths, access modes, and canonical signing routes the derived key inherits from the selected client. A policy cannot add authorization.

Generate the enrollment command

For an automated source with a selected policy, the Enrollment command generator builds the trustplane enroll command a workload runs. The command contains no secret values: it creates a mode-0600 local private key at the path you choose and carries only a proof transport choice. It never prints or stores a private key, signed proof, or token, and the CLI obtains its one-time enrollment challenge nonce transiently — the console never requests, displays, or stores it.

The generator uses:

The configured public Control URL — read-only. If a validated public Control API URL is not configured, the command is unavailable; the console never substitutes its browser origin or a private endpoint.
The opaque policy reference returned by Control for the exact policy. If Control does not return one, the command is unavailable — the reference is never reconstructed from internal IDs.
A private key file path for the workload-local key.
A proof transport — provider default (for example, the SPIFFE Workload API), a proof file path, or standard input. OIDC JWKS and CI OIDC sources require an explicit proof file or stdin. AWS EC2 IID is acquired from IMDSv2 by the CLI, with operator approval still required. Azure sources follow the revision’s immutable proof mode: managed_identity_jwt tokens are acquired by the CLI from Azure IMDS, while imds_attested_document uses PKCS#7 and compute-metadata files or acquires a nonce-bound document from Azure IMDS directly.

If the selected policy is not bound to the exact selected source, the generator refuses to produce a command — reload from the policy’s source-scoped Inspect link. Use Copy command to copy the generated command; a manual-copy fallback appears when clipboard access is unavailable.

For the complete end-to-end Kubernetes flow this generator supports — gathering issuer and JWKS coordinates, projecting the ServiceAccount token, and running trustplane enroll in the workload — see OIDC JWKS enrollment runbook.

Track enrollment progress and approvals

The Source-specific enrollment progress table reports stages derived only from the selected source and its enrollment: source validated, source active, refresh health, policy and derived-key counts, the enrollment decision, runtime activation, compatibility status, and a safe failure reason. It never uses general Auth Site readiness as a proxy for an exact target acknowledgement. Manual static distribution always reports awaiting_manual_distribution.

When an enrollment request needs review, the Enrollment request panel shows the request ID, source, client, enrollment decision, compatibility status, and runtime activation. Operators with Trust Anchor administration permission can Approve enrollment with an optional note or Reject enrollment with a required rejection reason — but only while the request is awaiting approval. Approval uses only the request Control already returned for this exact site; the operator cannot select a client, key ID, authorization, route, or subject here. See Enrollments for the approval queue.