-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
⚠️ Adds TLS options to managers #7483
⚠️ Adds TLS options to managers #7483
Conversation
12:14:48 ➜ ./capi -h
Usage of ./capi:
...
--sync-period duration The minimum interval at which watched resources are reconciled (e.g. 15m) (default 10m0s)
--tls-cipher-suites string Comma-separated list of cipher suites for the server. If omitted, the default Go cipher suites will be used.
Possible values are TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256, TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_3DES_EDE_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_RC4_128_SHA.
--tls-min-version string The minimum TLS version in use by the webhook server.
Possible values are VersionTLS10, VersionTLS11, VersionTLS12, VersionTLS13. (default "VersionTLS12")
-v, --v Level number for the log level verbosity
--vmodule pattern=N,... comma-separated list of pattern=N settings for file-filtered logging (only works for text log format)
...
pflag: help requested This is the help text for the new flags introduced. |
/hold |
main.go
Outdated
@@ -19,12 +19,14 @@ package main | |||
|
|||
import ( |
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.
Just to make it visible here: Let's also document this in the v1.2-v1.3 migration guide and link the current PR as a reference PR
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.
Does this PR require any action from providers?
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.
If so we should follow the new process since beta is already out:
All changes that impact providers' adoption of the new release should be announced in the provider updates section of the office hours meeting notes and approved in the PR or issue by both approvers and key affected providers
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.
In my opinion it doesn't require any action. We would add a recommendation to the migration guide as we usually do. But the migration guide itself is not binding and part of the contract. Some providers follow it, some don't (at least that's my impression from previous CAPI bumps).
But you have a point, it's a change that providers have to actively implement if they follow our migration guide which we see as a best practice.
That being said, I tend to agree that we should bring this up next Wednesday in the office hours.
If we don't get it approved, I would like to merge this change to core CAPI itself regardless (but without changing the migration guide) and add the documentation for providers in the upcoming v1.3 => v1.4 migration guide. I think the change to CAPI itself doesn't affect providers, only the recommendation for providers to do the same.
P.S. @fabriziopandini I think we have to put the instructions for SSA that we added to the previous migration guide to one of the contract docs as well: https://cluster-api.sigs.k8s.io/developer/providers/v1.1-to-v1.2.html#required-api-changes-for-providers. Otherwise it's hard for new providers to implement it correctly for new providers. And given we see this part of the contract for providers supporting ClusterClass we have to specify it also outside of the migration guide.
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.
From the wording of the guideline pointed out by Cecile above, this is not a change that needs to be adopted by the providers to adopt this CAPI release. This is more of a good to make change(klog logging change) rather than a must make change(like SSA).
My vote would be include these in the migration guide with an explicit callout saying that this is not required to be implemented/used by providers, but it is a good to be included for the sake of consistency amongst CAPI and providers.
We can chat more about this during the office hours and get more inputs.
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.
Documenting it like that sounds like a good trade-off to me
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.
@CecileRobertMichon Move the provider-relevant part to #7511
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.
Q: what about creating two util func, one for adding flags and one for setting them?
We can eventually also add those func to utils and make them usable from providers
Fine for me. If we go through the effort of implementing a util package including stuff like naming etc. I think we should consider exporting it directly, so providers don't even have to start copy&pasting our code |
d152b92
to
dcb1cb1
Compare
On the topic of creating util functions, I was not super clear what @fabriziopandini exactly meant, so I tried to create a util function for generating the TLSOptions func slice from the provided inputs. Currently, there are 2 ways of generating the TLSOptions func in the PR,
The idea is to have a single option. |
I think after my comment the idea was the separate package + another func in this package to define the flags so we don't have to copy&paste the flag definitions |
0d7f4a8
to
17d992c
Compare
1bf11fd
to
f1c99e1
Compare
Added the changes to the migration docs as a separate commit, should I move it out to a separate PR and we can figure out whether to include it in 1.3.0 release or not after the next office hours on Wednesday. |
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.
Just two nits.
Yes agree. Let's move the doc change to a separate PR, everything else doesn't affect providers at all.
This way we can get it merged today/tomorrow and include it in beta.1 (which also makes it easier to pick up by providers earlier if they want to independent of the note in the migration doc)
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.
overall lgtm, last round of nits
f1c99e1
to
b0d9021
Compare
This patch introduces two new flags to configure TLS options on the managers: 1. --tls-min-version which is used to set the minimum TLS version in use by the webhook server. 2. --tls-cipher-suites which is used to set the TLS cipher suites in use by the webhook server. The minimum TLS version defaults to 1.2 Signed-off-by: Sagar Muchhal <muchhals@vmware.com>
b0d9021
to
3ad56fa
Compare
/unhold |
Thx!! /lgtm |
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
/approve
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: fabriziopandini The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/retest flake |
What this PR does / why we need it:
This patch introduces two new flags to configure TLS options on the managers:
The minimum TLS version defaults to 1.2
Which issue(s) this PR fixes:
Fixes #6511