OpenBao Transit-backed Master KEK: never export the root key

Problem/Motivation

The roadmap's OpenBao item planned a Key provider that fetches the Master KEK from the store into Drupal. A stronger design is to never bring the Master KEK into Drupal at all, using the Transit secrets engine (encryption as a service): the Master KEK is a Transit key created in the store and never exported. Drupal sends a freshly generated Subject KEK to transit/encrypt and stores the returned ciphertext; it sends that ciphertext to transit/decrypt to get the Subject KEK back. A full Drupal compromise then cannot exfiltrate the root key for offline or permanent decryption. The Transit API is identical on OpenBao and HashiCorp Vault, so this works against either.

Proposed resolution

Implemented as a pluggable Master KEK wrap mechanism in pdv core, plus a submodule that implements it against Transit.

pdv core gains a MasterKeyWrap plugin type (attribute, interface, base, manager). The default local plugin keeps today's local-AEAD wrapping. SubjectKeyManager selects the plugin by the Master KEK Key's type (not by a cipher suite), so existing local keys are unchanged and new mechanisms slot in:

• create: the chosen plugin wraps the new Subject KEK; the returned blob is stored as wrapped_key.
• unwrap: the plugin recorded on the row unwraps it.
• rotate: when source and target share a mechanism the plugin's native rewrap is used (for Transit, transit/rewrap, so the Subject KEK plaintext never leaves the store); across mechanisms it unwraps with the source and re-wraps with the target.

The Master KEK selectors (site-wide and per-tenant) offer keys whose type a wrap plugin claims.

pdv_vault submodule adds a vault_transit wrap plugin and a pdv_vault_transit Key type whose value is the Transit key name. It calls the store directly over HTTP, so it needs no extra dependencies. The Transit key is created with derived=true and every call passes the owner identity as the per-call context, giving the same owner-binding as the local AEAD.

Auth. The token only needs encrypt/decrypt/rewrap on the one Transit key (never key export, never reading arbitrary secrets), supplied from settings.php or an environment variable, never DB config.

Trade-offs

• The Subject KEK plaintext still transits to and from the store on create and unwrap (Drupal needs it to wrap document DEKs); only the Master KEK never leaves, and during rotation the Subject KEK does not either.
• Every owner-key resolve becomes a store round-trip (latency and an availability dependency), versus fetch-the-master-once-then-local-crypto. The standard KMS/HSM trade-off.

Remaining tasks

• Review and merge the merge request.

API changes

New MasterKeyWrap plugin type in pdv core. SubjectKeyManager (which is @internal) gains the wrap-plugin manager as a constructor argument. No behaviour change for existing local Master KEKs.

User interface changes

The Master KEK select on the settings and tenant forms now also lists keys whose type a wrap plugin handles. Setup is documented in a new "Master KEK in OpenBao or Vault" handbook page.