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).

K e y D a t a b a s e R D e e a c d r y e p n t c r D y B p t w e i d t h R o R o o t o t K e K y e y M i n I O K M S D e c r y p t u P s l i a n i g n t t e h x e t K R e o y o C t o n K t e r y o l e n c r y p t i o n E n k t e r y u s t K e y C o n t r o l

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:

  • Encrypt
  • Decrypt
  • Get 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

  1. 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.

  2. Create a new symmetric encryption key within your Vault under the Keys section.

    MinIO KMS recommends an AES 256 or AES 128 key.

  3. Modify the configuration file for the MinIO KMS cluster

    Open the configuration file in your preferred text editor and add the hsm.entrust.keycontrol section:

    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

    Make the same changes to all MinIO KMS nodes in the cluster deployment. You can then restart the nodes using systemctl restart minkms.

  4. (Optional) Disable the local HSM

    You can disable the local HSM used to initialize the cluster MinIO KMS after configuring the external HSM. This prevents using that HSM or its associated Root Encryption Key (REK) for accessing the encryption key database.

    Record the MINIO_KMS_HSM_KEY value somewhere secure before you remove it. It is the only way back if KeyControl cannot unseal the key database.

    Open the MinIO KMS environment file at /etc/default/minkms in your preferred text editor. Remove the MINIO_KMS_HSM_KEY line on one node and restart that node. Continue only after that node unseals the key database with KeyControl and resumes normal operation. Then repeat on the remaining nodes.

  5. Restart the MinIO KMS process

    You can then restart all nodes in the deployment using systemctl restart minkms. Monitor the system logs using journalctl -uf minkms to ensure successful startup and resumption of internode and client API operations.