Skip to content

Commit 30c6e77

Browse files
committed
kubeadm: add guide for kubelet serving certs and metrics-server
Include a new section of the kubeadm certificate management page to talk about kubelet serving certificates and how to make them signed. Also include a note about using secure connection with the metrics-server.
1 parent 7f2b282 commit 30c6e77

File tree

2 files changed

+86
-1
lines changed

2 files changed

+86
-1
lines changed

content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md

Lines changed: 18 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -408,7 +408,7 @@ be advised that this is modifying a design principle of the Linux distribution.
408408

409409
## `kubeadm upgrade plan` prints out `context deadline exceeded` error message
410410

411-
This error message is shown when upgrading a Kubernetes cluster with `kubeadm` in the case of running an external etcd. This is not a critical bug and happens because older versions of kubeadm perform a version check on the external etcd cluster. You can proceed with `kubeadm upgrade apply ...`.
411+
This error message is shown when upgrading a Kubernetes cluster with `kubeadm` in the case of running an external etcd. This is not a critical bug and happens because older versions of kubeadm perform a version check on the external etcd cluster. You can proceed with `kubeadm upgrade apply ...`.
412412

413413
This issue is fixed as of version 1.19.
414414

@@ -420,3 +420,20 @@ To workaround the issue, re-mount the `/var/lib/kubelet` directory after perform
420420

421421
This is a regression introduced in kubeadm 1.15. The issue is fixed in 1.20.
422422

423+
## Cannot use the metrics-server securely in a kubeadm cluster
424+
425+
In a kubeadm cluster, the [metrics-server](https://github.com/kubernetes-sigs/metrics-server)
426+
can be used insecurely by passing the `--kubelet-insecure-tls` to it. This is not recommended for production clusters.
427+
428+
If you want to use TLS between the metrics-server and the kubelet there is a problem,
429+
since kubeadm deploys a self-signed serving certificate for the kubelet. This can cause the following errors
430+
on the side of the metrics-server:
431+
```
432+
x509: certificate signed by unknown authority
433+
x509: certificate is valid for IP-foo not IP-bar
434+
```
435+
436+
See [Enabling signed kubelet serving certificates](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/#kubelet-serving-certs)
437+
to understand how to configure the kubelets in a kubeadm cluster to have properly signed serving certificates.
438+
439+
Also see [How to run the metrics-server securely](https://github.com/kubernetes-sigs/metrics-server/blob/master/FAQ.md#how-to-run-metrics-server-securely).

content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md

Lines changed: 68 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -207,3 +207,71 @@ After a certificate is signed using your preferred method, the certificate and t
207207
Kubeadm does not support rotation or replacement of CA certificates out of the box.
208208

209209
For more information about manual rotation or replacement of CA, see [manual rotation of CA certificates](/docs/tasks/tls/manual-rotation-of-ca-certificates/).
210+
211+
## Enabling signed kubelet serving certificates {#kubelet-serving-certs}
212+
213+
By default the kubelet serving certificate deployed by kubeadm is self-signed.
214+
This means a connection from external services like the
215+
[metrics-server](https://github.com/kubernetes-sigs/metrics-server) to a
216+
kubelet cannot be secured with TLS.
217+
218+
To configure the kubelets in a new kubeadm cluster to obtain properly signed serving
219+
certificates you must pass the following minimal configuration to `kubeadm init`:
220+
221+
```yaml
222+
apiVersion: kubeadm.k8s.io/v1beta2
223+
kind: ClusterConfiguration
224+
---
225+
apiVersion: kubelet.config.k8s.io/v1beta1
226+
kind: KubeletConfiguration
227+
serverTLSBootstrap: true
228+
```
229+
230+
If you have already created the cluster you must adapt it by doing the following:
231+
- Find and edit the `kubelet-config-{{< skew latestVersion >}}` ConfigMap in the `kube-system` namespace.
232+
In that ConfigMap, the `config` key has a
233+
[KubeletConfiguration](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)
234+
document as its value. Edit the KubeletConfiguration document to set `serverTLSBootstrap: true`.
235+
- On each node, add the `serverTLSBootstrap: true` field in `/var/lib/kubelet/config.yaml`
236+
and restart the kubelet with `systemctl restart kubelet`
237+
238+
The field `serverTLSBootstrap: true` will enable the bootstrap of kubelet serving
239+
certificates by requesting them from the `certificates.k8s.io` API. One known limitation
240+
is that the CSRs (Certificate Signing Requests) for these certificates cannot be automatically
241+
approved by the default signer in the kube-controller-manager -
242+
[`kubernetes.io/kubelet-serving`](https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/#kubernetes-signers).
243+
This will require action from the user or a third party controller.
244+
245+
These CSRs can be viewed using:
246+
247+
```shell
248+
kubectl get csr
249+
NAME AGE SIGNERNAME REQUESTOR CONDITION
250+
csr-9wvgt 112s kubernetes.io/kubelet-serving system:node:worker-1 Pending
251+
csr-lz97v 1m58s kubernetes.io/kubelet-serving system:node:control-plane-1 Pending
252+
```
253+
254+
To approve them you can do the following:
255+
```shell
256+
kubectl certificate approve <CSR-name>
257+
```
258+
259+
By default, these serving certificate will expire after one year. Kubeadm sets the
260+
`KubeletConfiguration` field `rotateCertificates` to `true`, which means that close
261+
to expiration a new set of CSRs for the serving certificates will be created and must
262+
be approved to complete the rotation. To understand more see
263+
[Certificate Rotation](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#certificate-rotation).
264+
265+
If you are looking for a solution for automatic approval of these CSRs it is recommended
266+
that you contact your cloud provider and ask if they have a CSR signer that verifies
267+
the node identity with an out of band mechanism.
268+
269+
{{% thirdparty-content %}}
270+
271+
Third party custom controllers can be used:
272+
- [kubelet-rubber-stamp](https://github.com/kontena/kubelet-rubber-stamp)
273+
274+
Such a controller is not a secure mechanism unless it not only verifies the CommonName
275+
in the CSR but also verifies the requested IPs and domain names. This would prevent
276+
a malicious actor that has access to a kubelet client certificate to create
277+
CSRs requesting serving certificates for any IP or domain name.

0 commit comments

Comments
 (0)