Unterstützung für die Verbesserung dieser Seite beitragen

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

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

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Kubernetes-Workloads Zugriff auf AWS mithilfe von Kubernetes-Servicekonten gewähren

Verwaltung von ServicekontenIAM-Rollen für ServicekontenErfahren Sie, wie EKS Pod Identity Pods Zugriff auf AWS-Services gewährt

Servicekonto-Tokens

Das Feature BoundServiceAccountTokenVolume ist in Kubernetes-Versionen standardmäßig aktiviert. Die Funktion verbessert die Sicherheit von Servicekonto-Tokens, indem sie es auf Kubernetes ausgeführten Workloads ermöglicht, JSON-Web-Tokens, die an Zielgruppen, Zeit und Schlüssel gebunden sind, anzufordern. Die Ablaufzeit für Servicekonto-Tokens beträgt eine Stunde. In früheren Kubernetes-Versionen hatten Token kein Ablaufdatum. Clients, die diese Tokens verwenden, müssen die Tokens nun also innerhalb einer Stunde aktualisieren. Die folgenden Kubernetes-Client-SKDs aktualisieren Tokens automatisch im erforderlichen Zeitrahmen:

Wenn Ihre Workload eine frühere Client-Version verwendet, ist eine Aktualisierung erforderlich. Um Clients reibungslos zu neueren zeitlich begrenzten Servicekonto-Tokens zu migrieren, fügt Kubernetes eine verlängerte Ablaufzeit für Servicekonto-Tokens, welche die standardmäßige Stunde übersteigt. Für Amazon-EKS-Cluster gilt eine verlängerte Ablaufzeit von 90 Tagen. Der Kubernetes-API-Server Ihres Amazon-EKS-Clusters lehnt Anfragen mit Token ab, die älter als 90 Tage sind. Sie sollten Ihre Anwendungen und ihre Abhängigkeiten überprüfen, um sicherzustellen, dass die Kubernetes-Client-SDKs mit den zuvor aufgeführten Versionen identisch oder höher sind.

Wenn der API-Server Anfragen mit Token erhält, die älter als eine Stunde sind, kommentiert er das Audit-Protokollereignis der API mit annotations.authentication.k8s.io/stale-token. Die Anmerkung sieht zum Beispiel wie folgt aus:

subject: system:serviceaccount:common:fluent-bit, seconds after warning threshold: 4185802.

Wenn für Ihren Cluster die Steuerebenen-Protokollierung aktiviert ist, dann befinden sich die Anmerkungen in den Überwachungsprotokollen. Sie können die folgende Abfrage mit CloudWatch Logs Insights verwenden, um alle Pods in Ihrem Amazon-EKS-Cluster zu identifizieren, die veraltete Token verwenden:

fields @timestamp
|filter @logStream like /kube-apiserver-audit/
|filter @message like /seconds after warning threshold/
|parse @message "subject: *, seconds after warning threshold:*\"" as subject, elapsedtime

subject bezieht sich auf das Servicekonto, das der Pod verwendet hat. elapsedtime gibt die verstrichene Zeit (in Sekunden) nach dem Lesen des neuesten Tokens an. Die Anfragen an den API-Server werden abgelehnt, wenn elapsedtime 90 Tage (7 776 000 Sekunden) überschreitet. Sie sollten das Kubernetes-Client-SDK Ihrer Anwendungen proaktiv aktualisieren, um eine der zuvor aufgeführten Versionen zu verwenden, die das Token automatisch aktualisiert. Wenn das verwendete Servicekonto-Token fast 90 Tage erreicht hat, und Sie nicht genügend Zeit haben, Ihre Client-SDK-Versionen vor dem Ablauf des Tokens zu aktualisieren, können Sie die vorhandenen Pods beenden und neue erstellen. Dadurch wird das Servicekonto-Token erneut abgerufen, sodass Sie weitere 90 Tage Zeit haben, die SDKs Ihrer Client-Version zu aktualisieren.

Wenn der Pod Teil einer Bereitstellung ist, besteht die empfohlene Vorgehensweise zum Beenden der Pods und gleichzeitigen Aufrechterhaltung hoher Verfügbarkeit darin, mit dem folgenden Befehl eine Einführung durchzuführen. Ersetzen Sie my-deployment mit dem Namen Ihrer Bereitstellung.

kubectl rollout restart deployment/my-deployment

Cluster-Add-ons

Die folgenden Cluster-Add-Ons wurden für die Verwendung der Kubernetes-Client-SDKs aktualisiert, die Servicekonto-Token automatisch neu abrufen können. Wir empfehlen Ihnen, sicherzustellen, dass die aufgeführten Versionen oder neuere Versionen auf Ihrem Cluster installiert sind.

Gewährung von AWS Identity and Access Management für Workloads in Clustern von Amazon Elastic Kubernetes Service

Amazon EKS bietet zwei Möglichkeiten, um Workloads, die in Amazon-EKS-Clustern ausgeführt werden, Berechtigungen für AWS Identity and Access Management zu gewähren: IAM-Rollen für Servicekonten und EKS Pod Identities.

Vergleich von EKS Pod Identity und IRSA

Ganz allgemein ermöglichen es Ihnen sowohl EKS Pod Identity als auch IRSA, Anwendungen, die auf Kubernetes-Clustern ausgeführt werden, IAM-Berechtigungen zu gewähren. Sie unterscheiden sich jedoch grundlegend in ihrer Konfiguration, den unterstützten Grenzwerten und den aktivierten Features. Nachfolgend vergleichen wir einige der wichtigsten Aspekte beider Lösungen.