docs/source/includes/linux/common-minio-kes.rst

Download the latest stable release () of KES from github.com/minio/kes <kes/releases/latest>.

Select the binary appropriate for the host OS architecture. For example, hosts running X86-64 (Intel/AMD64) should download the kes-linux-amd64 package.

The following example code downloads the latest Linux AMD64-compatible binary and moves it to the system PATH:

curl --retry 10 https://github.com/minio/kes/releases/download/|kes-stable|/kes-linux-amd64 -o /tmp/kes
chmod +x /tmp/kes
sudo mv /tmp/kes /usr/local/bin

kes --version

For distributed KES topologies, repeat this step and all following KES-specific instructions for each host on which you want to deploy KES. MinIO uses a round-robin approach by default for routing connections to multiple configured KES servers. For more granular controls, deploy a dedicated load balancer to manage connections to distributed KES hosts.

Create the /etc/systemd/system/kes.service file on all KES hosts:

/extra/kes.service

You may need to run systemctl daemon-reload to load the new service file into systemctl.

The kes.service file runs as the kes User and Group by default. You can create the user and group using the useradd and groupadd commands. The following example creates the user and group. These commands typically require root (sudo) permissions.

groupadd -r kes
useradd -M -r -g kes kes

The kes user and group must have read access to all files used by the KES service:

chown -R kes:kes /opt/kes

Run the following command on each KES host to start the service:

systemctl start kes

You can validate the startup by using systemctl status kes. If the service started successfully, use journalctl -uf kes to check the KES output logs.

For new MinIO deployments, run the following command on each MinIO host to start the service:

systemctl start minio

For existing MinIO deployments, run the following command on each MinIO host to restart the service:

systemctl reload minio
systemctl restart minio

Enabling connectivity between MinIO and KES requires at minimum one TLS certificate for performing mutual TLS (mTLS) authentication. Depending on your Vault configuration, you may also need to create a dedicated set of TLS certificates for KES to connect and authenticate to Vault. Defer to your organizations best practices around generating production-ready TLS certificates.

Place the certificates and corresponding private keys an appropriate directory such that the MinIO and KES service users can access and read their contents. The following example structure uses the folder hierarchy suggested in the beginning of this procedure:

KES Hosts

-rw-r--r-- 1 kes:kes |kescertpath|/kes-server.cert
-rw-r--r-- 1 kes:kes |kescertpath|/kes-server.key

# If the Vault certs are self-signed or use a non-global CA
# Include those CA certs as well

-rw-r--r-- 1 kes:kes |kescertpath|/vault-CA.cert

MinIO Hosts

-rw-r--r-- 1 minio-user:minio-user |miniocertpath|/minio-kes.cert
-rw-r--r-- 1 minio-user:minio-user |miniocertpath|/minio-kes.key

# If KES certs are self-signed or use a non-global CA
# Include the CA certs as well
-rw-r--r-- 1 minio-user:minio-user |miniocertpath|/kes-server.cert

The general strategy for cert management is to ensure that each process (MinIO, KES, and Vault) have their own mTLS certificates and the Certificate Authority (CA) used to sign each client certificate.

MinIO requires that the exist on the root KMS before performing operations using that key. Use kes key create or mc admin kms key create to add a new for use with .

The following command uses the kes key create command to add a new External Key (EK) stored on the root KMS server for use with encrypting the MinIO backend.

export KES_SERVER=https://127.0.0.1:7373
export KES_CLIENT_KEY=|miniocertpath|/minio-kes.key
export KES_CLIENT_CERT=|miniocertpath|/minio-kes.cert

kes key create -k encrypted-bucket-key