From 0fb0c50071cbc0e26aae6224468d6633e1c5f7f9 Mon Sep 17 00:00:00 2001 From: kadtendulkar Date: Sat, 9 Jul 2022 22:10:15 +0530 Subject: [PATCH] Update content/en/docs/concepts/architecture/control-plane-node-communication.md --- .../concepts/architecture/control-plane-node-communication.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/architecture/control-plane-node-communication.md b/content/en/docs/concepts/architecture/control-plane-node-communication.md index df384800e9606..785040cda316e 100644 --- a/content/en/docs/concepts/architecture/control-plane-node-communication.md +++ b/content/en/docs/concepts/architecture/control-plane-node-communication.md @@ -33,7 +33,7 @@ are allowed. Nodes should be provisioned with the public root certificate for the cluster such that they can connect securely to the API server along with valid client credentials. A good approach is that the client credentials provided to the kubelet are in the form of a client certificate. See -[kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) +[kubelet TLS bootstrapping](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) for automated provisioning of kubelet client certificates. Pods that wish to connect to the API server can do so securely by leveraging a service account so