Sichere Kommunikation mit Zertifikaten

  • Artikel
  • 4 Minuten Lesedauer

Zertifikate werden für eine sichere Kommunikation zwischen Komponenten im Cluster verwendet. Azure Kubernetes Service (AKS) auf der Azure Stack HCI und Windows Server bietet die standardmäßige Bereitstellung und Verwaltung von Zertifikaten ohne manuelles Eingreifen für integrierte Kubernetes-Komponenten.

Zertifikate und Zertifizierungsstellen

AKS in Azure Stack HCI und Windows Server generiert und verwendet die folgenden Zertifikate und Zertifizierungsstellen (Certificate Authorities, CAs):

Cluster-ZS:

  • Der API-Server verfügt über eine Clusterzertifizierungsstelle, die Zertifikate für die unidirektionale Kommunikation vom API-Server zum kubelet signiert.
  • Jedes kubelet erstellt außerdem eine Zertifikatsignierungsanforderung (Certificate Signing Request, CSR), die von der Clusterzertifizierungsstelle signiert wird, für die Kommunikation vom kubelet zum API-Server.
  • Der etcd-Schlüsselwertspeicher verfügt über ein Zertifikat, das von der Clusterzertifizierungsstelle für die Kommunikation von etcd zum API-Server signiert wurde.

etcd-ZS:

  • Der etcd-Schlüsselwertspeicher hat eine etcd-Zertifizierungsstelle, die Zertifikate signiert, um die Datenreplikation zwischen etcd-Replikaten im Cluster zu authentifizieren und zu autorisieren.

Front-Proxy-ZS

  • Die Front-Proxy-Zertifizierungsstelle sichert die Kommunikation zwischen dem API-Server und dem Erweiterungs-API-Server.

Zertifikatbereitstellung

Die Zertifikatbereitstellung für kubelets erfolgt mithilfe des TLS-Bootstrappings. Verwenden Sie für alle anderen Zertifikate die Erstellung von YAML-basierten Schlüsseln und Zertifikaten.

  • Die Zertifikate werden unter „/etc/kubernetes/pki“ gespeichert.
  • Die Schlüssel sind RSA 4096, EcdsaCurve: P384

Hinweis

Die Stammzertifikate sind 10 Jahre lang gültig. Alle anderen Nicht-Stammzertifikate sind kurzlebig und vier Tage lang gültig.

Zertifikatverlängerung und -verwaltung

Nicht-Stammzertifikate werden automatisch verlängert. Alle Steuerungsebenenzertifikate für Kubernetes mit Ausnahme der folgenden Zertifikate werden verwaltet:

  • Kubelet-Serverzertifikat
  • Kubeconfig-Clientzertifikat

Es wird empfohlen, einmaliges Anmelden bei Active Directory als bewährte Sicherheitsmethode für die Benutzerauthentifizierung zu verwenden.

Zertifikatssperrung

Die Sperrung sollte ein seltener Vorfall sein und zum Zeitpunkt der Zertifikatserneuerung angewendet werden.

Sobald Sie über die Seriennummer des Zertifikats verfügen, das Sie widerrufen möchten, verwenden Sie die benutzerdefinierte Kubernetes-Ressource zum Definieren und Beibehalten von Sperrungsinformationen. Jedes Sperrungsobjekt kann aus einem oder mehreren Sperrungseinträgen bestehen.

Verwenden Sie zum Ausführen einer Sperrung eins der folgenden Elemente:

  • Seriennummer
  • Group
  • DNS-Name
  • IP-Adresse

Es kann ein notBefore-Zeitpunkt angegeben werden, um nur Zertifikate zu widerrufen, die vor einem bestimmten Zeitstempel ausgestellt wurden. Wenn kein notBefore-Zeitpunkt angegeben wird, werden alle vorhandenen und zukünftigen Zertifikate widerrufen, die der Sperrung entsprechen.

Hinweis

Die Sperrung für das kubelet-Serverzertifikat ist derzeit nicht verfügbar.

Wurde die Sperrung mithilfe einer Seriennummer durchgeführt, können Sie den unten beschriebenen PowerShell-Befehl Repair-AksHciClusterCerts verwenden, um Ihren Cluster in einen funktionierenden Zustand zu versetzen. Stellen Sie bei Durchführung der Sperrung mit anderen Feldern sicher, dass Sie einen notBefore-Zeitpunkt angeben, damit Sie Ihren Cluster mit dem Befehl Repair-AksHciClusterCerts wiederherstellen können.

apiVersion: certificates.microsoft.com/v1 
kind: RenewRevocation 
metadata: 
  name: my-renew-revocation 
  namespace: kube-system 
spec: 
  description: My list of renew revocations 
  revocations: 
  - description: Revoked certificates by serial number 
    kind: serialnumber 
    notBefore: "2020-04-17T17:22:05Z" 
    serialNumber: 77fdf4b1033b387aaace6ce1c18710c2 
  - description: Revoked certificates by group 
    group: system:nodes 
    kind: Group 
  - description: Revoked certificates by DNS 
    dns: kubernetes.default.svc. 
    kind: DNS 
  - description: Revoked certificates by DNS Suffix 
    dns: .cluster.local 
    kind: DNS 
  - description: Revoked certificates by IP 
    ip: 170.63.128.124 
    kind: IP

Problembehandlung und Wartung

Weitere Informationen zur Protokollierung und Überwachung finden Sie in den folgenden Skripts und Dokumentationen:

Verlängerung von Zertifikaten für Workerknoten

Bei Workerknoten werden fehlerhafte Zertifikatverlängerungen vom certificate-renewal-worker-Pod protokolliert. Wenn bei der Zertifikatverlängerung auf einem Workerknoten weiterhin Fehler auftreten und die Zertifikate ablaufen, wird der Knoten entfernt und an seiner Stelle ein neuer Workerknoten erstellt.

Im Folgenden finden Sie ein Beispiel für das Anzeigen der Protokolle für den Pod mit dem Präfix certificate-renewal-worker:

kubectl.exe --kubeconfig .\testcluster-kubeconfig -n=kube-system get pods 

NAME                                           READY   STATUS             RESTARTS   AGE 
… 
certificate-renewal-worker-6f68k               1/1     Running            0          6d

So rufen Sie die Protokolle aus dem Zertifikatverlängerungspod ab:

kubectl.exe --kubeconfig .\testcluster-kubeconfig -n=kube-system logs certificate-renewal-worker-6f68k

Verlängern von Zertifikaten für Knoten der Steuerungsebene

Bei Knoten der Steuerungsebene werden fehlerhafte Zertifikatverlängerungen vom certificate-renewal-controller-Pod protokolliert. Wenn Zertifikate auf einem Knoten der Steuerungsebene ablaufen, kann er möglicherweise nicht von anderen Knoten erreicht werden. Wenn alle Knoten der Steuerungsebene in diesen Zustand eintreten, ist der Cluster aufgrund eines TLS-Fehlers nicht mehr funktionsfähig. Zur Bestätigung, ob der Cluster in diesen Zustand eingetreten ist, können Sie versuchen, mithilfe von kubectl darauf zuzugreifen. Wenn eine Fehlermeldung bezüglich abgelaufener x509-Zertifikate vorliegt, ist bei der Verbindung ein Fehler aufgetreten ist.

Im Folgenden finden Sie ein Beispiel für das Anzeigen der Protokolle für den Pod mit dem Präfix certificate-renewal-controller:

kubectl.exe --kubeconfig .\testcluster-kubeconfig -n=kube-system get pods 

NAME                                           READY   STATUS             RESTARTS   AGE 
… 
certificate-renewal-controller-2cdmz               1/1     Running            0          6d

So rufen Sie die Protokolle aus dem Zertifikatverlängerungspod ab:

kubectl.exe --kubeconfig .\testcluster-kubeconfig -n=kube-system logs certificate-renewal-controller-2cdmz

Knoten der Steuerungsebene können nicht wie Workerknoten neu erstellt werden. Sie können jedoch mit dem Modul Repair-AksHciClusterCerts Fehler im Zusammenhang mit abgelaufenen Zertifikaten beheben. Wenn bei dem Cluster aufgrund abgelaufener Zertifikate ein Fehler auftritt, führen Sie den Befehl wie nachfolgend gezeigt aus:

Repair-AksHciClusterCerts -Name mytargetcluster

Wenn der Cluster über kubectl nicht erreichbar ist, finden Sie die Protokolle im Ordner /var/log/pods.

Nächste Schritte

In dieser Schrittanleitung haben Sie erfahren, wie Sie Zertifikate bereitstellen und verwalten. Als Nächstes haben Sie folgende Möglichkeiten: