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

⚠️ Adds TLS options to managers #7483

Merged
merged 1 commit into from
Nov 7, 2022

Conversation

srm09
Copy link
Contributor

@srm09 srm09 commented Nov 2, 2022

What this PR does / why we need it:
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

Which issue(s) this PR fixes:
Fixes #6511

@k8s-ci-robot k8s-ci-robot added cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Nov 2, 2022
@srm09
Copy link
Contributor Author

srm09 commented Nov 2, 2022

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.

@srm09
Copy link
Contributor Author

srm09 commented Nov 2, 2022

/hold

@k8s-ci-robot k8s-ci-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Nov 2, 2022
main.go Outdated Show resolved Hide resolved
main.go Outdated Show resolved Hide resolved
main.go Outdated Show resolved Hide resolved
main.go Outdated
@@ -19,12 +19,14 @@ package main

import (
Copy link
Member

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

Copy link
Contributor

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?

Copy link
Contributor

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

https://github.com/kubernetes-sigs/cluster-api/blob/main/docs/developer/release-cycle.md#release-cycle

Copy link
Member

@sbueringer sbueringer Nov 4, 2022

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.

Copy link
Contributor Author

@srm09 srm09 Nov 4, 2022

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.

Copy link
Member

@sbueringer sbueringer Nov 4, 2022

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

Copy link
Member

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

Copy link
Member

@fabriziopandini fabriziopandini left a 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

@sbueringer
Copy link
Member

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

@srm09
Copy link
Contributor Author

srm09 commented Nov 4, 2022

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,

  • a local method contained in the main.go
  • a util method contained in a new util/flags package.

The idea is to have a single option.

@sbueringer
Copy link
Member

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

@srm09 srm09 force-pushed the manager/add-tls-configs branch 2 times, most recently from 0d7f4a8 to 17d992c Compare November 4, 2022 18:53
util/flags/tls.go Outdated Show resolved Hide resolved
util/flags/tls.go Outdated Show resolved Hide resolved
@srm09 srm09 force-pushed the manager/add-tls-configs branch 2 times, most recently from 1bf11fd to f1c99e1 Compare November 4, 2022 19:42
@srm09
Copy link
Contributor Author

srm09 commented Nov 4, 2022

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.
That way this PR can be unblocked and made ready to merge.

util/flags/tls.go Outdated Show resolved Hide resolved
Copy link
Member

@sbueringer sbueringer left a 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)

util/flags/tls.go Outdated Show resolved Hide resolved
util/flags/tls.go Outdated Show resolved Hide resolved
Copy link
Member

@fabriziopandini fabriziopandini left a 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

bootstrap/kubeadm/main.go Show resolved Hide resolved
docs/book/src/developer/providers/v1.2-to-v1.3.md Outdated Show resolved Hide resolved
util/flags/tls.go Show resolved Hide resolved
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>
@srm09
Copy link
Contributor Author

srm09 commented Nov 7, 2022

/unhold
@fabriziopandini @sbueringer this should be ready to go now.

@k8s-ci-robot k8s-ci-robot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Nov 7, 2022
@sbueringer
Copy link
Member

Thx!!

/lgtm

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Nov 7, 2022
Copy link
Member

@fabriziopandini fabriziopandini left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm
/approve

@k8s-ci-robot
Copy link
Contributor

[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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Nov 7, 2022
@sbueringer
Copy link
Member

/retest

flake

@k8s-ci-robot k8s-ci-robot merged commit 97a685a into kubernetes-sigs:main Nov 7, 2022
@k8s-ci-robot k8s-ci-robot added this to the v1.3 milestone Nov 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. lgtm "Looks good to me", indicates that a PR is ready to be merged. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Allow configuration of TLS Version for Webhook servers
6 participants