Certificats PKI et exigences

Kubernetes requiert les certificats gérés par PKI (Public Key Infrastructure ou ICP pour Infrastructure à Clé Publique) pour l'authentification via TLS. Si vous installez Kubernetes à l'aide de kubeadm, les certificats dont votre grappe exige sont automatiquement générés. Vous pouvez également générer vos propres certificats -- par exemple, mieux sécuriser vos clés privées en ne les stockant pas tous sur la machine hébergeant le serveur API.

Cette page liste les certificats requis par votre grappe.

Comment les certificats au sein de votre grappe sont utilisés ?

Kubernetes requiert une PKI pour les opérations suivantes:

Certificats Serveur

• Certificat Serveur pour le serveur API.
• Certificate Serveur pour le serveur etcd
• Certificats Serveur pour chaque kubelet (chaque noeud exécute un kubelet)
• Certificat Serveur optionnel pour le front-proxy

Certificats Client

• Les certificats Client pour chaque kubelet, utilisés pour s'authentifier auprès du serveur API en tant que client de l'API de Kubernetes
• Certificat Client pour chaque serveur API, utilisé pour s'authentifier en tant que client auprès de etcd
• Certificat Client pour le gestionnaire de contrôleurs afin de sécuriser la communication avec le serveur API
• Certificat Client pour le planificateur afin de sécuriser la communication avec le serveur API
• Certificat Client, un pour chaque noeud, pour kube-proxy pour s'authentifier auprès du serveur API
• Certificats Client optionnels pour les administrateurs de la grappe afin de s'authentifier auprès du serveur API
• Certificat Client optionnel pour le front-proxy

Certificats client et serveur pour Kubelet

Pour établir une connexion sécurisée et s'authentifier lui-même auprès de kubelet, le serveur API a besoin d'une paire certificat client/clé privée.

Dans ce scénario, il existe deux approches pour l'utilisation du certificat:

• Certificat et clé privée partagés: kube-apiserver peut utiliser le même certificat et la même clé privée que ceux qu'il utilise pour permettre l'authentification de ses clients. C'est-à-dire, les fichiers existant, dont apiserver.crt et apiserver.key, peuvent être utilisés pour communiquer avec les serveurs kubelet.

• Certficat et clé privée distincts: D'un autre côté, kube-apiserver peut utiliser un autre certificat et une autre clé privée afin de s'authentifier auprès des serveurs kubelet. Dans ce cas précis, un nouveau certificat nommé kubelet-client.crt et la clé privée lui correspondant, kubelet-client.key devront alors être créés.

etcd implemente également le Mutual TLS (mTLS) pour authentifier ses clients et les peer.

Où sont stockés les certificats ?

Si vous installez Kubernetes à l'aide de kubeadm, la plupart des certificats se trouvent dans /etc/kubernetes/pki. Tous les chemins des fichiers dans cette documentation sont relatifs à ce dossier, sauf ceux des certificats du compte utilisateur dont la base est plutôt /etc/kubernetes, et que cette dernière soit l'emplacement par défaut utilisé par kubeadm pour stocker ces certificats.

Configurer manuellement les certificats

Si vous ne souhaitez pas utiliser kubeadm pour générer les certificats requis, vous pouvez les créer manuellement. Voir Certificats pour plus de détails sur la création de votre propre certificat racine et les certificats issus de ce dernier. Voir Gestion des certificats avec kubeadm pour en savoir plus sur la gestion des certificats.

Certificat racine principal

Vous pouvez créer un certificat racine principal, controllé par un administrateur. Ce certificat racine principal permet ensuite de créer de multiples certificats racine intermédiaires, et déléguer toute création supplémentaire à Kubernetes lui-même.

Certificats racines requis:

Avant les certificats racines précedent, il est aussi nécessaire d'avoir un couple de clés publiaue/privé pour la gestion du service account, sa.key and sa.pub. L'exemple ci-dessous illustre les fichiers vus dans le tableau précédent:

/etc/kubernetes/pki/ca.crt
/etc/kubernetes/pki/ca.key
/etc/kubernetes/pki/etcd/ca.crt
/etc/kubernetes/pki/etcd/ca.key
/etc/kubernetes/pki/front-proxy-ca.crt
/etc/kubernetes/pki/front-proxy-ca.key

Tous les certificats

Si vous ne souhaitez pas stocker les clés privées de vos certificats racine au sein de votre grappe, vous pouvez génrer tous les certificqts en dehors de cette dernière.

Certificats requis:

où kind correspond à une ou plusieurs valeurs de key usqge de x509 (dont key usage est une extension du standard x509), qui est documenté ici .spec.usages pour le type CertificateSigningRequest:

Les emplacements des Certificats

Les certificats devraient être placés dans un emplacement recommandé (tel qu'utilisé par kubeadm). Les chemins doivent être spécifiés en utilisant l'argument donné, quel que soit l'emplacement.

| CN par défaut | Chemin recommandé de la clé privée | Chemin recommandé pour le certificat | Commande | Argument pour la clé privée | Argument pour le certificat | |-------------------------------| | ------------------- | ------- | ----------- | ------------ | | etcd-ca | etcd/ca.key | etcd/ca.crt | kube-apiserver | | --etcd-cafile | | kube-apiserver-etcd-client | apiserver-etcd-client.key | apiserver-etcd-client.crt | kube-apiserver | --etcd-keyfile | --etcd-certfile | | kubernetes-ca | ca.key | ca.crt | kube-apiserver | | --client-ca-file | | kubernetes-ca | ca.key | ca.crt | kube-controller-manager | --cluster-signing-key-file | --client-ca-file,--root-ca-file,--cluster-signing-cert-file | | kube-apiserver | apiserver.key | apiserver.crt| kube-apiserver | --tls-private-key-file | --tls-cert-file | | kube-apiserver-kubelet-client | apiserver-kubelet-client.key | apiserver-kubelet-client.crt | kube-apiserver | --kubelet-client-key | --kubelet-client-certificate | | front-proxy-ca | front-proxy-ca.key | front-proxy-ca.crt | kube-apiserver | | --requestheader-client-ca-file | | front-proxy-ca | front-proxy-ca.key | front-proxy-ca.crt | kube-controller-manager | | --requestheader-client-ca-file | | front-proxy-client | front-proxy-client.key | front-proxy-client.crt | kube-apiserver | --proxy-client-key-file | --proxy-client-cert-file | | etcd-ca | etcd/ca.key | etcd/ca.crt | etcd | | --trusted-ca-file,--peer-trusted-ca-file | | kube-etcd | etcd/server.key | etcd/server.crt | etcd | --key-file | --cert-file | | kube-etcd-peer | etcd/peer.key | etcd/peer.crt | etcd | --peer-key-file | --peer-cert-file | | etcd-ca | | etcd/ca.crt | etcdctl | | --cacert | | kube-etcd-healthcheck-client | etcd/healthcheck-client.key | etcd/healthcheck-client.crt | etcdctl | --key | --cert |

Les mêmes recommandations s'appliquent pour la paire de clés du service account:

L'example suivant illustrate les chemins des fichiers du précédent tableau dont vous devez mettre en place si vous générez vous-même tous vos clés privées et vos certificats:

/etc/kubernetes/pki/etcd/ca.key
/etc/kubernetes/pki/etcd/ca.crt
/etc/kubernetes/pki/apiserver-etcd-client.key
/etc/kubernetes/pki/apiserver-etcd-client.crt
/etc/kubernetes/pki/ca.key
/etc/kubernetes/pki/ca.crt
/etc/kubernetes/pki/apiserver.key
/etc/kubernetes/pki/apiserver.crt
/etc/kubernetes/pki/apiserver-kubelet-client.key
/etc/kubernetes/pki/apiserver-kubelet-client.crt
/etc/kubernetes/pki/front-proxy-ca.key
/etc/kubernetes/pki/front-proxy-ca.crt
/etc/kubernetes/pki/front-proxy-client.key
/etc/kubernetes/pki/front-proxy-client.crt
/etc/kubernetes/pki/etcd/server.key
/etc/kubernetes/pki/etcd/server.crt
/etc/kubernetes/pki/etcd/peer.key
/etc/kubernetes/pki/etcd/peer.crt
/etc/kubernetes/pki/etcd/healthcheck-client.key
/etc/kubernetes/pki/etcd/healthcheck-client.crt
/etc/kubernetes/pki/sa.key
/etc/kubernetes/pki/sa.pub

Configurer les certificats pour les comptes utilisateur

Vous devez manuellement configurer ces comptes administrateurs et les comptes de services:

1. Pour chaque configuration, générez une paire certificat/clé privée x509 avec le Common Name (CN) et le Organization (O) fournis.

2. Exécutez kubectl comme suit pour chaque configuration:

   KUBECONFIG=<filename> kubectl config set-cluster default-cluster --server=https://<host ip>:6443 --certificate-authority <path-to-kubernetes-ca> --embed-certs
   KUBECONFIG=<filename> kubectl config set-credentials <credential-name> --client-key <path-to-key>.pem --client-certificate <path-to-cert>.pem --embed-certs
   KUBECONFIG=<filename> kubectl config set-context default-system --cluster default-cluster --user <credential-name>
   KUBECONFIG=<filename> kubectl config use-context default-system
   

Ces fichiers sont utilisés comme suit:

Les fichiers suivant illustrent les chemins absolues des fichiers listés dans le tableau précédent:

/etc/kubernetes/admin.conf
/etc/kubernetes/super-admin.conf
/etc/kubernetes/kubelet.conf
/etc/kubernetes/controller-manager.conf
/etc/kubernetes/scheduler.conf