b11adfa5cd
This commit simplifies the KMS configuration guide by adding a get started section that uses our KES play instance at `https://play.min.io:7373`. Further, it removes sections that we don't recommend for production anyways (MASTER_KEY). |
||
---|---|---|
.. | ||
kes-config.toml | ||
README.md | ||
vault-config.json | ||
vault-legacy.md |
KMS Guide
MinIO uses a key-management-system (KMS) to support SSE-S3. If a client requests SSE-S3, or auto-encryption is enabled, the MinIO server encrypts each object with an unique object key which is protected by a master key managed by the KMS.
Quick Start
MinIO supports multiple KMS implementations via our KES project. We run
a KES instance at https://play.min.io:7373
for you to experiment and quickly get started. To run MinIO with
a KMS just fetch the root identity, set the following environment variables and then start your MinIO server.
If you havn't installed MinIO, yet, then follow the MinIO install instructions
first.
- As initial step fetch the private key and certificate of the root identity:
curl -sSL --tlsv1.2 \ -O 'https://raw.githubusercontent.com/minio/kes/master/root.key' \ -O 'https://raw.githubusercontent.com/minio/kes/master/root.cert'
- Set the MinIO-KES related environment variables:
export MINIO_KMS_KES_ENDPOINT=https://play.min.io:7373 export MINIO_KMS_KES_KEY_FILE=root.key export MINIO_KMS_KES_CERT_FILE=root.cert export MINIO_KMS_KES_KEY_NAME=my-minio-key
- Start the MinIO server:
export MINIO_ACCESS_KEY=minio export MINIO_SECRET_KEY=minio123 minio server ~/export
The KES instance at
https://play.min.io:7373
is meant to experiment and provides a way to get started quickly. Note that anyone can access or delete master keys athttps://play.min.io:7373
. You should run your own KES instance in production.
Configuration Guides
A typical MinIO deployment that uses a KMS for SSE-S3 looks like this:
┌────────────┐
│ ┌──────────┴─┬─────╮ ┌────────────┐
└─┤ ┌──────────┴─┬───┴──────────┤ ┌──────────┴─┬─────────────────╮
└─┤ ┌──────────┴─┬─────┬──────┴─┤ KES Server ├─────────────────┤
└─┤ MinIO ├─────╯ └────────────┘ ┌────┴────┐
└────────────┘ │ KMS │
└─────────┘
So, there are n
MinIO instances talking to m
KES servers but only 1
central KMS. The most simple
setup consists of 1
MinIO server or cluster talking to 1
KMS via 1
KES server.
The main difference between various MinIO-KMS deployments is the KMS implementation. The following table helps you select the right option for your use case:
KMS | Purpose |
---|---|
Hashicorp Vault | Local KMS. MinIO and KMS on-prem (Recommended) |
AWS-KMS + SecretsManager | Cloud KMS. MinIO in combination with a managed KMS installation |
FS | Local testing or development (Not recommended for production) |
The MinIO-KES configuration is always the same - regardless of the underlying KMS implementation. Checkout the MinIO-KES configuration example.
Further references
- Run MinIO with TLS / HTTPS
- Tweak the KES server configuration
- Run a load balancer infront of KES
- Understand the KES server concepts
Auto Encryption
Optionally, you can instruct the MinIO server to automatically encrypt all objects with keys from the KES server - even if the client does not specify any encryption headers during the S3 PUT operation.
Auto-Encryption is especially useful when the MinIO operator wants to ensure that all data stored on MinIO gets encrypted before it's written to the storage backend.
To enable auto-encryption set the environment variable to on
:
export MINIO_KMS_AUTO_ENCRYPTION=on
Note that auto-encryption only affects requests without S3 encryption headers. So, if a S3 client sends e.g. SSE-C headers, MinIO will encrypt the object with the key sent by the client and won't reach out to the KMS.
To verify auto-encryption, use the mc
command:
mc cp test.file myminio/bucket/
test.file: 5 B / 5 B ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ 100.00% 337 B/s 0s
mc stat myminio/bucket/test.file
Name : test.file
...
Encrypted :
X-Amz-Server-Side-Encryption: AES256