Überblick über die Zertifikatsverwaltung in AKS auf Windows Server

Gilt für: AKS unter Windows Server

AKS auf Windows Server verwendet eine Kombination aus zertifikats- und tokenbasierter Authentifizierung, um die Kommunikation zwischen Diensten (oder Agenten) zu sichern, die für verschiedene Vorgänge innerhalb der Plattform verantwortlich sind. Bei der zertifikatbasierten Authentifizierung wird ein digitales Zertifikat verwendet, um eine Entität (Agent, Computer, Benutzer oder Gerät) zu identifizieren, bevor ihr Zugriff auf eine Ressource gewährt wird.

Cloud-Agent

Wenn Sie AKS auf Windows Server einsetzen, installiert AKS Agenten, die für verschiedene Funktionen innerhalb des Clusters verwendet werden. Dies betrifft folgende Agents:

• Cloud-Agent: Ein Dienst, der für die Orchestrierung der zugrunde liegenden Plattform zuständig ist.
• Knoten-Agent: Ein Dienst, der sich auf jedem Knoten befindet und die eigentlichen Arbeiten ausführt (etwa die Erstellung und Löschung virtueller Computer).
• KMS-Pod (Key Management System, Schlüsselverwaltungssystem): Ein Dienst, der für die Schlüsselverwaltung verantwortlich ist.
• Andere Dienste: Cloud-Betreiber, Zertifikatsverwalter, usw.

Der Cloud Agent Service in AKS ist für die Orchestrierung der CRUD-Vorgänge (Erstellen, Lesen, Aktualisieren und Löschen) von Infrastrukturkomponenten wie virtuellen Rechner (VMs), virtuellen Netzwerkschnittstellen (VNICs) und virtuellen Netzwerken (VNETs) im Cluster verantwortlich.

Bei der Kommunikation mit dem Cloud-Agent müssen Clients Zertifikate bereitstellen, um diese Kommunikation zu schützen. Jedem Client muss eine Identität zugeordnet sein. Diese Identität definiert die RBAC-Regeln (Role Based Access Control, rollenbasierte Zugriffssteuerung) für den Client. Jede Identität umfasst zwei Entitäten:

• Ein Token für die erste Authentifizierung. Hierbei wird ein Zertifikat zurückgegeben.
• Ein Zertifikat aus dem obigen Anmeldeprozess, das bei jeder Kommunikation zur Authentifizierung verwendet wird.

Jede Entität ist für einen Zeitraum (standardmäßig 90 Tage) gültig. Danach läuft sie ab. Damit weiterhin auf den Cloud-Agent zugegriffen werden kann, muss das Zertifikat verlängert und das Token rotiert werden.

Zertifikattypen

Es gibt zwei Arten von Zertifikaten, die in AKS auf Windows Server verwendet werden:

• Cloud-Agent-Zertifizierungsstellenzertifikat: Das Zertifikat, das zum Signieren bzw. Überprüfen von Clientzertifikaten verwendet wird. Dieses Zertifikat ist 365 Tage (also ein Jahr) lang gültig.
• Clientzertifikate: Zertifikate, die vom Cloud-Agent-Zertifizierungsstellenzertifikat für Clients ausgestellt werden, um die Authentifizierung beim Cloud-Agent zu ermöglichen. Diese Zertifikate sind in der Regel 90 Tage lang gültig.

Microsoft empfiehlt, Cluster innerhalb von 60 Tagen nach einem neuen Release zu aktualisieren – nicht nur, um zu gewährleisten, dass interne Zertifikate und Token auf dem neuesten Stand sind, sondern auch, um sicherzustellen, dass Ihnen neue Features und Fehlerkorrekturen zur Verfügung stehen und Sie über die neuesten kritischen Sicherheitspatches verfügen. Im Zuge dieser monatlichen Updates werden alle Token rotiert, die während des Normalbetriebs des Clusters nicht automatisch rotiert werden können. Die Gültigkeit von Zertifikaten und Token wird wieder auf die standardmäßigen 90 Tage festgelegt (ab dem Datum der Clusteraktualisierung).

Sichere Kommunikation mit Zertifikaten in AKS auf Windows Server

Zertifikate werden für eine sichere Kommunikation zwischen Komponenten im Cluster verwendet. AKS bietet Zero-Touch, sofortige Bereitstellung und Verwaltung von Zertifikaten für integrierte Kubernetes-Komponenten. In diesem Artikel erfahren Sie, wie Sie Zertifikate in AKS auf Windows Server bereitstellen und verwalten können.

Zertifikate und Zertifizierungsstellen

AKS erstellt und verwendet die folgenden Zertifizierungsstellen (CAs) und Zertifikate.

Cluster-CA

• 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 von der Cluster CA signierte Zertifikatsanforderung (CSR) 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 CA

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 Zertifikatsbereitstellung für ein kubelet erfolgt über TLS-Bootstrapping. Verwenden Sie für alle anderen Zertifikate die Erstellung von YAML-basierten Schlüsseln und Zertifikaten.

• Die Zertifikate werden in /etc/kubernetes/pkigespeichert.
• Die Schlüssel sind RSA 4096, EcdsaCurve: P384

Zertifikatverlängerung und -verwaltung

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

• Kubelet-Serverzertifikat
• Kubeconfig-Clientzertifikat

Als bewährte Sicherheitspraxis sollten Sie Active Directory single sign-in für die Benutzerauthentifizierung verwenden.

Zertifikatswiderruf

Der Widerruf von Zertifikaten sollte selten sein und zum Zeitpunkt der Zertifikatserneuerung erfolgen.

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
• Gruppe
• DNS-Name
• IP-Adresse

Eine notBefore Zeit kann angegeben werden, um nur Zertifikate zu widerrufen, die vor einem bestimmten Zeitstempel ausgestellt wurden. Wenn kein notBefore Zeitpunkt angegeben wird, werden alle bestehenden und zukünftigen Zertifikate, die dem Widerruf entsprechen, widerrufen.

Wenn Sie beim Ausführen eines Sperrvorgangs eine Seriennummer verwenden, können Sie den Repair-AksHciClusterCerts powerShell-Befehl wie folgt verwenden, um Ihren Cluster in einen Arbeitszustand zu versetzen. Wenn Sie eines der anderen oben aufgeführten Felder verwenden, stellen Sie sicher, dass Sie eine notBefore Zeit angeben.

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 

Nächste Schritte

• Zertifikate aktualisieren
• Bereitstellen einer Linux-Anwendung auf einem Kubernetes-Cluster
• Bereitstellen einer Windows Server-Anwendung in einem Kubernetes-Cluster