Enhancements: Encrypt secrets in etcd

[stevesloka]

Description

• One-line feature description (can be used as a release note):
  Encrypt secrets stored in etcd.
• Primary contact (assignee):
  
  
  
  • @smarterclayton
  
  
• Responsible SIGs: @kubernetes/sig-auth-feature-requests
• Design proposal link (community repo):
  https://github.com/kubernetes/community/pull/454
• Reviewer(s) - (for LGTM) recommend having 2+ reviewers (at least one from code-area OWNERS file) agreed to review. Reviewers from multiple companies preferred:
  
  
  
  • @saad-ali
  
  
  • @destijl
  
  
  • @liggitt
  
  
• Approver (likely from SIG/area to which feature belongs):
  
  
  
  • @liggitt
  
  
• Feature target (which target equals to which milestone):
  
  
  
  • Alpha release target (x.y)
  
  
  • 1.7
  
  
  • Beta release target (x.y)
  
  
  • 1.8
  
  
  • Stable release target (x.y)
  
  
  • 1.9
  
  

[stevesloka]

//cc @smarterclayton @philips

[liggitt]

cc @erictune @deads2k

[philips]

cc @hongchaodeng @xiang90

[deads2k]

@stevesloka Do you have a pull that describes your proposed solution in more detail?

[stevesloka]

@deads2k I pushed up my wip. I broke it last night, trying to see what went wrong, but you can see my work here: https://github.com/kubernetes/kubernetes/pull/32579

[alfred-huangjian]

cc @kubernetes/huawei

[ravilr]

@philips @stevesloka is this feature being targetted for 1.5 release? Thanks.

[stevesloka]

Yes would like to work on it. Last we spoke the 1.4 release was being finalized and wasn't time.

[philips]

@stevesloka I think the next step is to come up with a design proposal and we can help to review. I would suggest you come up with a handful of designs, make your recommendation, and move from there to get a proposal in. This feature repo isn't supposed to be used for design discussion; but I am happy to help. Put something together and we can discuss on https://groups.google.com/forum/#!forum/kubernetes-sig-auth.

[idvoretskyi]

@stevesloka what is the actual status of the feature? Any update on it?

[erictune]

I don't expect this in 1.5.
There has been recent discussion about Vault integration.
See: https://github.com/kelseyhightower/vault-controller
If that gains acceptance, I think the need for this feature will be
lessened.

On Thu, Nov 3, 2016 at 8:46 AM, Ihor Dvoretskyi [email protected]
wrote:

@stevesloka https://github.com/stevesloka what is the actual status of
the feature? Any update on it?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/features/issues/92#issuecomment-258182362,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHuudiCeKI58SSKcbkoinC_KcpKDHPCwks5q6gHHgaJpZM4J7rLO
.

[andrewsykim]

@idvoretskyi I'v been working with steve on a design proposal, should we open another PR for that? Part of the proposal is already on https://github.com/kubernetes/kubernetes/pull/32579

[idvoretskyi]

@andrewsykim please, take a look at @erictune's comment above.

[stevesloka]

The starter (incomplete) proposal is here: https://docs.google.com/document/d/1lFhPLlvkCo3XFC2xFDPSn0jAGpqKcCCZaNsBAv8zFdE/edit

@erictune How does Kelsey's repo resolve the problem? I do like the integration pattern with Vault, but now ALL of my apps are forced to understand Vault and how it works. I wrote this (https://github.com/upmc-enterprises/kubernetes-secret-manager) so that you could still use Vault, but your app is abstracted away from knowing the underlining pieces in use.

This is why I was looking to encrypt the secrets so we could continue to use them and they would be compliant at rest inside etcd.

[erictune]

Will take a look at upmc-enterprises/kubernetes-secret-manager.

On Thu, Nov 3, 2016 at 9:24 AM, Steve Sloka [email protected]
wrote:

The starter (incomplete) proposal is here: https://docs.google.com/
document/d/1lFhPLlvkCo3XFC2xFDPSn0jAGpqKcCCZaNsBAv8zFdE/edit

@erictune https://github.com/erictune How does Kelsey's repo resolve
the problem? I do like the integration pattern with Vault, but now ALL of
my apps are forced to understand Vault and how it works. I wrote this (
https://github.com/upmc-enterprises/kubernetes-secret-manager) so that
you could still use Vault, but your app is abstracted away from knowing the
underlining pieces in use.

This is why I was looking to encrypt the secrets so we could continue to
use them and they would be compliant at rest inside etcd.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/features/issues/92#issuecomment-258194574,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHuuduGCL05aRfJeKWdmH4qY7tmQ953tks5q6grIgaJpZM4J7rLO
.

[andrewsykim]

@idvoretskyi I read the comment, thanks. I said what I said because even though the need for the feature is lessened (as eric and steve mentioned), Kubernetes should still support encrypting Secrets in etcd so long as people are storing secrets using the Secrets api. Just my honest opinion. I'm more than happy to help get this feature out even though it is not expected for 1.5 release as I'm sure many other people could benefit from it.

[idvoretskyi]

@andrewsykim understood you. I would suggest to find the consensus within the sponsoring SIG @kubernetes/sig-auth /cc @erictune

[philips]

cc @kelseyhightower

[smarterclayton]

I'm going to take over shepherding this proposal for 1.6 since we have a need for it. I've added comments on the doc, let's get any open questions refined and then open a PR with a proposal as the next step.

[idvoretskyi]

@smarterclayton so, does this feature target 1.6?

[apsinha]

It would be great to target 1.6 as this is an often requested feature. @smarterclayton are we targeting alpha?

[destijl]

We're targeting 1.7 for this. The features template has been simplified, so here's the updated view:

• One-line feature description (can be used as a release note):
  Encrypt secrets stored in etcd.
• Primary contact (assignee):
  
  
  
  • @smarterclayton
  
  
• Responsible SIGs: @kubernetes/sig-auth-feature-requests
• Design proposal link (community repo):
  https://github.com/kubernetes/community/pull/454
• Reviewer(s) - (for LGTM) recommend having 2+ reviewers (at least one from code-area OWNERS file) agreed to review. Reviewers from multiple companies preferred:
  
  
  
  • @saad-ali
  
  
  • @destijl
  
  
  • @liggitt
  
  
• Approver (likely from SIG/area to which feature belongs):
  
  
  
  • @liggitt
  
  
• Feature target (which target equals to which milestone):
  
  
  
  • Alpha release target (x.y)
  
  
  • 1.7
  
  
  • Beta release target (x.y)
  
  
  • 1.8
  
  
  • Stable release target (x.y)
  
  
  • 1.9
  
  

[luxas]

@stevesloka @destijl Any documentation PR for this one yet?

[idvoretskyi]

@stevesloka @smarterclayton please, provide us with the design proposal link and docs PR link (and update the features tracking spreadsheet with it).
cc @kubernetes/sig-auth-feature-requests

[idvoretskyi]

@stevesloka @smarterclayton is this a new version of the design proposal? https://github.com/kubernetes/community/pull/607

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
/remove-lifecycle stale

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[idvoretskyi]

@mikedanese any progress is expected with this feature? It was on hold for a while.

[venezia]

Is there a link to where we are on this feature? The Documentation seems a bit dated with "_Users may be required to decrypt their data prior to upgrading to 1.8.0_" considering 1.10 is out.

There's been progress on the key storage via KMS provider - it would be great if both features had a schedule of when they'd be likely promoted to beta and stable

[ericchiang]

@venezia work is being done over the 1.11 release cycle to promote this to beta https://github.com/kubernetes/kubernetes/issues/61420

[justaugustus]

@mikedanese @smarterclayton @ericchiang
Any plans for this in 1.11?

If so, can you please ensure the feature is up-to-date with the appropriate:

• Description
• Milestone
• Assignee(s)
• Labels:
  
  
  
  • stage/{alpha,beta,stable}
  
  
  • sig/*
  
  
  • kind/feature
  
  

cc @idvoretskyi

[klausenbusk]

Could someone help me understand why the doc says that the key Must be rotated every 200k writes, but the code says:

// Because this mode requires a generated IV and IV reuse is a known weakness of AES-GCM, keys
// must be rotated before a birthday attack becomes feasible. NIST SP 800-38D
// (http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf) recommends using the same
// key with random 96-bit nonces (the default nonce length) no more than 2^32 times, and
// therefore transformers using this implementation must ensure they allow for frequent key
// rotation. Future work should include investigation of AES-GCM-SIV as an alternative to
// random nonces.

200k != 2^32
Where does the 200k writes statement come from?

[kacole2]

Hi
This enhancement has been tracked before, so we'd like to check in and see if there are any plans for this to graduate stages in Kubernetes 1.13. This release is targeted to be more ‘stable’ and will have an aggressive timeline. Please only include this enhancement if there is a high level of confidence it will meet the following deadlines:

• Docs (open placeholder PRs): 11/8
• Code Slush: 11/9
• Code Freeze Begins: 11/15
• Docs Complete and Reviewed: 11/27

Please take a moment to update the milestones on your original post for future tracking and ping @kacole2 if it needs to be included in the 1.13 Enhancements Tracking Sheet

Thanks!

[luxas]

I'm closing this tracking issue in favor of https://github.com/kubernetes/enhancements/issues/460. Correct me if I'm wrong. Also, this seems to be stable now.