Auto-Unseal
You can auto-unseal your OpenBao instance with Securosys Primus HSM and CloudHSM. This works through both the PKCS#11 and REST API, and is implemented via OpenBao plugins.
Background
OpenBao stores secrets using encryption-at-rest. When OpenBao starts, the vault needs to be unsealed before it can be used. Unsealing decrypts the keys that encrypt the secrets.
Traditionally, HashiCorp Vault, and now its fork OpenBao, have used Shamir's secret sharing to protect the key that unlocks the vault. However, this has the disadvantage that multiple human operators need to come together to manually unseal the vault. This can cause availability issues when the OpenBao restarts at unplanned times (for example, during the night).
To address this, OpenBao has introduced auto-unsealing. In this setup, the key needed to unseal the vault is stored in an HSM or a KMS. Thus, you can now use your Securosys Primus HSM or CloudHSM to automatically unseal your OpenBao vault when it starts.
Benefits
- Automatically unseal your vault when OpenBao starts. No more manual unsealing by human operators. Less downtime.
- If desired, maintain fine-grained control using SKA keys.
- Protect the unseal key with the strong physical protections of an HSM.
Installation
Auto-unsealing is available through two separate OpenBao plugins, giving you the choice between PKCS#11 and REST.
Both options are production-ready and actively maintained. Which options is "better" depends on your existing environment and your deployment preferences. The differences are the following:
| Pro | Con | |
|---|---|---|
| PKCS#11 |
|
|
| REST |
|
|
If in doubt, choose the REST option. It is often easier to set up, especially in CloudHSM where Securosys hosts the TSB for you.
You can migrate between different sealing methods. For example, you can migrate from manual sealing to auto-unseal, or from PKCS#11 to REST auto-unseal.