[ 
https://issues.apache.org/jira/browse/HADOOP-19892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Arslan Aziz updated HADOOP-19892:
---------------------------------
    Description: 
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 isolated by tenant.

  was:
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 isolated by tenant.


> 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 isolated by 
> 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]

Reply via email to