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

Support additional SSE methods for S3 #946

Closed
taharah opened this issue Mar 19, 2019 · 8 comments
Closed

Support additional SSE methods for S3 #946

taharah opened this issue Mar 19, 2019 · 8 comments

Comments

@taharah
Copy link

taharah commented Mar 19, 2019

Thanos, Prometheus and Golang version used

Thanos: 0.3.2
Prometheus: 2.7.2
Golang: 1.11.5

What happened

Currently, the S3 bucket client only supports using the default key for SSE [1].

What you expected to happen

The S3 bucket client should be able to also support SSE-KMS and SSE-C encryption [2].

How to reproduce it (as minimally and precisely as possible):

N/A

Full logs to relevant components

N/A

Anything else we need to know

I took a look at the code and this does introduce the opportunity to modify the existing SSE configuration in order to be a little cleaner as well as support the additional encryption methods.

For instance, the current configuration is this:

type: S3
config:
  encrypt_sse: false

I think it would be nice if we changed the configuration to something like the following:

type: S3
config:
  server_side_encryption:
    enabled: false
    kms_key_id: ""  # Used for SSE-KMS encrytpion
    encryption_key: ""  # Used for SSE-C encryption

NOTE: I've included only the relevant portions in the above examples.

However, the change could be made passive by just adding the parameters to the existing configuration at the top level.

@adrien-f
Copy link
Member

Hi 👋 !

This is an interesting feature. So we need to support three cases:

  • If no kms_key_id and no encryption_key but enabled then NewSSE
  • If kms_key_id and enabled then NewSSEKMS. Do you know what's the context parameter for ?
  • If encryption_key and enabled then NewSSEC

Seems clear enough ! What do you think ?

@taharah
Copy link
Author

taharah commented Apr 26, 2019

@adrien-f that looks good to me and what I was thinking. Additionally, the KMS encryption context is an optional set of key/value pairs that you can send with the requests.

@jujugrrr
Copy link

jujugrrr commented Jan 7, 2020

hi, it seems like a basic feature if you use S3 with server side encryption. @adrien-f Do you think it would be possible to work on this?

@taharah did you just use the default sse after all?

@bwplotka
Copy link
Member

bwplotka commented Jan 7, 2020

Valid request, help wanted (:

👍

@jujugrrr
Copy link

jujugrrr commented Jan 8, 2020

I can help with testing if needed, but I have limited go experience

@stale
Copy link

stale bot commented Feb 7, 2020

This issue/PR has been automatically marked as stale because it has not had recent activity. Please comment on status otherwise the issue will be closed in a week. Thank you for your contributions.

@stale stale bot added the stale label Feb 7, 2020
@jujugrrr
Copy link

jujugrrr commented Feb 7, 2020

Still a good feature to have :-)

@stale stale bot removed the stale label Feb 7, 2020
alex-laties pushed a commit to alex-laties/thanos that referenced this issue Feb 22, 2020
alex-laties pushed a commit to alex-laties/thanos that referenced this issue Feb 22, 2020
Signed-off-by: Alexander Laties <alex@laties.info>
alex-laties pushed a commit to alex-laties/thanos that referenced this issue Feb 22, 2020
Signed-off-by: Alexander Laties <agl@tumblr.com>
@stale
Copy link

stale bot commented Mar 8, 2020

This issue/PR has been automatically marked as stale because it has not had recent activity. Please comment on status otherwise the issue will be closed in a week. Thank you for your contributions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants