Wie verwende ich IRSA in Amazon EKS, um den Zugriff auf einen Amazon S3-Bucket einzuschränken?

Behebung

Hinweis: Wenn du beim Ausführen von AWS Command Line Interface (AWS CLI)-Befehlen Fehlermeldungen erhältst, findest du weitere Informationen dazu unter Problembehandlung bei der AWS CLI. Stelle außerdem sicher, dass du die neueste Version von AWS CLI verwendest.

Voraussetzungen: Erstelle einen IAM OpenID Connect (OIDC)-Anbieter für den Cluster.

Eine IAM-Richtlinie und Rolle erstellen

Führe die folgenden Schritte aus:

1. Erstelle eine JSON-Datei namens iam-policy.json. Beispiel für eine Richtlinie:

   {    
       "Version": "2012-10-17",
       "Statement": [
           {
               "Effect": "Allow",
               "Action": [
                   "s3:ListBucket"
               ],
               "Resource": "arn:aws:s3:::YOUR_BUCKET"
           },
           {
               "Sid": "List",
               "Effect": "Allow",
               "Action": [
                   "s3:GetObject",
                   "s3:GetObjectVersion"
               ],
               "Resource": "arn:aws:s3:::YOUR_BUCKET/*"
           }
       ]
   }

   Hinweis: Ersetze YOUR_BUCKET durch den S3-Bucket-Namen. Die vorstehende Beispielrichtlinie schränkt die Amazon S3-Berechtigungen ein, sodass IAM-Benutzer nur Objekte aus einem S3-Bucket auflisten und abrufen können.
2. Um die IAM-Richtlinie zu erstellen, führe den folgenden AWS-CLI-Befehl create-policy aus:

   aws iam create-policy \
       --policy-name YOUR_IAM_POLICY_NAME \
       --policy-document file://iam-policy.json

   Hinweis: Ersetze YOUR_IAM_POLICY_NAME durch den Richtliniennamen.
3. Erstelle eine IAM-Rolle und verknüpfe sie mit dem Cluster-Service-AWS-Konto.
4. Vergewissere dich, dass du die IAM-Richtlinie und -Rolle richtig konfiguriert hast.
5. (Optional) Führe den folgenden Befehl aus, um den Rollennamen abzurufen:

   kubectl get sa SERVICE_ACCOUNT_NAME -n NAMESPACE_NAME -o yaml | grep eks.amazonaws.com/role-arn | cut -d '/' -f 3

   **Hinweis:**Ersetze SERVICE_ACCOUNT_NAME durch den Service-Kontonamen und NAMESPACE_NAME durch den Namespace-Namen.
   Beispielausgabe:

   eksctl-EKS-LAB-addon-iamserviceaccount-defau-Role1-ASA1UEXAMPLE

Einen Amazon EKS-Pod erstellen

Vergewissere dich, dass dein Pod die IAM-Rolle mit den richtigen Berechtigungen übernehmen kann. Gehe wie folgt vor, um die Anwendung in der AWS-CLI durch ein offizielles Image zu ersetzen:

1. Erstelle eine YAML-Datei namens aws-cli-pod.yaml. Beispieldatei:

   apiVersion: v1
   kind: Pod
   metadata:
     name: aws-cli
     namespace: NAMESPACE_NAME
   spec:
     serviceAccountName: SERVICE_ACCOUNT_NAME
     containers:
     - name: aws-cli
       image: amazon/aws-cli:latest
       command:
         - sleep
         - "3600"
       imagePullPolicy: IfNotPresent
     restartPolicy: Always

   Hinweis: Ersetze NAMESPACE_NAME durch den Namespace und SERVICE_ACCOUNT_NAME durch den Kubernetes-Service-Kontonamen.
2. Führe den folgenden Befehl aus, um einen Amazon EKS-Pod zu erstellen:

   kubectl apply -f ./aws-cli-pod.yaml

Teste den Amazon EKS-Pod

Hinweis: Im folgenden Beispiel kann der Pod Objekte aus dem YOUR_BUCKET-S3-Bucket auflisten und abrufen.

Gehe wie folgt vor, um zu bestätigen, dass der Pod die richtige IAM-Rolle und die richtigen Aktionen für Amazon S3 verwendet:

1. Führe den folgenden Befehl aus, um die IAM-Rolle zu finden, die die Anmeldeinformationen verwendet:

   kubectl -n NAMESPACE_NAME exec -it aws-cli -- aws sts get-caller-identity

   Hinweis: Ersetze NAMESPACE_NAME durch den Namespace-Namen.
   Beispielausgabe:

   {   
       "UserId": "AIDACKCEVSQ6C2EXAMPLE:botocore-session-123456789012",
       "Account": "123456789012",
       "Arn": "arn:aws:sts::123456789012:assumed-role/eksctl-EKS-LAB-addon-iamserviceaccount-defau-Role1-ASA1UEXAMPLE/botocore-session-123456789012"
   }

2. Stelle sicher, dass der Pod die richtigen Berechtigungen für den S3-Bucket hat.
   Führe den folgenden Befehl aus, um zu überprüfen, ob der Pod über s3:ListBuckets-Berechtigungen verfügt:

   kubectl -n NAMESPACE_NAME exec -it aws-cli -- aws s3 ls s3://YOUR_BUCKET

   Hinweis: Ersetze NAMESPACE_NAME durch den Namespace-Namen und YOUR_BUCKET durch den Bucket.
   Beispielausgabe:

   2025-03-25 22:28:06         14 hello_s3.txt

   Führe den folgenden Befehl aus, um zu überprüfen, ob der Pod über s3:getObject-Berechtigungen verfügt:

   kubectl -n NAMESPACE_NAME exec -it aws-cli -- aws s3api get-object --bucket YOUR_BUCKET --key DIR/S3_OBJECT_FILE S3_FILE_NAME_LOCAL

   Hinweis: Ersetze NAMESPACE_NAME durch den Namespace-Namen und YOUR_BUCKET durch den Bucket. Ersetze außerdem DIR/S3_OBJECT_FILE durch den Verzeichnis- und Objektdateinamen und S3_FILE_NAME_LOCAL durch das neue lokale Amazon S3-Objekt.
   Beispielausgabe:

   {
       "AcceptRanges": "bytes",
       "LastModified": "2025-03-14T01:49:38+00:00",
       "ContentLength": 19,
       "ETag": "\"678b33365329cce6cd2bb1882e62fe3a\"",
       "ContentType": "text/plain",
       "ServerSideEncryption": "AES256",
       "Metadata": {}
   }

3. Führe den folgenden Befehl aus, um zu überprüfen, ob der Pod keine s3:deleteObject-Berechtigungen hat:

   kubectl -n NAMESPACE_NAME exec -it aws-cli -- aws s3 rm s3://YOUR_BUCKET/DEMO_TEST_FILE

   Hinweis: Ersetze NAMESPACE_NAME durch den Namespace-Namen und YOUR_BUCKET durch den Bucket. Ersetze außerdem DEMO_TEST_FILE durch die Amazon S3-Objektdatei.
   Wenn der Pod keine s3:deleteObject-Berechtigungen hat, erhältst du in der Ausgabe den folgenden Fehler Zugriff verweigert:

   delete failed: s3://YOUR_BUCKET/DEMO_TEST_FILE An error occurred (AccessDenied) when calling the DeleteObject operation: User: arn:aws:sts::123456789012:assumed-role/eksctl-EKS-LAB-addon-iamserviceaccount-defau-Role1-ASA1UEXAMPLE/botocore-session-123456789012 is not authorized to perform: s3:DeleteObject on resource: "arn:aws:s3:::YOUR_BUCKET/DEMO_TEST_FILE" because no identity-based policy allows the s3:DeleteObject action
   command terminated with exit code 1

Probleme beheben

Wichtig: Erstelle immer neue Pods, nachdem du Änderungen vorgenommen hast. Amazon EKS berücksichtigt Aktualisierungen nur in neu erstellten Pods, nicht in den vorhandenen.

NoSuchBucket-Fehler

Wenn du den S3-Bucket nicht finden kannst, weil er nicht existiert, erhältst du die folgende Fehlermeldung:

„Beim Aufrufen der Operation ListObjectsV2 ist ein Fehler aufgetreten (NoSuchBucket): Der angegebene Bucket ist nicht vorhanden, der Befehl wurde mit dem Exit-Code 254 beendet“

Um dieses Problem zu beheben, stelle sicher, dass du in den Befehlen den richtigen S3-Bucket-Namen verwendest.

NoSuchKey-Fehler

Wenn du nicht von einem bestimmten S3-Bucket-Pfad herunterladen kannst, erhältst du die folgende Fehlermeldung:

„Beim Aufrufen der GetObject-Operation ist ein Fehler aufgetreten (NoSuchKey): Der angegebene Schlüssel ist nicht vorhanden.“

Um dieses Problem zu beheben, stelle sicher, dass der Amazon S3-Pfad und der Dateiname in dem AWS-Konto vorhanden sind.

AccessDenied-Fehler

Wenn du nicht berechtigt bist, eine Aktion im S3-Bucket auszuführen, erhältst du eine Fehlermeldung. Beispielsweise tritt der folgende Fehler auf, wenn du die ListObjectsV2-Aktion nicht ausführen kannst:

„Beim Aufrufen der Operation ListObjectsV2 ist ein Fehler aufgetreten (AccessDenied): User: arn:aws:sts::123456789012:assumed-role/eksctl-EKS-LAB-addon-iamserviceaccount-defau-Role1-ASA1UEXAMPLE/botocore-session-123456789012 is not authorized to perform: s3:ListBucket on resource: "arn:aws:s3:::YOUR_BUCKET" because no identity-based policy allows the s3:ListBucket action command terminated with exit code 254"

Um dieses Problem zu beheben, stelle sicher, dass du die Berechtigung zu der IAM-Rollenrichtlinie hinzugefügt hast.

Wenn im IAM-Identitätsanbieter ein Fehler auftritt, erhältst du die folgende Fehlermeldung:

„Beim Aufrufen des Vorgangs AssumeRoleWithWebIdentity ist ein Fehler aufgetreten (AccessDenied): Nicht berechtigt, den Befehl „sts:AssumeRoleWithWebIdentity“ auszuführen, der mit dem Exit-Code 254 beendet wurde"

Bestätige die folgenden Konfigurationen, um dieses Problem zu beheben:

• Der IAM-OIDC-Anbieter für den Cluster ist korrekt konfiguriert.
• Die Vertrauensbeziehung der IAM-Rollen ist korrekt konfiguriert.
• Das Service-Konto verwendet die richtige IAM-Rolle.

InvalidIdentityToken-Fehler

Wenn Amazon EKS den OIDC-Anbieter des Kontos nicht finden kann, erhältst du die folgende Fehlermeldung:

„Beim Aufrufen des Vorgangs AssumeRoleWithWebIdentity ist ein Fehler aufgetreten (InvalidIdentityToken): In dem Konto wurde kein OpenIDConnect-Anbieter für den Befehl https://oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE gefunden, der mit dem Exit-Code 254 beendet wurde"

Um dieses Problem zu beheben, stelle sicher, dass der Identitätsanbieter für den OIDC in IAM vorhanden ist.

Ähnliche Informationen

Testen von IAM-Richtlinien mit dem IAM-Richtliniensimulator

Aktionen, Ressourcen und Bedingungsschlüssel für AWS Services