Unterstützung für die Verbesserung dieser Seite beitragen

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Um zu diesem Benutzerhandbuch beizutragen, wählen Sie den GitHub Link Diese Seite bearbeiten unter, der sich im rechten Bereich jeder Seite befindet.

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Rotieren Sie die EKS-Cluster-Zertifizierungsstelle (CA)

In der Public Key Infrastructure (PKI) ist eine Zertifizierungsstelle (CA) eine vertrauenswürdige Stelle, die digitale Zertifikate ausstellt und signiert. Diese Zertifikate stellen die Identität fest und ermöglichen eine verschlüsselte Kommunikation zwischen Systemen mithilfe von TLS (Transport Layer Security). Wenn ein Client eine Verbindung zu einem Server herstellt, präsentiert der Server ein von einer CA signiertes Zertifikat. Der Client überprüft das Zertifikat des Servers anhand der Zertifizierungsstellen, denen er vertraut, bevor die Verbindung hergestellt werden kann.

In Amazon Elastic Kubernetes Service (Amazon EKS) wird zum Zeitpunkt der Cluster-Erstellung eine CA für jeden EKS-Cluster erstellt. Dies folgt dem gleichen Modell wie Upstream-Kubernetes: Jeder EKS-Cluster hat seine eigene CA, die Zertifikate für den API-Server signiert. Auf diese Weise können sich Komponenten der Steuerungsebene, Worker-Knoten und Clients beim API-Server authentifizieren und verschlüsselte Verbindungen zum EKS-Cluster herstellen.

Diese Zertifizierungsstellen (CAs) haben eine definierte Gültigkeitsdauer. Bei der CA-Rotation wird die Zertifizierungsstelle Ihres EKS-Clusters ausgetauscht, bevor diese abläuft, um sicherzustellen, dass Ihr Cluster betriebsbereit und zugänglich bleibt. Wir haben integrierte Sicherheitsvorkehrungen, die diesen Prozess automatisch verwalten. Wenn Sie die CA-Rotation nicht selbst initiieren, fügen wir automatisch eine Nachfolge-CA hinzu und aktivieren sie, bevor die ausgehende CA abläuft, um sicherzustellen, dass Ihr Cluster verfügbar bleibt.

Während der CA-Rotation wird eine Nachfolge-CA an Ihren EKS-Cluster angehängt. EKS verteilt die Nachfolge-CA automatisch an alle AWS verwalteten Komponenten (Steuerungsebene, https://docs.aws.amazon.com/automode/automode.html EKS-Auto-Modus-Instanzen und AWS Fargate-Knoten). Sie sind dafür verantwortlich, die von Ihnen verwalteten Worker-Knoten (ohne EKS Auto Mode, nicht Fargate) und die externen Clients (wie Kubeconfig-Dateien und CI/CD Pipelines) so zu aktualisieren, dass sie der Nachfolger-CA vertrauen, bevor sie aktiviert wird. Nachdem die Nachfolge-CA aktiviert wurde, wechselt der EKS-Cluster zum Signieren von Zertifikaten mit der Nachfolge-CA. Die ausgehende CA wird dann außer Betrieb genommen.

Eine CA-Rotation ist für jeden EKS-Cluster erforderlich, da CAs eine begrenzte Gültigkeitsdauer haben. Die Gültigkeitsdauer hängt davon ab, wann die CA des Clusters erstellt wurde. Weitere Informationen finden Sie im Abschnitt mit häufig gestellten Fragen. EKS-Schutzmaßnahmen stellen sicher, dass Ihr Cluster selbst während des gesamten Rotationslebenszyklus verfügbar bleibt. Eine erfolgreiche Rotation hängt jedoch auch davon ab, dass Sie die von Ihnen verwalteten Worker-Knoten und externen Clients aktualisieren, damit sie nach der Aktivierung der Nachfolge-CA die Konnektivität aufrechterhalten.

Die APIs, die Erfahrung mit der Konsole, die Benachrichtigungen und die schrittweisen Anleitungen in den folgenden Abschnitten sollen Sie bei diesem Prozess unterstützen. Der gesamte Zuständigkeitsbereich wird im Abschnitt „Modell der gemeinsamen Verantwortung“ behandelt.

Wie funktioniert die CA-Rotation

Die CA-Rotation in Amazon EKS ist ein mehrstufiger Prozess. Wir verfügen über automatische Sicherheitsvorkehrungen, um die Verfügbarkeit von EKS-Clustern während des gesamten Rotationslebenszyklus aufrechtzuerhalten, unabhängig davon, ob Sie handeln oder nicht. Für eine erfolgreiche Rotation, bei der alle Ihre Komponenten die Konnektivität aufrechterhalten, sind die in den folgenden Abschnitten beschriebenen Schritte erforderlich.

Phase 1: Eine Nachfolger-CA anhängen

Eine Nachfolger-CA wird an den EKS-Cluster angehängt. Ab diesem Zeitpunkt vertraut der EKS-Cluster sowohl der ausgehenden CA als auch der Nachfolger-CA gleichzeitig. Zertifikate werden weiterhin von der ausgehenden CA ausgestellt. Es tritt keine Unterbrechung auf.

Sie können jederzeit selbst eine Nachfolger-CA anhängen, indem Sie die AWS CLI, die EKS-API, die Konsole oder Infrastructure as Code (IaC) verwenden, z. B. AWS CloudFormation, solange sich Ihr Cluster in einem aktiven Zustand befindet. Wenn Sie dies nicht tun, fügen wir automatisch eine in Ihrem Namen an.

Die Nachfolge-CA kann erst aktiviert werden, wenn die Verteilung an die AWS verwalteten Komponenten in EKS AWS abgeschlossen ist (Phase 2). Dies ist der richtige Zeitpunkt, um mit der Identifizierung der Worker-Knoten und externen Clients zu beginnen, die aktualisiert werden müssen. Die Identifizierung aller Systeme, die eine Verbindung zum API-Server Ihres EKS-Clusters herstellen, kann einige Zeit in Anspruch nehmen, insbesondere in Umgebungen mit mehreren Teams, CI/CD Pipelines und Überwachungstools. Wenn Sie diesen Prozess frühzeitig starten, haben Sie die größte Flexibilität, um Aktualisierungen nach Ihrem eigenen Zeitplan zu koordinieren.

Phase 2: Verteilen Sie die Nachfolge-CA

Nachdem die Nachfolger-CA angehängt wurde, AWS aktualisiert es die verwalteten Komponenten in Ihrem EKS-Cluster (die Steuerungsebene, EKS-Auto-Modus-Instances und AWS Fargate-Knoten), sodass beide CAs erkannt und ihnen vertraut werden. Sie können den Fortschritt anhand des Verteilungsstatus der CA verfolgen. Die Nachfolge-CA kann erst aktiviert werden, wenn die Verteilung abgeschlossen ist.

Nachdem wir die Verteilung der CA an die verwalteten Komponenten abgeschlossen haben, sind Sie dafür verantwortlich, zwei Gruppen zu aktualisieren: die von Ihnen verwalteten Worker-Knoten (Nicht-EKS Auto Mode, nicht Fargate) und externe Clients, sodass sie der Nachfolger-CA vertrauen. Dadurch wird sichergestellt, dass sie auch nach der Aktivierung der Nachfolge-CA weiterhin eine Verbindung zum API-Server herstellen. Wenn Komponenten vor der Aktivierung der Nachfolger-CA nicht aktualisiert werden, steht ein CA-Rollback zur Verfügung, um die Konnektivität wiederherzustellen, während Sie die verbleibenden Updates abschließen.

Phase 3: Aktivieren Sie die Nachfolge-CA

Nachdem wir die Verteilung der Nachfolge-CA an alle AWS verwalteten Komponenten in EKS abgeschlossen haben, kann die Nachfolger-CA aktiviert werden. Wir empfehlen, die Nachfolge-CA auf Ihrer eigenen Zeitleiste zu aktivieren. Nehmen Sie sich genügend Zeit, um die von Ihnen verwalteten Worker-Knoten und externen Clients zu ermitteln und zu aktualisieren, damit sie der Nachfolger-CA vertrauen. Nach der Aktivierung der Nachfolge-CA stellt der EKS-Cluster Zertifikate aus, die von der Nachfolge-CA signiert wurden. Die ausgehende CA bleibt vertrauenswürdig, wird aber nicht mehr zum Signieren verwendet. Nach der Aktivierung steht für einen begrenzten Zeitraum ein Rollback-Fenster zur Verfügung, sodass Sie bei Bedarf zur ausgehenden CA zurückkehren können. Rollback wird in einem späteren Abschnitt ausführlich behandelt.

Sie können die Nachfolge-CA selbst aktivieren, wenn Sie sicher sind, dass die von Ihnen verwalteten Worker-Knoten und die Clients aktualisiert wurden. Wenn Sie dies nicht tun, aktivieren wir die Nachfolge-CA automatisch, sobald sich die Ablauffrist nähert.

Die duale Vertrauensperiode

Die Zeit zwischen dem Hinzufügen einer Nachfolgezertifizierungsstelle (Phase 1) und der Außerbetriebnahme der ausgehenden Zertifizierungsstelle wird als duale Vertrauensperiode bezeichnet. Während dieser Zeit vertraut der EKS-Cluster beiden Zertifizierungsstellen gleichzeitig. Dies macht die Rotation unterbrechungsfrei: Komponenten können schrittweise aktualisiert werden, da der EKS-Cluster von einer der beiden Zertifizierungsstellen signierte Zertifikate akzeptiert.

Die duale Vertrauensperiode gibt Ihnen Zeit, alle von Ihnen verwalteten Worker-Knoten und externen Clients zu identifizieren und zu aktualisieren, ohne dass Sie alle Änderungen gleichzeitig koordinieren müssen.

Es ist wichtig zu verstehen, wie sich die Aktivierung der Nachfolger-CA auf die Konnektivität auswirkt. Wenn ein Client eine Verbindung zum API-Server herstellt, überprüft er die Identität des Servers, indem er überprüft, ob das Serverzertifikat von einer Zertifizierungsstelle signiert wurde, der er vertraut.

Nach der Aktivierung der Nachfolge-CA legt der API-Server sein Zertifikat vor, das von der Nachfolge-CA signiert wurde. Clients, die ihr Trust-Paket aktualisiert haben, um die Nachfolgezertifizierungsstelle einzubeziehen, verifizieren dies erfolgreich und stellen wie gewohnt eine Verbindung her. Clients, die ihr Trust Bundle nicht aktualisiert haben, erkennen das Zertifikat des Servers nicht und können keine Verbindung herstellen.

Das folgende Diagramm zeigt den TLS-Verbindungsablauf nach der Aktivierung der Nachfolge-CA.

Aus diesem Grund ist es wichtig, die Worker-Knoten und externen Clients vor der Aktivierung der Nachfolge-CA zu aktualisieren: Sie benötigen die Nachfolge-CA in ihrem Trust-Paket, um die Identität des API-Servers zu überprüfen und eine Verbindung herzustellen. Die duale Vertrauensperiode und das CA-Rollback bieten Ihnen Zeit und ein Sicherheitsnetz, um dies abzuschließen.

Modell der geteilten Verantwortung

Die CA-Rotation in Amazon EKS folgt demselben Modell der geteilten Verantwortung, das allgemein gilt. AWS AWS ist für die Sicherheit und Verfügbarkeit der Cloud-Infrastruktur verantwortlich, und Sie sind für die Sicherheit und Konfiguration Ihrer darin enthaltenen Workloads verantwortlich. Weitere Informationen darüber, wie die gemeinsame Verantwortung für Amazon EKS gilt, finden Sie in den Best Practices für EKS-Sicherheit.

Im Zusammenhang mit der CA-Rotation bedeutet dies:

AWS ist verantwortlich für

Sie sind verantwortlich für

Wir können diese Aktionen nicht in Ihrem Namen ausführen. Externe Kunden existieren außerhalb der AWS Betriebsgrenzen. Bei Worker-Knoten, die nicht von EKS Auto Mode oder Fargate verwaltet werden, wird die CA-Trust-Konfiguration beim Start oder durch Bootstrap-Prozesse festgelegt, die nur Sie steuern. Dies entspricht der Funktionsweise von TLS Trust: Der Client hat seinen eigenen Trust Store, und nur der Administrator des Clients kann ihn aktualisieren.

Die folgenden Abschnitte werden auf jeder Seite näher erläutert: AWS Was für Sie nützlich ist und was Sie tun müssen, zusammen mit einer schrittweisen Anleitung, wie Sie dies tun können.

Was AWS tut es für dich

AWS verwaltet während des gesamten CA-Rotationslebenszyklus für Ihren EKS-Cluster Folgendes:

Automatische CA-Erstellung

Wenn Sie Ihrer eigenen Timeline keine Nachfolger-CA anhängen, fügen wir automatisch eine hinzu, sobald sich die ausgehende CA Ihres EKS-Clusters dem Ablauf nähert. Dadurch wird sichergestellt, dass der Rotationsprozess mit genügend Zeit beginnt, um Ihre Kunden vor Ablauf der Ablauffrist zu ermitteln und zu aktualisieren.

Aktualisierungen auf der Kontrollebene

Wir aktualisieren die EKS-Cluster-Steuerungsebene automatisch, um der Nachfolge-CA zu vertrauen. Nach der Aktivierung der Nachfolge-CA stellt die Kontrollebene Zertifikate aus, die von der Nachfolge-CA signiert wurden. Für die Steuerungsebene sind keine Maßnahmen Ihrerseits erforderlich.

Aktualisierungen für EKS Auto Mode und Fargate

Wir aktualisieren EKS-Auto-Mode-Knoten und Fargate-Pods automatisch, damit sie der Nachfolger-CA vertrauen. Diese Komponenten werden vollständig von uns verwaltet und erfordern während der CA-Rotation keine Maßnahmen von Ihnen.

Aktualisierungen der EKS-Funktionen

Wir aktualisieren EKS Capabilities (AWS Controller for Kubernetes (ACK), Argo CD und kro (Kube Resource Orchestrator)) automatisch, um der Nachfolger-CA zu vertrauen. Diese verwalteten Ressourcen kommunizieren mit dem API-Server Ihres Clusters und werden im Rahmen des CA-Verteilungsprozesses aktualisiert. Für die verwalteten Ressourcen in EKS Capabilities sind keine Maßnahmen Ihrerseits erforderlich. Weitere Informationen finden Sie unter EKS-Funktionen.

Verfolgung des Vertriebsstatus

Während wir die verwalteten Komponenten in Ihrem EKS-Cluster aktualisieren, können Sie den Fortschritt anhand des Verteilungsstatus der CA überwachen. Dies zeigt Ihnen, ob wir unseren Teil der Rotation abgeschlossen haben. Die Nachfolge-CA kann erst aktiviert werden, wenn die Verteilung abgeschlossen ist.

Built-in Schutzmaßnahmen

Wir haben integrierte Schutzmaßnahmen zum Schutz Ihres EKS-Clusters während der Rotation eingebaut:

Diese Schutzmaßnahmen stellen sicher, dass die Verfügbarkeit des EKS-Clusters während des gesamten Rotationslebenszyklus erhalten bleibt, unabhängig davon, ob Sie handeln oder nicht.

Benachrichtigungen

Wir benachrichtigen Sie in jeder Phase des CA-Rotationslebenszyklus. Benachrichtigungen werden über AWS Health, Cluster Insights und E-Mail zugestellt. Jede Benachrichtigung informiert Sie darüber, was passiert ist, welche Maßnahmen (falls vorhanden) von Ihnen erforderlich sind und wo sich Ihr EKS-Cluster in der Rotationszeitleiste befindet.

Sie können mithilfe von Amazon auch Ihre eigenen Benachrichtigungen konfigurieren, EventBridge um CA-Rotationsereignisse in Ihre bestehenden Überwachungs- und Warnabläufe zu integrieren.

Was müssen Sie tun (und warum)

Für eine erfolgreiche CA-Rotation müssen Sie die Komponenten aktualisieren, die Sie AWS nicht erreichen können. Diese lassen sich in zwei Kategorien einteilen:

Externe Kunden

Jedes System, das von außerhalb des Clusters eine Verbindung zum API-Server Ihres EKS-Clusters herstellt. Dazu gehören Entwickler-Workstations, CI/CD Pipelines (Jenkins, GitHub Actions, ArgoCD) GitLab, Überwachungs- und Beobachtbarkeitstools, Automatisierungsskripte und jede Anwendung, die eine Kubeconfig zur Kommunikation mit dem API-Server verwendet.

Diese Systeme verfügen jeweils über ihre eigene Vertrauenskonfiguration. Wenn die Nachfolge-CA aktiviert ist, präsentiert der API-Server Zertifikate, die von der Nachfolge-CA signiert wurden. Wenn Sie diese Clients vor der Aktivierung der Nachfolgezertifizierungsstelle dahingehend aktualisieren, dass sie der Nachfolgezertifizierungsstelle vertrauen, wird sichergestellt, dass sie die Konnektivität aufrechterhalten. Wenn ein Client fehlt, kann das CA Rollback den Zugriff wiederherstellen, während Sie das Update abschließen.

Worker-Knoten (kein EKS Auto Mode, kein Fargate)

Bei Worker-Knoten, die nicht von EKS Auto Mode oder Fargate verwaltet werden, wird die CA-Trust-Konfiguration beim Start oder durch den Kubelet-Bootstrap-Prozess festgelegt. Diese Knoten müssen aktualisiert werden, damit sie der Nachfolge-CA vertrauen. Die erforderliche Aktion hängt vom Typ des Worker-Knotens ab:

Verwaltete Knotengruppen

Führen Sie ein Versionsupdate für die Knotengruppe durch, das einen fortlaufenden Austausch der Knoten auslöst. Neue Knoten werden automatisch mit der aktualisierten CA-Trust-Konfiguration gestartet.

Karpenter-controlled Knoten

Wenn die Drift-Erkennung aktiviert ist, wechselt Karpenter die Knoten innerhalb des konfigurierten Drift-Fensters, und neue Knoten übernehmen die Nachfolger-CA ohne manuelles Eingreifen. Wenn die Drift-Erkennung deaktiviert oder auf ein langes Zeitfenster eingestellt ist, behandeln Sie diese Knoten genauso wie selbstverwaltete Knoten.

Self-managed Knoten

Ersetzen Sie die Knoten, sodass sie beim Bootstrapping mit der aktualisierten CA-Trust-Konfiguration ausgeführt werden. Dies beinhaltet in der Regel die Aktualisierung der Startvorlage mit den aktualisierten CA-Daten und das Auslösen eines rollierenden Austauschs durch Ihre Auto Scaling-Gruppe.

Hybridknoten

Aktualisieren Sie die Vertrauenskonfiguration auf jedem Hybrid-Knoten, um die Nachfolge-CA einzubeziehen. Der spezifische Prozess hängt davon ab, wie Ihre Hybridknoten gebootet wurden und wie ihre Vertrauenskonfiguration verwaltet wird.

Mithilfe von Cluster Insights können Sie feststellen, welche Arten von Worker-Knoten in Ihrem EKS-Cluster ausgeführt werden. Eine ausführliche schrittweise Anleitung zur Aktualisierung der einzelnen Typen finden Sie in einem späteren Abschnitt.

Wir bieten CA Rollback als Sicherheitsnetz an, falls irgendwelche Worker-Nodes übersehen werden. Durch die Aktualisierung aller Worker-Knoten vor der Aktivierung der Nachfolge-CA werden Verbindungsunterbrechungen jedoch vollständig vermieden. Knoten, die vor der Aktivierung der Nachfolge-CA nicht aktualisiert werden, verlieren die Konnektivität zum API-Server des EKS-Clusters, bis sie ersetzt werden oder ein CA-Rollback durchgeführt wird.

Warum können nur Sie das tun

Externe Kunden existieren außerhalb der AWS Betriebsgrenze. Eine CI/CD Pipeline, die in Ihrem Unternehmensnetzwerk läuft, das Notebook eines Entwicklers, ein vor Ort gehostetes Überwachungstool: AWS Es gibt keinen Mechanismus, um in diese Systeme einzudringen und ihre Vertrauenskonfiguration zu aktualisieren.

Non-EKS Die Vertrauenskonfiguration von Worker-Nodes im automatischen Modus wird durch Startvorlagen, Benutzerdatenskripts oder Bootstrap-Prozesse gesteuert, die Sie besitzen. Um sie zu aktualisieren, müssen entweder die Knoten ausgetauscht oder ihre Konfiguration geändert werden. Beides sind Aktionen innerhalb Ihrer Infrastruktur.

Dies ist eine Einschränkung des TLS-Trust-Modells, das heute von Kubernetes verwendet wird. Es gibt keinen Mechanismus auf Protokollebene, mit dem der API-Server abfragen kann, ob ein Client sein Trust-Paket aktualisiert hat. Der Server kann sein Zertifikat nur vorlegen, wenn ein Client eine Verbindung herstellt. Wenn der Client der CA vertraut, die ihn signiert hat, ist die Verbindung erfolgreich. Wenn nicht, schlägt sie fehl. Es gibt keinen Verifizierungspfad vor der Aktivierung, mit AWS dem Sie die Einsatzbereitschaft Ihrer Komponenten in Ihrem Namen bestätigen könnten.

Wann soll ich anfangen

Fangen Sie so früh wie möglich an, Ihre externen Kunden zu identifizieren. Dies ist der zeitaufwändigste Teil der CA-Rotation, insbesondere in Umgebungen mit mehreren Teams, die Workloads unabhängig voneinander auf dem EKS-Cluster bereitstellen. Je früher Sie mit der Kundensuche beginnen, desto mehr Zeit haben Sie, um Updates teamübergreifend ohne Druck zu koordinieren.

Eine ausführliche Anleitung zur Aktualisierung der einzelnen Client- und Workerknotentypen finden Sie in den folgenden Abschnitten.

Voraussetzungen

Bevor Sie mit der CA-Rotation beginnen, überprüfen Sie Folgendes:

Außer den für die Verwaltung Ihres EKS-Clusters erforderlichen Berechtigungen sind keine weiteren IAM-Berechtigungen erforderlich. Wenn Sie heute EKS-APIs für Ihren EKS-Cluster aufrufen können, können Sie eine CA-Rotation durchführen.

Erste Schritte

Sie können die CA-Rotation mithilfe der AWS CLI oder der Amazon EKS-Konsole durchführen. Stellen Sie sicher, dass Sie AWS CLI Version 2.x oder höher ausführen (aws --versionzur Überprüfung).

Verwendung der AWS CLI

In der folgenden exemplarischen Vorgehensweise wird der vollständige CA-Rotationsprozess mithilfe der AWS CLI- und EKS-APIs behandelt.

Schritt 1: Überprüfen Sie Ihre aktive CA

Sehen Sie sich die aktive Zertifizierungsstelle in Ihrem EKS-Cluster an.

aws eks list-certificate-authorities --cluster-name my-cluster --region us-west-2

Erwartete Ausgabe:

{
    "certificateAuthorities": [
        {
            "id": "a1b2c3d4-5678-90ab-cdef-example11111",
            "createdAt": "2024-01-15T10:30:00-07:00",
            "createdBy": "EKS",
            "activatedAt": "2024-01-15T10:30:00-07:00",
            "activatedBy": "EKS",
            "signingStatus": "IN_USE",
            "distributionStatus": "COMPLETE"
        }
    ]
}

Dies zeigt die CA, die bei der Erstellung Ihres EKS-Clusters erstellt wurde. Sie wird derzeit verwendet (Signaturzertifikate) und die Verteilung ist abgeschlossen (alle AWS verwalteten Komponenten in EKS vertrauen ihr).

Schritt 2: CA-Details und Ablauf anzeigen

aws eks describe-certificate-authority --cluster-name my-cluster --certificate-authority-id a1b2c3d4-5678-90ab-cdef-example11111 --region us-west-2

Erwartete Ausgabe:

{
    "certificateAuthority": {
        "id": "a1b2c3d4-5678-90ab-cdef-example11111",
        "createdAt": "2024-01-15T10:30:00-07:00",
        "createdBy": "EKS",
        "activatedAt": "2024-01-15T10:30:00-07:00",
        "activatedBy": "EKS",
        "signingStatus": "IN_USE",
        "distributionStatus": "COMPLETE",
        "validity": {
            "notBefore": "2024-01-15T10:30:00-07:00",
            "notAfter": "2029-01-14T10:30:00-07:00"
        },
        "rollbackAvailable": false
    }
}

Der validity Block zeigt an, wann die CA erstellt wurde (notBefore) und wann sie abläuft (notAfter). rollbackAvailablegibt an, ob Sie nach der Aktivierung der Nachfolgezertifizierungsstelle zu einer früheren CA zurückkehren können. Für die ursprüngliche CA, die mit Ihrem EKS-Cluster erstellt wurde, liegt das false daran, dass es keine vorherige CA gibt, zu der Sie zurückkehren könnten.

Schritt 3: Eine Nachfolger-CA anhängen

aws eks create-certificate-authority --cluster-name my-cluster --region us-west-2

Dadurch wird eine Nachfolger-CA an Ihren EKS-Cluster angehängt. Die Antwort enthält einen, den updateId Sie verwenden können, um den Fortschritt zu verfolgen.

Schritt 4: Verfolge das Update

aws eks describe-update --name my-cluster --update-id a1b2c3d4-update-id --region us-west-2

Warten Sie, bis der Aktualisierungsstatus lautetSuccessful.

Schritt 5: Überprüfen Sie den Vertriebsstatus

aws eks list-certificate-authorities --cluster-name my-cluster --region us-west-2

Sie sollten jetzt zwei CAs sehen. Die Nachfolge-CA AWS hat alle verwalteten Komponenten in Ihrem EKS-Cluster aktualisiert signingStatus: NOT_USED und distributionStatus wird von dort IN_PROGRESS zu COMPLETE Schritt weitergehen.

Fahren Sie erst fort, wenn der Distributionsstatus der Nachfolger-CA erreicht istCOMPLETE.

Schritt 6: Aktualisieren Sie Ihre Kubeconfig

aws eks update-kubeconfig --name my-cluster --region us-west-2

Dadurch wird Ihre lokale Kubeconfig aktualisiert, sodass sie beiden CAs vertraut. Danach funktionieren Ihre kubectl-Befehle auch nach der Aktivierung der Nachfolge-CA weiter.

Schritt 7: Aktualisieren Sie die von Ihnen verwalteten Worker-Knoten und die externen Clients

Dies wird im nächsten Abschnitt ausführlich behandelt. Nachdem alle von Ihnen verwalteten Worker-Knoten und externen Clients so aktualisiert wurden, dass sie der Nachfolgezertifizierungsstelle vertrauen, fahren Sie mit der Aktivierung fort.

Schritt 8: Aktivieren Sie die Nachfolge-CA

aws eks activate-certificate-authority --cluster-name my-cluster --certificate-authority-id <successor-ca-id> --region us-west-2

Nach der Aktivierung der Nachfolge-CA stellt Ihr EKS-Cluster Zertifikate aus, die von der Nachfolge-CA signiert wurden. Überprüfen Sie die Konnektivität, um sicherzustellen, dass alle Komponenten erwartungsgemäß funktionieren.

Verwenden der Amazon-EKS-Konsole

Die Amazon EKS-Konsole bietet eine geführte Erfahrung mit der CA-Rotation. Sie können Ihren CA-Status einsehen, eine Nachfolger-CA anhängen, den Fortschritt der Verteilung überwachen und die Nachfolger-CA direkt von der Konsole aus aktivieren.

Die folgende Abbildung zeigt die Ansicht der Zertifizierungsstellendetails in der Amazon EKS-Konsole während einer aktiven Rotation. Die aktive CA und die Nachfolger-CA werden beide mit ihrem Signaturstatus, ihrem Ablaufdatum und den Tagen bis zum Ablauf angezeigt.

Die folgende Abbildung zeigt die Fortschrittsanzeige der Rotation in der Amazon EKS-Konsole. Jeder Schritt des Rotationsprozesses wird mit seinem aktuellen Status angezeigt, einschließlich Anhängen, Verteilen, Aktualisieren von Worker-Knoten und externen Clients sowie Aktivierung und Löschen der ausgehenden CA.

Aktualisierung Ihrer Kubernetes-Clients

Nachdem die Nachfolger-CA angehängt AWS wurde und die Verteilung an die verwalteten Komponenten in Ihrem EKS-Cluster (distributionStatus: COMPLETE) abgeschlossen ist, müssen Sie Ihre eigenen Komponenten aktualisieren, damit sie der Nachfolger-CA vertrauen. Ein „Client“ ist in diesem Zusammenhang jedes System, das eine Verbindung zum API-Server Ihres EKS-Clusters herstellt. Dazu gehören Ihre lokale Kubectl-Konfiguration, CI/CD Pipelines, Überwachungstools, Automatisierungsskripte und Ihre Worker-Knoten.

Die aktualisierten CA-Daten für Ihren EKS-Cluster (der jetzt sowohl die aktuelle CAs als auch die Nachfolge-CAs enthält) können wie folgt abgerufen werden:

aws eks describe-cluster --name my-cluster --region us-west-2 --query 'cluster.certificateAuthority.data' --output text

Verwenden Sie diesen Wert, um die Vertrauenskonfiguration der einzelnen Clienttypen in den folgenden Unterabschnitten zu aktualisieren.

Kubeconfig (Entwickler-Workstations, Pipelines, CI/CD Automatisierung)

Führen Sie Folgendes aus, um Ihre lokale Kubeconfig zu aktualisieren:

aws eks update-kubeconfig --name my-cluster --region us-west-2

Dadurch werden automatisch die neuesten CA-Daten abgerufen und Ihre Kubeconfig aktualisiert. Jedes System, das diese Kubeconfig verwendet, vertraut beiden CAs.

Bei CI/CD Pipelines und Automatisierungen, die ihre eigene Kubeconfig generieren (z. B. indem sie die EKS-APIs direkt verwenden oder kubeconfig als Geheimnis speichern), aktualisieren Sie das Feld mit dem Wert, von dem certificate-authority-data abgerufen wurde. describe-cluster

Verwaltete Knotengruppen

Führen Sie ein Versionsupdate für die Knotengruppe durch, um einen fortlaufenden Austausch der Knoten auszulösen:

aws eks update-nodegroup-version --cluster-name my-cluster --nodegroup-name my-nodegroup --region us-west-2

Neue Knoten werden automatisch mit den aktualisierten CA-Daten gestartet. Der fortlaufende Austausch stellt sicher, dass die Knoten einzeln ausgetauscht werden, ohne dass die laufenden Workloads unterbrochen werden.

Wenn Sie Ihre Knotengruppen über Terraform oder die CA-Rotation verwalten CloudFormation, führt die CA-Rotation nicht zu einer Abweichung in Ihrem IaC-Status. Der CA-Lebenszyklus wird über dedizierte EKS-APIs verwaltet, die von Ihrer Cluster-Ressourcenkonfiguration getrennt sind. Weitere Informationen darüber, wie die CA-Rotation mit der Infrastruktur als Code interagiert, finden Sie im Abschnitt Infrastruktur als Code.

Benutzerdefinierte Startvorlage mit einem benutzerdefinierten AMI

Wenn Ihre Knotengruppe mit einem benutzerdefinierten AMI bereitgestellt wird, werden AWS keine Benutzerdaten zusammengeführt. Sie sind dafür verantwortlich, die richtige Bootstrap-Konfiguration bereitzustellen, einschließlich des aktualisierten CA Trust Bundles. Durch die CA-Rotation werden Ihre Benutzerdaten nicht für Sie aktualisiert, und ein Knoten ohne die Nachfolge-CA kann dem Cluster nicht beitreten.

Stellen Sie sicher, dass die Knoten auf der aktualisierten Startvorlage ausgeführt werden

Bevor Sie mit der Aktivierung fortfahren, stellen Sie sicher, dass alle Knoten in Ihrer verwalteten Knotengruppe auf der neuesten Version der Startvorlage ausgeführt werden. Diese Version muss das aktualisierte CA Trust Bundle enthalten.

Karpenter-controlled Knoten

Wenn die Drift-Erkennung in Ihrem Karpenter aktiviert ist NodePool, erkennt Karpenter automatisch, dass Knoten mit veralteten CA-Daten laufen, und wechselt diese innerhalb des konfigurierten Unterbrechungsfensters. Neue Knoten übernehmen die Nachfolge-CA ohne manuelles Eingreifen.

Stellen Sie sicher, dass die Drift-Erkennung in Ihrer NodePool Konfiguration aktiviert ist:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    budgets:
      - nodes: "10%"
  template:
    spec:
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default

Wenn mit einer Konsolidierungsrichtlinie konfiguriert disruption ist, ist die Drift-Erkennung standardmäßig aktiv. Karpenter ersetzt Knoten, die ihren gewünschten Zustand verlassen haben, was auch Änderungen an CA-Daten einschließt.

Wenn die Drift-Erkennung aktiviert ist, stellen Sie sicher, dass Ihr Unterbrechungsbudget es zulässt, dass alle Karpenter-controlled Knoten vor dem Aktivierungsdatum der Nachfolge-CA ausgetauscht werden können. Wenn das Budget zu restriktiv ist (z. B. ein enges Wartungsfenster mit einem niedrigen Prozentsatz an Ersatzteilen), werden möglicherweise nicht alle Knoten rechtzeitig ausgetauscht.

Wenn die Drift-Erkennung deaktiviert ist oder Ihre Budgets für Unterbrechungen den Austausch auf ein Zeitfenster beschränken, das Ihren Rotationszeitplan überschreitet, können Sie den Austausch von Knoten manuell auslösen, indem Sie die Knoten absperren und entleeren:

kubectl cordon <node-name>
kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data

Karpenter stellt einen Ersatzknoten bereit, der das Bootstrap mit den aktualisierten CA-Daten durchführt.

Self-managed Knoten

Bei selbstverwalteten Knoten müssen Sie die CA-Daten in der Startvorlage oder im Benutzerdatenskript aktualisieren, das Ihre Knoten beim Bootstrap verwenden:

Neue Knoten starten mit den aktualisierten CA-Daten und vertrauen sowohl der aktuellen als auch der Nachfolger-CA.

AWS Fargate-Pods (Starttyp EKS Fargate)

AWS Fargate-Pods in Ihrem EKS-Cluster funktionieren anders als andere Startmodi der EKS-Datenebene (verwaltete Knotengruppen, selbstverwaltete Knoten, Knoten). Karpenter-controlled

Wenn ein Pod eine Verbindung zum API-Server herstellt, passieren zwei Dinge: Der Pod authentifiziert sich mit seinem Dienstkonto-Token (wodurch seine Identität gegenüber dem API-Server nachgewiesen wird), und der Pod überprüft die Identität des API-Servers, indem er überprüft, ob das Zertifikat des Servers von einer Zertifizierungsstelle signiert wurde, der er vertraut. Die in der Umgebung des Pods gespeicherten CA-Daten ermöglichen diese Überprüfung. Wenn der API-Server anfängt, von einer Nachfolge-CA signierte Zertifikate zu präsentieren, denen der Pod nicht vertraut, lehnt der Pod die Verbindung ab.

In anderen Startmodi der EKS-Datenebene (verwaltete Knotengruppen, selbstverwaltete Karpenter-controlled Knoten, Knoten) befinden sich die CA-Daten auf dem Knoten. Wenn Sie den Knoten austauschen, wird der neue Knoten mit den aktualisierten CA-Daten gestartet. Pods, die für diesen neuen Knoten geplant sind, erhalten die aktualisierten CA-Daten, sodass sie den API-Server verifizieren können, unabhängig davon, welche CA das Zertifikat signiert hat.

In Fargate läuft jeder Pod in seiner eigenen dedizierten Rechenumgebung mit einem eigenen Kubelet-Prozess. Dieses Kubelet führt zum Zeitpunkt der Erstellung des Pods einen Bootstrap mit den CA-Daten durch. Darunter befindet sich kein gemeinsam genutzter Knoten, und Sie haben keinen direkten Zugriff auf die zugrunde liegende Rechenleistung.

Während der CA-Rotation ist für AWS Fargate-Knoten in EKS keine Kundenaktion erforderlich. AWS recycelt Pods in Fargate-Knoten auf natürliche Weise im Rahmen des Patching-Prozesses. Nachdem eine Nachfolge-CA angehängt wurde, werden bereits vorhandene Fargate-Pods im Rahmen dieses Prozesses recycelt. Sie werden der Nachfolger-CA vertrauen, ohne dass Sie etwas unternehmen müssen. Da die AWS Nachfolger-CA weit vor jeder von ihr initiierten CA-Aktivierungszeitleiste in EKS AWS angehängt wird, sind Fargate-Pods recycelt und vertrauen der Nachfolger-CA, wenn die Nachfolger-CA AWS aktiviert wird. Es gibt eine integrierte Schutzmaßnahme, die die Aktivierung der Nachfolge-CA verhindert, bis die Fargate-Pods das Recycling abgeschlossen haben.

Das bedeutet, dass beide Optionen für verwaltete Datenebenen (EKS Auto Mode und Fargate) für einen EKS-Cluster die gleiche Benutzererfahrung bei der CA-Rotation bieten: Für Ihre Worker-Knoten sind keine Kundenaktionen erforderlich. Sie sind weiterhin für die Aktualisierung aller externen Clients verantwortlich, die eine Verbindung zum API-Server herstellen.

Dies ist ein Randfall. Angesichts des Rotationszeitplans (die Nachfolge-CA wird Jahre vor Ablauf angehängt) wird der natürliche Patching-Zyklus in den allermeisten Szenarien lange vor der Aktivierung der Nachfolgezertifizierungsstelle abgeschlossen sein. Die Schutzmaßnahme dient als Präventivmaßnahme für den unwahrscheinlichen Fall, dass ein Kunde versucht, eine frühzeitige Aktivierung zu versuchen.

Externe Kunden (Überwachungstools, Integrationen von Drittanbietern)

Jede Anwendung oder jedes Tool, das mithilfe einer Kubeconfig- oder Certificate-Trust-Konfiguration eine Verbindung zum API-Server Ihres EKS-Clusters herstellt, muss mit den aktualisierten CA-Daten aktualisiert werden. Dies umfasst:

Ersetzen Sie für jeden dieser Werte die gespeicherten CA-Daten durch den aktualisierten Wert vondescribe-cluster.

Wie verifiziert man, dass ein Client aktualisiert wurde

Bestätigen Sie nach dem Update eines Clients, dass er weiterhin mit dem API-Server kommunizieren kann:

kubectl get nodes

Wenn der Befehl erfolgreich ist, vertraut Ihre Kubeconfig den aktiven CA-Daten. Führen Sie nach der Aktivierung der Nachfolge-CA denselben Befehl aus, um die fortgesetzte Konnektivität zu bestätigen.

Infrastructure as Code

Sie können die CA-Rotation parallel zu Ihrer vorhandenen Infrastruktur als Code (IaC) durchführen, ohne dass es zu Abweichungen kommt oder Änderungen an Ihren IaC-Konfigurationen erforderlich sind.

Warum sich die CA-Rotation nicht auf Ihren IaC-Status auswirkt

Der CA-Lebenszyklus wird über dedizierte EKS-APIs (create-certificate-authority,,delete-certificate-authority) verwaltetactivate-certificate-authority, die vollständig von der EKS-Cluster-Ressourcenkonfiguration getrennt sind. Unabhängig davon, ob die CA-Rotation von Ihnen oder automatisch von Ihnen initiiert wird AWS, wird keine Eigenschaft geändert, die von Ihren IaC-Tools auf der EKS-Cluster-Ressource verfolgt wird.

Das bedeutet Folgendes:

Das von zurückgegebene certificateAuthority.data Feld describe-cluster ist eine schreibgeschützte Ausgabe. Es spiegelt das aktuelle kombinierte Vertrauenspaket wider (beide Zertifizierungsstellen während des dualen Vertrauenszeitraums), ist jedoch keine konfigurierbare Eigenschaft. Die IaC-Tools betrachten es nicht als etwas, das miteinander in Einklang gebracht werden muss.

Mithilfe der Attributionsfelder (createdBy,activatedBy) in jedem CA-Datensatz können Sie zwischen von Ihnen initiierten Vorgängen und automatisch AWS initiierten Vorgängen unterscheiden. Dies unterstützt Audit- und Change-Management-Workflows.

Verwendung CloudFormation mit CA-Rotation

Die CA-Rotation kann durch die CloudFormation Verwendung einer WriteOnly Eigenschaft für die AWS::EKS::Cluster Ressource ausgelöst werden. Diese Eigenschaft löst die Aktivierung aus, wird aber nicht im Status des Stacks gespeichert, sodass nachfolgende Stack-Updates ohne sie nicht versuchen, sie rückgängig zu machen oder zu deaktivieren.

# Phase 1: Add to existing stack that manages your cluster
Resources:
    NewCA:
        Type: AWS::EKS::CertificateAuthority
        Properties:
            ClusterName: my-cluster

    MyCluster:
        Type: AWS::EKS::Cluster
        Properties:
            Name: my-cluster

Bei diesem ersten Stack-Update wird eine Nachfolge-CA an Ihren Cluster angehängt. Warten Sie, bis der Verteilungsstatus der Nachfolge-CA erreicht ist, COMPLETE bevor Sie fortfahren.

# Phase 2: After distribution completes, update your existing Cluster resource to activate
Resources:
    NewCA:
        Type: AWS::EKS::CertificateAuthority
        Properties:
            ClusterName: my-cluster

    # Update your existing Cluster resource to activate
    MyCluster:
        Type: AWS::EKS::Cluster
        Properties:
            Name: my-cluster
            ActiveCertificateAuthorityId: !GetAtt NewCA.Id

Dieses zweite Stack-Update löst die Aktivierung der Nachfolge-CA aus. Da ActiveCertificateAuthorityId es sich um eine WriteOnly Eigenschaft handelt, CloudFormation wird sie beim Lesen nicht zurückgegeben und erkennt keine Abweichung, wenn sich die aktive CA außerhalb von ändert CloudFormation (z. B. durch automatische Aktivierung von AWS).

Wichtig: Die CloudFormation CA-Rotationsintegration folgt einem anderen Muster als typische CloudFormation Ressourcen. Eine Zertifizierungsstelle in EKS ist keine unabhängige Ressource mit einem eigenen ARN. Sie ist Teil des Zertifikatslebenszyklus des Clusters und wird durch den Cluster selbst autorisiert, ähnlich wie eine IAM-Rollenrichtlinie über ihre übergeordnete Rolle (AWS::IAM::RolePolicy) autorisiert wird oder eine EIP-Zuordnung über ihre Instanz (AWS::EC2::EIPAssociation) autorisiert wird. Kunden, die für die CA-Rotation zuständig sind, CloudFormation sollten sich dieses Unterschieds bewusst sein.

Verwaltete Knotengruppen und IaC

Das Durchführen eines Versionsupdates für die Knotengruppe, um Knoten mit der aktualisierten CA-Trust-Konfiguration zu aktualisieren, ist eine betriebliche Maßnahme. Neue Knoten starten automatisch mit den aktiven CA-Trust-Daten aus dem Cluster. Wenn Ihre IaC-Vorlagen keine CA-Daten in Startvorlagen oder Benutzerdaten fest codieren, sind keine Vorlagenänderungen erforderlich.

CA-Rollback

Nach der Aktivierung einer Nachfolgezertifizierungsstelle können Sie zur vorherigen CA zurückkehren, wenn Sie Verbindungsprobleme mit den von Ihnen verwalteten Worker-Knoten (nicht im EKS-Automatikmodus, nicht in Fargate) oder bei externen Clients feststellen. Durch das Rollback wird die vorherige CA erneut als Signaturautorität für Ihren EKS-Cluster aktiviert.

Wenn ein CA-Rollback verfügbar ist

Ein CA-Rollback ist nach der CA-Aktivierung verfügbar, sofern:

Sie können jederzeit überprüfen, ob CA Rollback verfügbar ist, indem Sie das rollbackAvailable Feld verwenden, das zurückgegeben wird von: describe-certificate-authority

aws eks describe-certificate-authority --cluster-name my-cluster --certificate-authority-id <ca-id> --region us-west-2

{
    "certificateAuthority": {
        "id": "a1b2c3d4-5678-90ab-cdef-example22222",
        "signingStatus": "IN_USE",
        "distributionStatus": "COMPLETE",
        "rollbackAvailable": true
    }
}

Wenn CA Rollback nicht verfügbar ist

Ein CA-Rollback ist nach der endgültigen automatischen Aktivierung nicht verfügbar. Wenn die Nachfolge-Zertifizierungsstelle zum letzten Mal AWS aktiviert wird (45 Tage vor Ablauf der CA), muss die Rotation fortgesetzt werden. Die endgültige automatische Aktivierung erfolgt nur, wenn die erste automatische Aktivierung zuvor rückgängig gemacht wurde. Sie dient als letzte Schutzmaßnahme, um sicherzustellen, dass der EKS-Cluster das Ablaufdatum der Zertifizierungsstelle nicht erreicht, ohne dass eine gültige CA vorhanden ist.

Wie führe ich ein Rollback durch

Um ein Rollback durchzuführen, aktivieren Sie die vorherige CA erneut:

aws eks activate-certificate-authority --cluster-name my-cluster --certificate-authority-id <previous-ca-id> --region us-west-2

Was passiert beim CA-Rollback

Wann sollte ein CA-Rollback in Betracht gezogen werden

Ein CA-Rollback ist ein Sicherheitsmechanismus für Situationen, in denen bei der Aktivierung der nächsten CA ein Verbindungsproblem aufgedeckt wird, das Sie vorher nicht bemerkt haben:

Nach dem Rollback behalten Sie die gesamte duale Vertrauensdauer bei, um das Problem zu identifizieren und zu beheben, bevor Sie die Nachfolgezertifizierungsstelle erneut aktivieren.

Wiederherstellung ohne CA-Rollback

Wenn Sie die Nachfolge-CA vor der Aktualisierung Ihrer verwalteten Knotengruppen aktivieren und das CA-Rollback-Fenster nicht mehr verfügbar ist (z. B. nach Ablauf der letzten Frist für die automatische Aktivierung), können Sie die Wiederherstellung durchführen, indem Sie ein fortlaufendes Update für die betroffenen Knotengruppen durchführen. Der erste Versuch eines fortlaufenden Updates schlägt jedoch fehl, da getrennte Knoten keine Befehle zum Löschen von Pods vom API-Server empfangen können.

Schritte zur Wiederherstellung

Überlegungen und Einschränkungen

Regionale Verfügbarkeit

Die CA-Rotation ist in allen AWS Handelsregionen verfügbar, in denen Amazon EKS unterstützt wird.

Maximal zwei CAs

Ein EKS-Cluster kann jederzeit maximal zwei CAs haben: die aktive CA und einen Nachfolger. Sie können keine zweite Nachfolger-CA anhängen, bis die vorherige Rotation abgeschlossen ist.

Kein Widerruf des Zertifikats

Die CA-Rotation unterstützt das Sperren einzelner Zertifikate nicht. Dies steht im Einklang mit Upstream-Kubernetes, das keine Zertifikatssperrung (CRL oder OCSP) implementiert. Die Rotation ersetzt die gesamte CA, wodurch natürlich alle Zertifikate ungültig werden, die von der ausgehenden CA signiert wurden, nachdem sie aus dem Trust Bundle entfernt wurde.

AWS-angehängte CAs können nicht gelöscht werden

Wenn eine Nachfolger-CA AWS automatisch angehängt wurde, können Sie sie nicht löschen. Diese Schutzmaßnahme stellt sicher, dass der Rotationsvorgang nicht durch versehentliches Löschen unterbrochen werden kann. Customer-appended Zertifizierungsstellen können gelöscht werden, solange sie nicht die aktive signierende CA sind.

Gültigkeitsdauer der CA

Die ursprüngliche CA, die mit Ihrem Cluster erstellt wurde, hat eine Gültigkeitsdauer von 10 Jahren. Nachfolgezertifizierungsstellen, die im Rahmen des Rotationsprozesses erstellt wurden, haben eine Gültigkeitsdauer von 5 Jahren. Alle zukünftigen Zertifizierungsstellen für Ihren Cluster haben eine Gültigkeitsdauer von 5 Jahren. Überprüfen Sie das Ablaufdatum Ihrer CA mitdescribe-certificate-authority.

Größe der EC2-Benutzerdaten bei Dual-Trust

Während der dualen Vertrauensperiode vergrößert sich das Vertrauenspaket Ihres Clusters, da es zwei CA-Zertifikate enthält (zusammen etwa 2,8 KB oder etwa 1,9 KB mit GZIP-Komprimierung). Stellen Sie bei Worker-Nodes, auf denen benutzerdefinierte Benutzerdaten in EC2-Startvorlagen bereitgestellt werden, sicher, dass die Gesamtgröße Ihrer Benutzerdaten das EC2-Benutzerdatenlimit von 16 KB nicht überschreitet. Wenn Ihre vorhandenen Benutzerdaten diesem Limit nahe kommen, kann das Hinzufügen einer zweiten CA dazu führen, dass die Erstellung der Startvorlage fehlschlägt und die Bereitstellung neuer Knoten verhindert wird. Erwägen Sie, Ihre Benutzerdateninhalte mit gzip zu komprimieren, um die Größe zu reduzieren.

Versionsaktualisierungen während der CA-Rotation

Aktualisierungen der EKS-Cluster-Version und die CA-Rotation sind unabhängige Vorgänge. Sie können jedoch nicht beide gleichzeitig ausführen. Wenn ein Zertifizierungsstellenrotationsvorgang im Gange ist, wird ein Versionsupgrade abgelehnt, bis der CA-Vorgang abgeschlossen ist, und umgekehrt.

Bringen Sie Ihre eigene CA mit (BYOCA)

Die Verwendung Ihrer eigenen AWS privaten CA zur Sicherung der Zertifikate Ihres EKS-Clusters wird derzeit nicht unterstützt.

Häufig gestellte Fragen

Wie fange ich mit der CA-Rotation an?

Starten Sie zunächst, aws eks list-certificate-authorities --cluster-name my-cluster um sich Ihre aktive CA und deren Ablauf anzusehen. Wenn Sie bereit sind, mit der Rotation zu beginnen, führen Sie den Befehl aus, aws eks create-certificate-authority --cluster-name my-cluster um eine Nachfolge-CA anzuhängen. Der vollständige Schritt für Schritt wird im Abschnitt Erste Schritte behandelt. Sie können die CA-Rotation auch über die Amazon EKS-Konsole durchführen.

Sind mit der CA-Rotation irgendwelche Kosten verbunden?

Nein. Die CA-Rotation ist für alle EKS-Cluster ohne zusätzliche Kosten verfügbar.

Was passiert, wenn ich meine CA nicht rotiere, bevor sie abläuft?

Wir verfügen über automatische Schutzmaßnahmen, die verhindern, dass Ihr EKS-Cluster den Ablauf der Zertifizierungsstelle erreicht, ohne dass eine gültige CA vorhanden ist. Wenn Sie die CA-Rotation nicht selbst initiieren, fügen wir vor Ablauf automatisch eine Nachfolge-CA hinzu und aktivieren sie, um sicherzustellen, dass Ihr Cluster verfügbar bleibt.

Für eine erfolgreiche Rotation müssen Sie jedoch auch die von Ihnen verwalteten Worker-Knoten (nicht EKS Auto Mode, nicht Fargate) und die externen Clients so aktualisieren, dass sie der Nachfolge-CA vertrauen. Wenn diese Komponenten nicht aktualisiert werden, bevor die Nachfolge-CA aktiviert wird, verlieren sie die Verbindung zum API-Server.

Wenn in Kubernetes eine CA nicht rotiert wird, bevor sie abläuft, werden alle von dieser CA signierten Zertifikate ungültig. Der API-Server kann von keinem Client mehr erreicht werden und der Cluster ist nicht mehr verfügbar.

Wie viel Zeit habe ich, um die CA-Rotation abzuschließen?

Die Gesamtzeit bis zum Abschluss der CA-Rotation hängt sowohl von den AWS automatisierten Schutzmaßnahmen als auch von Ihrem eigenen Aktualisierungsprozess ab.

AWS bietet definitive Zeitpläne für das, was es verwaltet. Eine Nachfolgezertifizierungsstelle wird etwa 2 Jahre vor Ablauf Ihrer ausgehenden Zertifizierungsstelle hinzugefügt. Wenn Sie die Nachfolgezertifizierungsstelle nicht selbst aktivieren, aktivieren wir sie etwa 6 Monate vor Ablauf automatisch. Wenn Sie nach der automatischen Aktivierung ein Rollback durchführen, führen wir 45 Tage vor Ablauf eine endgültige automatische Aktivierung durch. Diese Schutzmaßnahmen stellen sicher, dass Ihr EKS-Cluster verfügbar bleibt, unabhängig davon, ob Sie handeln.

Eine erfolgreiche CA-Rotation hängt auch davon ab, dass Sie die von Ihnen verwalteten Worker-Knoten (Nicht-EKS Auto Mode, nicht Fargate) und externe Clients so aktualisieren, dass sie der Nachfolger-CA vertrauen, bevor die Nachfolger-CA aktiviert wird. Wie lange das dauert, hängt von der Worker-Knoten-Konfiguration Ihrer Datenebene, Ihrem externen Kundenstamm und der Zeit ab, die Sie für die Erkennung und Aktualisierung dieser Komponenten benötigen.

Führt die CA-Rotation zu Ausfallzeiten für meinen Cluster?

Nein. Ihr EKS-Cluster bleibt während des gesamten CA-Rotationslebenszyklus verfügbar. Die Steuerungsebene bearbeitet weiterhin Anfragen in jeder Phase. Während der dualen Vertrauensphase wird sowohl der ausgehenden als auch der nachfolgenden Zertifizierungsstelle gleichzeitig vertraut, sodass Komponenten schrittweise aktualisiert werden können, ohne dass der Clusterbetrieb unterbrochen wird. Wenn Sie aufgrund von Problemen auf der Clientseite ein Rollback zur vorherigen CA AWS durchgeführt haben, wird zur Absicherung etwa 45 Tage vor Ablauf der ausgehenden CA ein letztes Rollforward durchgeführt.

Es ist wichtig, zwischen dem EKS-Cluster (Steuerungsebene) und Ihren Datenebenenkomponenten zu unterscheiden. Die Steuerungsebene wird vollständig von verwaltet AWS und bleibt während der gesamten Rotation verfügbar.

Für EKS Auto Mode und Fargate werden die Worker-Knoten automatisch AWS aktualisiert. In diesen Startmodi der Datenebene besteht kein Risiko eines Verbindungsverlusts für Ihre Worker-Knoten. Sie sind weiterhin für die Aktualisierung aller externen Clients verantwortlich, die eine Verbindung zum API-Server herstellen.

Bei verwalteten Knotengruppen, selbstverwalteten Knoten, Karpenter-controlled Instances (ohne aktivierte Drift-Erkennung) und Hybridknoten sind Sie dafür verantwortlich, diese Knoten vor der Aktivierung der Nachfolger-CA zu ersetzen oder zu aktualisieren. Wenn sie nicht ersetzt werden, verlieren diese Knoten nach der Aktivierung der Nachfolge-CA die Konnektivität zur Steuerungsebene, obwohl die Steuerungsebene selbst weiterhin voll funktionsfähig ist.

Wird meine Arbeitslast während der CA-Rotation unterbrochen?

Laufende Workloads (Pods) werden nicht durch die CA-Rotation selbst unterbrochen. Pods kommunizieren miteinander über das Cluster-Netzwerk, das von einer CA-Änderung nicht betroffen ist. Die CA wird für die Kommunikation zwischen Komponenten und dem API-Server verwendet, nicht für den Pod-zu-Pod-Verkehr.

Wenn Ihre Worker-Nodes im Zuge der Aktualisierung ersetzt werden müssen, damit sie der Nachfolger-CA vertrauen können (z. B. verwaltete Knotengruppen, die ein fortlaufendes Update durchführen, oder Karpenter ersetzt geänderte Knoten), werden Pods auf diesen Knoten im Rahmen des normalen Knotenaustauschprozesses neu geplant. Dies ist das Standardverhalten von Kubernetes beim Node-Austausch, kein Nebeneffekt der CA-Rotation. Stellen Sie sicher, dass Sie Pod Disruption Budgets (PDBs) für kritische Workloads konfiguriert haben, um zu kontrollieren, wie Pods beim Austausch von Knoten entfernt werden.

Wann läuft die CA meines Clusters ab?

Sie können mithilfe der AWS CLI, der EKS-APIs oder der Amazon EKS-Konsole überprüfen, wann die CA Ihres Clusters abläuft. Sie können beispielsweise Folgendes ausführen:

aws eks describe-certificate-authority --cluster-name my-cluster --certificate-authority-id <ca-id> --region us-west-2 --query 'certificateAuthority.validity.notAfter'

Sie können die ID Ihrer CA finden, indem Sie Folgendes ausführenaws eks list-certificate-authorities --cluster-name my-cluster.

Was ist die Gültigkeitsdauer der CA meines Clusters?

Die ursprüngliche CA, die mit Ihrem Cluster erstellt wurde, hat eine Gültigkeitsdauer von 10 Jahren. Nachfolgezertifizierungsstellen, die im Rahmen des Rotationsprozesses erstellt wurden, haben eine Gültigkeitsdauer von 5 Jahren. Alle zukünftigen Zertifizierungsstellen für Ihren Cluster haben eine Gültigkeitsdauer von 5 Jahren. Sie können den Ablauf Ihrer CA mit describe-certificate-authority überprüfen.

Kann ich vorher selbst eine CA-Rotation einleiten AWS macht es automatisch?

Ja. Sie können jederzeit eine Nachfolger-CA mit aws eks create-certificate-authority --cluster-name my-cluster anhängen. Sie müssen nicht warten, um die Rotation AWS einzuleiten. Wenn Sie früh beginnen, haben Sie mehr Zeit, Ihre Worker-Knoten und externen Clients nach Ihrem eigenen Zeitplan zu identifizieren und zu aktualisieren.

Kann ich nach der Aktivierung einer Nachfolger-CA ein Rollback durchführen?

Ja, ein CA-Rollback ist nach der Aktivierung der Nachfolger-CA verfügbar, solange das Rollback-Fenster nicht abgelaufen ist. CA Rollback aktiviert die vorherige CA erneut als Signaturautorität. Sie ist nach der endgültigen automatischen Aktivierung (45 Tage vor Ablauf der Zertifizierungsstelle) nicht mehr verfügbar. Sie können das rollbackAvailable Feld auf Ihrer CA mit describe-certificate-authority überprüfen. Einzelheiten finden Sie im Abschnitt CA Rollback.

Woher weiß ich, wann es sicher ist, die Nachfolge-CA zu aktivieren?

Es ist sicher, die Nachfolger-CA zu aktivieren, wenn alle von Ihnen verwalteten Worker-Knoten (Nicht-EKS-Auto-Modus, nicht Fargate) und externe Clients so aktualisiert wurden, dass sie der Nachfolger-CA vertrauen. Sie können dies überprüfen, indem Sie sicherstellen, dass jeder Client mithilfe der aktualisierten Vertrauenskonfiguration erfolgreich mit dem API-Server kommunizieren kann. AWS bietet keinen einzigen Indikator dafür, dass alle Clients bereit sind, da es Ihre externen Systeme nicht einsehen kann. Starten Sie den Erkennungsprozess frühzeitig, damit Sie Zeit haben, alle Kunden zu identifizieren.

Wie überwache ich den Fortschritt der CA-Rotation über mehrere Cluster hinweg?

Sie können dies programmgesteuert mithilfe der AWS CLI oder der EKS-API erreichen. aws eks list-certificate-authoritiesFür jeden Cluster verwenden. Die folgenden Felder bieten ein Situationsbewusstsein für die Überwachung auf Flottenebene:

Das folgende Beispielskript überprüft den CA-Rotationsstatus in einer Liste von Clustern:

#!/bin/bash
CLUSTERS=("cluster-1" "cluster-2" "cluster-3")
REGION="us-west-2"

for CLUSTER in "${CLUSTERS[@]}"; do
  echo "--- $CLUSTER ---"
  aws eks list-certificate-authorities \
    --cluster-name "$CLUSTER" \
    --region "$REGION" \
    --query 'certificateAuthorities[].{Id:id,Signing:signingStatus,Distribution:distributionStatus,Expiry:validity.notAfter}' \
    --output table
done

Sie können dies auf mehrere Regionen und Konten ausdehnen und nach Clustern filtern, denen eine Nachfolge-CA angehängt ist, die auf Ihre Aktion warten oder kurz vor der Deadline für die automatische Aktivierung stehen.

Benachrichtigungen werden außerdem in jeder Phase des Rotationslebenszyklus pro Cluster per AWS Health und E-Mail zugestellt.

Was passiert, wenn ich die Nachfolge-CA aktiviere, bevor ich alle meine Clients aktualisiere?

Jeder Client, der nicht so aktualisiert wurde, dass er der Nachfolge-CA vertraut, verliert die Konnektivität zum EKS-Cluster. Nach der Aktivierung der Nachfolge-CA präsentiert der API-Server Zertifikate, die von der Nachfolge-CA signiert wurden. Clients, die ihr nicht vertrauen, werden ihre TLS-Überprüfung nicht bestehen und können keine Verbindung herstellen. In diesem Fall können Sie zur vorherigen CA zurückkehren (falls das Rollback-Fenster noch verfügbar ist), um die Konnektivität wiederherzustellen, während Sie die verbleibenden Clients reparieren.

Was passiert, wenn ich die Ablauffrist der CA verpasse?

AWS verhindert, dass dies passiert. Automatische Schutzmaßnahmen stellen sicher, dass Ihr EKS-Cluster das Ablaufdatum der Zertifizierungsstelle nicht erreicht, ohne dass eine gültige CA vorhanden ist. Wir fügen eine Nachfolgezertifizierungsstelle hinzu, falls Sie dies nicht getan haben, und aktivieren sie etwa 6 Monate vor Ablauf automatisch. Wenn Sie nach der ersten automatischen Aktivierung ein Rollback durchführen, AWS führt 45 Tage vor Ablauf ein letztes Rollforward durch. Ihr Cluster bleibt verfügbar.

Wenn jedoch die von Ihnen verwalteten Worker-Knoten (ohne EKS Auto Mode, nicht Fargate) und die externen Clients zum Zeitpunkt der automatischen Aktivierung nicht so aktualisiert wurden, dass sie der Nachfolger-CA vertrauen, verlieren diese Komponenten die Konnektivität zum API-Server.

Kann ich während der CA-Rotation den Zugriff auf meinen Cluster verlieren?

Ihr EKS-Cluster (Control Plane) bleibt während des gesamten Lebenszyklus der CA-Rotation verfügbar. AWS Schutzmaßnahmen stellen sicher, dass der Cluster selbst nicht mehr verfügbar ist.

Einzelne von Ihnen verwaltete Clients können jedoch den Zugriff verlieren, wenn sie vor der Aktivierung der Nachfolgezertifizierungsstelle nicht dahingehend aktualisiert werden, dass sie der Nachfolgezertifizierungsstelle vertrauen. Wenn Ihre Kubeconfig-, CI/CD Pipeline- oder Monitoring-Tool beispielsweise immer noch nur auf die ausgehende CA verweist, können diese Clients nach der Aktivierung der Nachfolger-CA keine Verbindung herstellen. In diesem Fall kann das CA-Rollback den Zugriff wiederherstellen, während Sie die betroffenen Clients aktualisieren.

Muss ich meine Pods neu starten?

Laufende Workload-Pods sind nicht direkt von der CA-Rotation betroffen. Das Kubelet auf jedem Knoten übernimmt die API-Serverkommunikation, sodass Workload-Pods ohne Unterbrechung weiterlaufen, solange Ihre Knoten aktualisiert werden. Clusterinterne Controller und Operatoren, die Client-Go verwenden, um mit dem API-Server zu kommunizieren, müssen jedoch möglicherweise nach der Aktivierung der Nachfolge-CA neu gestartet werden, da client-go das CA Trust Bundle nicht dynamisch erneut liest. Insbesondere bei AWS Fargate-Knoten erfolgt das Update automatisch im Rahmen des natürlichen AWS Pod-Recycling-Prozesses.

Ändert sich mein Vertrauenspaket während der Rotation?

Ja. Während der CA-Rotation enthält das Vertrauenspaket Ihres Clusters zwei Zertifizierungsstellen gleichzeitig: die ausgehende CA und die Nachfolge-CA. Dies ist ein erwartetes Verhalten während der dualen Vertrauensperiode und sorgt dafür, dass durch den Rotationsprozess die Konnektivität für alle Komponenten aufrechterhalten wird.

Anwendungen und Clients sollten so konfiguriert werden, dass sie einem CA-Bundle vertrauen und nicht an ein einzelnes CA-Zertifikat gebunden sind. CA-Pinning (strikte Validierung anhand einer einzelnen CA) wird nicht empfohlen, da es bei der Aktualisierung des Vertrauenspakets zu Fehlern führen kann. Dies gilt für jede clientseitige TLS-Konfiguration, die eine Verbindung zum API-Server Ihres EKS-Clusters herstellt.

Warum unterscheidet sich mein Benachrichtigungszeitplan von dem, was in dieser Dokumentation beschrieben wird?

Wenn Ihr Cluster in den Jahren 2018-2019 erstellt wurde, erhält Ihr Cluster automatische Benachrichtigungen nach einem angepassten Zeitplan. Ihre erste Benachrichtigung enthält die relevanten Daten und die nächsten Schritte, die für Ihren Cluster spezifisch sind. Die Meilensteine für Standardbenachrichtigungen werden relativ zum Ablaufdatum der Zertifizierungsstelle Ihres Clusters berechnet. Bei Clustern in diesem Bereich gehen diese berechneten Daten der Verfügbarkeit dieser Funktion voraus, sodass ein angepasster Zeitplan angewendet wird.