Kubernetes-Servicekonten - Amazon EKS
Servicekonto-TokensCluster-Add-onsIAM-Anmeldeinformationen für Pods

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-Servicekonten

Ein Kubernetes-Servicekonto stellt eine Identität für Prozesse bereit, die in einem Pod ausgeführt werden. Weitere Informationen finden Sie unter Managing Service Accounts (Servicekonten verwalten) in der Kubernetes-Dokumentation. Wenn Ihr Zugriff auf - AWS Services Pod benötigt, können Sie das Servicekonto 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

Das BoundServiceAccountTokenVolume-Feature ist in Kubernetes-Versionen standardmäßig aktiviert. Dieses Feature 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:

  • 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 höher

  • Ruby master-Branch

  • Haskell-Version 0.3.0.0

  • C#-Version 7.0.5 und höher

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, die 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 CloudWatch Logs-Insights-Abfrage 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 die Kubernetes-Client-SDKs Ihrer Anwendungen proaktiv auf eine der zuvor aufgeführten Versionen aktualisieren, die das Token automatisch aktualisieren. Wenn das verwendete Servicekonto-Token fast 90 Tage erreicht hat, und Sie nicht genügend Zeit haben, Ihre Client-SDK-Versionen vor 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 ein Rollout 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.

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

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

IAM-Rollen für Servicekonten

IAM-Rollen für Servicekonten (IRSA) konfiguriert Kubernetes-Anwendungen, die auf ausgeführt werden, AWS mit detaillierten IAM-Berechtigungen für den Zugriff auf verschiedene andere AWS Ressourcen wie Amazon 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 Kubernetes Bereitstellungsoptionen zu unterstützen Red Hat OpenShift Service in AWS, die von unterstützt werden, AWS z. B. Amazon EKS, Amazon EKS Anywhere und selbstverwaltete Kubernetes Cluster auf Amazon EC2. Daher wurde IRSA mit grundlegenden AWS Services wie IAM erstellt und hat keine direkte Abhängigkeit vom Amazon-EKS-Service und der EKS-API angenommen. Weitere Informationen finden Sie unter IAM-Rollen für Servicekonten.

EKS-Pod-Identitäten

EKS Pod Identity bietet Clusteradministratoren einen vereinfachten Workflow für die Authentifizierung von Anwendungen, um auf verschiedene andere AWS Ressourcen wie Amazon S3-Buckets, Amazon-DynamoDB-Tabellen und mehr zuzugreifen. 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 konfiguriert werden AWS CLI, und es gibt keine Maßnahmen innerhalb des Clusters in Kubernetes Objekten. Cluster-Administratoren müssen nicht zwischen den EKS- und IAM-Services 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. Rollensitzungs-Tags ermöglichen es Administratoren, eine einzelne Rolle zu erstellen, die über Servicekonten hinweg arbeiten kann, indem sie den Zugriff auf AWS Ressourcen basierend auf übereinstimmenden Tags ermöglichen. Weitere Informationen finden Sie unter EKS-Pod-Identitäten.

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 der beiden Lösungen.

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 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 jedes Mal mit dem neuen Endpunkt des EKS-Cluster–OIDCAnbieters aktualisieren, wenn Sie die Rolle in einem neuen Cluster verwenden möchten.

Skalierbarkeit von Clustern

Bei EKS Pod Identity müssen Benutzer keinen IAM-OIDC-Anbieter einrichten, dieses Limit gilt also nicht.

Jedem EKS-Cluster ist eine OpenID Connect (OIDC)-Aussteller-URL zugeordnet. Um IRSA verwenden zu können, muss für jeden EKS-Cluster in IAM ein eigener OpenID Connect-Anbieter erstellt werden. IAM hat ein globales Standardlimit von jeweils 100 OIDC-Anbietern pro AWS-Konto. Wenn Sie mehr als 100 EKS-Cluster für jeden AWS-Konto mit IRSA haben möchten, erreichen Sie das IAM-OIDCAnbieterlimit.

Skalierbarkeit von Rollen

Bei EKS Pod Identity müssen Benutzer in der Vertrauensrichtlinie keine Vertrauensbeziehung zwischen der IAM-Rolle und dem Servicekonto definieren, dieses Limit gilt also nicht.

In IRSA muss die Vertrauensbeziehung zwischen einer IAM-Rolle und einem Servicekonto in der Vertrauensrichtlinie der Rolle definiert werden. 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 STS Zu den von EKS Pod Identity bereitgestellten temporären Anmeldeinformationen gehören Rollensitzungs-Tags wie Clustername, Namespace, Name des Servicekontos. Mithilfe von Rollensitzungs-Tags können Administratoren eine einzelne IAM-Rolle erstellen, die von mehreren Servicekonten mit unterschiedlichen effektiven Berechtigungen verwendet werden kann, indem auf Grundlage der ihnen zugewiesenen Tags Zugriff auf AWS -Ressourcen ermöglicht wird. Dies wird auch als attributbasierte Zugriffskontrolle (ABAC) bezeichnet. Weitere Informationen finden Sie unter Definieren von Berechtigungen für EKS-Pod-Identitäten, um Rollen basierend auf Tags anzunehmen.

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 in AWS und selbstverwaltete Kubernetes Cluster auf Amazon EC2 verwendet werden.

Unterstützte EKS-Versionen

EKS Kubernetes-Versionen 1.24 oder höher. Informationen über die jeweiligen Plattformversionen finden Sie unter Cluster-Versionen von EKS Pod Identity.

Alle unterstützten EKS-Cluster-Versionen.