Module vault 

Vault client used by handlers that need backend-specific secrets (Gitea token for create_session, Kubernetes credentials for the console and log-streaming handlers).

Token-fetch flow

Three steps every time secrets are needed (no caching):

1. http_client::auth_oidc_jwt POSTs the caller’s bearer token to /v1/auth/jwt-manta-<site>/login and pulls the auth.client_token out of the response.
2. http_client::get_secret GETs an arbitrary path with the X-Vault-Token header set to the client token and unwraps the .data field.
3. The caller (e.g. http_client::get_shasta_vcs_token) composes the secret path from site_name and reads the specific field it needs.

The flow is non-interactive — there is no human prompt at any point. If a site lacks Vault entirely, crate::server::common::app_context::InfraContext::vault_base_url is None and the calling handler returns 501 before ever entering this module. The Vault client token is short-lived and not cached across requests; every call re-runs auth_oidc_jwt.

Modules

http_client

Thin Vault HTTP client. Authenticates via OIDC/JWT against a per-site jwt-manta-<site> role, then reads K/V v2 secrets under manta/data/<...>.