SSE handling for gateway

gateway_sse.md

SSE Handling for Gateway

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)

SSE is handled by the gateway, thus terminating the SSE at gateway. Encrypted object is passed to backend as a plain object without accompanying SSE headers. This will break S3 compatibility

3. MINIO_GATEWAY_ENCRYPTION=BOTH (Encryption at both gateway and backend)

Assumptions:

• Amazon disallows presence of more than one of SSE-C, SSE-S3 and SSE-KMS headers on a PutObject/CopyObject request.To support double encryption, this will have to be relaxed to allow specifying upto 2 SSE headers.
• To ensure that users never download gateway encrypted object without proper permission, SSE-C will have to be at backend

Cases

1. SSE-C -> both gateway and backend use same customer provided encryption key, gateway encrypts first and passes encrypted object with SSE-C headers to backend for re-encryption.

2. SSE-S3 -> if master key is configured on gateway, gateway encrypts with SSE-S3 using derived per object key from master key, and passes encrypted object to Backend with forwarded SSE-S3 header for further backend encryption with SSE-S3. Downside will be that client can download gateway encrypted object from backend by bypassing minio [As per assumption b, this option has to be ruled out]

3. SSE-KMS -> if KMS is configured on gateway, gateway encrypts with SSE-S3 using plain key generated by KMS, and passes encrypted object to Backend with forwarded SSE-KMS header for further backend encryption with SSE-KMS [as per assumption b, this has to be ruled out]

4. SSE-C + SSE-KMS -> do the SSE-KMS on gateway, let backend do the SSE-C. [ flip side of doing SSE-C on gateway and SSE-KMS on backend is ruled out by assumption b ]

5. SSE-C + SSE-S3 -> do the SSE-S3 on gateway, let backend do the SSE-C. [ flip side of doing SSE-C on gateway and SSE-S3 on backend is ruled out by assumption b ]

6. SSE-KMS + SSE-S3 -> not a possible combination.

I think option 2 (MINIO_GATEWAY_ENCRYPTION=ON (Encryption at gateway)) is invalid. I am guessing that is what you are trying to imply also?

@kannappanr, if MINIO_GATEWAY_ENCRYPTION=ON/BOTH, it will cause vendor lock-in and break s3 compatibility. option 2 is a subset of option 3, and will give double encryption by just throwing in an extra sse header. So, there is no big advantage of MINIO_GATEWAY_ENCRYPTION=ON imo.

@Poorna
Following remarks:

1. MINIO_GATEWAY_ENCRYPTION = OFF should probably the standard behavior.
2. For MINIO_GATEWAY_ENCRYPTION = ON can only handle SSE-S3 and SSE-C (Minio does not support SSE-KMS).
   What should happen in SSE-KMS case. For consistency the gateway should respond like the minio server in this case (deny request).
   Otherwise it's confusing (SSE-S3 and SSE-C are terminated, but SSE-KMS is forward)
3. MINIO_GATEWAY_ENCRYPTION = ON does not break S3 compatibility - it causes vendor lock-in but does not (necessarily) break the S3 API compatibility.
4. MINIO_GATEWAY_ENCRYPTION=BOTH:

• SSE-S3 can be handled by gateway and be forwarded.
• SSE-C can be handled by gateway but should not be forwarded (defeat the purpose of SSE termination and also not useful)
• SSE-KMS cannot be handled by gateway and therefore must be rejected.

So the semantics of BOTH should be:

• Client send SSE-S3 -> gateway applies SSE-S3 -> forward request + SSE-S3 header
• Client sends SSE-C -> gateway applies SSE-C and derive 2nd SSE-C key from client key -> forward rquest but replace client key with derived key (While this can be implemented securely it's questionable whether it makes sense). Forwarding client key is not secure.
• Client sends SSE-KMS -> gateway rejects request