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 user KMS key #161

Closed
pierreozoux opened this issue Jan 16, 2019 · 5 comments · Fixed by #166
Closed

Support user KMS key #161

pierreozoux opened this issue Jan 16, 2019 · 5 comments · Fixed by #166
Assignees

Comments

@pierreozoux
Copy link

As a cluster operator in an enterprise env, I'm required to encrypt all the things.

It would be nice if I could supply my own kms key.

@bparees
Copy link
Contributor

bparees commented Jan 16, 2019

@pierreozoux can you open this as a formal RFE so we can track it properly? we are using github issues just for very lightweight items.

@pierreozoux
Copy link
Author

Should I open a RedHat support case? Or what is this RFE, is it on the coreos Jira? Or RedHat bugzilla? (I'm a bit confused, and that's why I thought GitHub would be the best place)

@bparees
Copy link
Contributor

bparees commented Jan 17, 2019

Going through a support case is best(and support can then open the RFE), that way the RFE is tied to a specific customer request which helps w/ prioritization.

That said, our support team may be slightly confused when you ask for an RFE against an unreleased product :) You can point them to this issue discussion.

I will also say we may choose not to implement this... basically i'd expect your choices to be:

  1. use the bucket we create, w/ whatever encryption we choose
    or
  2. supply your own bucket w/ whatever encryption you choose

(you'll be able to do either of those in the 4.0GA.. in fact you can do them in the beta today as well)

we are trying to move away from the hybrid model of us managing components that admins/end-users are customizing significantly. We are trying to simplify the configuration surface area.

@pierreozoux
Copy link
Author

we are trying to move away from the hybrid model of us managing components that admins/end-users are customizing significantly. We are trying to simplify the configuration surface area.

Sounds good :) I'll close this issue then!

@bparees
Copy link
Contributor

bparees commented Jan 22, 2019

actually @coreydaley understood this RFE better than I did and I now understand why we still need support on our side for KMS keys. Corey is implementing the support here:
#166

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

Successfully merging a pull request may close this issue.

3 participants