astelm/minio
1
0
Fork 0
mirror of https://github.com/pgsty/minio.git synced 2026-08-09 15:53:28 +03:00
Code Issues Packages Projects Releases Wiki Activity

docs: rebrand the repository documentation, templates and dashboards

Browse Source 
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>
This commit is contained in:
Feng Ruohang
2026-08-06 08:49:30 +08:00
parent 6613c2a3cb
commit fd2ca1c6d2
94 changed files with 1613 additions and 1347 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/sts/tls.md
+18 -18
View File
@@ -1,15 +1,15 @@
# AssumeRoleWithCertificate [![Slack](https://slack.min.io/slack?type=svg)](https://slack.min.io)
# AssumeRoleWithCertificate
## Introduction
MinIO provides a custom STS API that allows authentication with client X.509 / TLS certificates.
Silo provides a custom STS API that allows authentication with client X.509 / TLS certificates.
A major advantage of certificate-based authentication compared to other STS authentication methods, like OpenID Connect or LDAP/AD, is that client authentication works without any additional/external component that must be constantly available. Therefore, certificate-based authentication may provide better availability / lower operational complexity.
The MinIO TLS STS API can be configured via MinIO's standard configuration API (i.e. using `mc admin config set/get`). Further, it can be configured via the following environment variables:
The Silo TLS STS API can be configured via Silo's standard configuration API (i.e. using `mc admin config set/get`). Further, it can be configured via the following environment variables:
```
mc admin config set myminio identity_tls --env
mc admin config set mysilo identity_tls --env
KEY:
identity_tls enable X.509 TLS certificate SSO support
@@ -17,7 +17,7 @@ ARGS:
MINIO_IDENTITY_TLS_SKIP_VERIFY (on|off) trust client certificates without verification. Defaults to "off" (verify)
```
The MinIO TLS STS API is disabled by default. However, it can be *enabled* by setting environment variable:
The Silo TLS STS API is disabled by default. However, it can be *enabled* by setting environment variable:
```
export MINIO_IDENTITY_TLS_ENABLE=on
@@ -25,10 +25,10 @@ export MINIO_IDENTITY_TLS_ENABLE=on
## Example
MinIO exposes a custom S3 STS API endpoint as `Action=AssumeRoleWithCertificate`. A client has to send an HTTP `POST` request to `https://<host>:<port>?Action=AssumeRoleWithCertificate&Version=2011-06-15`. Since the authentication and authorization happens via X.509 certificates the client has to send the request over **TLS** and has to provide
Silo exposes a custom S3 STS API endpoint as `Action=AssumeRoleWithCertificate`. A client has to send an HTTP `POST` request to `https://<host>:<port>?Action=AssumeRoleWithCertificate&Version=2011-06-15`. Since the authentication and authorization happens via X.509 certificates the client has to send the request over **TLS** and has to provide
a client certificate.
The following curl example shows how to authenticate to a MinIO server with client certificate and obtain STS access credentials.
The following curl example shows how to authenticate to a Silo server with client certificate and obtain STS access credentials.
```curl
curl -X POST --key private.key --cert public.crt "https://minio:9000?Action=AssumeRoleWithCertificate&Version=2011-06-15&DurationSeconds=3600"
@@ -53,11 +53,11 @@ curl -X POST --key private.key --cert public.crt "https://minio:9000?Action=Assu
## Authentication Flow
A client can request temp. S3 credentials via the STS API. It can authenticate via a client certificate and obtain a access/secret key pair as well as a session token. These credentials are associated to an S3 policy at the MinIO server.
A client can request temp. S3 credentials via the STS API. It can authenticate via a client certificate and obtain a access/secret key pair as well as a session token. These credentials are associated to an S3 policy at the Silo server.
In case of certificate-based authentication, MinIO has to map the client-provided certificate to an S3 policy. MinIO does this via the subject common name field of the X.509 certificate. So, MinIO will associate a certificate with a subject `CN = foobar` to a S3 policy named `foobar`.
In case of certificate-based authentication, Silo has to map the client-provided certificate to an S3 policy. Silo does this via the subject common name field of the X.509 certificate. So, Silo will associate a certificate with a subject `CN = foobar` to a S3 policy named `foobar`.
The following self-signed certificate is issued for `consoleAdmin`. So, MinIO would associate it with the pre-defined `consoleAdmin` policy.
The following self-signed certificate is issued for `consoleAdmin`. So, Silo would associate it with the pre-defined `consoleAdmin` policy.
```
Certificate:
@@ -94,18 +94,18 @@ Certificate:
> Observe the `Subject: CN = consoleAdmin` field.
Also, note that the certificate has to contain the `Extended Key Usage: TLS Web Client Authentication`. Otherwise, MinIO would not accept the certificate as client certificate.
Also, note that the certificate has to contain the `Extended Key Usage: TLS Web Client Authentication`. Otherwise, Silo would not accept the certificate as client certificate.
Now, the STS certificate-based authentication happens in 4 steps:
- Client sends HTTP `POST` request over a TLS connection hitting the MinIO TLS STS API.
- MinIO verifies that the client certificate is valid.
- MinIO tries to find a policy that matches the `CN` of the client certificate.
- MinIO returns temp. S3 credentials associated to the found policy.
- Client sends HTTP `POST` request over a TLS connection hitting the Silo TLS STS API.
- Silo verifies that the client certificate is valid.
- Silo tries to find a policy that matches the `CN` of the client certificate.
- Silo returns temp. S3 credentials associated to the found policy.
The returned credentials expiry after a certain period of time that can be configured via `&DurationSeconds=3600`. By default, the STS credentials are valid for 1 hour. The minimum expiration allowed is 15 minutes.
Further, the temp. S3 credentials will never out-live the client certificate. For example, if the `MINIO_IDENTITY_TLS_STS_EXPIRY` is 7 days but the certificate itself is only valid for the next 3 days, then MinIO will return S3 credentials that are valid for 3 days only.
Further, the temp. S3 credentials will never out-live the client certificate. For example, if the `MINIO_IDENTITY_TLS_STS_EXPIRY` is 7 days but the certificate itself is only valid for the next 3 days, then Silo will return S3 credentials that are valid for 3 days only.
## Caveat
@@ -113,5 +113,5 @@ Further, the temp. S3 credentials will never out-live the client certificate. Fo
## Explore Further
- [MinIO Admin Complete Guide](https://silo.pgsty.com/reference/minio-mc-admin/)
- [The MinIO documentation website](https://silo.pgsty.com/docs/)
- [Silo Admin Complete Guide](https://silo.pgsty.com/reference/minio-mc-admin/)
- [The Silo documentation website](https://silo.pgsty.com/docs/)