kubernetes: Removing --root-ca-file from kube-controller-manager args does not update ServiceAccount token Secrets

What happened:

I removed the --root-ca-file from my kube-controller-manager command line arguments, but the ServiceAccount token (type: kubernetes.io/service-account-token) Secrets did not receive any updates to their ca.crt keys.

What you expected to happen:

I expected that the ca.crt key would be removed, since it is implied by the “accessing the API from a Pod” docs that that file will not be there if it’s not “available” and the kube-controller-manager command line reference docs imply that if the setting is not set, it will not include the CA in the ServiceAccount token’s secret.

How to reproduce it (as minimally and precisely as possible):

1. Start up a cluster where kube-controller-manager has a --root-ca-file flag set to a correct bundle for the apiserver’s server cert.
2. Create a ServiceAccount token Secret (e.g. by creating a ServiceAccount)
3. Observe that the Secret has a key called ca.crt
4. Restart kube-controller-manager without the --root-ca-file flag
5. Observe that the Secret still has a key called ca.crt and its value is unchanged

Anything else we need to know?:

I was able to confirm that if I keep the --root-ca-file flag but change it to some other file that’s still valid for the apiserver’s server cert, just contains other stuff in it, the Secrets do update with a new value for ca.crt.

I looked in logs for something that would help me figure out what was wrong, and I saw this, but it appeared both when I removed the --root-ca-file flag and when I kept it but changed the value for it, so I guess it’s not related?

controllermanager.go:518] Starting "root-ca-cert-publisher"
controllermanager.go:525] Skipping "root-ca-cert-publisher"

Environment:

• Kubernetes version (use kubectl version): 1.18.15
• Cloud provider or hardware configuration: AWS
• OS (e.g: cat /etc/os-release): Debian GNU/Linux 9 (stretch)
• Kernel (e.g. uname -a): Linux ip-10-47-23-237 5.4.38 #1~bt9+1 SMP Tue May 12 21:16:19 UTC 2020 x86_64 GNU/Linux (I think my company patched this kernel but I don’t think it’s relevant to this issue)
• Install tools: the hard way 😃
• Network plugin and version (if this is a network-related bug): n/a
• Others: