PKI Zertifikate and Anforderungen

Kubernetes benötigt PKI Zertifikate für die Authentifzierung über TLS. Falls Sie Kubernetes über kubeadm installieren, wurden die benötigten Zertifikate bereits automatisch generiert. In jedem Fall können Sie diese auch selbst generieren -- beispielsweise um private Schlüssel nicht auf dem API Server zu speichern und somit deren Sicherheit zu erhöhen. Diese Seite erklärt, welche Zertifikate ein Cluster benötigt.

Wie Zertifikate in Ihrem Cluster verwendet werden

Kubernetes benötigt PKI-Zertifikate für die folgenden Vorgänge:

Server Zertifikate

• Server Zertifikate für den API Server Endpunkt
• Server Zertifikate für den etcd Server
• Server Zertifikate für jeden kubelet (every node runs a kubelet)
• Optionale Server Zertifikate für den front-proxy

Client Zertifikate

• Client-Zertifikate für jedes Kubelet zur Authentifizierung gegenüber dem API-Server als Client der Kubernetes API
• Client-Zertifikat für jeden API-Server zur Authentifizierung gegenüber etcd
• Client-Zertifikat für den Controller Manager zur sicheren Kommunikation mit dem API-Server
• Client-Zertifikat für den Scheduler zur sicheren Kommunikation mit dem API-Server
• Client-Zertifikate, eines pro Node, für kube-proxy zur Authentifizierung gegenüber dem API-Server
• Optionale Client-Zertifikate für Administratoren des Clusters zur Authentifizierung gegenüber dem API-Server
• Optionales Client-Zertifikat für den Front-Proxy

Server- und Client-Zertifikate des Kubelets

Um eine sichere Verbindung herzustellen und sich gegenüber dem Kubelet zu authentifizieren, benötigt der API-Server ein Client-Zertifikat und ein Schlüsselpaar.

In diesem Szenario gibt es zwei Ansätze für die Verwendung von Zertifikaten:

• Gemeinsame Zertifikate: Der kube-apiserver kann dasselbe Zertifikat und Schlüsselpaar verwenden, das er zur Authentifizierung seiner Clients nutzt. Das bedeutet, dass bestehende Zertifikate wie apiserver.crt und apiserver.key für die Kommunikation mit den Kubelet-Servern verwendet werden können.

• Separate Zertifikate: Alternativ kann der kube-apiserver ein neues Client-Zertifikat und Schlüsselpaar zur Authentifizierung seiner Kommunikation mit den Kubelet-Servern generieren. In diesem Fall werden ein separates Zertifikat kubelet-client.crt und der dazugehörige private Schlüssel kubelet-client.key erstellt.

Auch etcd verwendet gegenseitiges TLS zur Authentifizierung von Clients und deren Gegenstelle.

Wo Zertifikate gespeichert werden

Wenn Sie Kubernetes mit kubeadm installieren, werden die meisten Zertifikate im Verzeichnis /etc/kubernetes/pki gespeichert. Alle Pfade in dieser Dokumentation beziehen sich auf dieses Verzeichnis, mit Ausnahme der Benutzerzertifikate, die von kubeadm unter /etc/kubernetes ablegt werden.

Zertifikate manuell konfigurieren

Wenn Sie nicht möchten, dass kubeadm die benötigten Zertifikate generiert, können Sie diese entweder mithilfe einer einzelnen Root-CA selbst erstellen oder alle Zertifikate vollständig manuell bereitstellen. Details zur Erstellung einer eigenen Zertifizierungsstelle finden Sie unter Zertifikate. Weitere Informationen zur Verwaltung von Zertifikaten mit kubeadm bietet Zertifikatsverwaltung mit kubeadm.

Einzelne Root-CA

Sie können eine einzelne Root-CA erstellen, welche dann mehrere Zwischen-CAs generieren
und die Erstellung weiterer Zertifikate Kubernetes selbst überlassen kann.

Erforderliche CAs:

Zusätzlich zu den oben genannten CAs wird auch ein öffentliches/privates Schlüsselpaar für das Service-Account-Management benötigt: sa.key und sa.pub.

Das folgende Beispiel zeigt die CA-Schlüssel- und Zertifikatsdateien aus der vorherigen Tabelle:

/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

Alle Zertifikate

Wenn Sie die privaten CA-Schlüssel nicht in Ihren Cluster kopieren möchten, können Sie alle Zertifikate selbst generieren.

Erforderliche Zertifikate:

Der Wert in der Spalte Typ entspricht einer oder mehreren x509-Schlüsselverwendungen, die auch in .spec.usages eines CertificateSigningRequest-Typs dokumentiert sind:

Zertifikatspfade

Zertifikate sollten in einem empfohlenen Pfad abgelegt werden (wie von kubeadm verwendet). Die Pfade sollten mit dem angegebenen Argument festgelegt werden, unabhängig vom Speicherort.

Gleiche Überlegungen gelten für das Service-Account-Schlüsselpaar:

Das folgende Beispiel zeigt die Dateipfade aus den vorherigen Tabellen, die Sie bereitstellen müssen, wenn Sie alle Schlüssel und Zertifikate selbst generieren:

/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

Zertifikate für Benutzerkonten konfigurieren

Sie müssen diese Administrator- und Servicekonten manuell konfigurieren:

1. Generieren Sie für jede Konfiguration ein x509-Zertifikat/Schlüsselpaar mit dem angegebenen Common Name (CN) und der Organisation (O).

2. Führen Sie für jede Konfiguration kubectl wie folgt aus:

   KUBECONFIG=<Dateiname> kubectl config set-cluster default-cluster --server=https://<Host-IP>:6443 --certificate-authority <Pfad-zur-kubernetes-ca> --embed-certs
   KUBECONFIG=<Dateiname> kubectl config set-credentials <Anmeldeinfo-Name> --client-key <Pfad-zum-Schlüssel>.pem --client-certificate <Pfad-zum-Zertifikat>.pem --embed-certs
   KUBECONFIG=<Dateiname> kubectl config set-context default-system --cluster default-cluster --user <Anmeldeinfo-Name>
   KUBECONFIG=<Dateiname> kubectl config use-context default-system
   

Diese Dateien werden wie folgt verwendet:

Beispielhafte vollständige Pfade zu den Dateien aus der obigen Tabelle:

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