How should administrators handle Vault replication when clusters are integrated with an HSM?
Scenario: You have multiple Vault Enterprise clusters in replication relationships and would like to leverage seal wrapping/auto-unseal/entropy augmentation offered by HSM integration on all clusters.
With this scenario, you can design and integrate your HSM with the Vault nodes in the way that is most cost-effective and efficient for your organization without having concern with Vault requirements across clusters. There is no requirement to connect replica clusters to the same HSM if you're using replication, which should give you the flexibility to mix and match solutions to meet your needs. Each Vault cluster can have their own TPM (if it speaks PKCS #11) or HSM (can even be different brands).
The flexibility to mix and match HSMs allows some Vault admins to remove the need to purchase more expensive HA enabled HSMs just to achieve HA. Instead, they purchase 2 of the low priced non-HA HSMs, put an HSM behind each cluster, and use Vault replication. This way, if one of the Vault clusters or HSMs fails you still have another Vault cluster backed by a functioning HSM unsealed and ready to go, without having to pay more for HA in the HSM and also eliminating a single point of failure.
Vault's master key (KEK) is encrypted by the symmetric key in the HSM the Vault cluster is pointing at (stored at rest in the storage backend), and the encryption key (DEK) is the same between Vault clusters.
Note: You can also mix and match seal types with replication relationships. For example, a Performance Primary Vault cluster may be using an HSM pkcs11 Seal, whereas a Performance Secondary cluster might be using a Shamir or Cloud KMS Seal. This is possible because the encryption key is shared among Vault clusters.