-
Notifications
You must be signed in to change notification settings - Fork 24.3k
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
Conversation
# Conflicts: # plugins/repository-s3/src/main/java/org/elasticsearch/repositories/s3/S3Repository.java
Pinging @elastic/es-distributed (:Distributed/Snapshot/Restore) |
|
||
public boolean sseAwsKeyIsEmpty() { | ||
if (sseAwsKeyId == null || sseAwsKeyId.trim().isEmpty()) { | ||
return true; |
There was a problem hiding this comment.
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()
There was a problem hiding this 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 { |
There was a problem hiding this comment.
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()) { |
There was a problem hiding this comment.
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? :)
There was a problem hiding this comment.
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"); |
There was a problem hiding this comment.
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 :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
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.) |
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. |
Is there an ETA on the completion of this merge? |
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. |
No description provided.