Helfen Sie mit, diese Seite 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.
Möchten Sie zu diesem Benutzerhandbuch beitragen? Wählen Sie den GitHub Link Diese Seite bearbeiten auf, der sich im rechten Bereich jeder Seite befindet. Ihre Beiträge werden dazu beitragen, dass unser Benutzerhandbuch für alle besser wird.
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
Servicekonto-Tokens
Die BoundServiceAccountTokenVolume
-
Go-Version
0.15.7
und höher -
Python-Version
12.0.0
und höher -
Java-Version
9.0.0
und höher -
JavaScript Version
0.10.3
und später -
Ruby
master
-Branch -
Haskell-Version
0.3.0.0
-
C# Version
7.0.5
und später
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 eine verlängerte Ablaufzeit hinzu, die standardmäßig über eine Stunde liegt. Für Amazon-EKS-Cluster gilt eine verlängerte Ablaufzeit von 90 Tagen. Ihre Amazon EKS-Cluster Kubernetes Der API-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 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 in Ihrem Cluster die Protokollierung auf der Protokolle der Kontrollebene an CloudWatch Logs senden Kontrollebene aktiviert ist, befinden sich die Anmerkungen in den Audit-Logs. Sie können die folgende CloudWatch Logs Insights-Abfrage verwenden, um alle Pods in Ihrem Amazon EKS-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 elapsedtime
90 Tage (7 776 000 Sekunden) überschreitet. Sie sollten Ihre Anwendungen proaktiv aktualisieren Kubernetes Client-SDK, 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 Client-SDK-Versionen vor Ablauf des Tokens zu aktualisieren, können Sie das bestehende beenden 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 Kubernetes Client SDKs , der Dienstkonto-Tokens automatisch erneut abruft. Wir empfehlen Ihnen, sicherzustellen, dass die aufgeführten Versionen oder neuere Versionen auf Ihrem Cluster installiert sind.
-
Amazon VPC CNI plugin for Kubernetes Version
1.8.0
und höher der Metrics Helper-Plugins. Zum Überprüfen oder Aktualisieren Ihrer aktuellen Version siehe Zuweisen IPs zu Pods mit dem Amazon VPC CNI und cni-metrics-helper. -
CoreDNS Version
1.8.4
und später. Zum Überprüfen oder Aktualisieren Ihrer aktuellen Version siehe CoreDNS für DNS in Amazon EKS-Clustern verwalten. -
AWS Load Balancer Controller Version
2.0.0
und später. Zum Überprüfen oder Aktualisieren Ihrer aktuellen Version siehe Internetverkehr mit dem AWS Load Balancer Controller weiterleiten. -
Eine aktuelle
kube-proxy
-Version. Zum Überprüfen oder Aktualisieren Ihrer aktuellen Version siehe kube-proxyIn Amazon EKS-Clustern verwalten. -
AWS für Fluent Bit-Version
2.25.0
oder später. Informationen zum Aktualisieren Ihrer aktuellen Version finden Sie unter Veröffentlichungenauf GitHub. -
Fluentd-Imageversion 1.14.6-1.2
oder höher und Fluentd-Filter-Plugin für Kubernetes-Metadatenversion 2.11.1 oder höher.
Erteilen von AWS Identity and Access Management Zugriffsverwaltungsberechtigungen für Workloads auf Amazon Elastic Kubernetes Service Service-Clustern
Amazon EKS bietet zwei Möglichkeiten, AWS Identity and Access Management Zugriffsverwaltungsberechtigungen für Workloads zu gewähren, die in Amazon EKS-Clustern ausgeführt werden: IAM-Rollen für Dienstkonten und EKS-Pod-Identitäten.
- IAM-Rollen für Servicekonten
-
IAM-Rollen für Dienstkonten (IRSA) konfiguriert Kubernetes-Anwendungen, auf denen sie ausgeführt werden, AWS mit detaillierten IAM-Berechtigungen für den Zugriff auf verschiedene andere AWS Ressourcen wie Amazon S3 S3-Buckets, Amazon DynamoDB-Tabellen und mehr. Sie können mehrere Anwendungen zusammen in demselben Amazon EKS-Cluster ausführen und sicherstellen, dass jede Anwendung nur über die erforderlichen Mindestberechtigungen verfügt. IRSA wurde entwickelt, um verschiedene zu unterstützen Kubernetes Bereitstellungsoptionen, die AWS von Amazon EKS, Amazon EKS Anywhere, Red Hat OpenShift Service on AWS unterstützt und selbst verwaltet werden Kubernetes Cluster auf EC2 Amazon-Instances. Daher wurde IRSA mithilfe grundlegender AWS Dienste wie IAM erstellt und war nicht direkt vom Amazon EKS-Service und der EKS-API abhängig. Weitere Informationen finden Sie unter IAM-Rollen für Servicekonten.
- EKS-Pod-Identitäten
-
EKS Pod Identity bietet Clusteradministratoren einen vereinfachten Arbeitsablauf für die Authentifizierung von Anwendungen für den Zugriff auf verschiedene andere AWS Ressourcen wie Amazon S3 S3-Buckets, Amazon DynamoDB-Tabellen und mehr. EKS Pod Identity ist nur für EKS vorgesehen und vereinfacht Cluster-Administratoren so die Konfiguration von Kubernetes-Anwendungen, um IAM-Berechtigungen zu erhalten. Diese Berechtigungen können jetzt einfach mit weniger Schritten direkt über AWS Management Console die EKS-API und die AWS CLI konfiguriert werden, und es müssen keinerlei Maßnahmen innerhalb des Clusters ergriffen werden Kubernetes Objekte. Clusteradministratoren müssen nicht zwischen den EKS- und IAM-Diensten wechseln oder privilegierte IAM-Operationen verwenden, um die für Ihre Anwendungen erforderlichen Berechtigungen zu konfigurieren. IAM-Rollen können jetzt in mehreren Clustern verwendet werden, ohne dass bei der Erstellung neuer Cluster die Rollenvertrauensrichtlinie aktualisiert werden muss. Die von EKS Pod Identity bereitgestellten IAM-Anmeldeinformationen umfassen Rollensitzungs-Tags mit Attributen wie Cluster-Name, Namespace und dem Namen des Servicekontos. Mithilfe von Rollensitzungs-Tags können Administratoren eine einzelne Rolle erstellen, die für alle Dienstkonten verwendet werden kann, indem sie den Zugriff auf AWS Ressourcen auf der Grundlage übereinstimmender Tags ermöglicht. Weitere Informationen finden Sie unter Erfahre wie EKS Pod Identity gewährt Pods Zugriff auf AWS Dienste.
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. Im Folgenden vergleichen wir einige der wichtigsten Aspekte beider Lösungen.
Attribut | EKS Pod Identity | IRSA |
---|---|---|
Erweiterbarkeit von Rollen |
Sie müssen jede Rolle einmal einrichten, um das Vertrauen des neu eingeführten Amazon EKS-Service-Prinzipal zu erhalten |
Sie müssen die Vertrauensrichtlinie der IAM-Rolle mit dem neuen EKS-Cluster aktualisieren OIDC Anbieter-Endpunkt jedes Mal, wenn Sie die Rolle in einem neuen Cluster verwenden möchten. |
Skalierbarkeit von Clustern |
Bei EKS Pod Identity müssen Benutzer den IAM-OIDC-Anbieter nicht einrichten, sodass dieses Limit nicht gilt. |
Jeder EKS-Cluster hat einen OpenID Connect (OIDC) Damit ist die URL des Ausstellers verknüpft. Um IRSA zu verwenden, ist eine eindeutige OpenID Connect Ein Anbieter muss für jeden EKS-Cluster in IAM erstellt werden. IAM hat ein globales Standardlimit von 100 OIDC Anbieter für jedes AWS Konto. Wenn Sie planen, mehr als 100 EKS-Cluster für jedes AWS Konto bei IRSA einzurichten, erreichen Sie das IAM OIDC Anbieterlimit. |
Skalierbarkeit von Rollen |
Bei EKS Pod Identity müssen Benutzer in der Vertrauensrichtlinie keine Vertrauensbeziehung zwischen der IAM-Rolle und dem Dienstkonto definieren, sodass dieses Limit nicht gilt. |
In IRSA definieren Sie die Vertrauensbeziehung zwischen einer IAM-Rolle und einem Dienstkonto in der Vertrauensrichtlinie der Rolle. Standardmäßig beträgt die Größe der Vertrauensrichtlinie |
Wiederverwendbarkeit von Rollen |
AWS Zu den temporären STS-Anmeldeinformationen, die von EKS Pod Identity bereitgestellt werden, gehören Rollensitzungs-Tags wie Clustername, Namespace und Dienstkontoname. Mithilfe von Rollensitzungs-Tags können Administratoren eine einzelne IAM-Rolle erstellen, die mit mehreren Dienstkonten mit unterschiedlichen effektiven Berechtigungen verwendet werden kann, indem sie den Zugriff auf AWS Ressourcen auf der Grundlage der ihnen zugewiesenen Tags ermöglichen. Dies wird auch als attributbasierte Zugriffskontrolle (ABAC) bezeichnet. Weitere Informationen finden Sie unter Gewährung pods Zugriff auf AWS Ressourcen basierend auf Tags. |
AWS STS-Sitzungs-Tags werden nicht unterstützt. Sie können eine Rolle in verschiedenen Clustern wiederverwenden, aber jeder Pod erhält alle Berechtigungen der Rolle. |
Unterstützte Umgebungen |
EKS Pod Identity ist nur in Amazon EKS verfügbar. |
IRSA kann wie Amazon EKS, Amazon EKS Anywhere, Red Hat OpenShift Service on AWS verwendet und selbst verwaltet werden Kubernetes Cluster auf EC2 Amazon-Instances. |
Unterstützte EKS-Versionen |
EKS Kubernetes Versionen |
Alle unterstützten EKS-Cluster-Versionen. |