-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Comments
Hi 👋 ! This is an interesting feature. So we need to support three cases:
Seems clear enough ! What do you think ? |
@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. |
Valid request, help wanted (: 👍 |
I can help with testing if needed, but I have limited go experience |
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. |
Still a good feature to have :-) |
Signed-off-by: Alexander Laties <alex@laties.info>
Signed-off-by: Alexander Laties <agl@tumblr.com>
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. |
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:
I think it would be nice if we changed the configuration to something like the following:
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.
The text was updated successfully, but these errors were encountered: