AWS EKS: "Your current user or role does not have access" lösen

Wer mit Amazon Elastic Kubernetes Service (EKS) arbeitet, ist vielleicht schon einmal über die Fehlermeldung "Your current user or role does not have access to Kubernetes objects on this EKS cluster" gestolpert. Diese Meldung ist erst einmal verwirrend – vor allem, wenn man als globaler Super-Admin plötzlich keine Rechte haben soll. In diesem Artikel erklären wir, was hinter der Meldung steckt, und zeigen Schritt für Schritt, wie Sie das Problem lösen.

access

Beispiel aus der UI der AWS Console

AWS

Beispiel aus der kubectl-CLI auf einem EKS-Cluster

Das Problem verstehen

Damit Sie Kubernetes-Ressourcen in der AWS Management Console sehen können, muss der AWS-IAM-User oder die IAM-Rolle in der aws-auth``ConfigMap des EKS-Clusters gemappt sein. Dieses Mapping ist entscheidend: Wer einen EKS-Cluster anlegt, erhält mit dem zugehörigen IAM-User oder der IAM-Rolle automatisch system:masters-Rechte in der RBAC-Konfiguration (Role-Based Access Control) des Clusters. Damit lassen sich Kubernetes-Ressourcen über die EKS-Konsole einsehen und auch die aws-auth``ConfigMap innerhalb von Kubernetes bearbeiten, um weiteren AWS-Usern oder -Rollen den Zugriff auf den Cluster zu erlauben.

Der AWS-IAM-User bzw. die IAM-Rolle, die den Cluster erstellt, hat standardmäßig exklusiven Zugriff – sowohl auf die AWS Console als auch auf das kubectl-Tool. Anders als vielleicht erwartet, liegt der Grund dafür, dass in der AWS Console nichts angezeigt wird, im fehlenden Mapping zwischen Kubernetes-RBAC-Rechten und IAM in der aws-auth``ConfigMap.

So lösen Sie das Problem

Den Cluster-Ersteller identifizieren

Zunächst gilt es herauszufinden, wer den EKS-Cluster ursprünglich erstellt hat. Eine Möglichkeit führt über die Logs von AWS CloudTrail. CloudTrail zeichnet alle AWS-API-Aufrufe auf – inklusive der Aufrufe aus der AWS Management Console, den SDKs und der CLI. Ist CloudTrail in Ihrem Konto aktiviert, lässt sich also nachvollziehen, welcher User den EKS-Cluster angelegt hat.

So gehen Sie dabei vor:

Melden Sie sich an der AWS Management Console an.
Öffnen Sie CloudTrail – Sie finden den Dienst, indem Sie "CloudTrail" in die Suchleiste eingeben und ihn aus dem Dropdown auswählen.
Wählen Sie im CloudTrail-Dashboard in der Seitenleiste "Event history" aus.
Auf der Seite "Event history" finden Sie oben die Filter. Setzen Sie den Filter "Event name" auf "CreateCluster" – das ist der API-Aufruf, mit dem ein neuer EKS-Cluster erstellt wird.
Wenn Sie den Namen des EKS-Clusters kennen, können Sie zusätzlich nach "Resource name" filtern und den Cluster-Namen angeben.
Nach dem Anwenden der Filter erscheint eine Liste mit "CreateCluster"-Ereignissen. Klicken Sie auf einen Eintrag, um die Details zu sehen. Im Feld "User name" steht die Identität des Users, der den EKS-Cluster erstellt hat.

Bitte beachten Sie: Dieser Weg funktioniert nur, wenn CloudTrail im AWS-Konto zum Zeitpunkt der Cluster-Erstellung aktiv war – was standardmäßig in der Regel der Fall ist. War CloudTrail damals nicht aktiv, lässt sich der Ersteller des EKS-Clusters nicht mehr ermitteln. In diesem Fall empfiehlt es sich, eine AWS-Administratorin oder einen AWS-Administrator, DevOps, SRE oder eine entsprechende Fachperson in Ihrer Organisation um Unterstützung zu bitten.

Den IAM-Identity-ARN ermitteln

Ermitteln Sie den IAM-User oder die IAM-Rolle, mit der Sie auf die Konsole zugreifen. Den IAM-Identity-ARN bekommen Sie über folgenden AWS-CLI-Befehl:

aws sts get-caller-identity --query Arn

IAM-User oder -Rolle zur aws-auth ConfigMap hinzufügen

Um Zugriff auf den EKS-Cluster zu gewähren, kann der Cluster-Ersteller einen IAM-User oder eine IAM-Rolle zur aws-auth``ConfigMap hinzufügen. So kann der User bzw. die Rolle reibungslos mit dem Cluster arbeiten. Die folgenden Beispiele zeigen, wie das mit kubectl oder eksctl funktioniert:

kubectl

Aktuelle ConfigMap abrufen:

kubectl get -n kube-system configmap/aws-auth -o yaml

Dieser Befehl gibt die aktuelle aws-auth``ConfigMap aus. Sie sollte etwa so aussehen:

apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-auth
  namespace: kube-system
data:
  mapRoles: |
    - rolearn: arn:aws:iam::11122223333:role/EKS-Worker-NodeInstanceRole-1I00GBC9U4U7B
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:bootstrappers
        - system:nodes

Um einen neuen IAM-User oder eine neue IAM-Rolle hinzuzufügen, passen Sie das YAML so an, dass der neue User oder die neue Rolle unter mapRoles oder mapUsers aufgeführt ist. So könnte das aussehen:

apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-auth
  namespace: kube-system
data:
  mapRoles: |
    - rolearn: arn:aws:iam::11122223333:role/EKS-Worker-NodeInstanceRole-1I00GBC9U4U7B
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:bootstrappers
        - system:nodes
    - rolearn: arn:aws:iam::11122223333:role/YourNewRole
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:masters
  mapUsers: |
    - userarn: arn:aws:iam::11122223333:user/YourNewUser
      username: YourNewUser
      groups:
        - system:masters

Ersetzen Sie in diesem Beispiel arn:aws:iam::11122223333:role/YourNewRole durch den ARN Ihrer neuen IAM-Rolle und arn:aws:iam::11122223333:user/YourNewUser durch den ARN Ihres neuen IAM-Users. Tauschen Sie außerdem YourNewUser gegen den Benutzernamen des neuen IAM-Users aus.

3. Wenden Sie die geänderte ConfigMap anschließend mit folgendem Befehl an:

kubectl apply -f aws-auth-configmap.yaml

Ersetzen Sie im obigen Befehl aws-auth-configmap.yaml durch den Dateinamen Ihrer angepassten ConfigMap.

eksctl

Einen IAM-User hinzufügen:

eksctl create iamidentitymapping --region region-code --cluster cluster-name --arn arn:aws:iam::11122223333:user/YourNewUser --group system:masters

Eine IAM-Rolle hinzufügen:

eksctl create iamidentitymapping --region region-code --cluster cluster-name --arn arn:aws:iam::11122223333:role/YourNewRole --group system:masters

In den obigen Beispielen gilt:

Ersetzen Sie region-code durch den AWS-Regionscode (z. B. us-west-2 ).
Ersetzen Sie cluster-name durch den Namen des EKS-Clusters.
Ersetzen Sie arn:aws:iam::11122223333:role/YourNewRole durch den ARN der neuen IAM-Rolle und arn:aws:iam::11122223333:user/YourNewUser durch den ARN des neuen IAM-Users.
Ersetzen Sie system:masters durch die passende Kubernetes-Gruppe. Details dazu finden Sie weiter unten im Abschnitt zu Kubernetes-Gruppen.

Kubernetes-Gruppen

In Kubernetes ist eine Gruppe eine Menge von Usern mit denselben Berechtigungen. Hier einige der Standardgruppen:

system:authenticated: Umfasst alle authentifizierten User.
system:unauthenticated: Umfasst alle nicht authentifizierten User.
system:masters: Diese Gruppe hat vollen Zugriff auf den Cluster und kann jede Aktion darin ausführen. Sie ist typischerweise mit Cluster-Ersteller-Rollen verknüpft.
system:serviceaccounts:<namespace>: Umfasst alle Service-Accounts im Namespace <namespace>.

Die Gruppe system:masters gewährt vollen Zugriff auf den Cluster, einschließlich der Möglichkeit, jede Ressource zu erstellen, zu lesen, zu ändern und zu löschen. Gehen Sie deshalb sorgsam damit um, wem Sie diese Gruppe zuweisen. Nur vertrauenswürdige User oder Rollen sollten Mitglied sein – und folgen Sie immer dem Prinzip der minimalen Rechtevergabe (Least Privilege). Dabei erhält ein User oder eine Rolle nur genau die Zugriffe und Berechtigungen, die für die jeweilige Aufgabe nötig sind. Das verkleinert die Angriffsfläche und reduziert das Risiko von Missbrauch oder Sicherheitsvorfällen.

Wenn Zugriffsprobleme bestehen bleiben

Falls die Probleme auch nach dem Update der aws-auth ConfigMap weiter bestehen, kann das daran liegen, dass die IAM-Policy nicht aktualisiert wurde oder Kubernetes RBAC die Änderungen nicht erkennt. Wie bereits erwähnt, sind IAM- und Kubernetes-Berechtigungen voneinander getrennt – beide müssen korrekt gesetzt sein, damit der User mit der Kubernetes-API arbeiten kann.

Hier eine Checkliste zur Fehlersuche:

Prüfen Sie, ob die aws-auth ConfigMap im Namespace kube-system korrekt aktualisiert wurde:

kubectl -n kube-system describe configmap aws-auth

In der Ausgabe sollte der IAM-User oder die IAM-Rolle unter mapRoles oder mapUsers erscheinen. Fehlt der Eintrag, wurde die ConfigMap nicht korrekt aktualisiert oder ist möglicherweise fehlerhaft. Eine fehlerhafte ConfigMap in Kubernetes wirkt wie eine gelöschte – und kann potenziell alle außer dem Cluster-Ersteller aussperren. Gehen Sie deshalb behutsam vor und prüfen Sie Ihr YAML mit Linting-Tools wie YAML Lint.

2. Verifizieren Sie den IAM-User bzw. die IAM-Rolle und stellen Sie sicher, dass genau diese auch in der aws-auth``ConfigMap hinterlegt ist. Tippfehler im IAM-User- oder -Rollen-ARN sind ein häufiges Problem.

3. Stellen Sie sicher, dass der IAM-User oder die IAM-Rolle die nötigen AWS-Berechtigungen hat. Prüfen Sie dazu die zugewiesenen IAM-Policies. Wenn Sie EKS-Cluster und Nodes verwalten möchten, vergeben die Policies AmazonEKSClusterPolicy und AmazonEKSWorkerNodePolicy die nötigen Rechte. Details finden Sie im Leitfaden AWS managed policies for Amazon Elastic Kubernetes Service.

Sie können auch eine eigene IAM-Policy erstellen, die Read-only-Berechtigungen für die Aktionen eks:Describe* und eks:List* umfasst, sodass der User oder die Rolle Informationen zu EKS-Ressourcen einsehen kann.

4. Stellen Sie sicher, dass der Kubernetes-User und die Gruppen, auf die die IAM-Identität gemappt ist, in Kubernetes über die nötigen Berechtigungen verfügen. Orientieren Sie sich dazu am User Guide zu Kubernetes-RBAC-Rollen und -Bindings.

Halten Sie sich beim Vergeben von Rechten – sowohl in AWS als auch in Kubernetes – stets an das Least-Privilege-Prinzip. Vergeben Sie nur die Berechtigungen, die der User oder die Rolle für die jeweiligen Aufgaben tatsächlich braucht.

Wichtig: Wird die aws-auth ConfigMap entfernt, enthält sie Syntaxfehler oder ist sie falsch formatiert, verlieren alle User außer dem Cluster-Ersteller den Zugriff. Nur der Cluster-Ersteller kann diese Situation dann noch korrigieren.

Die Welt der AWS-EKS-Fehler ist komplex, und der Weg dort durch kann durchaus herausfordernd sein – mit der richtigen Mischung aus Wissen, passenden Tools und praktischer Erfahrung lassen sich diese Hürden aber gut meistern. Das Zusammenspiel zwischen IAM- und Kubernetes-Identitäten zu verstehen, ist dabei ein zentrales Puzzleteil – ebenso wie der souveräne Umgang mit der aws-auth ConfigMap. Wir hoffen, dieser Leitfaden ist eine nützliche Ressource für Sie – egal, ob Sie ein erfahrener EKS-Profi sind oder gerade erst auf der Plattform starten.