--- title: "EKS CA Rotation: So tauschen Sie das Cluster-Zertifikat aus, bevor es abläuft" description: "EKS CA Rotation erklärt: Wer was erledigen muss, welche Clients ausfallen können und wie Sie in fünf Schritten rotieren. Jetzt Checkliste für Cluster lesen." image: https://dmoove.com/hubfs/blog/agent-images/eks-ca-rotation-cluster-zertifikat-featured-050058.png --- [Zum Inhalt springen](https://dmoove.com/blog/eks-ca-rotation-cluster-zertifikat#main-content) [![DMoove](https://dmoove.com/hubfs/raw_assets/public/dmoove-2026/images/logo.svg)](https://dmoove.com/) Menü - Leistungen - [AWS Landing Zone](https://dmoove.com/aws-landing-zone) - [Kubernetes auf AWS](https://dmoove.com/kubernetes-auf-aws) - [European Sovereign Cloud](https://dmoove.com/european-sovereign-cloud) - [Amazon Quick & KI](https://dmoove.com/amazon-quick-ki) - [Migration & DevOps](https://dmoove.com/migration-devops) - Lösungen - [GuardAudit](https://dmoove.com/dmoove-guardaudit) - [Cloud Kosten optimieren](https://dmoove.com/cloud-kosten-optimieren) - [EC2 Image Builder](https://dmoove.com/ec2-image-builder) - [Case Study](https://dmoove.com/case-study-kubernetes-cluster) - [Über uns](https://dmoove.com/ueber-uns) - [Blog](https://dmoove.com/blog) [Termin buchen](https://dmoove.com/meetings/yannick-tresch) 1. [Blog](https://dmoove.com/blog) 2. [Cloud Computing](https://dmoove.com/blog/tag/cloud-computing) Cloud Computing # EKS CA Rotation: So tauschen Sie das Cluster-Zertifikat aus, bevor es abläuft [Yannick Tresch](https://dmoove.com/blog/author/yannick-tresch) 29\. Oktober 2026 · Min. Lesezeit ![Ein alter Messingschlüssel wird durch einen neuen silbernen Schlüssel ersetzt, umgeben von kleineren Schlüsseln an einem Serverrack.](https://dmoove.com/hs-fs/hubfs/blog/agent-images/eks-ca-rotation-cluster-zertifikat-featured-050058.png?width=1200&height=750&name=eks-ca-rotation-cluster-zertifikat-featured-050058.png) Jeder EKS-Cluster hat eine eigene Certificate Authority (CA) und die der ältesten Cluster läuft irgendwann ab. AWS schreibt dazu: Seit dem Start 2018 erstellte Cluster haben CAs mit zehn Jahren Gültigkeit, und diese Cluster nähern sich dem Punkt, an dem die Rotation beginnen sollte. Der Cluster selbst bleibt dabei erreichbar, denn AWS hängt rund zwei Jahre vor Ablauf selbst eine Nachfolger-CA an und aktiviert sie spätestens rund sechs Monate vorher. Wer die EKS CA Rotation ignoriert, riskiert aber Worker-Nodes und Clients, die der neuen CA nicht vertrauen und dann den API-Server nicht mehr erreichen. Seit gestern zeigt das EKS Dashboard den Rotationsstatus zudem flottenweit an. Dieser Beitrag erklärt, was bei der Rotation automatisch passiert und was in Ihrer Verantwortung bleibt. ## Warum die Cluster-CA überhaupt ein Thema ist Die CA ist laut [AWS-Deep-Dive](https://aws.amazon.com/blogs/containers/deep-dive-into-amazon-eks-certificate-authority-rotation/) die Vertrauensbasis des gesamten Clusters: kubectl, ArgoCD und die Kubelets der Worker-Nodes authentifizieren sich gegenüber dem API-Server über Zertifikate, die auf diese CA zurückgehen. In Kubernetes allgemein werden bei einer abgelaufenen CA alle von ihr signierten Zertifikate ungültig, und der API-Server ist für keinen Client mehr erreichbar. Bei EKS verhindert AWS genau das mit automatischen Schutzmechanismen. Die Rotation ist laut [EKS-Dokumentation](https://docs.aws.amazon.com/eks/latest/userguide/certificate-authority-rotation.html) trotzdem für jeden Cluster verpflichtend, und sie wiederholt sich: Nachfolger-CAs sind nur fünf Jahre gültig. Rechnerisch betrifft das die ersten Cluster ab 2028. Der Zeitplan ist enger, als das klingt, denn die AWS-Fristen laufen rückwärts vom Ablaufdatum: - etwa 2,5 Jahre vor Ablauf: erste Erinnerung - etwa 2 Jahre vorher: AWS hängt automatisch eine Nachfolger-CA an - 60 Tage vor der Auto-Aktivierung: Warnung - etwa 6 Monate vorher: AWS aktiviert die Nachfolger-CA automatisch - 45 Tage vorher: finale Aktivierung, aber nur, wenn die erste zurückgerollt wurde Für Cluster von 2018 und 2019 liegen diese Termine teils schon in der Gegenwart; AWS wendet dafür laut Dokumentation einen angepassten Benachrichtigungsplan an. Die konkreten Daten Ihres Clusters stehen in der Beschreibung der Nachfolger-CA (Feld scheduledEvents). Ältere Cluster überleben oft mehrere Plattform-Generationen, und die Erinnerung daran, welche Pipeline welche kubeconfig verwendet, geht dabei verloren. ## Was AWS automatisch erledigt und was bei Ihnen bleibt ![Zwei parallele Brücken über dieselbe Lücke, über beide laufen Datenpakete, während eine Brücke ausgetauscht wird.](https://dmoove.com/hubfs/blog/agent-images/eks-ca-rotation-cluster-zertifikat-inline-050057.png) Die Rotation ist als geteilte Verantwortung angelegt. AWS hängt eine Nachfolger-CA an den Cluster an und verteilt sie an die verwalteten Komponenten: Control Plane, EKS Auto Mode, Fargate und die verwalteten EKS Capabilities (ACK, Argo CD, kro). Dafür ist keine Aktion nötig. Bei Ihnen liegen dagegen: - Worker-Nodes, die Sie selbst verwalten: Managed Node Groups, Karpenter-Nodes, Self-Managed Nodes und Hybrid Nodes - externe Clients: kubeconfig-Dateien auf Workstations, CI/CD-Pipelines, selbst betriebene GitOps-Controller wie ArgoCD oder Flux außerhalb des Clusters und Monitoring-Werkzeuge Auch wer nur Auto Mode oder Fargate nutzt, hat externe Clients, die nur er selbst aktualisieren kann. Das ist die Stelle, an der Rotationen in der Praxis schiefgehen: Nicht der Cluster fällt aus, sondern die Komponente, die ihm nicht mehr vertraut. ## EKS CA Rotation in fünf Schritten Während der Rotation vertraut der Cluster beiden CAs gleichzeitig (Dual-Trust-Phase). Dadurch lassen sich Komponenten nacheinander umstellen. Der Ablauf laut Dokumentation und Deep-Dive: 1. **Bestand prüfen.** Aktive CA und Status anzeigen, dann Ablaufdatum abfragen: ``` aws eks list-certificate-authorities --cluster-name my-cluster aws eks describe-certificate-authority --cluster-name my-cluster --certificate-authority-id ``` Das Ablaufdatum steht im Feld validity.notAfter der zweiten Abfrage. 2. **Nachfolger-CA anhängen.** ``` aws eks create-certificate-authority --cluster-name my-cluster ``` Ein Cluster kann höchstens zwei CAs gleichzeitig haben. Die Nachfolger-CA lässt sich erst aktivieren, wenn ihr distributionStatus auf COMPLETE steht. 3. **Worker-Nodes ersetzen.** Das Vorgehen hängt vom Node-Typ ab: - Managed Node Groups: `aws eks update-nodegroup-version` löst den rollenden Austausch aus. Bei eigenem Launch Template mit eigener AMI müssen Sie die neuen CA-Daten selbst ins User Data schreiben, sonst joint der Node nicht. - Karpenter: Mit aktiver Drift Detection tauscht Karpenter die Nodes selbst. Prüfen Sie, ob Ihre Disruption Budgets den Austausch vor der Aktivierung überhaupt zulassen, sonst cordon und drain von Hand. - Self-Managed Nodes: CA-Daten im Launch Template aktualisieren und per Instance Refresh ersetzen. 4. **Externe Clients aktualisieren.** Lokal genügt: ``` aws eks update-kubeconfig --name my-cluster --region eu-central-1 ``` Das holt die aktuellen CA-Daten mit beiden CAs. Pipelines und GitOps-Controller, die certificate-authority-data statisch speichern, brauchen den Wert aus `describe-cluster` in ihrer Konfiguration. Clients mit CA-Pinning auf eine einzelne CA müssen vorher auf ein Bundle umgestellt werden. 5. **Nachfolger-CA aktivieren** (`aws eks activate-certificate-authority`), erst wenn alles umgestellt ist. Danach prüfen Sie mit `kubectl get nodes`, ob alle Nodes Ready sind. Controller im Cluster, die client-go nutzen, müssen eventuell neu gestartet werden, weil client-go das Trust-Bundle nicht dynamisch neu liest. Nach der Aktivierung signiert der Cluster mit der Nachfolger-CA. Die ausgehende CA bleibt zunächst vertraut und kann danach gelöscht werden. Alternativ erledigen Sie die Schritte in der EKS-Konsole. ## Was passiert, wenn Sie nichts tun AWS fängt das ab: Legen Sie keine Nachfolger-CA an, hängt EKS laut Dokumentation vor dem Ablauf selbst eine an. Aktivieren Sie nicht selbst, aktiviert EKS automatisch. Vorab gibt es Benachrichtigungen über AWS Health, Cluster Insights und E-Mail; eigene Alarme lassen sich über EventBridge bauen. Genau das ist der Haken: Eine automatische Aktivierung nimmt keine Rücksicht darauf, ob Ihre Komponenten die neue CA schon kennen. Pipelines brechen dann ab, und nicht aktualisierte Worker-Nodes verlieren die Verbindung zum API-Server. Für diesen Fall gibt es eine Rückfalloption. Nach einer eigenen oder der ersten automatischen Aktivierung können Sie auf die vorherige CA zurückwechseln, solange das Rollback-Fenster offen ist; ob es das ist, zeigt das Feld rollbackAvailable. Nach der finalen automatischen Aktivierung 45 Tage vor Ablauf geht das nicht mehr; diese greift laut Dokumentation aber nur, wenn die erste automatische Aktivierung zuvor zurückgerollt wurde. Wer rollt, sollte also den Zeitplan im Blick behalten und die Ursache beheben. Ohne Rollback bleibt nur der harte Weg: Pods auf NotReady-Nodes force-löschen und die Node Group erneut rollen, mit dem Risiko ungraceful beendeter Workloads. ## Was die Rotation kostet und wo sie hakt Die Rotation selbst ist laut EKS-Dokumentation nicht gesondert bepreist, und das Dashboard ist laut [AWS-Ankündigung](https://aws.amazon.com/about-aws/whats-new/2026/10/amazon-eks-dashboard-fleet-wide-visibility-certificate-authority-ca-rotation/) ohne Zusatzkosten nutzbar. Zusätzliche IAM-Berechtigungen sind nicht nötig: Wer die EKS-APIs für den Cluster aufrufen darf, darf auch rotieren. Der Aufwand liegt woanders: - **Node-Austausch.** Je nach Zahl der Node Groups und der Toleranz Ihrer Workloads gegenüber Rolling Updates ist das der größte Block. Pod Disruption Budgets für kritische Workloads sind Pflicht. Wie lange der Austausch dauert, hängt von Ihrer Workload ab. - **Inventur der Clients.** Wer alles per kubeconfig auf den Cluster zugreift, steht in keiner Konsole. Das ist Teamarbeit und kostet Zeit. - **User Data.** Die Trust-Bundle-Größe mit zwei CAs liegt laut AWS bei etwa 2,8 KB (gzip: etwa 1,9 KB). Wer in Launch Templates eigene User Data nahe am EC2-Limit von 16 KB hat, sollte vorher nachrechnen, sonst scheitert die Erstellung des Launch Templates. - **Kein eigenes CA-Backend.** Die Verwendung einer eigenen AWS Private CA für Cluster-Zertifikate wird derzeit nicht unterstützt. - **Infrastructure as Code.** Der CA-Lebenszyklus läuft über eigene APIs und ändert keine Eigenschaft der Cluster-Ressource. IaC-Stände zeigen also keinen Drift an. Mit CloudFormation lässt sich die Rotation sogar im Code abbilden: Die Ressource `AWS::EKS::CertificateAuthority` hängt die Nachfolger-CA an, die Write-Only-Property `ActiveCertificateAuthorityId` am Cluster aktiviert sie. Für andere IaC-Werkzeuge haben wir das nicht geprüft. Versionsupdates und Rotation lassen sich nicht gleichzeitig ausführen: Läuft eine CA-Operation, wird ein Upgrade abgelehnt, und umgekehrt. Ob sich das nur auf den einzelnen API-Vorgang oder auf die gesamte Dual-Trust-Phase bezieht, geht aus der Dokumentation nicht eindeutig hervor. Planen Sie beides deshalb getrennt und prüfen Sie es zuerst im Staging. Zu den Updates selbst lesen Sie unseren Beitrag zum [Ende des Supports für Kubernetes 1.34 auf EKS](https://dmoove.com/blog/kubernetes-1-34-end-of-life-eks) und die Anleitung zum [Rückgängigmachen von EKS-Upgrades](https://dmoove.com/blog/eks-version-rollback-kubernetes-upgrade). ## Flottenweit im Blick: das EKS Dashboard Seit dem 28. Oktober 2026 zeigt das EKS Dashboard laut AWS, welche Cluster eine CA kurz vor dem Ablauf haben und welche automatischen Rotationsereignisse anstehen. Die Daten kommen über AWS Organizations: Sie aktivieren den Zugriff für das Dashboard im Management-Konto und rufen es in us-east-1 auf. Für Teams mit vielen Konten und Regionen ist das der schnellste Weg zur Bestandsliste. Ohne Organizations-Setup genügt eine Schleife über die Cluster: ``` for c in cluster-1 cluster-2; do aws eks list-certificate-authorities --cluster-name "$c" \ --query 'certificateAuthorities[].{Id:id,Signing:signingStatus,Distribution:distributionStatus}' \ --output table done ``` Wenn Sie Ihre Cluster über GitOps betreiben, lohnt zusätzlich ein Blick darauf, wie selbst betriebene Controller ihre Cluster-Verbindungen speichern, denn dort steckt die CA oft als Secret. Managed Argo CD aus den EKS Capabilities aktualisiert AWS dagegen selbst. Mehr zu verwalteten GitOps-Bausteinen finden Sie in unserem Überblick zu [EKS Capabilities mit Managed Argo CD](https://dmoove.com/blog/eks-capabilities-platform-engineering). ## Was Sie diese Woche tun sollten Öffnen Sie das EKS Dashboard oder führen Sie `list-certificate-authorities` und `describe-certificate-authority` für alle Cluster aus, und notieren Sie die Ablaufdaten und, falls schon angehängt, die geplanten Auto-Aktivierungstermine. Legen Sie für jeden Cluster einen Termin für die Rotation fest, der vor dem AWS-Termin liegt, und sammeln Sie bis dahin die Liste aller Clients mit kubeconfig-Zugriff: Workstations, Pipelines, GitOps-Controller, Monitoring. Prüfen Sie außerdem Karpenter-Disruption-Budgets und Launch Templates mit eigener User Data. Testen Sie den Ablauf zuerst an einem Staging-Cluster, inklusive Rollback. Wenn Sie dabei Unterstützung brauchen, sprechen Sie uns an. Yannick Tresch In diesem Artikel Fragen zu Ihrer Plattform? 30 Minuten, direkt mit dem Gründer. [Termin buchen](https://dmoove.com/meetings/yannick-tresch) Weiterlesen ## Weitere Artikel. - ### [![Förderband mit vielen Warnmarken, von denen ein Sortiertor nur eine orangefarbene durchlässt, die ein Roboterarm mit einem Flicken repariert.](https://dmoove.com/hs-fs/hubfs/blog/agent-images/schwachstellen-automatisch-beheben-aws-c-featured-050101.png?width=800&height=500&name=schwachstellen-automatisch-beheben-aws-c-featured-050101.png) Cloud Computing Schwachstellen automatisch beheben: Was AWS Continuum nach PHP2Shell leistet 27\. Oktober 2026 · Min. Lesezeit](https://dmoove.com/blog/schwachstellen-automatisch-beheben-aws-continuum) - ### [![Uhr kurz vor Mitternacht auf einem Server-Rack – symbolisiert das bevorstehende Kubernetes 1.34 End of Life auf EKS](https://dmoove.com/hs-fs/hubfs/blog/agent-images/kubernetes-1-34-end-of-life-eks-featured-040109.png?width=800&height=500&name=kubernetes-1-34-end-of-life-eks-featured-040109.png) Cloud Computing Kubernetes 1.34 End of Life: Was EKS-Teams jetzt tun müssen – bevor AWS die Kontrolle übernimmt 26\. Oktober 2026 · Min. Lesezeit](https://dmoove.com/blog/kubernetes-1-34-end-of-life-eks) - ### [![Schematische Darstellung eines kontinuierlichen Cloud-Analyse-Kreislaufs mit vernetzten Knoten und Dokumenten-Icons – symbolisiert den AWS Well-Architected Agent](https://dmoove.com/hs-fs/hubfs/blog/agent-images/aws-well-architected-agent-preview-featured-040119.png?width=800&height=500&name=aws-well-architected-agent-preview-featured-040119.png) Cloud Computing AWS Well-Architected Agent: Kontinuierliche Cloud-Optimierung statt jährlichem Review 24\. Oktober 2026 · Min. Lesezeit](https://dmoove.com/blog/aws-well-architected-agent-cloud-optimierung) ![DMoove](https://dmoove.com/hubfs/raw_assets/public/dmoove-2026/images/logo-white.svg) DMoove Solutions GmbH Damaschkestraße 23 10711 Berlin Leistungen - [AWS Landing Zone](https://dmoove.com/aws-landing-zone) - [Kubernetes auf AWS](https://dmoove.com/kubernetes-auf-aws) - [European Sovereign Cloud](https://dmoove.com/european-sovereign-cloud) - [Amazon Quick & KI](https://dmoove.com/de/amazon-quick-ai-essentials) - [Migration & DevOps](https://dmoove.com/migration-devops) Unternehmen - [Über uns](https://dmoove.com/ueber-uns) - [Blog](https://dmoove.com/blog) - [Termin buchen](https://dmoove.com/meetings/yannick-tresch) - [LinkedIn](https://www.linkedin.com/company/dmoove) Rechtliches - [Impressum](https://dmoove.com/impressum) - [Datenschutz](https://dmoove.com/datenschutz) © 2026 DMoove Solutions GmbH ```json { "@context" : "https://schema.org", "@type" : "BlogPosting", "author" : { "@type" : "Person", "name" : "Yannick Tresch", "url" : "https://dmoove.com/blog/author/yannick-tresch" }, "dateModified" : "2026-10-29T15:24:51.888Z", "datePublished" : "2026-10-29T15:24:51.000Z", "headline" : "EKS CA Rotation: So tauschen Sie das Cluster-Zertifikat aus, bevor es abläuft", "image" : [ "https://dmoove.com/hubfs/blog/agent-images/eks-ca-rotation-cluster-zertifikat-featured-050058.png" ], "mainEntityOfPage" : { "@id" : "https://dmoove.com/blog/eks-ca-rotation-cluster-zertifikat", "@type" : "WebPage" }, "publisher" : { "@type" : "Organization", "logo" : { "@type" : "ImageObject", "url" : "https://dmoove.com/hubfs/dmo_logo450.png" }, "name" : "DMoove Solutions GmbH" } } ``` ```json { "@context" : "https://schema.org", "@type" : "BreadcrumbList", "itemListElement" : [ { "@type" : "ListItem", "item" : "https://dmoove.com/blog", "name" : "Blog", "position" : 1 }, { "@type" : "ListItem", "item" : "https://dmoove.com/blog/tag/cloud-computing", "name" : "Cloud Computing", "position" : 2 }, { "@type" : "ListItem", "item" : "https://dmoove.com/blog/eks-ca-rotation-cluster-zertifikat", "name" : "EKS CA Rotation: So tauschen Sie das Cluster-Zertifikat aus, bevor es abläuft", "position" : 3 } ] } ```