Enterprise: present Image Factory credentials as customer ID + API keys, never expose secrets

[sterlingkoch]

Problem Description

Enterprise Image Factory credentials are presented as a "username" and "password" — shared-credential semantics, with the secret handled like a human login. Enterprise customers expect API-key semantics: a per-customer identifier plus a revocable secret.

The original driver for this ticket — plaintext credentials embedded in the download/boot URLs of the install-media dialog — is now owned elsewhere: image download URLs are replaced by signed download tokens (#3138, mechanism shipped in siderolabs/image-factory#509), and security artifacts (SBOM/VEX/scan reports) will be served through Omni server-side so factory credentials never reach the browser (#3166).

What neither of those covers is the credential the customer holds and uses outside Omni:

• The cluster create command on the install-media confirmation screen renders --image-factory-auth='username:password' — the local cluster pulls the installer from the factory and must authenticate to it.
• The installer image in the machine config is pulled from the enterprise factory's registry, so machines authenticate with registry credentials.
• Self-hosted Omni is itself configured with factory credentials (registries.factories.primary).

These need a durable credential — a short-lived link can't serve them. The question this ticket answers is what shape that credential takes and how it is presented.

The shape is already half-decided: the factory accepts Auth0 bearer tokens in the Basic auth password field (siderolabs/image-factory#514), because OCI and Talos registry clients only speak Basic. So what a customer holds is an identifier plus a token — customer ID + API key. The rename describes what the credential now actually is.

Solution

• Rename throughout the enterprise UI: "username" → customer ID, "password" → API key.
• Deliberate, never incidental: a credential appears only where the user explicitly asked for it (e.g. the cluster-create command they're about to copy), never baked into rendered URLs, download links, or page content as a side effect. Surfaces that just need an authenticated fetch use Support time-based signed download URLs #3138 tokens (images) or the Serve EIF security artifacts through Omni (API + UI) instead of client-side factory fetches #3166 server-side path (artifacts).
• Align rotation language with the Auth0 model: revocation/rotation happens on the identity side; when Omni's own factory credential rotates, Omni reconciles the change out to machine configs.

Out of scope

• Removing credentials from download URLs — Support time-based signed download URLs #3138 (images) and Serve EIF security artifacts through Omni (API + UI) instead of client-side factory fetches #3166 (security artifacts).
• The auth backend itself (Auth0 provider rollout, machine-account/API-key semantics) — ops track, feat: add auth0 bearer token authentication image-factory#514.
• Show-once-at-creation presentation — parked. Omni has no credential creation flow to hang it on; it returns with the RFD 38 provisioning work.

Notes

• The credential is already redacted in the Talos machine config; this ticket is about the UI surfaces.
• Related: Support time-based signed download URLs #3138 (signed download URLs), Serve EIF security artifacts through Omni (API + UI) instead of client-side factory fetches #3166 (artifacts through Omni), fix(frontend): add missing credentials to security pages #3248 (consolidated the current embedded-credential path into useResolvedFactory — the code the rename lands in), feat: add auth0 bearer token authentication image-factory#514 (tokens in the Basic password field).

[sterlingkoch]

Rewrote the description. The original was written July 15, before the pieces that reshaped it: signed download tokens shipped (siderolabs/image-factory#509), Auth0 was selected with tokens accepted in the Basic password field (siderolabs/image-factory#514), and we decided security artifacts get served through Omni server-side (#3166). Its third solution bullet — "Remove embedded credentials from all displayed URLs" — is now owned by #3138 and #3166, so read as written the ticket looked like a rename plus URL cleanup that other work already covers.

What it actually covers is the credential customers hold and use outside Omni — the cluster-create command, registry pulls of the installer image, self-hosted Omni's factory config — where a durable credential is required and short-lived links can't help. The rewrite scopes it to that: the customer ID + API key shape, and a "deliberate, never incidental" rendering rule.

Also dropped "never render an API key in clear text anywhere in the UI after creation" — that can't hold while the confirmation screen shows a working cluster-create command. And parked the show-once-at-creation piece: there's no credential creation flow in Omni yet, so it returns with the RFD 38 provisioning work rather than sitting here as scope.