Deploy MinIO KMS as a Container

MinIO KMS is licensed under the MinIO Software License.

MinIO Key Management Service (KMS) supports deploying as a container for supporting local development and evaluation.

In this tutorial you will create a single node MinIO KMS cluster that stores cryptographic key data on a host-local storage device. This node has no redundancy outside of that provided by the underlying storage. Local data modification or deletion results in the loss of both local cryptographic keys and remote data encrypted with those keys.

For production environments, use either the Linux or Kubernetes installation procedures.

This procedure assumes you have an existing Docker or Podman installation configured.

Procedure

1. Pull the latest stable image of MinIO KMS

2. Create directory structure

This procedure uses a folder structure that stores MinIO KMS data and configurations under ${HOME}/minkms. You can modify these paths to reflect your environment.

mkdir -p ${HOME}/minkms/{data,certs}

3. Download certgen and create certificates

certgen creates self-signed certificates for TLS encryption suitable for MinIO KMS. Download the binary for your platform from the minio/certgen repository. Either move the binary to a directory in your PATH or specify the path to directly run the binary.

The following command creates a self-signed certificate for localhost and 127.0.0.1. You can modify the --host string to indicate additional hostnames or IP addresses based on your local container environment.

cd ${HOME}/minkms/certs
certgen --host "localhost, 127.0.0.1"

The command outputs a public.crt and private.key in the directory.

4. Create the configuration file

Create a file at ${HOME}/minkms/config.yaml with the following content:

version: v1

tls:
  certs:
  - key: /etc/minkms/certs/private.key
    cert: /etc/minkms/certs/public.crt

The paths specified in the configuration file represent the container’s directory structure.

5. Create the environment file

Create a file at ${HOME}/minkms/minkms.env with the following content:

MINIO_KMS_HSM_KEY=hsm:aes256:KEYVALUE

MINIO_KMS_VOLUME=/mnt/minio-kms

You can generate a new key by running the minkms --soft-hsm command:

Replace the KEYVALUE with the command output.

6. Start the MinIO KMS server

The following command starts the MinIO KMS server in a container. It maps the files and configurations you created in the previous steps to the container structure.

The command starts the container attached to the current shell session. You can optionally add the run -d flag to run the container in the background.

The output includes the root API Key as k1:VALUE. If you run the container in a detached mode, use the docker|podman logs command to retrieve the API key. Save the value to a secure location for use in the next steps.

7. Connect to the MinIO KMS server.

Follow the MinIO KMS installation instructions to install the minkms binary to your local machine.

After installation, connect to the MinIO KMS server with the following command:

export MINIO_KMS_SERVER=https://127.0.0.1:7373
export MINIO_KMS_API_KEY=k1:VALUE
minkms stat -k

minkms env lists the variables the command line tool reads. MINIO_KMS_SERVER is one of them; MINIO_KMS_ENDPOINT is not. MinIO KMS serves HTTPS only, and certgen issues a self-signed certificate, which is why every command here carries -k.

The command returns the status of the MinIO KMS server.

Use the minkms binary to manage the MinIO KMS server. All changes persist to the mounted location ${HOME}/minkms/data.

8. Create an enclave and identity for AIStor

Each AIStor object store requires an enclave and identity for accessing MinIO KMS and performing cryptographic operations.

Run the following commands to generate the necessary resources. Change ENCLAVE_NAME to reflect the name or label you want to associate with AIStor.

minkms add-enclave -k ENCLAVE_NAME

minkms add-identity -k --enclave ENCLAVE_NAME --admin

The second command returns the API Key and Identity for use with AIStor. This enclave API key is not the same value as the root API key from step 6.

Record the enclave API key now. The command prints it once at creation. The server never stores it and cannot show it again.

Do not reuse the root API key as the object store’s API key. AIStor Object Store logs a warning at startup if the API key it receives has SysAdmin privileges.

9. Create the default server-side encryption key

The object store uses this key to encrypt object data.

minkms add-key -k --enclave ENCLAVE_NAME SSE_KEY_NAME

10. Configure the object store

Set the following environment variables on the AIStor Object Store.

Environment Variable Value
MINIO_KMS_SERVER The address the object store uses to reach the container, such as https://127.0.0.1:7373
MINIO_KMS_ENCLAVE The enclave name from step 8
MINIO_KMS_API_KEY The enclave API key from step 8, not the root API key from step 6
MINIO_KMS_SSE_KEY The encryption key name from step 9

The object store must also trust the MinIO KMS server certificate. Add public.crt to the object store’s certs/CAs directory, not the one inside this container. Depending on your container configuration, you may also need to run AIStor on the same host machine to ensure network access to the container.

Next steps

Setting the environment variables does not by itself encrypt anything. Restart the object store to apply them, then turn on default bucket encryption. AIStor Server Side Encryption covers both steps.