Hilf mit, diese Seite zu verbessern

Möchten Sie zu diesem Benutzerhandbuch beitragen? Scrollen Sie zum Ende dieser Seite und wählen Sie Diese Seite bearbeiten am aus GitHub. Ihre Beiträge werden dazu beitragen, unser Benutzerhandbuch für alle zu verbessern.

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.

Gewähren Sie Kubernetes-Workloads Zugriff auf die Verwendung von AWSKubernetes Dienstkonten

A Kubernetes Ein Dienstkonto bietet eine Identität für Prozesse, die in einem Pod. Weitere Informationen finden Sie unter Verwaltung von Dienstkonten im Kubernetes -Dokumentation. Wenn Ihre Pod benötigt Zugriff auf AWS Dienste. Sie können das Dienstkonto einer AWS Identity and Access Management Identität zuordnen, um diesen Zugriff zu gewähren. Weitere Informationen finden Sie unter IAM-Rollen für Servicekonten.

Servicekonto-Tokens

Die BoundServiceAccountTokenVolumeFunktion ist standardmäßig aktiviert in Kubernetes Versionen. Diese Funktion verbessert die Sicherheit von Dienstkonto-Tokens, indem sie Workloads ermöglicht, auf Kubernetes um JSON Web-Token anzufordern, die an Zielgruppen, Uhrzeit und Schlüssel gebunden sind. Die Ablaufzeit für Servicekonto-Tokens beträgt eine Stunde. Vorhin Kubernetes In den Versionen hatten die Token kein Ablaufdatum. Clients, die diese Tokens verwenden, müssen die Tokens nun also innerhalb einer Stunde aktualisieren. Das Folgende Kubernetes SDKsClient-Aktualisierungstoken automatisch innerhalb des erforderlichen Zeitrahmens:

Wenn Ihre Workload eine frühere Client-Version verwendet, ist eine Aktualisierung erforderlich. Um eine reibungslose Migration von Clients zu den neueren zeitgebundenen Dienstkonto-Tokens zu ermöglichen, Kubernetes fügt dem Dienstkonto-Token einen längeren Ablaufzeitraum hinzu, der standardmäßig über eine Stunde liegt. Für EKS Amazon-Cluster beträgt die verlängerte Ablaufzeit 90 Tage. Die Ihres EKS Amazon-Clusters Kubernetes APIDer Server lehnt Anfragen mit Tokens ab, die älter als 90 Tage sind. Wir empfehlen Ihnen, Ihre Anwendungen und deren Abhängigkeiten zu überprüfen, um sicherzustellen, dass es sich bei den Kubernetes-Clients um dieselben oder eine neuere Version als die zuvor aufgeführten Versionen SDKs handelt.

Wenn der API Server Anfragen mit Tokens empfängt, die älter als eine Stunde sind, vermerkt er das API Audit-Log-Ereignis 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 CloudWatch Logs Insights-Abfrage verwenden, um alle Pods in Ihrem EKS Amazon-Cluster, 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

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

Wenn das Symbol Pod ist Teil einer Bereitstellung, die vorgeschlagene Methode zum Beenden Pods Um die hohe Verfügbarkeit aufrechtzuerhalten, müssen Sie einen Rollout mit dem folgenden Befehl durchfü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 aktualisiert und verwenden nun das Kubernetes ClientSDKs, der Dienstkonto-Tokens automatisch erneut abruft. Wir empfehlen Ihnen, sicherzustellen, dass die aufgeführten Versionen oder neuere Versionen auf Ihrem Cluster installiert sind.

Erteilen von AWS Identity and Access Management Berechtigungen für Workloads auf Amazon Elastic Kubernetes Service Service-Clustern

Amazon EKS bietet zwei Möglichkeiten, AWS Identity and Access Management Berechtigungen für Workloads zu erteilen, die in EKS Amazon-Clustern ausgeführt werden: IAMRollen für Dienstkonten und EKSPod-Identitäten.

Vergleich von EKS Pod Identity und IRSA

Auf einer höheren Ebene IRSA ermöglichen Ihnen sowohl EKS Pod Identity als auch die Erteilung von IAM Berechtigungen für Anwendungen, die auf Kubernetes-Clustern ausgeführt werden. Sie unterscheiden sich jedoch grundlegend in ihrer Konfiguration, den unterstützten Grenzwerten und den aktivierten Features. Im Folgenden vergleichen wir einige der wichtigsten Aspekte beider Lösungen.