Konfiguration des Endpunkts des AWS-Sicherheitstoken-Service für ein Servicekonto - Amazon EKS

Unterstützung für die Verbesserung dieser Seite beitragen

Um zu diesem Benutzerhandbuch beizutragen, klicken Sie auf den Link Diese Seite auf GitHub bearbeiten, der sich im rechten Bereich jeder Seite befindet.

Konfiguration des Endpunkts des AWS-Sicherheitstoken-Service für ein Servicekonto

Wenn Sie ein Kubernetes-Servicekonto mit IAM-Rollen für Servicekonten verwenden, können Sie den Typ des AWS-Sicherheitstoken-Service-Endpunkts konfigurieren, der vom Servicekonto verwendet wird.

AWS empfiehlt die Verwendung der regionalen AWS-STS-Endpunkte statt des globalen Endpunkts. Dies reduziert die Latenz, bietet integrierte Redundanz und erhöht die Gültigkeit der Sitzungstoken. Der AWS-Sicherheitstoken-Service muss in der AWS-Region, in welcher der Pod ausgeführt wird, aktiv sein. Ihre Anwendung muss außerdem über integrierte Redundanz verfügen, um bei Ausfall des Service in der AWS-Region eine andere AWS-Region auszuwählen. Weitere Informationen finden Sie unter Verwaltung von AWS STS in einer AWS-Region im IAM-Benutzerhandbuch.

Die folgenden Beispiele verwenden alle das vom Amazon-VPC-CNI-Plugin verwendete Kubernetes-Servicekonto aws-node. Sie können die Beispielwerte durch eigene Servicekonten, Pods, Namespaces und anderen Ressourcen ersetzen.

  1. Wählen Sie einen Pod aus, der ein Servicekonto verwendet, für das Sie den Endpunkt ändern möchten. Bestimmen Sie, in welcher AWS-Region der Pod ausgeführt wird. Ersetzen Sie aws-node-6mfgv durch den Namen Ihres Pods und kube-system mit dem Namespace Ihres Pods.

    kubectl describe pod aws-node-6mfgv -n kube-system |grep Node:

    Eine Beispielausgabe sieht wie folgt aus.

    ip-192-168-79-166.us-west-2/192.168.79.166

    In der vorherigen Ausgabe wird der Pod in einem Knoten in der AWS-Region us-west-2 ausgeführt.

  2. Ermitteln Sie den Endpunkt-Typ, den das Servicekonto des Pods verwendet.

    kubectl describe pod aws-node-6mfgv -n kube-system |grep AWS_STS_REGIONAL_ENDPOINTS

    Eine Beispielausgabe sieht wie folgt aus.

    AWS_STS_REGIONAL_ENDPOINTS: regional

    Wenn der aktuelle Endpunkt global ist, dann wird global in der Ausgabe zurückgegeben. Wenn keine Ausgabe zurückgegeben wird, wird der Standard-Endpunkttyp verwendet und wurde nicht überschrieben.

  3. Wenn Ihre Cluster- oder Plattformversion dieselbe oder höher ist als die in der Tabelle aufgeführten, können Sie den von Ihrem Servicekonto verwendeten Endpunkttyp mit einem der folgenden Befehle vom Standardtyp in einen anderen Typ ändern. Ersetzen Sie aws-node durch den Namen Ihres Servicekontos und kube-system durch den Namespace Ihres Servicekontos.

    • Wenn Ihr Standard- oder aktueller Endpunkttyp global ist und Sie ihn in regional ändern möchten:

      kubectl annotate serviceaccount -n kube-system aws-node eks.amazonaws.com/sts-regional-endpoints=true

      Wenn Sie IAM-Rollen für Servicekonten verwenden, um vorsignierte S3-URLs in Ihrer Anwendung zu generieren, die in Pods-Containern ausgeführt wird, ähnelt das Format der URL für regionale Endpunkte dem folgenden Beispiel:

      https://bucket.s3.us-west-2.amazonaws.com/path?...&X-Amz-Credential=your-access-key-id/date/us-west-2/s3/aws4_request&...

    • Wenn Ihr Standard- oder aktueller Endpunkttyp regional ist und Sie ihn in global ändern möchten:

      kubectl annotate serviceaccount -n kube-system aws-node eks.amazonaws.com/sts-regional-endpoints=false

      Wenn Ihre Anwendung explizit Anfragen an globale AWS-STS-Endpunkte stellt und Sie das Standardverhalten der Verwendung regionaler Endpunkte in Amazon-EKS-Clustern nicht außer Kraft setzen, werden Anfragen mit einem Fehler fehlschlagen. Weitere Informationen finden Sie unter Pod-Container erhalten folgenden Fehler: An error occurred (SignatureDoesNotMatch) when calling the GetCallerIdentity operation: Credential should be scoped to a valid region.

      Wenn Sie IAM-Rollen für Servicekonten verwenden, um vorsignierte S3-URLs in Ihrer Anwendung zu generieren, die in Pods-Containern ausgeführt wird, entspricht das Format der URL für globale Endpunkte in etwa dem folgenden Beispiel:

      https://bucket.s3.amazonaws.com/path?...&X-Amz-Credential=your-access-key-id/date/us-west-2/s3/aws4_request&...

    Wenn Sie über eine Automatisierung verfügen, welche die vorsignierte URL in einem bestimmten Format erwartet, oder wenn Ihre Anwendung oder Downstream-Abhängigkeiten, die vorsignierte URLs verwenden, eine bestimmte AWS-Region als Ziel erwarten, nehmen Sie die notwendigen Änderungen vor, um den entsprechenden AWS-sTS-Endpunkt zu verwenden.

  4. Löschen Sie alle vorhandenen Pods, die dem Servicekonto zugeordnet sind, und erstellen Sie sie neu, um die Umgebungsvariablen für Anmeldeinformationen anzuwenden. Der mutierende Webhook wendet sie nicht auf Pods an, die bereits ausgeführt werden. Sie können Pods, kube-system, und-l k8s-app=aws-Knoten mit den Informationen für die Pods, für die Sie Ihre Annotation festlegen, ersetzen.

    kubectl delete Pods -n kube-system -l k8s-app=aws-node

  5. Bestätigen Sie, dass alle Pods neu gestartet wurden.

    kubectl get Pods -n kube-system -l k8s-app=aws-node

  6. Zeigen Sie die Umgebungsvariablen für einen der Pods an. Stellen Sie sicher, dass der AWS_STS_REGIONAL_ENDPOINTS-Wert der ist, den Sie im vorherigen Schritt festgelegt haben.

    kubectl describe pod aws-node-kzbtr -n kube-system |grep AWS_STS_REGIONAL_ENDPOINTS

    Eine Beispielausgabe sieht wie folgt aus.

    AWS_STS_REGIONAL_ENDPOINTS=regional