When initializing the Vault, it is possible to supply gpg keys to use to encrypt the key shards. It would be useful to be able to specify a list of keys to encrypt the key shards so that only the owners of those shards can decrypt them. The CLI accepts either paths to files or Keybase ids of the form keybase:<username>. Looking at the API docs, it looks like the CLI does the resolution of Keybase IDs to public key material, so in theory the keys could be resolved from any keyserver.
A potential API for this could be something like this:
spec:
unsealer:
secretShares: 5
secretThreshold: 3
# secretCustodians must have `secretShares` entries
secretCustodians:
- kind: GPG
publicKey: <base64-encoded public key>
- kind: GPG
publicKeyId: <hexadecimal key id>
keyServers:
- hkp://keys.gnupg.net # This should be the default if no keyserver is specified.
# Could also support other options that gpg can use to lookup
# keys such as LDAP, though those options may require
# additional authentication configuration
- kind: Keybase
username: <keybase user name>
publicKeyId: <hexadecimal key id> # By default, use the first valid key
Since Vault will consume the public key material in the order it is presented, as long as the keys are supplied to Vault in the same order they are specified in keyCustodians, the existing method of naming the keys using their index should be sufficient, though potentially more meaningful names could be derived from the keys themselves or from an optional name field.
This feature would work best if #29 were implemented first, as the unsealer would no longer have access to the keyshards. Experimental work that we've done (by providing the unseal configuration as part of the spec.configSource ConfigMap) shows that native auto unsealing happens early enough in Vault's initialization that the unsealer never sees the Vault as sealed, so it's not absolutely necessary, though it requires a manual migration from a shamir seal created during initialization.
When initializing the Vault, it is possible to supply gpg keys to use to encrypt the key shards. It would be useful to be able to specify a list of keys to encrypt the key shards so that only the owners of those shards can decrypt them. The CLI accepts either paths to files or Keybase ids of the form
keybase:<username>. Looking at the API docs, it looks like the CLI does the resolution of Keybase IDs to public key material, so in theory the keys could be resolved from any keyserver.A potential API for this could be something like this:
Since Vault will consume the public key material in the order it is presented, as long as the keys are supplied to Vault in the same order they are specified in
keyCustodians, the existing method of naming the keys using their index should be sufficient, though potentially more meaningful names could be derived from the keys themselves or from an optionalnamefield.This feature would work best if #29 were implemented first, as the unsealer would no longer have access to the keyshards. Experimental work that we've done (by providing the unseal configuration as part of the
spec.configSourceConfigMap) shows that native auto unsealing happens early enough in Vault's initialization that the unsealer never sees the Vault as sealed, so it's not absolutely necessary, though it requires a manual migration from ashamirseal created during initialization.CLI Reference: https://www.vaultproject.io/docs/commands/operator/init.html API Reference: https://www.vaultproject.io/api/system/init.html
CLI code for retrieving keys from Keybase: https://github.com/hashicorp/vault/blob/master/helper/pgpkeys/keybase.go#L24:6 CLI code for reading keys from a file: https://github.com/hashicorp/vault/blob/master/helper/pgpkeys/flag.go#L99