Kubernetes-Workloads Zugriff auf die AWS Nutzung von Kubernetes-Dienstkonten gewähren - Amazon EKS

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 die AWS Nutzung von Kubernetes-Dienstkonten gewähren

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. Die folgenden Kubernetes-Clients SDKs aktualisieren die Token automatisch innerhalb des erforderlichen Zeitrahmens:

  • 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 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 in Ihrem Cluster die Protokollierung auf der Protokolle der Kontrollebene an CloudWatch Logs senden Kontrollebene aktiviert ist, befinden sich die Anmerkungen in den Auditprotokollen. 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 my-deployment mit dem Namen Ihrer Bereitstellung.

kubectl rollout restart deployment/my-deployment

Cluster-Add-ons

Die folgenden Cluster-Add-Ons wurden aktualisiert, um das zu verwenden 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 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 EKS Amazon-Clustern ausgeführt werden: IAMRollen für Dienstkonten und EKSPod-Identitäten.

IAMRollen für Dienstkonten

IAMroles for service accounts (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 EKS Amazon-Cluster ausführen und sicherstellen, dass jede Anwendung nur über die Mindestberechtigungen verfügt, die sie benötigt. IRSAwurde gebaut, um verschiedene zu unterstützen Kubernetes Bereitstellungsoptionen, die AWS von AmazonEKS, Amazon EKS Anywhere, Red Hat OpenShift Service on und AWS Self-Managed unterstützt werden Kubernetes Cluster auf EC2 Amazon-Instances. IRSAEs wurde also mit grundlegenden AWS Diensten wie IAM erstellt und war nicht direkt vom EKS Amazon-Service und dem EKS API abhängig. Weitere Informationen finden Sie unter IAM-Rollen für Servicekonten.

EKSPod-Identitäten

EKSPod 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. EKSPod Identity dient EKS nur dazu und vereinfacht daher die Konfiguration von Kubernetes-Anwendungen für den Erhalt von Berechtigungen durch Clusteradministratoren. IAM Diese Berechtigungen können jetzt einfach mit weniger Schritten direkt über AWS Management Console, und konfiguriert werden EKS API AWS CLI, und es müssen keinerlei Maßnahmen innerhalb des Clusters ergriffen werden Kubernetes Objekte. Clusteradministratoren müssen nicht zwischen den IAM Diensten EKS und wechseln oder privilegierte IAM Operationen verwenden, um die für Ihre Anwendungen erforderlichen Berechtigungen zu konfigurieren. IAMRollen können jetzt in mehreren Clustern verwendet werden, ohne dass die Rollenvertrauensrichtlinie bei der Erstellung neuer Cluster aktualisiert werden muss. IAMZu den von EKS Pod Identity bereitgestellten Anmeldeinformationen gehören Rollensitzungs-Tags mit Attributen wie Clustername, Namespace und Dienstkontoname. 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öglichen. Weitere Informationen finden Sie unter Erfahre wie EKS Pod Identity gewährt Pods Zugriff auf AWS Dienste.

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.

Attribut EKSPod-Identität IRSA

Erweiterbarkeit von Rollen

Sie müssen jede Rolle einmal einrichten, um Vertrauen mit dem neu eingeführten Amazon EKS Service Principal aufzubauen. pods.eks.amazonaws.com Nach diesem einmaligen Schritt müssen Sie die Vertrauensrichtlinie der Rolle nicht jedes Mal aktualisieren, wenn sie in einem neuen Cluster verwendet wird.

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

EKSFür Pod Identity müssen Benutzer den IAM OIDC Anbieter nicht einrichten, daher gilt dieses Limit nicht.

Jeder EKS Cluster hat einen OpenID Connect (OIDC) Damit URL verbundener Emittent. Zu verwendenIRSA, ein Unikat OpenID Connect Ein Anbieter muss für jeden EKS Cluster in erstellt werdenIAM. IAMhat ein globales Standardlimit von 100 OIDC Anbieter für jedes AWS Konto. Wenn Sie planen, für jedes AWS Konto mehr als 100 EKS Cluster zu habenIRSA, dann erreichen Sie IAM OIDC Anbieterlimit.

Skalierbarkeit von Rollen

EKSBei Pod Identity müssen Benutzer in der Vertrauensrichtlinie keine Vertrauensbeziehung zwischen IAM Rolle und 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 2048. Das bedeutet, dass Sie in der Regel vier Vertrauensbeziehungen in einer Vertrauensrichtlinie definieren können. Sie können zwar das Limit für die maximale Größe der Vertrauensrichtlinie erhöhen, sind jedoch in der Regel auf maximal acht Vertrauensbeziehungen innerhalb einer Vertrauensrichtlinie beschränkt.

Wiederverwendbarkeit von Rollen

AWS STSZu den von EKS Pod Identity bereitgestellten temporären Anmeldeinformationen 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 und 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 attributebasierte Zugriffskontrolle () bezeichnet. ABAC 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

EKSPod Identity ist nur bei Amazon erhältlichEKS.

IRSAkann wie AmazonEKS, Amazon EKS Anywhere, Red Hat OpenShift Service on AWS verwendet und selbst verwaltet werden Kubernetes Cluster auf EC2 Amazon-Instances.

EKSunterstützte Versionen

EKS Kubernetes Versionen 1.24 oder später. Informationen über die jeweiligen Plattformversionen finden Sie unter EKSPod Identity-Cluster-Versionen.

Alle unterstützten EKS Cluster-Versionen.