Store HSM on Hashicorp Vault

AIStor Key Manager supports using Hashicorp Vault 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 A I S t o r K e y M a n D a e g c e r r y p t u P s l i a n i g n t t e r x a t n s R i o t o t e n K g e i y n e e n c r y p t i o n H a k s e h y i c o r p V a u l t

The Vault instance stores the HSM such that a user with access to the cluster Key Manager has no immediate access to the plaintext key value. You can enable the external HSM Key Manager at any time after completing the initial installation.

Configuring an external KMS for HSM storage can help meet compliance requirements around keeping root or master keys on the same system as the encryption database. The total security of the system however still 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 two Key Manager installations:

  • The local or cluster Key Manager deployment
  • The Hashicorp Vault deployment acting as HSM.

The Hashicorp Vault instance must provide support for the transit engine to support external HSM storage. The transit configuration must allow the following set of permissions:

path "transit/encrypt/minkms-sealing-key" {
   capabilities = [ "update" ]
}
path "transit/decrypt/minkms-sealing-key" {
   capabilities = [ "update" ]
}
path "transit/hmac/minkms-sealing-key" {
   capabilities = [ "update" ]
}

Refer to the Vault documentation for guidance on setup and configuration.

See the installation instructions for further guidance on deploying AIStor Key Manager.

Procedure

  1. Create the necessary tokens for authenticating to Vault

    Key Manager supports either the approle or the kubernetes authentication method.

    Prepare the following for this procedure:

  2. Modify the configuration file for the cluster Key Manager

    Open the configuration file in your preferred text editor and add the hsm.hashicorp.vault section:

    version: v1

# Other configuration settings above this line

hsm:
  vault:
    server: https://vault.example.net:8200
    approle:
      id: UUID # App Role ID
      secret: UUID # App Role Secret
      namespace: ns-1 # Optional namespace for the approle
      path: approle # Optional mount point for the approle
    transit:
      key: aistor-key-manager-hsm
      namespace: ns-1 # Optional namespace for the transit engine
      path: transit # Optional mount point for the transit engine

    Make the same changes to all AIStor Key Manager nodes in the cluster deployment. You can then restart the nodes using systemctl restart minkms.

  3. (Optional) Disable the local HSM

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

    Open the Key Manager environment file at /etc/default/minkms in your preferred browser. Remove the MINIO_KMS_HSM_KEY line on all nodes.

  4. Restart the key manager 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.