Amazon EKS trennt OIDC-Zugänge: zehn Anbieter für einen Cluster

Ein Cluster akzeptiert mehrere OIDC-Quellen

Amazon EKS kann seit dem 24. August 2026 mehrere externe OpenID-Connect-Anbieter an einen einzelnen Cluster binden. Das klingt nach einem kleinen Eintrag in der Verwaltungskonsole, trifft aber einen Punkt, an dem viele Plattformteams bisher unnötig basteln mussten: Ein Cluster hatte oft genau einen Weg in die Unternehmensidentität, obwohl Mitarbeiter, externe Dienstleister und Automatisierung längst aus verschiedenen Verzeichnissen kommen. AWS erlaubt nun bis zu zehn solcher Anbieter pro Cluster. Der AWS-Beitrag vom 24. August 2026 nennt ausdrücklich Nutzer und Workloads als mögliche Authentifizierungsziele.

Der praktische Gewinn liegt nicht im Aufaddieren von zehn Einträgen. Er liegt darin, dass ein Team die Zuständigkeiten dort lassen kann, wo sie bereits gepflegt werden. Ein zentraler Unternehmens-IdP muss nicht zwangsläufig auch noch Konten eines Dienstleisters oder Tokens einer Build-Pipeline schlucken. Wer bisher einen Vermittler nur gebaut hat, um unterschiedliche Identitätsquellen vor EKS zusammenzuführen, darf diese Konstruktion neu bewerten. Das ist keine Einladung, Zugänge wahllos zu vervielfachen. Es ist eine Gelegenheit, vorhandene Grenzen sauberer abzubilden.

Für Lukas Stein zählt an solchen Änderungen zuerst die Betriebsrealität: Welche Gruppe gehört zu welchem Anbieter, wer besitzt dessen Konfiguration, und wie lässt sich ein Fehler eingrenzen? Ein zusätzlicher Loginpfad senkt keine Risiken von allein. Er kann aber die Fehlersuche vereinfachen, wenn die Zuordnung nicht mehr in einem unübersichtlichen Broker verschwindet. Der neue Spielraum ist vor allem ein Wartbarkeitswerkzeug. Er ersetzt weder Rollenmodell noch Protokollierung noch einen klaren Entzug von Berechtigungen.

Zehn Anbieter sind eine harte Obergrenze

AWS setzt die Grenze bei zehn OIDC-Identitätsanbietern je Cluster. Diese Zahl ist konkret genug, um Architekturentscheidungen daran zu messen. Ein Plattformteam mit zwei Unternehmensverzeichnissen, einem Partnerzugang und mehreren Automatisierungswegen hat damit Reserven; ein Konzern, der jede Tochtergesellschaft einzeln ankoppeln will, muss die Grenze früh in die Planung aufnehmen. Zehn sind kein Grund, einen Cluster als universellen Identitätssammelpunkt zu behandeln. Die Zahl zwingt vielmehr dazu, die tatsächlichen Nutzerpopulationen zu benennen.

AWS nennt als Beispiele Mitarbeiter, Auftragnehmer und CI/CD-Systeme. Diese Gruppen haben unterschiedliche Lebenszyklen. Ein Mitarbeiterkonto folgt typischerweise dem HR-Prozess, ein Auftragnehmerkonto einem Vertrag und ein CI/CD-Token dem technischen Lebenszyklus einer Pipeline. Werden sie über getrennte Anbieter angebunden, kann jede Gruppe ihren eigenen Eigentümer und ihre eigene Zuordnung behalten. Das reduziert nicht automatisch die Zahl der Kubernetes-Berechtigungen. Es trennt aber die Stelle, an der die Identität festgestellt wird, von der Stelle, an der Kubernetes-Zugriff vergeben wird.

Gerade beim Grenzfall Automatisierung lohnt sich Nüchternheit. Ein OIDC-Anbieter für einen Builddienst sagt noch nichts darüber aus, welche Rechte dessen Token im Cluster erhält. Prüfen Sie Aussteller, Zielgruppe, Token-Laufzeit, Gruppenclaims und die anschließende Kubernetes-Zuordnung getrennt. Ein kurzer Test mit einem absichtlich eingeschränkten Konto ist hier nützlicher als eine lange Konfigurationsdebatte. Wenn der Token zwar akzeptiert wird, aber mehr Zugriff bekommt als vorgesehen, liegt das Problem meist nicht bei der Zahl der Anbieter, sondern bei der Zuordnung dahinter.

Nutzergruppen bleiben getrennt zuordenbar

AWS beschreibt die Anbieter als unabhängig konfiguriert und verwaltet. Jede Population authentifiziert sich über ihren eigenen Anbieter und ihre eigene Identitätszuordnung. Das ist die relevante Aussage hinter der neuen Funktion. Ein Cluster kann mehrere Vertrauensbeziehungen halten, ohne dass alle Beteiligten vorher in ein gemeinsames Verzeichnis überführt werden müssen. Für Organisationen mit gewachsenen Strukturen ist das oft näher an der Wirklichkeit als ein großes Konsolidierungsprojekt, das Monate bindet und am Ende Sonderfälle erzeugt.

Die Trennung hilft auch beim Rückbau. Verlässt ein externer Dienstleister das Projekt, kann dessen Anbindung entfernt werden, ohne die Loginwege der eigenen Belegschaft anzufassen. Wechselt eine CI-Plattform, bleibt deren Integration ein abgegrenztes Paket. Dieser Nutzen entsteht nur, wenn Sie die Anbieter nicht mit identischen, breit gefassten Gruppenregeln versehen. Unterschiedliche Wege zur Anmeldung sind wertlos, wenn am Ende alle dieselbe Clusteradministrator-Rolle erhalten. Die Berechtigungsebene braucht weiterhin minimale Rechte und einen nachvollziehbaren Besitzer.

Hier passt ein Blick auf unseren Beitrag zu verbundenen Code-Assistenten: Sobald externe Systeme auf Entwicklungsressourcen zugreifen, entscheidet die saubere Begrenzung der Identität über die Qualität der Kontrolle. Für EKS heißt das: Ein Anbieter sollte eine erkennbare Population repräsentieren, keine bequeme Restekategorie. Dokumentieren Sie pro Eintrag Zweck, verantwortliches Team, erwartete Claims und das Datum der nächsten Überprüfung. Das klingt trocken, spart aber Stunden, wenn ein Zugriff plötzlich nicht mehr funktioniert.

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellflux_2; model=pro; resolution=1k; aspect_ratio=16:9; web derivative 1200x675PromptAt midday in a bright coworking meeting room, four platform engineers representing employees, contractors, and automation teams place distinct blank color-coded access tokens around one shared unlabeled cluster map on a round table, with natural office objects and no technical lab equipment. A documentary composition emphasizes practical consequences; every surface is blank and unbranded, with no readable text, words, numbers, labels, logos, screens, user interfaces, dashboards, or signs. Photorealistic style image. Mood: practical, focused, and investigative. Avoid: watermark, signature, blurry, low quality, distorted, deformed.

IAM läuft neben OIDC weiter

Die bestehende IAM-Authentifizierung bleibt neben jedem konfigurierten OIDC-Anbieter aktiv. AWS nimmt Teams damit nicht den bisherigen Zugang weg und erzwingt keine komplette Umstellung. Das ist wichtig für Cluster, in denen Administration und Automatisierung noch über etablierte IAM-Pfade laufen. Niemand muss den alten Weg in einer Nacht abschalten, nur weil ein neuer OIDC-Anbieter hinzugekommen ist. Die parallele Nutzung erlaubt einen kontrollierten Übergang, sofern die beiden Pfade im Berechtigungsmodell sichtbar bleiben.

Parallelbetrieb ist allerdings kein Freifahrtschein für doppelte Privilegien. Wenn dieselbe Person über IAM und über einen externen Anbieter in den Cluster gelangt, müssen beide Wege vergleichbare Rechte oder klar dokumentierte Abweichungen haben. Sonst wird eine Sperre am IdP durch einen alten IAM-Zugang ausgehebelt. Ein belastbarer Testfall lautet daher nicht nur: Kann sich die neue Gruppe anmelden? Er lautet auch: Ist ein entzogenes Konto über keinen verbleibenden Pfad mehr berechtigt? Diese Gegenprobe gehört in jede Änderung.

Die Umstellung darf klein anfangen. Binden Sie zuerst eine klar abgegrenzte Population an, prüfen Sie erfolgreiche und abgelehnte Anmeldungen und vergleichen Sie die resultierenden Kubernetes-Identitäten mit dem Soll. Danach kommt die nächste Gruppe. Dieser Ablauf ist weniger spektakulär als ein Komplettumbau, aber er erzeugt verwertbare Logs und eine Rückfalloption. AWS verspricht mit der Funktion Kompatibilität zum bestehenden IAM-Zugang; die konkrete Ordnung der Rechte bleibt Ihre Arbeit.

Die API bleibt der bekannte Verwaltungspfad

AWS führt die neuen Anbieter über denselben Verwaltungspfad ein wie bisher: über die AWS Management Console oder die AssociateIdentityProviderConfig-API, nutzbar mit AWS CLI und SDKs. Für Teams, die Infrastruktur deklarativ verwalten, ist das wichtiger als eine neue Schaltfläche. Ein zusätzlicher Anbieter muss in dieselben Reviews, Variablen und Löschpfade passen wie der erste. Wer die Einstellungen nur in der Konsole anklickt, kann sie zwar schnell anlegen, verliert aber leicht die Übersicht über Redirect-URLs, Issuer und Zuordnungen.

Behandeln Sie jeden Anbieter als eigenes Infrastrukturobjekt. Halten Sie die Konfiguration versioniert, trennen Sie Geheimnisse von der Definition und legen Sie fest, welches Team Änderungen freigibt. Die API macht die Funktion nicht automatisch reproduzierbar; sie ermöglicht es nur. Besonders beim Löschen ist ein sauberer Ablauf wichtig: erst Zugriffe der betroffenen Gruppe prüfen, dann die Zuordnung entfernen, anschließend den Anbieter löschen. Andernfalls entsteht ein Fehlerbild, bei dem sich Nutzer noch authentifizieren können, aber keinen sinnvollen Zugriff mehr erhalten.

AWS gibt für die Fähigkeit keine zusätzlichen Kosten an und nennt alle Regionen, in denen Amazon EKS verfügbar ist. Das sagt nichts über den Aufwand aus, den ein zusätzlicher IdP im Betrieb verursacht. Lizenzkosten des Anbieters, Supportverträge und Zeit für Audits bleiben außerhalb dieser Aussage. Rechnen Sie daher nicht mit einem pauschalen Sparversprechen. Vergleichen Sie stattdessen den Wartungsaufwand eines Vermittlers mit den dauerhaft gepflegten Einzelanbindungen. Das Ergebnis wird je nach vorhandener Identitätslandschaft unterschiedlich ausfallen. Ein sinnvoller Kostenvergleich erfasst deshalb nicht nur die AWS-Position. Er zählt auch die Pflege von Zertifikaten, die Verfügbarkeit eines Vermittlers, die Anzahl manueller Ausnahmen und die Zeit, die ein Onboarding tatsächlich braucht. Wenn die direkte Anbindung diese Posten senkt, ist das ein belastbarer Nutzen. Wenn sie zusätzliche Sonderregeln erzeugt, bleibt der Broker möglicherweise die stabilere Wahl. Die neue EKS-Funktion liefert Optionen, aber keine fertige Betriebsentscheidung.

Ein Rollout ohne Identitätsbroker braucht Disziplin

Ein zwischengeschalteter Identitätsbroker kann künftig entbehrlich werden, wenn er ausschließlich mehrere Anbieter vor EKS zusammengeführt hat. AWS erlaubt die direkte Zuordnung jedes Anbieters zum Cluster. Damit verschwindet aber nicht jede Berechtigung für einen Broker. Manche Installationen nutzen ihn für eigene Regeln, Protokolltransformationen oder zentrale Compliance-Vorgaben. Entfernen Sie ihn deshalb nicht aus Reflex. Schreiben Sie erst auf, welche Funktion er heute tatsächlich erfüllt und welche davon die EKS-Anbindung abdeckt.

Ein brauchbarer Rollout beginnt mit einem Inventar der bestehenden Loginwege. Ordnen Sie jedem Weg eine Population, einen Eigentümer, ein Ablaufdatum für externe Zugänge und die erwartete Kubernetes-Gruppe zu. Fügen Sie dann einen Anbieter über Console, CLI oder SDK hinzu und testen Sie mit einem Konto, das nur die kleinste erforderliche Rolle besitzt. Wiederholen Sie den Test nach Entzug der Gruppenmitgliedschaft. Erst wenn Anmeldung, Ablehnung und Auditspur plausibel sind, lohnt sich die nächste Migration. Das ist Terminalpraxis, keine Folklore. Halten Sie auch fest, welche Logs den Aussteller, die zugeordnete Gruppe und die abgelehnte Anfrage sichtbar machen. Ohne diese drei Spuren wird ein späteres Berechtigungsproblem zur Suche in mehreren Systemen. Mit ihnen kann das zuständige Team die Ursache auf Anbieter, Claim oder Kubernetes-Zuordnung eingrenzen und Änderungen wieder zurücknehmen, ohne den Cluster für alle Nutzer zu öffnen.

Auch die zweite interne Perspektive ist nützlich: Der Beitrag zu OpenAIs Entwicklerneuigkeiten zeigt, wie schnell neue technische Schnittstellen in bestehende Abläufe rutschen können. Für Amazon EKS OIDC sollte der Maßstab enger sein. AWS hat die Obergrenze von zehn Anbietern, die unabhängige Verwaltung, den Parallelbetrieb mit IAM und die bekannten Konfigurationswege dokumentiert. Daraus folgt ein klarer Auftrag: Anbieter nach Populationen schneiden, Rechte klein halten und jeden Zugang so testen, dass sein Entzug ebenso sicher funktioniert wie seine Einrichtung.