-
Notifications
You must be signed in to change notification settings - Fork 3.4k
Deprecate providing Hubble TLS secrets in helm values #34114
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
Conversation
5737504
to
0dfd20d
Compare
/test |
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.
Ideally deprecations should also be documented in upgrade notes (Documentation/operations/upgrade.rst
), can you add a note there?
Also deprecate specifying Hubble TLS key/cert values directly in Helm values. Signed-off-by: Chance Zibolski <chance.zibolski@gmail.com>
Signed-off-by: Chance Zibolski <chance.zibolski@gmail.com>
Instead of suggesting users put TLS private keys into their helm values, instruct them to create secrets themselves and configure their helm values to use these pre-existing secrets. Signed-off-by: Chance Zibolski <chance.zibolski@gmail.com>
0dfd20d
to
2fa742f
Compare
/test |
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.
lgtm
/test |
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 great doc improvement, thanks!
This is the first step in a few changes to improve our documentation around configuring and using Hubble with TLS. The next PR #34115 will build upon this to make some improvements on the Hubble TLS documentation.
The primary goal with this PR is to add support for using existing secrets for Hubble TLS certificates and private keys to discourage storing private keys in helm values, and to better support users who wish to manage TLS certificates using other methods. While introducing support for using existing secrets, we should deprecate the previous method of directly providing certificates via helm values.
In the same vein, we want to encourage users to use one of the automated TLS methods rather than provide their own certificates in most cases, so let's move the documentation for user provided certificates to the end of the section.
I've got a number of other TLS related improvements coming, mostly in the form of documentation updates, and would like to get all of those improvements in to the stable/v1.16 documentation, so I'm setting the
needs-backport/1.16
label on this PR. If the deprecation, and/or helm changes are an issue to backport, then we could skip the backport on this PR, and I'll just have to deal with conflicts when back porting the rest of my upcoming PRs to v1.16. Let me know what you think.