Added the Paragraph: Use of Custom kubelet credentials with the kubeadm join. (#40882)

* Added the Note: Use of Custom kubelet credentials with the kubeadm join.

* Updated the note.

* Updated the indentation.

* Removed Note and Added the content in the paragraph.

* resolved nit.

* Update kubeadm-join.md

* Rephrased the content.

* modified the content.

* Update kubeadm-join.md

---------

Co-authored-by: Qiming Teng <tengqm@outlook.com>
pull/41162/head
Shubham 2023-05-16 07:55:14 +05:30 committed by GitHub
parent 2016ffd896
commit b78e254bf1
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 24 additions and 1 deletions

View File

@ -81,7 +81,12 @@ the cluster configuration (including root CA) and validates it using the token
as well as validating that the root CA public key matches the provided hash and
that the API server certificate is valid under the root CA.
The CA key hash has the format `sha256:<hex_encoded_hash>`. By default, the hash value is returned in the `kubeadm join` command printed at the end of `kubeadm init` or in the output of `kubeadm token create --print-join-command`. It is in a standard format (see [RFC7469](https://tools.ietf.org/html/rfc7469#section-2.4)) and can also be calculated by 3rd party tools or provisioning systems. For example, using the OpenSSL CLI:
The CA key hash has the format `sha256:<hex_encoded_hash>`.
By default, the hash value is printed at the end of the `kubeadm init` command or
in the output from the `kubeadm token create --print-join-command` command.
It is in a standard format (see [RFC7469](https://tools.ietf.org/html/rfc7469#section-2.4))
and can also be calculated by 3rd party tools or provisioning systems.
For example, using the OpenSSL CLI:
```shell
openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | openssl dgst -sha256 -hex | sed 's/^.* //'
@ -175,6 +180,24 @@ In case the discovery file does not contain credentials, the TLS discovery token
you must keep it secret and transfer it over a secure channel. This might be possible with your
cloud provider or provisioning tool.
#### Use of custom kubelet credentials with `kubeadm join`
To allow `kubeadm join` to use predefined kubelet credentials and skip client TLS bootstrap
and CSR approval for a new node:
1. From a working control plane node in the cluster that has `/etc/kubernetes/pki/ca.key`
execute `kubeadm kubeconfig user --org system:nodes --client-name system:node:$NODE > kubelet.conf`.
`$NODE` must be set to the name of the new node.
2. Modify the resulted `kubelet.conf` manually to adjust the cluster name and the server endpoint,
or run `kubeadm kubeconfig user --config` (it accepts `InitConfiguration`).
If your cluster does not have the `ca.key` file, you must sign the embedded certificates in
the `kubelet.conf` externally.
1. Copy the resulting `kubelet.conf` to `/etc/kubernetes/kubelet.conf` on the new node.
2. Execute `kubeadm join` with the flag
`--ignore-preflight-errors=FileAvailable--etc-kubernetes-kubelet.conf` on the new node.
### Securing your installation even more {#securing-more}
The defaults for kubeadm may not work for everyone. This section documents how to tighten up a kubeadm installation