Note: A kypello-io Homebrew tap is not yet available. Use binary releases or build from source instead.

For development, you can install the upstream MinIO KES which is API-compatible:

brew install minio/stable/kes

Pull the latest release via:

docker pull ghcr.io/kypello-io/kes:latest

Download the binary via curl but replace <OS> and <ARCH> with your operating system and CPU architecture.

curl -sSL --tlsv1.2 'https://github.com/kypello-io/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/kypello-io/kes/releases/latest/download/kes-<OS>-<ARCH>.minisig' -o ./kes.minisig

minisign -Vm ./kes -P RWTx5Zr1tiHQLwG9keckT0c45M3AGeHD6IvimQHpyRywVWGbP1aVSGav

Note: If using minisign verification, the signing key may still be MinIO's key until Kypello establishes its own signing infrastructure.

Download and install the binary via your Go toolchain:

go install github.com/kypello-io/kes/cmd/kes@latest

For testing and development, start a KES server with in-memory storage:

kes server --dev

This starts KES at https://127.0.0.1:7373 with a self-signed certificate and prints the API key to the console.

In a new terminal, point the KES CLI to your local server:

export KES_SERVER=https://127.0.0.1:7373
export KES_API_KEY=<copy-from-server-output>

Create a new root encryption key - e.g. my-key:

kes key create my-key

Note: Creating a key will fail with key already exists if it already exists.

Derive a new data encryption key (DEK):

kes key dek my-key

The plaintext part of the DEK is used by applications to encrypt data. The ciphertext part is stored alongside the encrypted data for future decryption.

Production Setup: For production deployments, configure KES with a proper KMS backend (Vault, AWS KMS, etc.) instead of in-memory storage. See the integration guides for details.

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:

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

2. 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, like my-key-1 or a pattern allowing arbitrary key names, like my-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.