Feng Ruohang
fe6dc47804
The address MinIO attributes a request to is read from X-Forwarded-For,
X-Real-IP or RFC 7239 Forwarded, and never from the connection unless all
three are absent. It becomes aws:SourceIp and the audit remotehost field,
so any client that can reach the API port chooses the value an IpAddress
condition is evaluated against and the address every logged action is
attributed to.
MINIO_API_TRUSTED_PROXIES now selects who may make that claim:
unset the historical behaviour, unchanged
none no forwarded header is believed; the TCP peer wins
<CIDRs> believed only from listed peers, chains read right-to-left
Reading right-to-left is what makes an appending proxy safe: each hop
appends the peer it actually saw, so an entry a client injected can only
sit to the left of one a proxy wrote. The stock nginx recipe
$proxy_add_x_forwarded_for appends, which leaves the client's entry
left-most - exactly where the untrusted path reads - so a deployment with
no direct route to the API port was forgeable too.
_MINIO_API_XFF_HEADER is deliberately untouched, in semantics and in read
timing. Widening it to mean "trust nothing" was implemented and reverted:
it is the only part of this change that could alter a deployed
configuration, and the new variable expresses the same guarantee at no
compatibility cost. Upstream's TestXFFDisabled is retained verbatim.
Notes on the allow-list mode, all covered by tests:
- it must name proxies, not the subnet they sit in; listed entries are
skipped while walking, so a range covering clients lets them forge
- a cluster must list its own nodes, because MinIO forwards between
them and a client can force a hop via the ListObjectsV2 token
- loopback is trusted as a peer, not as a chain entry, so FTP and SFTP
keep attributing their sessions
- the node-to-node forwarder drops X-Real-IP and Forwarded from a peer
not entitled to have set them
- the walk scans the header in place and stops after 100 hops, so a
long chain costs neither allocation nor unbounded work
No behaviour change for any deployment that does not set the new
variable: the untrusted path is a verbatim copy of the previous function
body, differentially verified against it over ~5.1M header combinations.
The LDAP STS allow-list now shares the list parser as pure code motion,
verified identical across every combination of 37 allow-list values and
21 peer addresses.
Co-authored-by: ChatGPT <noreply@openai.com>
Co-authored-by: Claude <noreply@anthropic.com>
MinIO Security Overview 
For fork-specific security advisories and upgrade notes in pgsty/minio, see advisories.md.
For which peers may tell the server where a request came from — and therefore whether aws:SourceIp conditions and audit client addresses can be relied on — see Client source address trust.
Server-Side Encryption
MinIO supports two different types of server-side encryption (SSE):
- SSE-C: The MinIO server en/decrypts an object with a secret key provided by the S3 client as part of the HTTP request headers. Therefore, SSE-C requires TLS/HTTPS.
- SSE-S3: The MinIO server en/decrypts an object with a secret key managed by a KMS. Therefore, MinIO requires a valid KMS configuration for SSE-S3.
Server-Side Encryption - Preliminaries
Secret Keys
The MinIO server uses a unique, randomly generated secret key per object also known as, Object Encryption Key (OEK). Neither the client-provided SSE-C key nor the KMS-managed key is directly used to en/decrypt an object. Instead, the OEK is stored as part of the object metadata next to the object in an encrypted form. To en/decrypt the OEK another secret key is needed also known as, Key Encryption Key (KEK).
The MinIO server runs a key-derivation algorithm to generate the KEK using a pseudo-random function (PRF):
KEK := PRF(EK, IV, context_values) where:
- EK: is the external key. In case of SSE-C this is the client-provided key. In case of SSE-S3 this is secret key generated by the KMS. For further details see SSE-C or SSE-S3.
- IV: is a randomly generated initialization vector. It is public and part of the object metadata.
context_values: are values like the bucket and object name and other information which should be cryptographically bound to the KEK.
To summarize for any encrypted object there exists (at least) three different keys:
- OEK: A secret and unique key used to encrypted the object, stored in an encrypted form as part of the object metadata and only loaded to RAM in plaintext during en/decrypting the object.
- KEK: A secret and unique key used to en/decrypt the OEK and never stored anywhere. It is(re-)generated whenever en/decrypting an object using an external secret key and public parameters.
- EK: An external secret key - either the SSE-C client-provided key or a secret key generated by the KMS.
Content Encryption
The MinIO server uses an authenticated encryption scheme (AEAD) to en/decrypt and authenticate the object content. The AEAD is combined with some state to build a Secure Channel. A Secure Channel is a cryptographic construction that ensures confidentiality and integrity of the processed data. In particular the Secure Channel splits the plaintext content into fixed size chunks and en/decrypts each chunk separately using a unique key-nonce combination.
Figure 1 - Secure Channel construction
plaintext := chunk_0 || chunk_1 || chunk_2 || ...
| | |
| | |
AEAD <- key, nonce + 0 AEAD <- key, nonce + 1 AEAD <- key, nonce + 2 ...
| | |
| | |
ciphertext := sealed_chunk_0 || sealed_chunk_1 || sealed_chunk_2 || ...
In case of a S3 multi-part operation each part is en/decrypted with the scheme shown in Figure 1. However, for each part a unique secret key is derived from the OEK and the part number using a PRF. So in case of multi-part not the OEK but the output of PRF(OEK, part_id) is used as secret key.
Cryptographic Primitives
The SSE schemes described in Secret Keys and Content Encryption are generic over the cryptographic primitives. However, the MinIO server uses the following cryptographic primitive implementations:
- PRF: HMAC-SHA-256
- AEAD: AES-256-GCM if the CPU supports AES-NI, ChaCha20-Poly1305 otherwise. More specifically AES-256-GCM is only selected for X86-64 CPUs with AES-NI extension.
Further any secret key (apart from the KMS-generated ones) is 256 bits long. The KMS-generated keys may be 256 bits but this depends on the KMS capabilities and configuration.
The Secure Channel splits the object content into chunks of a fixed size of 65536 bytes. The last chunk may be smaller to avoid adding additional overhead and is treated specially to prevent truncation attacks. The nonce value is 96 bits long and generated randomly per object / multi-part part. The Secure Channel supports plaintexts up to 65536 * 2^32 = 256 TiB.
Randomness
The MinIO server generates unique keys and other cryptographic values using a cryptographically secure pseudo-random number generator (CSPRNG). However, in the context of SSE, the MinIO server does not require that the CSPRNG generates values that are indistinguishable from truly random bit strings. Instead, it is sufficient if the generated values are unique - which is a weaker requirement. Nevertheless other parts - for example the TLS-stack - may require that CSPRNG-generated values are indistinguishable from truly random bit strings.
Server-Side Encryption with client-provided Keys
SSE-C allows an S3 client to en/decrypt an object at the MinIO server. Therefore the S3 client sends a secret key as part of the HTTP request. This secret key is never stored by the MinIO server and only resides in RAM during the en/decryption process.
MinIO does not assume or require that the client-provided key is unique. It may be used for multiple objects or buckets. Especially a single client-provided key may be used for all objects - even though all objects must be treated as compromised if that key is ever compromised.
Key rotation
S3 clients can change the client-provided key of an existing object. Therefore an S3 client must perform a S3 COPY operation where the copy source and destination are equal. Further the COPY request headers must contain the current and the new client key:
X-Amz-Server-Side-Encryption-Customer-Key: Base64 encoded new key.X-Amz-Copy-Source-Server-Side-Encryption-Customer-Key: Base64 encoded current key.
Such a special COPY request is also known as S3 SSE-C key rotation.
Server-Side Encryption with a KMS
SSE-S3 allows an S3 client to en/decrypt an object at the MinIO server using a KMS. The MinIO server only assumes that the KMS provides two services:
-
GenerateKey: Takes a key ID and generates a new data key from a master key referenced by the key ID. It returns the new data key in two different forms: The plain data key and the data key encrypted using the master key. -
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.
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:
Figure 2 - KMS key hierarchy
CMK (master key)
|
+-----------------------------------+-----------------------------------+
| | |
+-------+----------------+ +-------+----------------+ ...
| EK_1 | EK_1_encrypted | | EK_2 | EK_2_encrypted |
+---+----------+---------+ +---+----------+---------+
| | | |
| | | |
+---+---+ | +---+---+ |
| KEK_1 | | | KEK_2 | |
+---+---+ | +---+---+ |
| | | |
| | | |
+---+---+ | +---+---+ |
| OEK_1 | | | OEK_2 | |
+---+---+ | +---+---+ |
| |
| |
| |
+---------+---------+ +---------+---------+
| object_metadata_1 | | object_metadata_2 |
+-------------------+ +-------------------+
Key rotation - Basic Operation
The MinIO server supports key rotation for SSE-S3 encrypted objects. The minio server decrypts the OEK using the current encrypted data key and the master key ID of the object metadata. If this succeeds, the server requests a new data key from the KMS using the master key ID of the current MinIO KMS configuration and re-wraps the OEK with a new KEK derived from the new data key / EK:
Figure 3 - KMS data key rotation
object metadata KMS
| |
| +----------------+ 1a | +-------+
|-------------------->| EK_1_encrypted |-----------|->| CMK_1 |
| +----------------+ | +---+---+
| | |
| +---------------+ +------+ 1b | |
|------------->| OEK_encrypted | | EK_1 |<---|------+
| +-------+-------+ +------+ |
| \ / |
| \___ 2 ___/ |
| \___/ |
| | |
| +--+--+ |
| | OEK | | +-------+
| +--+--+ | | CMK_2 |
| | | +---+---+
| | | |
| 5 +----------------+ |4 +------+ 3a | |
|<------| OEK_encrypted' |<----+-------| EK_2 |<---|------+
| +----------------+ +------+ | |
| +----------------+ 3b | |
|<-------------------| EK_2_encrypted |<-----------|------+
| +----------------+ |
| |
1a) Send encrypted data key and master key ID to KMS.
1b) Receive decrypted data key.
2) Decrypt encrypted object key with the KEK derived from the data key.
3a) Receive new plain data key from the KMS using the master key ID of the server config.
3b) Receive encrypted form of the data key from the KMS.
4) Derive a new KEK from the new data key and re-encrypt the OEK with it.
5) Store the encrypted OEK encrypted data key and master key ID in object metadata.
Only the root/admin user can perform an SSE-S3 key rotation using the Admin-API via mc. For more details about how to perform key management operations using the CLI refer to mc admin guide or run mc admin kms key.
Secure Erasure and Locking
The MinIO server requires an available KMS to en/decrypt SSE-S3 encrypted objects. Therefore it is possible to erase or lock some or all encrypted objects. For example in case of a detected attack or other emergency situations the following actions can be taken:
- Seal the KMS such that it cannot be accessed by MinIO server anymore. That will lock all SSE-S3 encrypted objects protected by master keys stored on the KMS. All these objects can not be decrypted as long as the KMS is sealed.
- Seal/Unmount one/some master keys. That will lock all SSE-S3 encrypted objects protected by these master keys. All these objects can not be decrypted as long as the key(s) are sealed.
- Delete one/some master keys. From a security standpoint, this is equal to erasing all SSE-S3 encrypted objects protected by these master keys. All these objects are lost forever as they cannot be decrypted. Especially deleting all master keys at the KMS is equivalent to secure erasing all SSE-S3 encrypted objects.
Acronyms
- AEAD: Authenticated Encryption with Associated Data
- CSPRNG: Cryptographically Secure Pseudo Random Number Generator
- EK: External Key
- IV: Initialization Vector
- KEK: Key Encryption Key
- OEK: Object Encryption Key
- PRF: Pseudo Random Function
- SSE: Server-Side Encryption
- SSE-C: Server-Side Encryption with client-provided Keys
- SSE-S3: Server-Side Encryption with a KMS