**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 die AWS Nutzung von Kubernetes-Dienstkonten gewähren [Verwaltung von Servicekonten](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin)[IAM-Rollen für Servicekonten](iam-roles-for-service-accounts.md)[Erfahren Sie, wie EKS Pod Identity Pods Zugriff auf AWS-Services gewährt](pod-identities.md) ## Servicekonto-Tokens Die [BoundServiceAccountTokenVolume](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-token-volume)Funktion 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](https://kubernetes.io/docs/reference/using-api/client-libraries/) 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 später + 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, 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](control-plane-logs.md) aktiviert ist, dann befinden sich die Anmerkungen in den Überwachungsprotokollen. Sie können die folgende [CloudWatch Logs Insights-Abfrage](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) 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. + Amazon-VPC-CNI-Plugin für Kubernetes und Metrik-Hilfs-Plugins Version `1.8.0` und höher. Zum Überprüfen oder Aktualisieren Ihrer aktuellen Version siehe [Zuweisung von IPs zu Pods mit Amazon VPC CNI](managing-vpc-cni.md) und [cni-metrics-helper](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/cmd/cni-metrics-helper/README.md). + CoreDNS-Version `1.8.4` und höher. Zum Überprüfen oder Aktualisieren Ihrer aktuellen Version siehe [Verwalten von CoreDNS für DNS in Amazon-EKS-Clustern](managing-coredns.md). + AWS Load Balancer Controller-Version `2.0.0` und höher. Zum Überprüfen oder Aktualisieren Ihrer aktuellen Version siehe [Internetverkehr mit AWS Load Balancer Controller weiterleiten](aws-load-balancer-controller.md). + Eine aktuelle `kube-proxy`-Version. Zum Überprüfen oder Aktualisieren Ihrer aktuellen Version siehe [Verwaltung von `kube-proxy` in Amazon-EKS-Clustern](managing-kube-proxy.md). + AWS für Fluent Bit-Version `2.25.0` oder höher. Informationen zum Aktualisieren Ihrer aktuellen Version finden Sie unter [Veröffentlichungen](https://github.com/aws/aws-for-fluent-bit/releases) am GitHub. + Fluentd-Imageversion [1.14.6-1.2](https://hub.docker.com/r/fluent/fluentd/tags?page=1&name=v1.14.6-1.2) oder höher und Fluentd-Filter-Plugin für Kubernetes-Metadatenversion [2.11.1](https://rubygems.org/gems/fluent-plugin-kubernetes_metadata_filter/versions/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 Kubernetes-Bereitstellungsoptionen zu unterstützen, die von AWS Amazon EKS, Amazon EKS Anywhere, Red Hat OpenShift Service on und selbstverwaltete Kubernetes-Cluster auf AWS Amazon EC2 EC2-Instances unterstützt werden. 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](iam-roles-for-service-accounts.md). **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-Managementkonsole die EKS-API und die AWS CLI konfiguriert werden, und es müssen keine Maßnahmen innerhalb des Clusters in Kubernetes-Objekten ergriffen werden. 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. 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 [Erfahren Sie, wie EKS Pod Identity Pods Zugriff auf AWS-Services gewährt](pod-identities.md). ### 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. **Anmerkung** AWS empfiehlt, EKS Pod Identities zu verwenden, um Ihren Pods wann immer möglich Zugriff auf AWS Ressourcen zu gewähren. Weitere Informationen finden Sie unter [Erfahren Sie, wie EKS Pod Identity Pods Zugriff auf AWS-Services gewährt](pod-identities.md). | 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 `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-OIDC-Anbieters 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 zu verwenden, muss für jeden EKS-Cluster in IAM ein eindeutiger OpenID-Connect-Anbieter erstellt werden. IAM hat ein globales Standardlimit von 100 OIDC-Anbietern für jedes Konto. AWS 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 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. | | STS-API-Kontingentnutzung | EKS Pod Identity vereinfacht die Übermittlung von AWS Anmeldeinformationen an Ihre Pods und erfordert nicht, dass Ihr Code direkt mit dem AWS Security Token Service (STS) aufruft. Der EKS-Dienst kümmert sich um die Rollenübernahme und stellt Anmeldeinformationen für Anwendungen bereit, die mit dem AWS SDK in Ihren Pods geschrieben wurden, ohne dass Ihre Pods mit AWS STS kommunizieren oder das STS-API-Kontingent verwenden. | In IRSA verwenden Anwendungen, die mit dem AWS SDK in Ihren Pods geschrieben wurden, Token, um die `AssumeRoleWithWebIdentity` API im AWS Security Token Service (STS) aufzurufen. Abhängig von der Logik Ihres Codes im AWS SDK ist es möglich, dass Ihr Code unnötige Aufrufe an AWS STS tätigt und Drosselungsfehler erhält. | | 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 [Pods Zugriff auf AWS Ressourcen basierend auf Tags gewähren](pod-id-abac.md). | 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 und selbstverwaltete Kubernetes-Cluster auf AWS Amazon EC2 EC2-Instances verwendet werden. | | Unterstützte EKS-Versionen | Alle unterstützten EKS-Cluster-Versionen. Informationen über die jeweiligen Plattformversionen finden Sie unter [Cluster-Versionen von EKS Pod Identity](pod-identities.md#pod-id-cluster-versions). | Alle unterstützten EKS-Cluster-Versionen. |