mirror of
https://github.com/pgsty/minio.git
synced 2026-08-10 00:03:29 +03:00
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>
72 lines
2.8 KiB
Markdown
72 lines
2.8 KiB
Markdown
# How to secure access to Silo on Kubernetes with TLS
|
|
|
|
This document explains how to configure Silo server with TLS certificates on Kubernetes.
|
|
|
|
## 1. Prerequisites
|
|
|
|
- Familiarity with [Silo deployment process on Kubernetes](https://silo.pgsty.com/operations/deployments/kubernetes/).
|
|
|
|
- Kubernetes cluster with `kubectl` configured.
|
|
|
|
- Acquire TLS certificates, either from a CA or [create self-signed certificates](https://silo.pgsty.com/operations/network-encryption/).
|
|
|
|
For a [distributed Silo setup](https://silo.pgsty.com/operations/deployments/kubernetes/), where there are multiple pods with different domain names expected to run, you will either need wildcard certificates valid for all the domains or have specific certificates for each domain. If you are going to use specific certificates, make sure to create Kubernetes secrets accordingly.
|
|
|
|
For testing purposes, here is [how to create self-signed certificates](https://github.com/pgsty/minio/tree/master/docs/tls#3-generate-self-signed-certificates).
|
|
|
|
## 2. Create Kubernetes secret
|
|
|
|
[Kubernetes secrets](https://kubernetes.io/docs/concepts/configuration/secret) are intended to hold sensitive information.
|
|
We'll use secrets to hold the TLS certificate and key. To create a secret, update the paths to `private.key` and `public.crt`
|
|
below.
|
|
|
|
Then type
|
|
|
|
```sh
|
|
kubectl create secret generic tls-ssl-minio --from-file=path/to/private.key --from-file=path/to/public.crt
|
|
```
|
|
|
|
Cross check if the secret is created successfully using
|
|
|
|
```sh
|
|
kubectl get secrets
|
|
```
|
|
|
|
You should see a secret named `tls-ssl-minio`.
|
|
|
|
## 3. Update deployment yaml file
|
|
|
|
Whether you are planning to use Kubernetes StatefulSet or Kubernetes Deployment, the steps remain the same.
|
|
|
|
If you're using certificates provided by a CA, add the below section in your yaml file under `spec.volumes[]`
|
|
|
|
```yaml
|
|
volumes:
|
|
- name: secret-volume
|
|
secret:
|
|
secretName: tls-ssl-minio
|
|
items:
|
|
- key: public.crt
|
|
path: public.crt
|
|
- key: private.key
|
|
path: private.key
|
|
- key: public.crt
|
|
path: CAs/public.crt
|
|
```
|
|
|
|
Note that the `secretName` should be same as the secret name created in previous step. Then add the below section under
|
|
`spec.containers[].volumeMounts[]`
|
|
|
|
```yaml
|
|
volumeMounts:
|
|
- name: secret-volume
|
|
mountPath: /<user-running-silo>/.silo/certs
|
|
```
|
|
|
|
Here the name of `volumeMount` should match the name of `volume` created previously. Also `mountPath` must be set to the path of
|
|
the Silo server's config sub-directory that is used to store certificates. By default, the location is
|
|
`/<user-running-silo>/.silo/certs`.
|
|
|
|
*Tip*: In a standard Kubernetes configuration, this will be `/root/.silo/certs`. Kubernetes will mount the secrets volume read-only,
|
|
so avoid setting `mountPath` to a path that Silo server expects to write to.
|