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 /lib/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

KES requires TLS connectivity for all client connections, including those originating from MinIO. See minio-tls for more information on enabling TLS for the MinIO deployment.

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 organization's best practices around generating production-ready TLS certificates.

Place the certificates and corresponding private keys in a directory that the KES service user has permissions to access and read the directory's contents. For example:

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

mc admin kms key create ALIAS KEYNAME