Feng Ruohang
fd2ca1c6d2
README, README_ZH, SECURITY, COMPLIANCE, CONTRIBUTING, NOTICE, code_of_conduct, the vulnerability and PR-etiquette documents, the GitHub issue and pull request templates, and the docs/ tree all present Silo as the product. The Grafana dashboards under docs/metrics/prometheus/grafana/ have their panel titles and descriptions rebranded while every minio_* query, label and expression is left alone, so existing alerts and recording rules keep matching. The distinction the review demanded is applied per hit rather than by search-and-replace: - Product and command text becomes Silo and silo: install and run instructions, systemd examples, compose services, download links, badges. - Protocol and interface text keeps MinIO: MINIO_* variables, minio_* metrics, x-minio-* headers, /minio/* routes, .minio.sys, arn:minio, and API field and error names. - Attribution keeps MinIO and gains the fork's own: the AGPL obligations, original copyright, CREDITS and NOTICE stay, with the modification notice added alongside rather than replacing them. - Historical and third-party references are left as facts, not rewritten for brand tidiness. README and README_ZH each carry an explicit non-affiliation notice, document the side-by-side package migration including the /etc/systemd/system/silo.service.d/10-legacy-user.conf drop-in for keeping a legacy UID/GID, and state that recursive chown is never performed. The trademark attribution uses the policy's approved "based on MinIO technology" wording, not the shortened form the policy rejects. github.com/pgsty/minio links are left in place and labelled transitional. The repository has not been renamed, and rewriting them now would produce documented URLs that 404 until the cutover; they change in the cutover commit together with the goreleaser release target, the OCI source label and the raw-content branch. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
6.4 KiB
KMS Guide
Silo uses a key-management-system (KMS) to support SSE-S3. If a client requests SSE-S3, or auto-encryption is enabled, the Silo server encrypts each object with a unique object key which is protected by a master key managed by the KMS.
Quick Start
Silo supports KMS integration through a KES-compatible endpoint. Deploy and control your own KES instance, create a dedicated client identity and key, and then configure Silo with the compatibility environment variables below. Do not use a public or shared KES instance for real data.
1. Set the Silo-to-KES configuration
export MINIO_KMS_KES_ENDPOINT=https://kes.example.com:7373
export MINIO_KMS_KES_KEY_FILE=/etc/silo/kes/client.key
export MINIO_KMS_KES_CERT_FILE=/etc/silo/kes/client.crt
export MINIO_KMS_KES_KEY_NAME=silo-default-key
2. Start the Silo server
export MINIO_ROOT_USER=minio
export MINIO_ROOT_PASSWORD=silo123
silo server ~/export
The certificate, private key, KES policy, and named key must be provisioned by the administrator. Protect the client private key and use TLS verification in every environment.
Configuration Guides
A typical Silo deployment that uses a KMS for SSE-S3 looks like this:
┌────────────┐
│ ┌──────────┴─┬─────╮ ┌────────────┐
└─┤ ┌──────────┴─┬───┴──────────┤ ┌──────────┴─┬─────────────────╮
└─┤ ┌──────────┴─┬─────┬──────┴─┤ KES Server ├─────────────────┤
└─┤ Silo ├─────╯ └────────────┘ ┌────┴────┐
└────────────┘ │ KMS │
└─────────┘
In a given setup, there are n Silo instances talking to m KES servers but only 1 central KMS. The most simple setup consists of 1 Silo server or cluster talking to 1 KMS via 1 KES server.
The main difference between various Silo-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. Silo and KMS on-prem (Recommended) |
| AWS-KMS + SecretsManager | Cloud KMS. Silo in combination with a managed KMS installation |
| Gemalto KeySecure /Thales CipherTrust | Local KMS. Silo and KMS On-Premises. |
| Google Cloud Platform SecretManager | Cloud KMS. Silo in combination with a managed KMS installation |
| FS | Local testing or development (Not recommended for production) |
The Silo-to-KES configuration is the same regardless of the KMS implementation. Consult the KES project documentation for the selected keystore.
Further references
- Run Silo with TLS / HTTPS
- Tweak the KES server configuration
- Run a load balancer in front of KES
- Understand the KES server concepts
Auto Encryption
Auto-Encryption is useful when Silo administrator wants to ensure that all data stored on Silo is encrypted at rest.
Using mc encrypt (recommended)
Silo automatically encrypts all objects on buckets if KMS is successfully configured and bucket encryption configuration is enabled for each bucket as shown below:
mc encrypt set sse-s3 mysilo/bucket/
Verify if Silo has sse-s3 enabled
mc encrypt info mysilo/bucket/
Auto encryption 'sse-s3' is enabled
Using environment (not-recommended)
Silo automatically encrypts all objects on buckets if KMS is successfully configured and following ENV is enabled:
export MINIO_KMS_AUTO_ENCRYPTION=on
Verify auto-encryption
Note that auto-encryption only affects requests without S3 encryption headers. So, if a S3 client sends e.g. SSE-C headers, Silo will encrypt the object with the key sent by the client and won't reach out to the configured KMS.
To verify auto-encryption, use the following mc command:
mc cp test.file mysilo/bucket/
test.file: 5 B / 5 B ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ 100.00% 337 B/s 0s
mc stat mysilo/bucket/test.file
Name : test.file
...
Encrypted :
X-Amz-Server-Side-Encryption: AES256
Encrypted Private Key
Silo supports encrypted KES client private keys. Therefore, you can use
an password-protected private keys for MINIO_KMS_KES_KEY_FILE.
When using password-protected private keys for accessing KES you need to provide the password via:
export MINIO_KMS_KES_KEY_PASSWORD=<your-password>
Note that Silo only supports encrypted private keys - not encrypted certificates. Certificates are no secrets and sent in plaintext as part of the TLS handshake.