kubeadm: Add certificateKey field to v1beta2 config #77012
What type of PR is this?
What this PR does / why we need it:
This change introduces config fields to the v1beta2 format, that allow certificate key to be specified in the config file. This certificate key is a hex encoded AES key, that is used to encrypt certificates and keys, needed for secondary control plane nodes to join. The same key is used for the decryption
It is important to note, that this key is never uploaded to the cluster. It can only be specified on either command line or the config file.
The new fields can be used like so:
Note 1: I thought about adding validation of the key (should be hex encoded AES key + probably verify minimal key length), but since this was not done for the command line flag, I perceive it as out of scope for this PR. Hence, only a TODO is added.
Note 2: Currently, the command line option does not override the config file option. Instead an error is printed if both are specified. I am open to change for this behavior.
Which issue(s) this PR fixes:
Special notes for your reviewer:
Please, review only the top commit. Depends on #76710
Does this PR introduce a user-facing change?:
An example between the two different UX approaches in practice (Note 3).
i'm starting to realize that the kubeadm configuration is a bit weird WRT to bootstrap tokens:
the same problem happens now for the certs key. where should we put it?
A) so if we want to follow the existing patterns we should have it as a root field of Init and have it as a field under Discovery.
my vote goes for A), but i don't like any of the options.
@neolit123 I think it would be more confusing if we put tokens in a central place. What if you have multiple ones, which one are you going to use for the discovery process? What if you don't want to use token for discovery (use kubeconfig instead)?
From a UX perspective I am in favor of
Mainly because this seems a better separation of concerns. Ideally I would not want this key to end up on worker nodes even by accident. Writing it to the node registration struct will likely mean that the "common" join config will be made available to all nodes.
I also prefer
The benefit of
So my suggestion is:
[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: rosti
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