KES is a cloud-native distributed key management and encryption server designed to secure modern applications at scale.
KES is a distributed key management server that scales horizontally. It can either be run as edge server close to the applications reducing latency to and load on a central key management system (KMS) or as central key management service. KES nodes are self-contained stateless instances that can be scaled up and down automatically.
The KES server and CLI is available as a single binary, container image or can be build from source.
Homebrew
brew install minio/stable/kes
Binary Releases
OS | ARCH | Binary |
---|---|---|
linux | amd64 | linux-amd64 |
linux | arm64 | linux-arm64 |
darwin | arm64 | darwin-arm64 |
windows | amd64 | windows-amd64 |
Download the binary via curl
but replace <OS>
and <ARCH>
with your operating system and CPU architecture.
curl -sSL --tlsv1.2 'https://github.com/minio/kes/releases/latest/download/kes-<OS>-<ARCH>' -o ./kes
chmod +x ./kes
You can also verify the binary with minisign by downloading the corresponding .minisig
signature file.
Run:
curl -sSL --tlsv1.2 'https://github.com/minio/kes/releases/latest/download/kes-<OS>-<ARCH>.minisig' -o ./kes.minisig
minisign -Vm ./kes -P RWTx5Zr1tiHQLwG9keckT0c45M3AGeHD6IvimQHpyRywVWGbP1aVSGav
Build from source
Download and install the binary via your Go toolchain:
go install github.com/minio/kes/cmd/kes@latest
We run a public KES instance at https://play.min.io:7373
as playground.
You can interact with our play instance either via the KES CLI or cURL.
Alternatively, you can get started by setting up your own KES server in
less than five minutes.
First steps
Point the KES CLI to the KES server at https://play.min.io:7373
and use the following API key:
export KES_SERVER=https://play.min.io:7373
export KES_API_KEY=kes:v1:AD9E7FSYWrMD+VjhI6q545cYT9YOyFxZb7UnjEepYDRc
Create a new root encryption key - e.g. my-key
.
kes key create my-key
Note that creating a new key will fail with
key already exist
if it already exist.
Derive a new data encryption keys (DEK).
kes key dek my-key
The plaintext part of the DEK would be used by an application to encrypt some data. The ciphertext part of the DEK would be stored alongside the encrypted data for future decryption.
If you want to learn more about KES checkout our documentation.
KES servers provide an API endpoint /v1/metrics
that observability tools, like Prometheus, can scrape.
Refer to the monitoring documentation for how to setup and capture KES metrics.
For a graphical Grafana dashboard refer to the following example.
I have received an insufficient permissions
error
This means that you are using a KES identity that is not allowed to perform a specific operation, like creating or listing keys.
The KES admin identity
can perform any general purpose API operation. You should never experience a not authorized: insufficient permissions
error when performing general purpose API operations using the admin identity.
In addition to the admin identity, KES supports a policy-based access control model.
You will receive a not authorized: insufficient permissions
error in the following two cases:
-
You are using a KES identity that is not assigned to any policy. KES rejects requests issued by unknown identities.
This can be fixed by assigning a policy to the identity. Checkout the examples.
-
You are using a KES identity that is assigned to a policy but the policy either not allows or even denies the API call.
In this case, you have to grant the API permission in the policy assigned to the identity. Checkout the list of APIs. For example, when you want to create a key you should allow the
/v1/key/create/<key-name>
. The<key-name>
can either be a specific key name, likemy-key-1
or a pattern allowing arbitrary key names, likemy-key*
.Also note that deny rules take precedence over allow rules. Hence, you have to make sure that any deny pattern does not accidentally matches your API request.
Use of KES
is governed by the AGPLv3 license that can be found in the LICENSE file.