albs-sign-node, albs-sign-file: support fetching GPG key passphrases from HashiCorp Vault

[anfimovdm]

Background

#280 ("Bitwarden (and other vaults) integration in sign service") added the ability to
fetch GPG key passphrases from a Bitwarden vault, and was closed once Bitwarden
shipped. The "other vaults" part was never done, so HashiCorp Vault is not an
option for sign nodes today.

Currently a sign node operator has exactly two non-interactive choices:
Bitwarden, or development_mode with a single shared passphrase. Everything
else falls back to an interactive getpass prompt at startup, which is what
makes unattended restarts painful.

Goal

Allow both sign services to pull per-key GPG passphrases from HashiCorp Vault
at startup, as an alternative to Bitwarden.

Why this is small

The Bitwarden work already introduced the right seam. Passphrases are resolved
once at startup and handed to PGPPasswordDB as preloaded_passwords:

• albs-sign-node: almalinux_sign_node.py calls
  sign_node/utils/bitwarden.py::fetch_passphrases() when
  config.bitwarden_enabled, and passes the result into
  PGPPasswordDB(..., preloaded_passwords=...)
  (sign_node/utils/pgp_utils.py).
• albs-sign-file: same shape — sign/pgp/bitwarden.py::fetch_passphrases(),
  consumed by sign/pgp/pgp_password_db.py, whose documented precedence is
  already preloaded passwords > development password > interactive prompt.

So Vault support is a second provider returning the same
Dict[keyid, passphrase], not a rework of the signing flow.

Proposed scope

1. Provider abstraction

Rather than bolting a second if onto each entrypoint, introduce a small
secrets provider layer with bitwarden and vault implementations, both
returning Dict[str, str] keyed by GPG keyid and raising
ConfigurationError when a requested keyid is missing (Bitwarden's current
fail-fast behaviour — do not silently fall through to an interactive prompt
when a backend is explicitly enabled).

Enabling two providers at once should be a configuration error, not a
merge — signing keys should have one unambiguous source of truth.

2. albs-sign-node config (flat keys, cerberus schema in
sign_node/config.py, alongside the existing bitwarden_* keys):

vault_enabled: false
vault_addr: https://vault.example.com:8200
vault_namespace:            # optional, Vault Enterprise / HCP
vault_mount: secret         # KV v2 mount point
vault_path_prefix: albs/sign-keys
vault_token_file: /run/secrets/vault_token
vault_role_id:              # AppRole alternative to a static token
vault_secret_id_file:
vault_ca_cert:              # optional custom CA bundle

3. albs-sign-file config (nested pydantic section in sign/config.py,
mirroring the bitwarden: block in config.yaml, with SF_VAULT_* env
overrides):

vault:
  enabled: false
  addr: https://vault.example.com:8200
  mount: secret
  path_prefix: albs/sign-keys
  token_file: /run/secrets/vault_token

4. Secret layout

One KV v2 secret per key at <mount>/<path_prefix>/<keyid> with a
passphrase field, e.g.:

vault kv put secret/albs/sign-keys/7C3955C2A345DA89 passphrase='...'

This keeps the Bitwarden convention (one item per keyid) while using a
field name that actually describes the value, instead of Bitwarden's
password. The field name should be configurable for operators with an
existing layout.

5. Authentication

Support a static token (from *_token_file, preferred over an inline value)
and AppRole (role_id + secret_id_file). VAULT_TOKEN / VAULT_ADDR from
the environment should be honoured as a fallback so the services work
naturally on a host that already has a Vault agent.

Token renewal is explicitly out of scope: passphrases are read once at
startup, so a short-lived token is sufficient and no long-lived session needs
to be maintained in-process.

6. Dependency

Use hvac. In albs-sign-file add it as a [vault] extra next to the
existing [bitwarden] extra in setup.py, and import it lazily so the
dependency is only required when the backend is enabled (same pattern as
sign/pgp/bitwarden.py). Mirror the lazy import in albs-sign-node.

Acceptance criteria

• With vault_enabled: true and all keyids present in Vault, both
  services start with no interactive prompt and sign successfully.
• A missing keyid, an unreachable/sealed Vault, or a bad token fails at
  startup with a clear error naming the offending keyid or condition —
  no silent fallback to a prompt or to a dev passphrase.
• Enabling Bitwarden and Vault simultaneously is rejected at config
  validation time.
• hvac is not required when the backend is disabled.
• Unit tests with a mocked hvac client, mirroring
  tests/sign_node/utils/test_bitwarden.py and the sign-file equivalent.
• README / config.yaml / node-config/sign_node.yml document the new
  keys and the expected Vault secret layout.

Out of scope

• Storing the GPG private keys themselves in Vault (only passphrases here).
• Vault Transit as a signing backend — that would replace local GPG entirely
  and deserves its own issue.
• Ansible/deployment wiring in albs-deploy — follow-up once the config
  surface is settled.

Related

• #280 — Bitwarden (and other vaults) integration in sign service (closed; this is the unfinished half)
• #542 — intermittent RPM sign failures, gpg-agent passphrase cache expiring

[anfimovdm]

Implementation PRs:

• albs-sign-node: feat: fetch GPG passphrases from HashiCorp Vault albs-sign-node#184
• albs-sign-file: feat: fetch GPG passphrases from HashiCorp Vault albs-sign-file#71

Both follow the same shape: a lazily-imported hvac KV v2 fetcher behind a small provider resolver that also owns the existing Bitwarden path.

Two decisions made while implementing, flagged for review in both PRs:

1. Strict mutual exclusion — enabling Bitwarden and Vault together is a configuration error rather than a precedence chain, since a signing key silently resolved from the wrong vault is a bad failure mode. Needs softening if a migration period requires both configured at once.
2. The Vault field is passphrase, not password — Bitwarden's wrapper hardcodes password, Vault has no such constraint. Configurable (vault_passphrase_field / vault.passphrase_field) for an existing layout.

The out-of-scope items in the description are untouched: private keys stay out of Vault, no Transit backend, and the albs-deploy wiring is still to do.