Within certain environments, customers want to leverage key management systems external to Vault, when handling, storing, and interacting with private key material, or are required to do so by standards requirements.
To satisfy these requirements, Vault has a centralized abstraction called Managed Keys that different secrets engines can plug into, allowing them to delegate these operations to a trusted external KMS.
Minimally, a managed key consists of a named managed key entry managed by the
sys/managed-key API. Besides a name,
there are backend specific configurations to access the key in question.
For PKCS#11 (HSM) backed managed keys, the managed key configuration must reference a kms library stanza which points to a PKCS#11 access library on the host machine.
Note that a configured, named managed key corresponds to a single key within a backend. More than one managed key can be configured targeting a single backend by creating multiple managed keys with the API.
Every configured Managed Key is bound to a given namespace, defaulting to the root namespace. Any secrets engine's mount path must exist within the same namespace as the Managed Key for which it intends to use.
Managed Keys were developed to support different types of external backends. At this time supported backends are PKCS#11, AWS KMS, Azure Key Vault, and Google Cloud KMS. Support for additional integrations may be added in the future.
The PKI Secrets Engine has been integrated with Managed Keys to offer certificate generation, both root and intermediary PKI paths, leveraging private keys from an external trusted KMS.
More engines may leverage managed keys in the future.
Managed Keys can be managed over the HTTP API. Please see Managed Keys API for more details.
To configure PKI secrets engine with Managed Keys please see PKI Secret API