8

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.

Wytrzymały Wiktor
  • 11,492
  • 5
  • 29
  • 37
u123
  • 15,603
  • 58
  • 186
  • 303

1 Answers1

2

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.

  • 7
    Ok so basically the short answer to my question I asked is that the CA itself is not sensitive and does NOT need to be kept in a secret - although the convention is to have it stored in based64? – u123 Mar 18 '22 at 13:54
  • 4
    tl;dr is yes, you don't have (or even should not) keep `certificate-authority-data` secret. base64 is not there to encrypt the data but to encode it, it's a different thing. There is a good answer [here](https://stackoverflow.com/questions/4657416/difference-between-encoding-and-encryption) explaining the difference. –  Mar 18 '22 at 17:09