Should the k8s Cluster Certificate Authority be kept secret? - kubernetes

Question

I have an azure aks cluster and a local kubeconfig:
apiVersion: v1
kind: Config
clusters:
- name: my-cluster
cluster:
certificate-authority-data: LS0...0tCg==
server: https://api-server:443
contexts:
- name: my-context
context:
cluster: my-cluster
namespace: samples
user: my-context-user
current-context: my-context
users:
- name: my-context-user
user:
token: ey...jI
that is used for connecting to the cluster, listing pods etc.
From what I understand its important that the token in the kubeconfig is kept secret/private. But whats about the certificate-authority-data?
Since its just used to verify the the API server certificate I guess it has the same status as a public key and can be made public available at least for internal team members.
And is there and documentation that confirms this?
I did not find any info regarding that here or here.

Answer 1

All clients (pods, normal users using kubeconfigfile, service accounts, component clients: kubelet to kube-apiserver etc.) are suing ca.crt in order to recognize self-signed certificates.
As we can see in the docs
Client certificate authentication is enabled by passing the --client-ca-file=SOMEFILE option to API server. The referenced file must contain one or more certificate authorities to use to validate client certificates presented to the API server. If a client certificate is presented and verified, the common name of the subject is used as the user name for the request. As of Kubernetes 1.4, client certificates can also indicate a user's group memberships using the certificate's organization fields. To include multiple group memberships for a user, include multiple organization fields in the certificate.
In k8s cluster boostraped using kubeadm by default kube-apiserver is consigured with --client-ca-file=/etc/kubernetes/pki/ca.crt.
As you can see in the docs certificate-authority ca.crt should be be referenced in any config file for all clients which are used to securely connect with k8s cluster.
Sometimes you may want to use Base64-encoded data embedded here instead of separate certificate files; in that case you need to add the suffix -data to the keys, for example, certificate-authority-data, client-certificate-data, client-key-data
By default this value is Base64-encoded and embedded in tho the KubeconfigFile.
When your workload is accessing the k8s API from within a Pod
You can find also information about
# Reference the internal certificate authority (CA)
CACERT=${SERVICEACCOUNT}/ca.crt
by default ca.crt is located in /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
Why ca.crt is included in all kubeconfigFiles - as we can see in the docs
A client node may refuse to recognize a self-signed CA certificate as valid. For a non-production deployment, or for a deployment that runs behind a company firewall, you can distribute a self-signed CA certificate to all clients and refresh the local list for valid certificates.
According to your last statement.
Since its just used to verify the the API server certificate I guess it has the same status as a public key and can be made public available at least for internal team members
certificate-authority-data should be included in all kubeconfig files for all internal team members, while client-key-data or tokens should be kept secret between different clients.