Store HSM on Entrust KeyControl
MinIO KMS supports using Entrust KeyControl for storing the Hardware Security Module (HSM) key associated with a Root Encryption Key (REK).
The KeyControl instance stores the HSM such that a user with access to the cluster MinIO KMS has no immediate access to the plaintext key value. You can enable an external HSM for MinIO KMS at any time after completing the initial installation.
Configuring an external KMS for HSM storage can help meet compliance requirements that prohibit keeping root or master keys on the same system as the encryption database. The total security of the system relies on protections applied to the final key in any such KMS chain. Ultimately basic security measures such as root access protection and systems of least privilege carry the same weight and importance across all encryption related services.
Prerequisites
This procedure assumes the following installations:
- The local or cluster MinIO KMS deployment
- The Entrust KeyControl deployment
The Entrust KeyControl instance must provide support for Application Security Vaults to support external HSM storage. The KeyControl user account used by MinIO KMS to access the application security vault must allow the following set of permissions:
EncryptDecryptGet Keys List
Refer to your Entrust KeyControl documentation for guidance on how to create an application security vault user and assign policies.
See the installation instructions for further guidance on deploying MinIO KMS.
Procedure
-
Obtain your application security vault ID. It is a UUID that forms part of the vault’s URL.
For example,
e5095f4a-8eea-4215-9038-8014442e984c. -
Create a new symmetric encryption key within your Vault under the
Keyssection.MinIO KMS recommends an
AES 256orAES 128key. -
Write the MinIO KMS server configuration with the
hsm.entrust.keycontrolsectionThe
minkmsHelm chart does not generate this section, so write the server configuration yourself:version: v1 # Other configuration settings above this line hsm: entrust: keycontrol: server: https://10.1.2.3:443 # KeyControl cluster endpoint vault: e5095f4a-8eea-4215-9038-8014442e984c # KeyControl vault ID key: my-key # Name of the encryption key created above. username: "minkms@example.com" # User account for accessing KeyControl password: "Nh[a7*J)oRbXR$wi74" # Password for the user account -
Store the configuration in a Secret
Create a Secret in the MinIO KMS namespace with a
server-config.yamlkey holding the configuration from the previous step:kubectl create secret generic minkms-server-config \ --namespace minkms \ --from-file=server-config.yaml=server-config.yamlThe key must be named
server-config.yaml, because the Operator reads that key and no other. The Secret name must be lowercase and use hyphens rather than underscores, because Kubernetes object names follow RFC 1123. -
Point the chart at that Secret
Open the chart values file in your preferred text editor. Set
minkms.configuration.existingSecrettotrueand setminkms.configuration.nameto the name of the Secret you created.Leave
minkms.hsm.keyin place. The chart requires either that static HSM key or an external HSM it can generate configuration for, which at present means another MinIO KMS cluster or HashiCorp Vault. The chart does not generate Entrust KeyControl configuration, so removing the key makeshelm upgradefail withAt least one HSM must be defined. -
Update the chart with the new
values.yaml:Use the
helm upgradecommand to upgrade the chart with the newvalues.yaml:helm upgrade minkms minio/minkms \ -n minkms \ -f minkms-values.yaml