<p>I have an azure aks cluster and a local kubeconfig:</p>
<pre><code>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
</code></pre>
<p>that is used for connecting to the cluster, listing pods etc.</p>
<p>From what I understand its important that the token in the kubeconfig is kept secret/private. But whats about the <code>certificate-authority-data</code>?</p>
<p>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.</p>
<p>And is there and documentation that confirms this?</p>
<p>I did not find any info regarding that <a href="https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/" rel="noreferrer">here</a> or <a href="https://kubernetes.io/docs/reference/access-authn-authz/authentication/" rel="noreferrer">here</a>.</p>

<p>All clients (pods, normal users using kubeconfigfile, service accounts, component clients: kubelet to kube-apiserver etc.) are suing <em>ca.crt</em> in order to recognize self-signed certificates.</p>
<p>As we can see in the <a href="https://kubernetes.io/docs/reference/access-authn-authz/authentication/#x509-client-certs" rel="nofollow noreferrer">docs</a></p>
<blockquote>
<p>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.</p>
</blockquote>
<p>In k8s cluster boostraped using kubeadm by default kube-apiserver is consigured with <code>--client-ca-file=/etc/kubernetes/pki/ca.crt</code>.</p>
<p>As you can see in the <a href="https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#define-clusters-users-and-contexts" rel="nofollow noreferrer">docs</a> certificate-authority <em>ca.crt</em> should be be referenced in any config file for all clients which are used to securely connect with k8s cluster.</p>
<p>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</p>
<p>By default this value is Base64-encoded and embedded in tho the KubeconfigFile.</p>
<p>When your workload is accessing the k8s API from within a <a href="https://kubernetes.io/docs/tasks/run-application/access-api-from-pod/#without-using-a-proxy" rel="nofollow noreferrer">Pod</a>
You can find also information about</p>
<pre><code># Reference the internal certificate authority (CA)
CACERT=${SERVICEACCOUNT}/ca.crt
</code></pre>
<p>by default <em>ca.crt</em> is located in <code>/var/run/secrets/kubernetes.io/serviceaccount/ca.crt</code></p>
<p>Why <em>ca.crt</em> is included in all kubeconfigFiles - as we can see in the <a href="https://kubernetes.io/docs/tasks/administer-cluster/certificates/#distributing-self-signed-ca-certificate" rel="nofollow noreferrer">docs</a></p>
<blockquote>
<p>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.</p>
</blockquote>
<p>According to your last statement.</p>
<blockquote>
<p>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</p>
</blockquote>
<p><code>certificate-authority-data</code> should be included in all kubeconfig files for all internal team members, while <code>client-key-data</code> or tokens should be kept secret between different clients.</p>
