Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

#41196 | Add aws KMS encryption in the elastic search repository-s3 plugin #47486

Closed
wants to merge 4 commits into from

Conversation

Prasannasaraf
Copy link

No description provided.

# Conflicts:
#	plugins/repository-s3/src/main/java/org/elasticsearch/repositories/s3/S3Repository.java
@Prasannasaraf Prasannasaraf changed the title Add aws KMS encryption in the elastic search repository-s3 plugin #41196 | Add aws KMS encryption in the elastic search repository-s3 plugin Oct 3, 2019
@original-brownbear original-brownbear added the :Distributed/Snapshot/Restore Anything directly related to the `_snapshot/*` APIs label Oct 3, 2019
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-distributed (:Distributed/Snapshot/Restore)


public boolean sseAwsKeyIsEmpty() {
if (sseAwsKeyId == null || sseAwsKeyId.trim().isEmpty()) {
return true;

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can be simplified into:

return sseAwsKeyId == null || sseAwsKeyId.trim().isEmpty()

Copy link
Member

@original-brownbear original-brownbear left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this PR @Prasannasaraf !

I left a few comments/questions on the exact mechanics of how the new setting should work.

Also, we definitely have to add a 3rd party test for this that runs if the appropriate environment variable is set. Something along the lines of what we did for Azure SAS tokens is probably what we want here (see https://github.com/elastic/elasticsearch/pull/42982/files#diff-972bd167c62a9bf3a9bf9a80d6ea2298R79).

I also wonder if we sohuld make setting an endpoint on a repo or client mutually exclusive with using KMS on the settings layer already since this won't work with non-AWS S3 endpoints anyway?

md.setSSEAlgorithm(ObjectMetadata.AES_256_SERVER_SIDE_ENCRYPTION);
if (blobStore.sseAwsKeyIsEmpty()) {
md.setSSEAlgorithm(ObjectMetadata.AES_256_SERVER_SIDE_ENCRYPTION);
}else {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NIT: formatting is off here

@@ -313,14 +314,22 @@ void executeSingleUpload(final S3BlobStore blobStore,
}

final ObjectMetadata md = new ObjectMetadata();
final PutObjectRequest putRequest = new PutObjectRequest(blobStore.bucket(), blobName, input, md);
md.setContentLength(blobSize);
if (blobStore.serverSideEncryption()) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a little strange now IMO. I think we should always use encryption if a kms key is set. Otherwise, we force the user to set the true flag on server_side_encryption for a value of the kms key to take effect. That's counterintuitive and error prone isn't it? :)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we put a warning if sse is disabled but KMS key is set and continue?

* When aws_kms_key is set, files are encrypted on server side using kms key provided or AE256 algorithm is used.
* Defaults to AES256 algorithm.
*/
static final Setting<String> AWS_KMS_KEY = Setting.simpleString("aws_kms_key");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We will need a documentation change for this and document this setting in repository-s3.asciidoc.
Before we do we should come to a conclusion on how this setting will work relative to server_side_encryption though :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd also like a second opinion here (@ywelsch, @tlrx maybe?) on whether or not this should be a secure setting. It seems technically safe since it's just a key id but I wonder if not having it in the key store might create some potential (compliance?) issues?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we want to add support for KMS then I think we need smarter settings that allow to distinguish between server side encryption using AES256, SSE with KMS and default key and SSE with KMS and specific key id.

I'd also like a second opinion here (@ywelsch, @tlrx maybe?) on whether or not this should be a secure setting.

I tend to think that it should be a secured setting. I also think that it should be correctly documented as we don't want users to remove or update keys and not being able to decrypt data afterwards? Also, @albertzaharovits might have an opinion on this.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think the key identifier should be a secure setting. It's just an identifier, and I think that putting it in the keystore creates unnecessary complications for the user.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, from https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObject.html I see that the API has complexish rules:

x-amz-server-side​-encryption
x-amz-server-side-encryption-aws-kms-key-id
x-amz-server-side-encryption-context

Note:
If you specify x-amz-server-side-encryption:aws:kms, but don't provide x-amz-server-side- encryption-aws-kms-key-id, Amazon S3 uses the default AWS KMS key to protect the data.

that don't really make much sense to me.

I would think to whitelist these request headers, together with x-amz-server-side​-encryption​-customer-algorithm, x-amz-server-side​-encryption​-customer-key, x-amz-server-side​-encryption​-customer-key-MD5 from below, and delegate the responsibility to the user to validate them. What do you think?

@original-brownbear
Copy link
Member

Hi @Prasannasaraf,

sorry for the delay here. As I said in my last comment, this will require adding some actual third party tests against real AWS S3 to validate that it works. Are you interested in working on those and continuing here? (I realize that this is a non-trivial amount of effort on top of the actual change so no worries if not.)

@Prasannasaraf
Copy link
Author

Hi @original-brownbear

I can work on adding third-party tests along with the changes suggested by @albertzaharovits. Do let me know the amount of work involved here.

@rjernst rjernst added the Team:Distributed Meta label for distributed team label May 4, 2020
@jstolle
Copy link

jstolle commented Nov 20, 2020

Is there an ETA on the completion of this merge?

@elasticsearchmachine elasticsearchmachine changed the base branch from master to main July 22, 2022 23:14
@wywywywy
Copy link

Is this ever going to get merged?

@DaveCTurner
Copy link
Contributor

Is this ever going to get merged?

Not in its current state, no, we can't accept this kind of change without supporting tests. I'm going to close this because it has been waiting for the missing tests to be added for a very long time - see the contributing guidelines for further information.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Distributed/Snapshot/Restore Anything directly related to the `_snapshot/*` APIs Team:Distributed Meta label for distributed team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet