Credential encryption key: keep it outside the catalog and add a rotation path #707

Raised by @jcshepherd on #228.

Today

extenddb init generates the AES-256-GCM key that encrypts stored access key secrets and the secret keys of the temporary credentials AssumeRole issues. It stores the key, base64 encoded and not wrapped by any other key, as the encryption_key entry of the catalog's settings table (the settings collection on MongoDB) on all four backends. The server reads it from the catalog and caches it in memory.

The key and the ciphertext it protects are in the same database, so read access to the catalog, or to a catalog backup, yields every stored secret. There is no way to rotate the key: re-keying means re-creating the access keys. #228 documents this boundary in docs/manuals/10-security-model.md.

Request

Let the operator keep the key, or the key that wraps it, outside the catalog. Options named on #228:

• wrap the key with an external key management service or an HSM, so the catalog holds only the wrapped key;
• unwrap or derive it from a passphrase the operator supplies when the server starts;
• a pluggable key provider, so a deployment can add its own.

Add a rotation path that re-encrypts the stored secrets under a new key without re-creating the access keys.

Questions for the design

• Which providers come first, and where a provider is configured (extenddb.toml, the environment, a plugin).
• What the server does when the provider cannot be reached at start-up, and whether it keeps caching the unwrapped key in memory.
• How an existing deployment moves over: wrap the current key in place, or re-encrypt every secret.
• How rotation treats secrets written while it runs, on each backend.
• What backup and restore carry, and what a restore into another deployment needs.

This changes the on-disk format, so the pull request template asks for an RFC before the code.