[
https://issues.apache.org/jira/browse/HDDS-17498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wei-Chiu Chuang updated HDDS-17498:
-----------------------------------
Release Note: S3 Gateway now validates server-side encryption headers.
Requests using AES256 or aws:kms require an encrypted bucket and use its
configured encryption key; requests to unencrypted buckets are rejected. SSE-C
remains unsupported and is rejected. Previously, these headers were silently
ignored.
> S3 Gateway should reject requests for server-side encryption instead of
> silently ignoring them
> ----------------------------------------------------------------------------------------------
>
> Key: HDDS-17498
> URL: https://issues.apache.org/jira/browse/HDDS-17498
> Project: Apache Ozone
> Issue Type: Bug
> Components: s3gateway
> Reporter: Andrey Yarovoy
> Assignee: Andrey Yarovoy
> Priority: Major
> Labels: pull-request-available
>
> *Problem*
> The S3 Gateway doesn't support S3 server-side encryption (SSE): `S3.md` lists
> it as not supported. It doesn't reject
> requests for it either. No code in `hadoop-ozone/s3gateway` reads the
> `x-amz-server-side-encryption*` headers, and
> `ObjectAttributesHandler` notes that "SSE-C encryption headers are also not
> supported and are silently ignored".
> So a client that asks for its data to be encrypted at rest gets a success
> response, and the object is stored as
> written, which is unencrypted unless the bucket is an encrypted (TDE) bucket.
> For example:
> - `PutObject` with `x-amz-server-side-encryption: AES256` or `aws:kms`
> returns 200 and stores the object in plaintext;
> - `PutObject` with SSE-C
> (`x-amz-server-side-encryption-customer-algorithm/-key/-key-MD5`) returns 200
> and the
> customer key is discarded. A later `GetObject` without the key also succeeds,
> while S3 requires the key to read an
> SSE-C object.
> The client has no way to tell that its request wasn't honoured. Applications
> and compliance checks that rely on
> requesting SSE therefore assume the data is encrypted at rest when it isn't.
> AWS S3 fails such requests when it can't
> honour them, for example an unknown algorithm or a missing or invalid
> customer key, rather than storing the data
> unencrypted.
> The bucket-level API is already handled: `PutBucketEncryption` and
> `GetBucketEncryption` (`?encryption`) return
> `NotImplemented` through `BucketOperationNotImplementedHandler`. Only the
> per-request headers are ignored.
> *Proposed change*
> Reject object requests that ask for server-side encryption with the existing
> S3 `NotImplemented` error (501), the
> same way the gateway already rejects other unsupported features.
> Headers to check:
> - `x-amz-server-side-encryption` (SSE-S3 / SSE-KMS);
> - `x-amz-server-side-encryption-aws-kms-key-id`,
> `x-amz-server-side-encryption-context`,
> `x-amz-server-side-encryption-bucket-key-enabled`;
> - `x-amz-server-side-encryption-customer-algorithm`, `-customer-key`,
> `-customer-key-MD5` (SSE-C);
> - `x-amz-copy-source-server-side-encryption-customer-*` (SSE-C copy source).
> Operations to check: `PutObject`, `CopyObject`, `CreateMultipartUpload`,
> `UploadPart` and `UploadPartCopy`. For SSE-C,
> also the read operations that carry the customer key: `GetObject`,
> `HeadObject` and `GetObjectAttributes`.
> - **Compatibility.** Clients that send these headers today, and work because
> the headers are ignored, will start to
> fail. An example is S3A with `fs.s3a.encryption.algorithm` set. That is the
> intent: the failure is visible, rather
> than the data silently not being encrypted. If a transition is needed, a
> gateway setting could keep the old
> behaviour, but it should default to rejecting.
> - Update `S3.md`, and the `ObjectAttributesHandler` comment, to say that SSE
> requests are rejected.
> *Testing*
> - Unit tests in `hadoop-ozone/s3gateway`: each listed header on each listed
> operation returns `NotImplemented`, and
> nothing is written (no key, no multipart upload created). The same requests
> without the headers still succeed.
> - If SSE-S3/KMS is accepted for encrypted buckets: such a request succeeds on
> an encrypted bucket and is rejected on a
> regular one.
> - Smoke test (`hadoop-ozone/dist/src/main/smoketest/s3`): `aws s3api
> put-object --server-side-encryption AES256` and
> `--sse-customer-algorithm AES256 --sse-customer-key ...` fail with
> `NotImplemented`.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
