[
https://issues.apache.org/jira/browse/HADOOP-19892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18099050#comment-18099050
]
Arslan Aziz commented on HADOOP-19892:
--------------------------------------
Hi [[email protected]], do you have any thoughts on this? I'm happy to
contribute a PR, but it's not clear to me the original reason why CSE and SSE
are implemented as mutually exclusive.
I guess one complication I see is (depending on how this is implemented) is
that it could change the fields in EncryptionSecrets, which impacts backward
compatibility of S3A delegation tokens.
> Support S3 CSE and SSE simultaneously
> -------------------------------------
>
> Key: HADOOP-19892
> URL: https://issues.apache.org/jira/browse/HADOOP-19892
> Project: Hadoop Common
> Issue Type: Improvement
> Components: fs/s3
> Reporter: Arslan Aziz
> Priority: Major
>
> S3AFileSystem has added support for client-side encryption (CSE) in Hadoop
> 3.4; however, it treats CSE as mutually exclusive with SSE (only one can be
> enabled).
> CSE and SSE are orthogonal features. CSE relies on the S3 Encryption Client
> and Keyring to encrypt data on the client-side, whereas SSE requires setting
> appropriate headers on put/multipart-put/copy requests.
> In some organizations, there are mandatory bucket policies for compliance
> purposes to require SSE to be explicitly set. For example, a bucket policy
> like:
> {code:java}
> {
> "Sid": "DenyIncorrectEncryptionHeader",
> "Effect": "Deny",
> "Principal": "*",
> "Action": "s3:PutObject",
> "Resource": "arn:aws:s3:::<bucket_name>/*",
> "Condition": {
> "StringNotEquals": {
> "s3:x-amz-server-side-encryption": "aws:kms"
> }
> }
> }, {code}
> However, there are still legitimate reasons to use CSE even when SSE is
> enabled, such as multi-tenant buckets where data needs to be encrypted per
> tenant.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
