Change:
(ex: `ca.crt`, `ca.key`, `front-proxy-ca.crt`, and `front-proxy-ca.key`) to all your control plane nodes in the Kubernetes certificates directory. <del> 1. Update *Kubernetes controller manager's* `--root-ca-file` to include both old and new CA and restart controller manager. </del> <ins> 1. Update {{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}'s `--root-ca-file` to include both old and new CA. Then restart the component. </ins> Any service account created after this point will get secrets that include both old and new CAs. {{< note >}} <del> Remove the flag `--client-ca-file` from the *Kubernetes controller manager* configuration. You can also replace the existing client CA file or change this configuration item to reference a new, updated CA. [Issue 1350](https://github.com/kubernetes/kubeadm/issues/1350) tracks an issue with *Kubernetes controller manager* being unable to accept a CA bundle. </del> <ins> The files specified by the kube-controller-manager flags `--client-ca-file` and `--cluster-signing-cert-file` cannot be CA bundles. If these flags and `--root-ca-file` point to the same `ca.crt` file which is now a bundle (includes both old and new CA) you will face an error. To workaround this problem you can copy the new CA to a separate file and make the flags `--client-ca-file` and `--cluster-signing-cert-file` point to the copy. Once `ca.crt` is no longer a bundle you can restore the problem flags to point to `ca.crt` and delete the copy. </ins> {{< /note >}} 1. Update all service account tokens to include both old and new CA certificates.

Discussion:
This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: There is a remark that mixes up two issues: is not about , rather it is about . even actually relevant to kube-controller-manager? Ayodele Abejide and I can not see any relevant for it (). 1350 looks like a show-stopper for this recipe. Proposed Solution: Fix the recipe. Fix issue 1350. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/sig auth /language en
/kind bug (seems valid to me)
Note: Remove the flag --client-ca-file from the Kubernetes controller manager configuration. You can also replace the existing client CA file or change this configuration item to reference a new, updated CA. Issue 1350 tracks an issue with Kubernetes controller manager being unable to accept a CA bundle. i think the problem that --client-ca-file and --cluster-signing-cert-file flags share is that the KCM does not allow CA bundles for both of them. this also implies complications around this guide. the kubeadm ticket is noisy and i don't think it should be linked from this page. note that the step above mentions: Update Kubernetes controller manager's --root-ca-file to include both old and new CA and restart controller manager. at that point if the same file is a bundle the KCM would just error out because of --client-ca-file, thus the recommendation about removal or making it point to a separate CA. used for client certificate authentication to allow clients to validate the signature of the serving certificate. the KCM can still be served over HTTPs. i guess not if the flag is removed from from the KCM, until the old CA is removed from the bundle at which point the flag can be re-. i think there are wider problems here and we should have an issue in k/k tagged with sig/auth that tracks progress on the KCM supporting bundles.

i've seen mentions around this being worked on here: the note in this document needs clarification: it should link to the k/k issue, if one day the KCM --client-ca-file supports bundles it should explain why the flag is being removed and what are the consequences of doing that (e.g. MITM?). should the flag removal be temporary until the bundle no longer has the old CA? cc
In my opinion, the flag is still needed, when I tested the recipe there were 2 problems at the start, one from and another from , that when I found to be problematic, the point that later only got caught when I removed chain from . That's why I included this in the recipe, that we should either remove it or replace it with the new CA, whichever fits the need cluster to cluster basis. It doesn't makes it show stopper but, yes, I agree that the page needs a bit reword in the paragraph to make it less confusing for people following it.
PS: Just in case someone wants to re-validate, the error I was getting with with old+new CA certs was similar to "certificate signed by unknown authority" and stopped when I replaced it with only new CA. So it was more like the first bundle in the chain was accepted but the newer one did not.
/priority awaiting-more-evidence Please feel free to /priority some-other-value and /triage accepted if this is confirmed valid.
would you like send a PR to amend the paragraph? EDIT: NVM i've sent the PR here, PTAL:
(sent the PR) /remove-priority awaiting-more-evidence /priority backlog
/triage accepted