docs: refresh security docs and fork references

Update the STS, security, select, and Docker documentation to reflect the recent hardening work, including LDAP STS throttling details, OIDC JWT verification changes, and the new pgsty-specific security policy and advisory index.

Rewrite repository and raw-document links that still pointed at minio/minio so the docs consistently reference pgsty/minio instead.

The core idea is to keep the documentation aligned with the fork's actual security behavior, ownership, and upgrade guidance without mixing in unrelated code changes.
This commit is contained in:
Feng Ruohang
2026-04-17 15:06:42 +08:00
parent f44110890b
commit f48dbe777d
44 changed files with 203 additions and 163 deletions
+3 -1
View File
@@ -1,5 +1,7 @@
# MinIO Security Overview [![Slack](https://slack.min.io/slack?type=svg)](https://slack.min.io)
For fork-specific security advisories and upgrade notes in `pgsty/minio`, see [advisories.md](advisories.md).
## Server-Side Encryption
MinIO supports two different types of server-side encryption ([SSE](#sse)):
@@ -83,7 +85,7 @@ server only assumes that the KMS provides two services:
- `DecryptKey`: Takes a key ID and an encrypted data key and returns the plain data key - the decryption of the encrypted data key using the master key referenced by the key ID - on success or an error otherwise.
More details about supported KMS implementations and configuration can be found at the [KMS guide](https://github.com/minio/minio/blob/master/docs/kms/README.md).
More details about supported KMS implementations and configuration can be found at the [KMS guide](https://github.com/pgsty/minio/blob/master/docs/kms/README.md).
The MinIO server requests a new data key from the KMS for each uploaded object and uses that data key as EK. Additionally it stores the encrypted form of the data key and the master key ID as part of the object metadata. The plain data only resides in RAM during the en/decryption process. The MinIO server does not store any SSE-related key at the KMS. Instead the KMS is treated as trusted component that performs key sealing/unsealing operations to build a key hierarchy: