Übersicht über die Zertifikatverwaltung in AKS, die von Azure Arc aktiviert sind

Artikel
11/23/2024

Gilt für: AKS auf Azure Stack HCI 22H2, AKS unter Windows Server

AKS, die von Azure Arc aktiviert werden, verwendet eine Kombination aus Zertifikat- und tokenbasierter Authentifizierung, um die Kommunikation zwischen Diensten (oder Agents) zu sichern, die für unterschiedliche 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 bereitstellen, die von Arc aktiviert sind, installiert AKS Agents, die zum Ausführen verschiedener 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: Cloudoperator, Zertifikat-Manager usw.

Der Cloud-Agent-Dienst in AKS ist für die Orchestrierung der Erstellungs-, Lese-, Aktualisierungs- und Löschvorgänge (CRUD) von Infrastrukturkomponenten wie virtuellen Computern (VMs), Virtual Network Interfaces (VNICs) und Virtual Networks (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 verwendet werden, die von Arc aktiviert sind:

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 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, die von Arc aktiviert sind

Zertifikate werden für eine sichere Kommunikation zwischen Komponenten im Cluster verwendet. AKS bietet zero-touch,out-of-the-box provisioning, and management of certificates for built-in Kubernetes components. In diesem Artikel erfahren Sie, wie Sie Zertifikate in AKS bereitstellen und verwalten, die von Arc aktiviert sind.

Zertifikate und Zertifizierungsstellen

AKS generiert und verwendet die folgenden Zertifizierungsstellen und Zertifikate.

Clusterzertifizierungsstelle

Der API-Server verfügt über eine Clusterzertifizierungsstelle, die Zertifikate für die unidirektionale Kommunikation vom API-Server zum kubelet signiert.
Jede kubelet erstellt außerdem eine Zertifikatsignaturanforderung (Certificate Signing Request, CSR), die von der Cluster-Zertifizierungsstelle signiert ist, für die kubelet Kommunikation vom API-Server an den 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 Zertifikatbereitstellung für ein kubelet Zertifikat erfolgt mithilfe des TLS-Bootstrappings. Verwenden Sie für alle anderen Zertifikate die Erstellung von YAML-basierten Schlüsseln und Zertifikaten.

Die Zertifikate werden in /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 gültig für vier Tage.

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

Als bewährte Methode für die Sicherheit sollten Sie die einmalige Anmeldung von Active Directory für die Benutzerauthentifizierung verwenden.

Zertifikatswiderruf

Die Zertifikatsperrung sollte selten sein und zum Zeitpunkt der Zertifikatverlängerung 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
Group
DNS-Name
IP-Adresse

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

Hinweis

Der Widerruf von kubelet Serverzertifikaten ist derzeit nicht verfügbar.

Wenn Sie beim Ausführen eines Sperrvorgangs eine Seriennummer verwenden, können Sie den Repair-AksHciClusterCerts unten beschriebenen PowerShell-Befehl verwenden, um Ihren Cluster in einen Arbeitszustand zu versetzen. Wenn Sie eines der anderen zuvor aufgeführten Felder verwenden, stellen Sie sicher, dass Sie eine notBefore Uhrzeit 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

Freigeben über