Caveat: this method is not for very high value secrets, where you want to protect the secrets even against somebody breaking into a machine running vault. It does however, I think, protect against anybody discovering the secrets from backup copies.
I recently learned that gpg can store its keys on cheap smartcards, including Yubikeys:
I’m not using this in production, but I did a proof of concept where I could create a vault store that I can scriptably unseal while storing the base encryption key in a yubikey 4 where it can’t be read back. I initialized the key and store with these steps:
- gpg --expert --full-gen-key, select 4096-bit encrypt-only key with name “vault seal”, email vault@seal, and no passphrase.
- Move the key to the yubikey with gpg --edit-key and keytocard.
- gpg -a --export vault >vaultseal.pub
- vault operator init -key-shares=1 -key-threshold=1 -pgp-keys=vaultseal.pub
- copy/paste the given unseal key into vaultseal.gpg.b64
- vault operator unseal $(echo 123456|gpg --passphrase-fd=0 --pinentry-mode=loopback --decrypt <(base64 --decode </etc/vault/vaultseal.gpg.b64))
The reason why it doesn’t protect against breakins into the machine is that an attacker could run the command in backquotes and get the unencrypted unseal key, but a backup will be fully encrypted. On the other hand if you have a mechanism to exclude certain files from backup, you could store the unseal key unencrypted and just keep that file from getting backed up.
What I think would be ideal would be an unseal mechanism builtin to vault that was integrated with opensc the way gpg is.