You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
remove redundant fields minio and format which are currently used only for verification, and update fs.json version
In the future, checksum info will be used by caching for storing bit-rot checksum. Since the version is being updated for fs.json checksum info fields are being piggy-backed as as placeholder.
Provide a env variable MINIO_GATEWAY_ENCRYPTION = ON | OFF | BOTH that allows user
to configure whether gateway does all the encryption, passes through to the backend storage provider or have gateway encrypt
and forward with headers to backend so that backend will re-encrypt the object
1. MINIO_GATEWAY_ENCRYPTION=OFF (Pass-through for gateway)
Encryption is handled by the backend,SSE headers are forwarded to backend as is the case today.
2. MINIO_GATEWAY_ENCRYPTION=ON (Encryption at gateway)
There is a need for custom format in the backend for gateway sse encryption for multipart
operations, primarily because of limitations of s3 multipart API protocol and the need for size
of each encrypted part to be maintained for successful decryption.
multipart operation with sse at gateway
multipart gateway sse encryption creates an object per object-part at the backend like below:
Gateway receives a new-multi-part request for bucket/foo by client.
-> Gateway creates the object-prefix bucket/foo and stores encryption metadata for foo as bucket/foo/dare.meta
This file will itself be encrypted to avoid leaking information.
For objects created by the PUT Object, POST Object, or Copy operation, AWS returns MD5(object) for SSE-S3 encrypted objects and random ETag for SSE-C encrypted objects
To preserve security guarantees, we must not store MD5(object) in plaintext as ETag.Hence the ETag has to be stored in encrypted form as Encrypt(ETag = MD5(object)). However since APIs like ListObject do not require SSE-C key but return ETag information, this forces Minio server to also store encrypted MD5Sum for SSE-S3 and SSE-C, but return random ETag for SSE-C, and MD5(object) for SSE-S3.
In the gateway for double encryption scenario, to maintain compatibility X-Minio-Internal-ETag needs to be maintained with Encrypt(ETag = MD5(object)), and ETag set at the backend needs to be discarded and return Decrypt(Metadata['X-Minio-Internal-ETag']).
For server side copy operations, the encrypted ETag of original object MD5 needs to be decrypted correctly and re-encrypted with the target side key.