**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.
# Sicherheit in Amazon EKs
Cloud-Sicherheit AWS hat höchste Priorität. Als AWS Kunde profitieren Sie von einer Rechenzentrums- und Netzwerkarchitektur, die darauf ausgelegt sind, die Anforderungen der sicherheitssensibelsten Unternehmen zu erfüllen.
Sicherheit ist eine gemeinsame Verantwortung von Ihnen AWS und Ihnen. Das [Modell der geteilten Verantwortung](https://aws.amazon.com/compliance/shared-responsibility-model/) beschreibt dies als Sicherheit *der* Cloud und Sicherheit *in* der Cloud:
+ **Sicherheit der Cloud** — AWS ist verantwortlich für den Schutz der Infrastruktur, die AWS Dienste in der AWS Cloud ausführt. AWS Ist für Amazon EKS für die Kubernetes-Steuerebene verantwortlich, die die Knoten und `etcd` die Datenbank der Kontrollebene umfasst. Auditoren von Drittanbietern testen und überprüfen die Effektivität unserer Sicherheitsmaßnahmen im Rahmen der [AWS -Compliance-Programme](https://aws.amazon.com/compliance/programs/) regelmäßig. Informationen zu den Compliance-Programmen, die für Amazon EKS gelten, finden Sie unter [AWS -Services im Geltungsbereich nach Compliance-Programm](https://aws.amazon.com/compliance/services-in-scope/).
+ **Sicherheit in der Cloud** – Ihre Verantwortlichkeit umfasst die folgenden Bereiche.
+ Die Sicherheitskonfiguration der Datenebene, einschließlich der Konfiguration der Sicherheitsgruppen, die den Durchgang des Datenverkehrs aus der Amazon-EKS-Steuerebene in die VPC des Kunden zulassen.
+ Die Konfiguration der Knoten und der Container selbst.
+ Das Betriebssystem (einschließlich Aktualisierungen und Sicherheits-Patches) des Knotens
+ Andere zugehörige Anwendungssoftware:
+ Einrichten und Verwalten von Kontrollelementen für das Netzwerk (wie beispielsweise Firewall-Regeln)
+ Verwalten des Identity and Access Management auf Plattformebene, entweder mit oder zusätzlich zu IAM
+ Die Vertraulichkeit Ihrer Daten, die Anforderungen Ihres Unternehmens und geltende Gesetze und Vorschriften
Amazon EKS ist durch mehrere Compliance-Programme für regulierte und vertrauliche Anwendungen zertifiziert. Amazon EKS ist konform mit [SOC](https://aws.amazon.com/compliance/soc-faqs/), [PCI](https://aws.amazon.com/compliance/pci-dss-level-1-faqs/), [ISO](https://aws.amazon.com/compliance/iso-certified/), [FedRAMP-Moderate](https://aws.amazon.com/compliance/fedramp/), [IRAP](https://aws.amazon.com/compliance/irap/), [C5](https://aws.amazon.com/compliance/bsi-c5/), [K-ISMS](https://aws.amazon.com/compliance/k-isms/), [ENS High](https://aws.amazon.com/compliance/esquema-nacional-de-seguridad/), [OSPAR](https://aws.amazon.com/compliance/OSPAR/), [HITRUST CSF](https://aws.amazon.com/compliance/hitrust/) und ist ein [HIPAA](https://aws.amazon.com/compliance/hipaa-compliance/)-fähiger Service. Weitere Informationen finden Sie unter [Erfahren Sie, wie die Zugriffskontrolle in Amazon EKS funktioniert](cluster-auth.md).
Diese Dokumentation zeigt Ihnen, wie Sie das Modell der übergreifenden Verantwortlichkeit bei der Verwendung von Amazon EKS einsetzen können. Die folgenden Themen zeigen Ihnen, wie Sie Amazon EKS konfigurieren, um Ihre Sicherheits- und Compliance-Ziele zu erreichen. Sie erfahren auch, wie Sie andere AWS Services nutzen können, mit denen Sie Ihre Amazon EKS-Ressourcen überwachen und sichern können.
**Anmerkung**
Linux-Container bestehen aus Kontrollgruppen (Cgroups) und Namespaces, die dazu beitragen, den Zugriff eines Containers einzuschränken, aber alle Container verwenden denselben Linux-Kernel wie die Host-Amazon-Instance. EC2 Es wird dringend davon abgeraten, einen Container als Root-Benutzer (UID 0) auszuführen oder einem Container Zugriff auf Hostressourcen oder Namespaces wie das Hostnetzwerk oder den Host-PID-Namespace zu gewähren, da dies die Effektivität der von Containern bereitgestellten Isolation verringert.
**Topics**
+ [
# Amazon-EKS-Cluster mit bewährten Methoden sichern
](security-best-practices.md)
+ [
# Analyse von Schwachstellen in Amazon EKS
](configuration-vulnerability-analysis.md)
+ [
# Compliance-Validierung für Amazon-EKS-Cluster
](compliance.md)
+ [
# Sicherheitsüberlegungen für Amazon Elastic Kubernetes Service
](security-eks.md)
+ [
# Sicherheitsüberlegungen für Kubernetes
](security-k8s.md)
+ [
# Sicherheitsüberlegungen für Amazon EKS Auto Mode
](auto-security.md)
+ [
# Sicherheitsüberlegungen für EKS-Funktionen
](capabilities-security.md)
+ [
# Identitäts- und Zugriffsverwaltung für Amazon EKS
](security-iam.md)
# Amazon-EKS-Cluster mit bewährten Methoden sichern
Die bewährten Sicherheitsmethoden für Amazon EKS finden unter [Bewährte Methoden für die Sicherheit](https://docs.aws.amazon.com/eks/latest/best-practices/security.html) im *Leitfaden zu bewährten Methoden für Amazon EKS*.
# Analyse von Schwachstellen in Amazon EKS
Sicherheit ist ein wichtiger Aspekt bei der Konfiguration und Wartung von Kubernetes-Clustern und -Anwendungen. Nachfolgend finden Sie Ressourcen zur Analyse der Sicherheitskonfiguration Ihrer EKS-Cluster, Ressourcen zur Überprüfung auf Schwachstellen sowie Integrationen mit AWS-Services, die diese Analyse für Sie durchführen.
## Der Center for Internet Security (CIS)-Benchmark für Amazon EKS
Der [Kubernetes Benchmark des Center for Internet Security (CIS)](https://www.cisecurity.org/benchmark/kubernetes/) bietet Anleitungen für Amazon-EKS-Sicherheitskonfigurationen. Die Benchmark:
+ Gilt für Amazon EC2-Knoten (sowohl verwaltete als auch selbstverwaltete), bei denen Sie für die Sicherheitskonfigurationen von Kubernetes-Komponenten verantwortlich sind.
+ Bietet eine von der Community genehmigte Standardmethode, um sicherzustellen, dass Sie Ihren Kubernetes-Cluster und Ihre Knoten sicher konfiguriert haben, wenn Sie Amazon EKS verwenden.
+ Besteht aus vier Abschnitten; Protokollierungskonfiguration der Steuerebene, Knotensicherheitskonfigurationen, Richtlinien und verwaltete Services.
+ Unterstützt alle Kubernetes-Versionen, die derzeit in Amazon EKS verfügbar sind und können mit[kube-bench](https://github.com/aquasecurity/kube-bench), ein Standard-Open-Source-Tool zur Überprüfung der Konfiguration mit dem CIS-Benchmark auf Kubernetes-Clustern.
Weitere Informationen hierzu finden Sie unter[Einführung des CIS Amazon EKS Benchmark](https://aws.amazon.com/blogs/containers/introducing-cis-amazon-eks-benchmark)aus.
Eine automatisierte `aws-sample`-Pipeline zur Aktualisierung Ihrer Knotengruppe mit einer CIS-geprüften AMI finden Sie unter [EKS-optimierte AMI-Hardening-Pipeline](https://github.com/aws-samples/pipeline-for-hardening-eks-nodes-and-automating-updates).
## Amazon-EKS-Plattformversionen
Amazon-EKS-*Plattformversionen* definieren die Funktionalitäten der Cluster-Steuerebene (z. B. welche Kubernetes-API-Server-Flags aktiviert sind) sowie die aktuelle Kubernetes-Patch-Version. Neue Cluster werden mit der neuesten Plattformversion bereitgestellt. Weitere Details finden Sie unter [EKS-Plattformversionen](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html).
Sie können einen [Amazon EKS-Cluster](update-cluster.md) auf neuere Kubernetes-Versionen aktualisieren. Wenn neue Kubernetes-Versionen in Amazon EKS verfügbar werden, empfehlen wir Ihnen, Ihre Cluster proaktiv auf die neueste verfügbare Version zu aktualisieren. Weitere Informationen zu den Kubernetes-Versionen in EKS finden Sie unter [Von Amazon EKS unterstützte Versionen](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html).
## Liste der Betriebssystem-Schwachstellen
### AL2023-Schwachstellenliste
Sie können Sicherheits- oder Datenschutzereignisse für Amazon Linux 2023 im [Amazon Linux-Sicherheitszentrum](https://alas.aws.amazon.com/alas2023.html) verfolgen oder den zugehörigen [RSS-Feed](https://alas.aws.amazon.com/AL2023/alas.rss) abonnieren. Sicherheits- und Datenschutzereignisse enthalten eine Übersicht über das Problem sowie Pakete und Anweisungen zum Aktualisieren Ihrer Instances, um das Problem zu beheben.
### Schwachstellenliste für Amazon Linux 2
Sie können Sicherheits- oder Datenschutzereignisse für Amazon Linux 2 im [Amazon Linux-Sicherheitszentrum](https://alas.aws.amazon.com/alas2.html) verfolgen oder den zugehörigen [RSS-Feed](https://alas.aws.amazon.com/AL2/alas.rss) abonnieren. Sicherheits- und Datenschutzereignisse enthalten eine Übersicht über das Problem sowie Pakete und Anweisungen zum Aktualisieren Ihrer Instances, um das Problem zu beheben.
## Knoten-Erkennung mit Amazon Inspector
Mit [Amazon Inspector](https://docs.aws.amazon.com/inspector/latest/userguide/inspector_introduction.html) können Sie eine Prüfung auf nicht gewünschte Netzwerkzugänglichkeit Ihrer Arbeitsknoten und auf Schwachstellen auf diesen Amazon-EC2-Instances vornehmen.
## Cluster- und Knoten-Erkennung mit Amazon GuardDuty
Der Amazon GuardDuty-Service zur Erkennung von Bedrohungen unterstützt Sie beim Schutz Ihrer Konten, Container, Workloads und Daten in Ihrer AWS-Umgebung. Neben anderen Features bietet GuardDuty die folgenden zwei Features, die potenzielle Bedrohungen für Ihre EKS-Cluster erkennen: *EKS-Schutz* und *Laufzeit-Überwachung*.
Weitere Informationen finden Sie unter [Bedrohungen mit Amazon GuardDuty erkennen](integration-guardduty.md).
# Compliance-Validierung für Amazon-EKS-Cluster
Informationen dazu, ob ein AWS-Service im Rahmen bestimmter Compliance-Programme angeboten wird, finden Sie unter [AWS-Services im Rahmen von Compliance-Programmen](https://aws.amazon.com/compliance/services-in-scope/). Wählen Sie dazu das gewünschte Compliance-Programm aus. Allgemeine Informationen finden Sie unter [AWS-Compliance-Programme](https://aws.amazon.com/compliance/programs/).
Die Auditberichte von Drittanbietern lassen sich mit AWS Artifact herunterladen. Weitere Informationen finden Sie unter [Herunterladen von Berichten in AWS-Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html).
Ihre Verantwortung in Bezug auf die Compliance bei der Verwendung von AWS-Services ergibt sich aus der Vertraulichkeit der Daten, den Compliance-Zielen des Unternehmens sowie den einschlägigen Gesetzen und Vorschriften. AWS stellt die folgenden Ressourcen zur Sicherstellung der Compliance bereit:
+ [Compliance und Governance im Bereich Sicherheit](https://aws.amazon.com/solutions/security/security-compliance-governance/) – In diesen Anleitungen für die Lösungsimplementierung werden Überlegungen zur Architektur behandelt. Außerdem werden Schritte für die Bereitstellung von Sicherheits- und Compliance-Features beschrieben.
+ [Referenz für berechtigte HIPAA-Services](https://aws.amazon.com/compliance/hipaa-eligible-services-reference/) – Listet berechtigte HIPAA-Services auf. Nicht alle AWS-Services sind HIPAA-konform.
+ [AWS-Compliance-Ressourcen](https://aws.amazon.com/compliance/resources/) – Diese Arbeitsbücher und Leitfäden könnten für Ihre Branche und Ihren Standort interessant sein.
+ [AWS-Compliance-Leitfäden für Kunden](https://d1.awsstatic.com/whitepapers/compliance/AWS_Customer_Compliance_Guides.pdf) – Verstehen Sie das Modell der geteilten Verantwortung aus dem Blickwinkel der Einhaltung von Vorschriften. In den Leitfäden werden die bewährten Methoden zum Schutz von AWS-Services zusammengefasst und die Leitlinien den Sicherheitskontrollen in verschiedenen Frameworks (einschließlich des National Institute of Standards and Technology (NIST), des Payment Card Industry Security Standards Council (PCI) und der International Organization for Standardization (ISO)) zugeordnet.
+ [Auswertung von Ressourcen mit Regeln](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) im * AWS-Config-Entwicklerhandbuch* – Der AWS-Config-Service bewertet, wie gut Ihre Ressourcenkonfigurationen mit internen Praktiken, Branchenrichtlinien und Vorschriften übereinstimmen.
+ [AWS Security Hub](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) – Dieser AWS-Service bietet einen umfassenden Überblick über Ihren Sicherheitsstatus innerhalb von AWS. Security Hub verwendet Sicherheitskontrollen, um Ihre AWS-Ressourcen zu bewerten und Ihre Einhaltung von Sicherheitsstandards und bewährten Methoden zu überprüfen. Die Liste der unterstützten Services und Kontrollen finden Sie in der [Security-Hub-Steuerelementreferenz](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-controls-reference.html).
+ [Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/what-is-guardduty.html) – Dieser AWS-Service erkennt potenzielle Bedrohungen für Ihre AWS-Konten, Workloads, Container und Daten, indem er Ihre Umgebung auf verdächtige und böswillige Aktivitäten überwacht. GuardDuty kann Ihnen helfen, verschiedenen Compliance-Anforderungen wie PCI DSS nachzukommen, indem es die Anforderungen zur Erkennung von Eindringlingen erfüllt, die in bestimmten Compliance-Frameworks vorgeschrieben sind.
+ [AWS Audit Manager](https://docs.aws.amazon.com/audit-manager/latest/userguide/what-is.html) – Dieser AWS-Service hilft Ihnen, Ihre AWS-Nutzung kontinuierlich zu überprüfen, um zu vereinfachen, wie Sie mit Risiken umgehen und Compliance sowie Branchenstandards einhalten.
# Sicherheitsüberlegungen für Amazon Elastic Kubernetes Service
Nachfolgend finden Sie Überlegungen zur Sicherheit der Cloud, da diese Auswirkungen auf Amazon EKS haben.
**Topics**
+ [
# Infrastruktursicherheit in Amazon EKS
](infrastructure-security.md)
+ [
# Ausfallsicherheit in Amazon-EKS-Clustern verstehen
](disaster-recovery-resiliency.md)
+ [
# Serviceübergreifende Vermeidung verwirrter Stellvertreter in Amazon EKS
](cross-service-confused-deputy-prevention.md)
# Infrastruktursicherheit in Amazon EKS
Als verwalteter Service ist Amazon Elastic Kubernetes Service durch die globale Netzwerksicherheit von AWS geschützt. Informationen zu AWS-Sicherheitsservices und wie AWS die Infrastruktur schützt, finden Sie unter [AWS-Cloud-Sicherheit](https://aws.amazon.com/security/). Informationen zum Entwerfen Ihrer AWS-Umgebung anhand der bewährten Methoden für die Infrastruktursicherheit finden Sie unter [Infrastrukturschutz](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html) im *Security Pillar AWS Well‐Architected Framework*.
Sie greifen mithilfe von AWS veröffentlichten API-Aufrufe über das Netzwerk auf Amazon EKS zu. Kunden müssen Folgendes unterstützen:
+ Transport Layer Security (TLS). Wir benötigen TLS 1.2 und empfehlen TLS 1.3.
+ Verschlüsselungs-Suiten mit Perfect Forward Secrecy (PFS) wie DHE (Ephemeral Diffie-Hellman) oder ECDHE (Elliptic Curve Ephemeral Diffie-Hellman). Die meisten modernen Systeme wie Java 7 und höher unterstützen diese Modi.
Außerdem müssen Anforderungen mit einer Zugriffsschlüssel-ID und einem geheimen Zugriffsschlüssel signiert sein, der einem IAM-Prinzipal zugeordnet ist. Oder Sie können den [AWS-Sicherheitstoken-Service](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) (AWS STS) verwenden, um temporäre Sicherheitsanmeldeinformationen zum Signieren von Anfragen zu generieren.
Wenn Sie einen Amazon-EKS-Cluster erstellen, geben Sie die VPC-Subnetze an, die Ihr Cluster verwenden soll. Amazon EKS erfordert Subnetze in mindestens zwei Availability Zones. Wir empfehlen eine VPC mit öffentlichen und privaten Subnetzen, damit Kubernetes öffentliche Load Balancer in den öffentlichen Subnetzen erstellen kann, die den Datenverkehr auf Pods ausgleichen, die auf Knoten in privaten Subnetzen ausgeführt werden.
Weitere Informationen zu Überlegungen bezüglich der VPC finden Sie unter [Amazon-EKS-Netzwerkanforderungen für VPC und Subnetze](network-reqs.md).
Wenn Sie Ihre VPC und Knotengruppen mit den AWS-CloudFormation-Vorlagen erstellen, die in der schrittweisen Anleitung [Erste Schritte mit Amazon EKS](getting-started.md) bereitgestellt werden, werden die Steuerebene und die Sicherheitsgruppen des Knotens mit unseren empfohlenen Einstellungen konfiguriert.
Weitere Informationen zu Überlegungen bezüglich Sicherheitsgruppen finden Sie unter [Anforderungen der Amazon-EKS-Sicherheitsgruppe für Cluster anzeigen](sec-group-reqs.md).
Wenn Sie einen neuen Cluster erstellen, erstellt Amazon EKS einen Endpunkt für den verwalteten Kubernetes-API-Server, über den Sie mit Ihrem Cluster kommunizieren (mit Kubernetes-Verwaltungswerkzeugen wie `kubectl`). Standardmäßig ist dieser API-Server-Endpunkt öffentlich im Internet zugänglich und der Zugriff auf den API-Server wird durch eine Kombination aus AWS Identity and Access Management (IAM) und nativer Kubernetes [Role Based Access Control](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) (RBAC) gesichert.
Sie können den privaten Zugriff auf den Kubernetes-API-Server aktivieren, sodass die gesamte Kommunikation zwischen Ihren Knoten und dem API-Server innerhalb Ihrer VPC bleibt. Sie können die IP-Adressen einschränken, die über das Internet auf Ihren API-Server zugreifen können, oder den Internetzugriff auf den API-Server vollständig deaktivieren.
Weitere Informationen zum Ändern des Zugriffs auf Cluster-Endpunke finden Sie unter [Ändern des Cluster-Endpunktzugriffs](cluster-endpoint.md#modify-endpoint-access).
Sie können Kubernetes-*Netzwerkrichtlinien* mit dem Amazon VPC CNI oder Tools von Drittanbietern wie [Project Calico](https://docs.tigera.io/calico/latest/about/) implementieren. Weitere Informationen zur Verwendung von Amazon VPC CNI für Netzwerkrichtlinien finden Sie unter [Begrenzen Sie den Pod-Datenverkehr mit Kubernetes-Netzwerkrichtlinien.](cni-network-policy.md). Project Calico ist ein Open-Source-Projekt eines Drittanbieters. Weitere Informationen finden Sie in der [Dokumentation zu Project Calico](https://docs.tigera.io/calico/latest/getting-started/kubernetes/managed-public-cloud/eks/).
# Zugriff auf Amazon EKS über AWS PrivateLink
Sie können mit AWS PrivateLink eine private Verbindung zwischen Ihrer VPC und Amazon Elastic Kubernetes Service herstellen. Sie können auf Amazon EKS zugreifen, als wäre es in Ihrer VPC, ohne dass Sie ein Internet-Gateway, ein NAT-Gerät, eine VPN-Verbindung oder eine AWS-Direct-Connect-Verbindung verwenden müssen. Instances in Ihrer VPC benötigen keine öffentlichen IP-Adressen, um auf Amazon EKS zuzugreifen.
Sie stellen diese private Verbindung her, indem Sie einen Schnittstellenendpunkt erstellen, der von AWS PrivateLink unterstützt wird. Wir erstellen eine Endpunkt-Netzwerkschnittstelle in jedem Subnetz, das Sie für den Schnittstellen-Endpunkt aktivieren. Hierbei handelt es sich um vom Anforderer verwaltete Netzwerkschnittstellen, die als Eingangspunkt für den Datenverkehr dienen, der für Amazon EKS bestimmt ist.
Weitere Informationen finden Sie unter [Zugriff auf AWS-Services über AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/privatelink-access-aws-services.html) im * AWS-PrivateLink-Handbuch*.
## Bevor Sie beginnen
Stellen Sie zunächst sicher, dass Sie die folgenden Aufgaben durchgeführt haben:
+ [Zugriff auf einen AWS-Service über einen Schnittstellen-VPC-Endpunkt](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#considerations-interface-endpoints) im *AWS-PrivateLink-Handbuch* überprüfen
## Überlegungen
+ **Support und Einschränkungen**: Amazon-EKS-Schnittstellenendpunkte ermöglichen sicheren Zugriff auf alle Amazon-EKS-API-Aktionen von Ihrem VPC aus, weisen jedoch bestimmte Einschränkungen auf: Sie unterstützen keinen Zugriff auf Kubernetes-APIs, da diese über einen separaten privaten Endpunkt verfügen. Sie können Amazon EKS nicht so konfigurieren, dass nur über den Schnittstellenendpunkt darauf zugegriffen werden kann.
+ **Preise**: Für die Verwendung von Schnittstellenendpunkten für Amazon EKS fallen Standardgebühren für AWS PrivateLink an: Stundengebühren für jeden in jeder Availability Zone bereitgestellten Endpunkt, Datenverarbeitungsgebühren für den Datenverkehr über den Endpunkt. Weitere Informationen finden Sie unter [Preise zu AWS PrivateLink](https://aws.amazon.com/privatelink/pricing/).
+ **Sicherheit und Zugriffskontrolle**: Wir empfehlen, die Sicherheit zu erhöhen und den Zugriff mit diesen zusätzlichen Konfigurationen zu steuern: Verwenden Sie VPC-Endpunktrichtlinien, um den Zugriff auf Amazon EKS über den Schnittstellenendpunkt zu steuern, ordnen Sie Sicherheitsgruppen den Endpunkt-Netzwerkschnittstellen zu, um den Datenverkehr zu verwalten, und verwenden Sie VPC-Ablaufprotokolle, um den IP-Datenverkehr zu und von den Schnittstellenendpunkten zu erfassen und zu überwachen, wobei die Protokolle in Amazon CloudWatch oder Amazon S3 veröffentlicht werden können. Weitere Informationen finden Sie unter [Zugriff auf VPC-Endpunkte mithilfe von Endpunktrichtlinien steuern](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html) und [Protokollierung von IP-Datenverkehr mithilfe von VPC-Ablaufprotokollen](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html).
+ **Konnektivitätsoptionen**: Schnittstellenendpunkte bieten flexible Konnektivitätsoptionen über den **On-Premises-Zugriff** (verbinden Sie Ihr lokales Rechenzentrum über AWS Direct Connect oder AWS Site-to-Site VPN mit einem VPC über den Schnittstellenendpunkt) oder über die **Inter-VPC-Konnektivität** (verwenden Sie AWS Transit Gateway oder VPC Peering, um andere VPCs mit dem VPC über den Schnittstellenendpunkt zu verbinden, wobei der Datenverkehr innerhalb des AWS-Netzwerks bleibt).
+ **Support für IP-Versionen**: Endpunkte, die vor August 2024 erstellt wurden, unterstützen nur IPv4 unter Verwendung von eks.region.amazonaws.com. Neue Endpunkte, die nach August 2024 erstellt wurden, unterstützen Dual-Stack-IPv4 und IPv6 (z. B. eks.region.amazonaws.com, eks.region.api.aws).
+ **Regionale Verfügbarkeit**: AWS PrivateLink ist für die EKS-API ist in den Regionen Asien-Pazifik (Malaysia) (ap-southeast-5), Asien-Pazifik (Thailand) (ap-southeast-7), Mexiko (Zentral) (mx-central-1) und Asien-Pazifik (Taipeh) (ap-east-2) nicht verfügbar. AWS PrivateLink-Support für eks-auth (EKS Pod Identity) ist in der Region Asien-Pazifik (Malaysia) (ap-southeast-5) verfügbar.
## Erstellen eines Schnittstellen-Endpunkts für Amazon EKS
Sie können einen Schnittstellenendpunkt für Amazon EKS entweder über die Amazon-VPC-Konsole oder die AWS-Befehlszeilenschnittstelle (AWS-CLI) erstellen. Weitere Informationen finden Sie unter [Erstellen eines VPC-Endpunkts](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint-aws) im * AWS-PrivateLink-Leitfaden *.
Erstellen Sie einen Schnittstellenendpunkt für Amazon EKS unter Verwendung der folgenden Service-Namen:
### EKS-API
+ com.amazonaws.region-code.eks
+ com.amazonaws.region-code.eks-fips (für FIPS-kompatible Endpunkte)
### EKS-Auth-API (EKS Pod Identity)
+ com.amazonaws.region-code.eks-auth
## Private DNS-Feature für Amazon-EKS-Schnittstellenendpunkte
Das private DNS-Feature, das standardmäßig für Schnittstellenendpunkte von Amazon EKS und anderen AWS-Services aktiviert ist, ermöglicht sichere und private API-Anfragen unter Verwendung der standardmäßigen regionalen DNS-Namen. Dieses Feature stellt sicher, dass API-Aufrufe über den Schnittstellenendpunkt über das private AWS-Netzwerk geleitet werden, was die Sicherheit und Leistung verbessert.
Das private DNS-Feature wird automatisch aktiviert, wenn Sie einen Schnittstellenendpunkt für Amazon EKS oder andere AWS-Services erstellen. Zur Aktivierung, müssen Sie Ihre VPC korrekt konfigurieren, indem Sie bestimmte Attribute festlegen:
+ **enableDnsHostnames**: Ermöglicht Instances innerhalb der VPC, DNS-Host-Namen zu verwenden.
+ **enableDnsSupport**: Aktiviert die DNS-Auflösung im gesamten VPC.
Eine Schritt-für-Schritt-Anleitung zum Überprüfen oder Ändern dieser Einstellungen finden Sie unter [Anzeigen und Aktualisieren der DNS-Attribute für Ihre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating).
### DNS-Namen und IP-Adresstypen
Wenn das private DNS-Feature aktiviert ist, können Sie bestimmte DNS-Namen verwenden, um eine Verbindung zu Amazon EKS herzustellen. Diese Optionen werden im Laufe der Zeit weiterentwickelt:
+ **eks.region.amazonaws.com**: Der herkömmliche DNS-Name, der vor August 2024 nur zu IPv4-Adressen aufgelöst wird. Für vorhandene Endpunkte, die auf Dual-Stack aktualisiert wurden, wird dieser Name sowohl in IPv4- als auch in IPv6-Adressen aufgelöst.
+ **eks.region.api.aws**: Dieser Dual-Stack-DNS-Name ist für neue Endpunkte verfügbar, die nach August 2024 erstellt wurden, und wird sowohl in IPv4- als auch in IPv6-Adressen aufgelöst.
Nach August 2024 werden neue Schnittstellenendpunkte mit zwei DNS-Namen bereitgestellt, und Sie haben die Möglichkeit, den Dual-Stack-IP-Adresstyp zu wählen. Für vorhandene Endpunkte wird durch die Aktualisierung auf Dual-Stack **eks.region.amazonaws.com** so geändert, dass sowohl IPv4 als auch IPv6 unterstützt werden.
### Verwendung des privaten DNS-Features
Nach der Konfiguration kann das private DNS-Feature in Ihre Workflows integriert werden und bietet Ihnen folgende Möglichkeiten:
+ **API-Anfragen**: Verwenden Sie die standardmäßigen regionalen DNS-Namen, entweder`eks.region.amazonaws.com` oder `eks.region.api.aws`, basierend auf der Konfiguration Ihres Endpunkts, um API-Anfragen an Amazon EKS zu senden.
+ **Anwendungskompatibilität**: Ihre vorhandenen Anwendungen, die EKS-APIs aufrufen, erfordern keine Änderungen, um dieses Feature zu nutzen.
+ ** AWS-CLI mit Dual-Stack**: Informationen zur Verwendung der Dual-Stack-Endpunkte mit der AWS-CLI finden Sie in der Konfiguration für [Dual-Stack- und FIPS-Endpunkte](https://docs.aws.amazon.com/sdkref/latest/guide/feature-endpoints.html) im * AWS-SDK- und Tools-Referenzhandbuch.*.
+ **Automatische Weiterleitung**: Jeder Aufruf des Standard-Service-Endpunkts von Amazon EKS wird automatisch über den Schnittstellenendpunkt weitergeleitet, wodurch eine private und sichere Verbindung gewährleistet wird.
# Ausfallsicherheit in Amazon-EKS-Clustern verstehen
Im Zentrum der globalen AWS-Infrastruktur stehen die AWS-Regionen und Availability Zones (Verfügbarkeitszonen, AZs). AWS Regionen stellen mehrere physisch getrennte und isolierte Availability Zones bereit, die mit Netzwerken mit geringer Latenz, hohem Durchsatz und hochredundanten Vernetzungen verbunden sind. Mithilfe von Availability Zones können Sie Anwendungen und Datenbanken erstellen und ausführen, die automatisch Failover zwischen Availability Zones ausführen, ohne dass es zu Unterbrechungen kommt. Availability Zones sind besser hoch verfügbar, fehlertoleranter und skalierbarer als herkömmliche Infrastrukturen mit einem oder mehreren Rechenzentren.
Amazon EKS führt und skaliert die Kubernetes-Steuerungsebene über mehrere AWS-Availability-Zones hinweg, um eine hohe Verfügbarkeit zu gewährleisten. Amazon EKS skaliert Steuerebene-Instances automatisch basierend auf der Last, erkennt und ersetzt fehlerhafte Steuerebene-Instances und patcht die Steuerebene automatisch. Nachdem Sie ein Versionsupdate eingeleitet haben, aktualisiert Amazon EKS Ihre Steuerebene für Sie und behält die hohe Verfügbarkeit der Steuerebene während des Updates bei.
Diese Steuerebene besteht aus mindestens zwei API-Server-Instances und drei `etcd`-Instances, die über drei Availability Zones innerhalb einer AWS-Region hinweg ausgeführt werden. Amazon EKS:
+ Überwacht aktiv die Last auf Kontrollebeneninstanzen und skaliert sie automatisch, um eine hohe Leistung zu gewährleisten.
+ Erkennt und ersetzt automatisch fehlerhafte Instances der Steuerebene und startet sie bei Bedarf in den Availability Zones innerhalb der AWS-Region neu.
+ Nutzt die Architektur von AWS-Regionen, um eine hohe Verfügbarkeit zu gewährleisten. Aus diesem Grund ist Amazon EKS in der Lage, ein [SLA für die Verfügbarkeit von API-Server-Endpunkten](https://aws.amazon.com/eks/sla) bereitzustellen.
Weitere Informationen über AWS-Regionen und -Availability Zones finden Sie unter [Globale AWS-Infrastruktur](https://aws.amazon.com/about-aws/global-infrastructure/).
# Serviceübergreifende Vermeidung verwirrter Stellvertreter in Amazon EKS
Das Problem des verwirrten Stellvertreters ist ein Sicherheitsproblem, bei dem eine Entität, die keine Berechtigung zur Durchführung einer Aktion hat, eine privilegiertere Entität zur Durchführung der Aktion zwingen kann. In AWS, dienstübergreifender Identitätswechsel kann zum Problem des verwirrten Stellvertreters führen. Ein serviceübergreifender Identitätswechsel kann auftreten, wenn ein Service (der *Anruf-Service*) einen anderen Service anruft (den *aufgerufenen Service*). Der Aufruf-Service kann so manipuliert werden, dass er seine Berechtigungen verwendet, um auf die Ressourcen eines anderen Kunden zu reagieren, auf die er sonst nicht zugreifen dürfte. Um dies zu verhindern, AWS bietet Tools, mit denen Sie Ihre Daten für alle Dienste mit Dienstprinzipalen schützen können, denen Zugriff auf Ressourcen in Ihrem Konto gewährt wurde.
Wir empfehlen die Verwendung der globalen Bedingungskontextschlüssel [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) und [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) in Ressourcenrichtlinien, um die Berechtigungen einzuschränken, die Amazon Elastic Kubernetes Service (Amazon EKS) einem anderen Service für die Ressource gewährt.
`aws:SourceArn`
Verwenden Sie `aws:SourceArn`, um nur einer Ressource den serviceübergreifenden Zugriff zuzuordnen.
`aws:SourceAccount`
Verwenden Sie `aws:SourceAccount`, um jede Ressource in diesem Konto der serviceübergreifenden Nutzung zuzuordnen.
Der effektivste Weg, um sich vor dem Confused-Deputy-Problem zu schützen, ist die Verwendung des globalen Bedingungskontext-Schlüssels `aws:SourceArn` mit dem vollständigen ARN der Ressource. Wenn Sie die vollständige ARN der Ressource nicht kennen oder mehrere Ressourcen angeben, verwenden Sie den globalen Kontextbedingungsschlüssel `aws:SourceArn` mit Platzhalterzeichen (\$1) für die unbekannten Teile der ARN. Beispiel, ` arn:aws::*:<123456789012>:*`.
Wenn der `aws:SourceArn`-Wert die Konto-ID nicht enthält, z. B. einen Amazon-S3-Bucket-ARN, müssen Sie sowohl `aws:SourceAccount` als auch `aws:SourceArn` verwenden, um Berechtigungen einzuschränken.
## Serviceübergreifende Vermeidung verwirrter Stellvertreter in Amazon-EKS-Cluster-Rollen
Für jeden Cluster ist eine IAM-Rolle für Amazon-EKS-Cluster erforderlich. Von Amazon EKS verwaltete Kubernetes-Cluster verwenden diese Rolle zur Verwaltung von Knoten, und der [veraltete Cloud-Anbieter](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/#legacy-cloud-provider) nutzt diese Rolle, um Load Balancer mit Elastic Load Balancing für Services zu erstellen. Diese Cluster-Aktionen können sich nur auf dasselbe Konto auswirken. Daher empfehlen wir, jede Cluster-Rolle auf diesen Cluster und dieses Konto zu beschränken. Dies ist eine spezifische Anwendung der AWS Empfehlung, in Ihrem Konto den *Grundsatz der geringsten Rechte* zu befolgen.
**Format der Quell-ARN**
Der Wert von `aws:SourceArn` muss die ARN eines EKS-Clusters im Format ` arn:aws: eks:region:account:cluster/cluster-name ` sein. Beispiel, ` arn:aws: eks:us-west-2:123456789012:cluster/my-cluster`.
**Format für Vertrauensrichtlinie für EKS-Cluster-Rollen**
Das folgende Beispiel zeigt, wie Sie die globalen Bedingungskontextschlüssel `aws:SourceArn` und `aws:SourceAccount` für Amazon EKS verwenden können, um das Problem mit verwirrtem Stellvertreter zu verhindern.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:eks:us-west-2:123456789012:cluster/my-cluster"
},
"StringEquals": {
"aws:SourceAccount": "123456789012"
}
}
}
]
}
```
# Sicherheitsüberlegungen für Kubernetes
Nachfolgend finden Sie Überlegungen zur Sicherheit in der Cloud, da diese sich auf Kubernetes in Amazon-EKS-Clustern auswirken. Eine ausführliche Übersicht über Sicherheitskontrollen und -praktiken in Kubernetes finden Sie unter [Cloudnative Sicherheit und Kubernetes](https://kubernetes.io/docs/concepts/security/cloud-native-security/) in der Kubernetes-Dokumentation.
**Topics**
+ [
# Sicherung von Workloads mit Kubernetes-Zertifikaten
](cert-signing.md)
+ [
# Die von Amazon EKS erstellten RBAC-Rollen und -Benutzer verstehen
](default-roles-users.md)
+ [
# Verschlüsselung von Kubernetes-Geheimnissen mit KMS in vorhandenen Clustern
](enable-kms.md)
+ [
# Verwendung von AWS-Secrets-Manager-Geheimnissen mit Amazon-EKS-Pods
](manage-secrets.md)
+ [
# Standardmäßige Umschlagverschlüsselung für alle Kubernetes-API-Daten
](envelope-encryption.md)
# Sicherung von Workloads mit Kubernetes-Zertifikaten
Die Kubernetes-Zertifikats-API automatisiert die Bereitstellung von [X.509](https://www.itu.int/rec/T-REC-X.509)-Anmeldeinformationen. Die API verfügt über eine Befehlszeilenschnittstelle, über die Kubernetes-API-Clients [X.509-Zertifikate](https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/) von einer Zertifizierungsstelle (CA) anfordern und abrufen kann. Sie können die `CertificateSigningRequest` (CSR)-Ressource verwenden, um anzufordern, dass ein benannter Unterzeichner das Zertifikat signiert. Ihre Anträge werden entweder genehmigt oder abgelehnt, bevor sie signiert werden. Kubernetes unterstützt sowohl integrierte Unterzeichner als auch benutzerdefinierte Unterzeichner mit klar definierten Verhaltensweisen. Auf diese Weise können Kunden vorhersehen, was mit ihren CSRs passiert. Weitere Informationen zur Zertifikatsignatur finden Sie unter [Signieren von Anforderungen](https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/).
Einer der integrierten Unterzeichner ist `kubernetes.io/legacy-unknown`. Die `v1beta1`-API der CSR-Ressource berücksichtigte diesen Unterzeichnertyp „legacy-unknown“. Die stabile `v1`-API von CSR lässt jedoch nicht zu, dass `signerName` auf `kubernetes.io/legacy-unknown` festgelegt wird.
Wenn Sie Amazon EKS CA zum Generieren von Zertifikaten verwenden möchten, müssen Sie einen benutzerdefinierten Unterzeichner verwenden. Um die CSR-`v1`-API-Version zu verwenden und ein neues Zertifikat zu generieren, müssen Sie alle vorhandenen Manifeste und API-Clients migrieren. Bestehende Zertifikate, die mit der vorhandenen `v1beta1`-API erstellt wurden, sind gültig und funktionieren, bis sie ablaufen. Diese umfasst die folgenden Funktionen:
+ Vertrauensverteilung: keine. Es gibt kein Standardvertrauen oder eine Standardverteilung für diesen Unterzeichner in einem Kubernetes-Cluster.
+ Zulässige Themen: beliebig
+ Zulässige x509-Erweiterungen: Berücksichtigt SubjectAltName und Schlüsselnutzungserweiterungen und verwirft andere Erweiterungen
+ Zulässige Schlüsselnutzung: Darf keine anderen Nutzungen als [„Schlüsselverschlüsselung“, „digitale Signatur“, „Serverauth“] enthalten
**Anmerkung**
Das Signieren von Clientzertifikaten wird nicht unterstützt.
+ Ablauf/Zertifikatslebensdauer: 1 Jahr (Standard und Maximum)
+ CA-Bit zulässig/unzulässig: unzulässig
## Beispiel CSR-Erstellung mit signerName
Diese Schritte veranschaulichen, wie Sie ein Bereitstellungszertifikat für DNS-Namen `myserver.default.svc` mit `signerName: beta.eks.amazonaws.com/app-serving` erstellen. Verwenden Sie dies als Leitfaden für Ihre eigene Umgebung.
1. Führen Sie den Befehl `openssl genrsa -out myserver.key 2048` aus, um einen privaten RSA-Schlüssel zu erzeugen.
```
openssl genrsa -out myserver.key 2048
```
1. Führen Sie den folgenden Befehl aus, um eine Zertifikatsanforderung zu erstellen.
```
openssl req -new -key myserver.key -out myserver.csr -subj "/CN=myserver.default.svc"
```
1. Generieren Sie einen `base64`-Wert für die CSR-Variablen für die Verwendung in einem späteren Schritt.
```
base_64=$(cat myserver.csr | base64 -w 0 | tr -d "
")
```
1. Führen Sie den folgenden Befehl aus, um eine Datei mit dem Namen `mycsr.yaml` zu erstellen. Im folgenden Beispiel ist `beta.eks.amazonaws.com/app-serving` der `signerName`.
```
cat >mycsr.yaml < myserver.crt
```
# Die von Amazon EKS erstellten RBAC-Rollen und -Benutzer verstehen
Wenn Sie einen Kubernetes-Cluster erstellen, werden für das ordnungsgemäße Funktionieren von Kubernetes mehrere Kubernetes-Standardidentitäten in diesem Cluster erstellt. Amazon EKS erstellt Kubernetes-Identitäten für jede seiner Standardkomponenten. Die Identitäten stellen eine rollenbasierte Autorisierungskontrolle (RBAC) von Kubernetes für die Cluster-Komponenten bereit. Weitere Informationen finden Sie unter [Verwendung der RBAC-Autorisierung](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) in der Kubernetes-Dokumentation.
Wenn Sie optionale [Add-Ons](eks-add-ons.md) zu Ihrem Cluster installieren, werden Ihrem Cluster möglicherweise zusätzliche Kubernetes-Identitäten hinzugefügt. Weitere Informationen zu Identitäten, die in diesem Thema nicht behandelt werden, finden Sie in der Dokumentation des Add-Ons.
Sie können die Liste der von Amazon EKS erstellten Kubernetes-Identitäten auf Ihrem Cluster mit dem `kubectl` Befehlszeilentool AWS-Managementkonsole oder anzeigen. Alle Benutzeridentitäten erscheinen in den `kube` Audit-Logs, die Ihnen über Amazon CloudWatch zur Verfügung stehen.
## AWS-Managementkonsole
### Voraussetzung
Der von Ihnen verwendete [IAM-Prinzipal](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) muss über die unter [Erforderliche Berechtigungen](view-kubernetes-resources.md#view-kubernetes-resources-permissions) beschriebenen Berechtigungen verfügen.
### Um von Amazon EKS erstellte Identitäten anzuzeigen, verwenden Sie den AWS-Managementkonsole
1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters).
1. Wählen Sie in der Liste **Clusters** (Cluster) den Cluster aus, der die anzuzeigenden Identitäten enthält.
1. Wählen Sie die Registerkarte **Resources (Ressourcen)** aus.
1. Wählen Sie unter **Resource types** (Ressourcentypen) die Option **Authorization** (Autorisierung) aus.
1. Wählen Sie **ClusterRoles**, **ClusterRoleBindings**, **Rollen** oder **RoleBindings**. Alle Ressourcen, denen **eks** vorangestellt ist, wurden von Amazon EKS erstellt. Weitere von Amazon EKS erstellte Identitätsressourcen sind:
+ Der **ClusterRole**und **ClusterRoleBinding**benannte **aws-node**. Die **aws-node**-Ressourcen unterstützen das [Amazon-VPC-CNI-Plugin für Kubernetes](managing-vpc-cni.md), das Amazon EKS auf allen Clustern installiert.
+ Ein **ClusterRole**benannter **vpc-resource-controller-role**und ein benannter. **ClusterRoleBinding**vpc-resource-controller-rolebinding**** Diese Ressourcen unterstützen den [Amazon-VPC-Ressourcencontroller](https://github.com/aws/amazon-vpc-resource-controller-k8s), den Amazon EKS auf allen Clustern installiert.
Zusätzlich zu den Ressourcen, die Sie in der Konsole sehen, sind die folgenden speziellen Benutzeridentitäten in Ihrem Cluster vorhanden, obwohl sie in der Konfiguration des Clusters nicht sichtbar sind:
+ ** `eks:cluster-bootstrap` ** – Wird für `kubectl`-Vorgänge während des Cluster-Bootstraps verwendet.
+ ** `eks:support-engineer` ** – Wird für Cluster-Management-Operationen verwendet.
1. Wählen Sie eine bestimmte Ressource aus, um Details dazu anzuzeigen. Standardmäßig werden Ihnen Informationen in der **Strukturierten Ansicht** angezeigt. In der oberen rechten Ecke der Detailseite können Sie die **Raw view** (Rohansicht) auswählen, um alle Informationen für die Ressource anzuzeigen.
## Kubectl
### Voraussetzung
Die Entität, die Sie verwenden (AWS Identity and Access Management (IAM) oder OpenID Connect (OIDC)), um die Kubernetes-Ressourcen auf dem Cluster aufzulisten, muss von IAM oder Ihrem OIDC-Identitätsanbieter authentifiziert werden. Der Entität müssen Berechtigungen zur Verwendung der Kubernetes-Verben `get` und `list` für die `Role`-, `ClusterRole`-, `RoleBinding`- und `ClusterRoleBinding`-Ressourcen in Ihrem Cluster gewährt werden, mit denen die Entität arbeiten soll. Weitere Informationen zum Gewähren von Zugriff auf IAM-Entitäten auf Ihren Cluster finden Sie unter [Gewähren Sie IAM-Benutzern und -Rollen Zugriff auf Kubernetes APIs](grant-k8s-access.md). Weitere Informationen zum Gewähren von Zugriff auf Ihren Cluster durch Entitäten, die von Ihrem eigenen OIDC-Anbieter authentifiziert wurden, finden Sie unter [Benutzern Zugriff auf Kubernetes mit einem externen OIDC-Anbieter gewähren](authenticate-oidc-identity-provider.md).
### So zeigen Sie von Amazon EKS erstellte Identitäten mit dem `kubectl` an
Führen Sie den Region aus, die Sie anzeigen möchten. Alle zurückgegebenen Ressourcen, denen **eks** vorangestellt ist, wurden von Amazon EKS erstellt. Zusätzlich zu den Ressourcen, die in der Ausgabe der Befehle zurückgegeben werden, sind die folgenden speziellen Benutzeridentitäten in Ihrem Cluster vorhanden, obwohl sie in der Konfiguration des Clusters nicht sichtbar sind:
+ ** `eks:cluster-bootstrap` ** – Wird für `kubectl`-Vorgänge während des Cluster-Bootstraps verwendet.
+ ** `eks:support-engineer` ** – Wird für Cluster-Management-Operationen verwendet.
**ClusterRoles**— `ClusterRoles` sind auf Ihren Cluster beschränkt, sodass jede für eine Rolle erteilte Berechtigung für Ressourcen in jedem Kubernetes-Namespace auf dem Cluster gilt.
Der folgende Befehl gibt alle von Amazon EKS erstellten Kubernetes `ClusterRoles` in Ihrem Cluster zurück.
```
kubectl get clusterroles | grep eks
```
Zusätzlich zu dem in der Ausgabe zurückgegebenen `ClusterRoles`, dem etwas vorangestellt ist, sind die folgenden `ClusterRoles` vorhanden.
+ ** `aws-node` ** – Diese `ClusterRole` unterstützt das [Amazon-VPC-CNI-Plugin für Kubernetes](managing-vpc-cni.md), das Amazon EKS in allen Clustern installiert.
+ **`vpc-resource-controller-role`** – Diese `ClusterRole` unterstützt den [Amazon-VPC-Ressourcen-Controller](https://github.com/aws/amazon-vpc-resource-controller-k8s), den Amazon EKS in allen Clustern installiert.
Um die Spezifikation für a zu sehen`ClusterRole`, ersetzen Sie den folgenden Befehl durch einen, der *eks:k8s-metrics* in der Ausgabe des vorherigen Befehls `ClusterRole` zurückgegeben wurde. Das folgende Beispiel gibt die Spezifikation für die zurück *eks:k8s-metrics*`ClusterRole`.
```
kubectl describe clusterrole eks:k8s-metrics
```
Eine Beispielausgabe sieht wie folgt aus.
```
Name: eks:k8s-metrics
Labels:
Annotations:
PolicyRule:
Resources Non-Resource URLs Resource Names Verbs
--------- ----------------- -------------- -----
[/metrics] [] [get]
endpoints [] [] [list]
nodes [] [] [list]
pods [] [] [list]
deployments.apps [] [] [list]
```
**ClusterRoleBindings**— `ClusterRoleBindings` sind auf Ihren Cluster beschränkt.
Der folgende Befehl gibt alle von Amazon EKS erstellten Kubernetes `ClusterRoleBindings` in Ihrem Cluster zurück.
```
kubectl get clusterrolebindings | grep eks
```
Zusätzlich zu dem in der Ausgabe zurückgegebenen `ClusterRoleBindings`, sind die folgenden `ClusterRoleBindings` vorhanden.
+ ** `aws-node` ** – Diese `ClusterRoleBinding` unterstützt das [Amazon-VPC-CNI-Plugin für Kubernetes](managing-vpc-cni.md), das Amazon EKS in allen Clustern installiert.
+ **`vpc-resource-controller-rolebinding`** – Diese `ClusterRoleBinding` unterstützt den [Amazon-VPC-Ressourcen-Controller](https://github.com/aws/amazon-vpc-resource-controller-k8s), den Amazon EKS in allen Clustern installiert.
Um die Spezifikation für a zu sehen`ClusterRoleBinding`, ersetzen Sie *eks:k8s-metrics* den folgenden Befehl durch einen, der in der Ausgabe des vorherigen Befehls `ClusterRoleBinding` zurückgegeben wurde. Das folgende Beispiel gibt die Spezifikation für die zurück *eks:k8s-metrics*`ClusterRoleBinding`.
```
kubectl describe clusterrolebinding eks:k8s-metrics
```
Eine Beispielausgabe sieht wie folgt aus.
```
Name: eks:k8s-metrics
Labels:
Annotations:
Role:
Kind: ClusterRole
Name: eks:k8s-metrics
Subjects:
Kind Name Namespace
---- ---- ---------
User eks:k8s-metrics
```
**Rollen** – `Roles` sind auf einen Kubernetes-Namespace beschränkt. Alle mit `Roles` erstellten Amazon EKS sind auf den `kube-system`-Namespace beschränkt.
Der folgende Befehl gibt alle von Amazon EKS erstellten Kubernetes `Roles` in Ihrem Cluster zurück.
```
kubectl get roles -n kube-system | grep eks
```
Um die Spezifikation für a zu sehen`Role`, ersetzen Sie *eks:k8s-metrics* den folgenden Befehl durch den Namen von a, der in der Ausgabe des vorherigen Befehls `Role` zurückgegeben wurde. Das folgende Beispiel gibt die Spezifikation für die zurück *eks:k8s-metrics*`Role`.
```
kubectl describe role eks:k8s-metrics -n kube-system
```
Eine Beispielausgabe sieht wie folgt aus.
```
Name: eks:k8s-metrics
Labels:
Annotations:
PolicyRule:
Resources Non-Resource URLs Resource Names Verbs
--------- ----------------- -------------- -----
daemonsets.apps [] [aws-node] [get]
deployments.apps [] [vpc-resource-controller] [get]
```
**RoleBindings**— `RoleBindings` sind auf einen Kubernetes-Namespace beschränkt. Alle mit `RoleBindings` erstellten Amazon EKS sind auf den `kube-system`-Namespace beschränkt.
Der folgende Befehl gibt alle von Amazon EKS erstellten Kubernetes `RoleBindings` in Ihrem Cluster zurück.
```
kubectl get rolebindings -n kube-system | grep eks
```
Um die Spezifikation für a zu sehen`RoleBinding`, ersetzen Sie den folgenden Befehl durch einen, der *eks:k8s-metrics* in der Ausgabe des vorherigen Befehls `RoleBinding` zurückgegeben wurde. Das folgende Beispiel gibt die Spezifikation für die zurück *eks:k8s-metrics*`RoleBinding`.
```
kubectl describe rolebinding eks:k8s-metrics -n kube-system
```
Eine Beispielausgabe sieht wie folgt aus.
```
Name: eks:k8s-metrics
Labels:
Annotations:
Role:
Kind: Role
Name: eks:k8s-metrics
Subjects:
Kind Name Namespace
---- ---- ---------
User eks:k8s-metrics
```
# Verschlüsselung von Kubernetes-Geheimnissen mit KMS in vorhandenen Clustern
**Wichtig**
Dieses Verfahren gilt nur für EKS-Cluster, auf denen Kubernetes Version 1.27 oder niedriger ausgeführt wird. Wenn Sie Kubernetes Version 1.28 oder höher ausführen, werden Ihre Kubernetes-Geheimnisse standardmäßig durch Umschlagverschlüsselung geschützt. Weitere Informationen finden Sie unter [Standardmäßige Umschlagverschlüsselung für alle Kubernetes-API-Daten](envelope-encryption.md).
Wenn Sie die [Verschlüsselung von Geheimnissen](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) aktivieren, werden die Kubernetes-Geheimnisse mit dem von Ihnen ausgewählten AWS KMS-Schlüssel verschlüsselt. Der KMS-Schlüssel muss die folgenden Bedingungen erfüllen:
+ Symmetrisch
+ Kann Daten verschlüsseln und entschlüsseln
+ In derselben AWS Region wie der Cluster erstellt
+ Wenn der KMS-Schlüssel in einem anderen Konto erstellt wurde, muss der [IAM-Prinzipal](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) Zugriff auf den KMS-Schlüssel haben.
Weitere Informationen finden Sie unter [Zulassen, dass IAM-Prinzipale in anderen Konten einen KMS-Schlüssel verwenden können im AWS Key](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying-external-accounts.html) *[Management Service Developer Guide](https://docs.aws.amazon.com/kms/latest/developerguide/)*.
**Warnung**
Sie können die Verschlüsselung von Geheimnissen nicht deaktivieren, nachdem Sie sie aktiviert haben. Diese Aktion ist unumkehrbar.
eksctl
Dieses Verfahren gilt nur für EKS-Cluster, auf denen Kubernetes Version 1.27 oder niedriger ausgeführt wird. Weitere Informationen finden Sie unter [Standardmäßige Umschlagverschlüsselung für alle Kubernetes-API-Daten](envelope-encryption.md).
Sie können die Verschlüsselung auf zwei Arten aktivieren:
+ Fügen Sie Ihrem Cluster mit einem einzigen Befehl Verschlüsselung hinzu.
Um Ihre Secrets automatisch erneut zu verschlüsseln, führen Sie den folgenden Befehl aus.
```
eksctl utils enable-secrets-encryption \
--cluster my-cluster \
--key-arn arn:aws: kms:region-code:account:key/key
```
Um die automatische Neuverschlüsselung Ihrer Secrets zu deaktivieren, führen Sie den folgenden Befehl aus.
```
eksctl utils enable-secrets-encryption
--cluster my-cluster \
--key-arn arn:aws: kms:region-code:account:key/key \
--encrypt-existing-secrets=false
```
+ Fügen Sie Ihrem Cluster eine Verschlüsselung mit einer `kms-cluster.yaml`-Datei hinzu.
```
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: my-cluster
region: region-code
secretsEncryption:
keyARN: arn:aws: kms:region-code:account:key/key
```
Um Ihre Secrets automatisch erneut zu verschlüsseln, führen Sie den folgenden Befehl aus.
```
eksctl utils enable-secrets-encryption -f kms-cluster.yaml
```
Um die automatische Neuverschlüsselung Ihrer Secrets zu deaktivieren, führen Sie den folgenden Befehl aus.
```
eksctl utils enable-secrets-encryption -f kms-cluster.yaml --encrypt-existing-secrets=false
```
AWS-Managementkonsole
1. Dieses Verfahren gilt nur für EKS-Cluster, auf denen Kubernetes Version 1.27 oder niedriger ausgeführt wird. Weitere Informationen finden Sie unter [Standardmäßige Umschlagverschlüsselung für alle Kubernetes-API-Daten](envelope-encryption.md).
1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters).
1. Wählen Sie den Cluster aus, dem Sie die KMS-Verschlüsselung hinzufügen möchten.
1. Wählen Sie die Registerkarte **Overview** (Übersicht) aus (sie ist standardmäßig ausgewählt).
1. Scrollen Sie nach unten zum Abschnitt **Secrets encryption** (Secrets-Verschlüsselung) und wählen Sie **Enable** (Aktivieren) aus.
1. Wählen Sie einen Schlüssel in der Dropdown-Liste und dann die Schaltfläche **Enable** (Aktivieren) aus. Wenn keine Schlüssel aufgeführt sind, müssen Sie zuerst einen erstellen. Weitere Informationen finden Sie unter [Erstellen von Schlüsseln](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html)
1. Wählen Sie die Schaltfläche **Confirm** (Bestätigen) aus, um den ausgewählten Schlüssel zu verwenden.
AWS CLI
1. Dieses Verfahren gilt nur für EKS-Cluster, auf denen Kubernetes Version 1.27 oder niedriger ausgeführt wird. Weitere Informationen finden Sie unter [Standardmäßige Umschlagverschlüsselung für alle Kubernetes-API-Daten](envelope-encryption.md).
1. Ordnen Sie die [Secrets-Verschlüsselungskonfiguration](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) mithilfe des folgenden AWS CLI-Befehls Ihrem Cluster zu. Ersetzen Sie die Beispielwerte durch Ihre eigenen Werte.
```
aws eks associate-encryption-config \
--cluster-name my-cluster \
--encryption-config '[{"resources":["secrets"],"provider":{"keyArn":"arn:aws: kms:region-code:account:key/key"}}]'
```
Eine Beispielausgabe sieht wie folgt aus.
```
{
"update": {
"id": "3141b835-8103-423a-8e68-12c2521ffa4d",
"status": "InProgress",
"type": "AssociateEncryptionConfig",
"params": [
{
"type": "EncryptionConfig",
"value": "[{\"resources\":[\"secrets\"],\"provider\":{\"keyArn\":\"arn:aws: kms:region-code:account:key/key\"}}]"
}
],
"createdAt": 1613754188.734,
"errors": []
}
}
```
1. Sie können den Status Ihrer Verschlüsselungsaktualisierung mit dem folgenden Befehl überwachen. Verwenden Sie den `cluster name` und die `update ID`, die in der vorherigen Ausgabe zurückgegeben wurden. Wenn der Status `Successful` angezeigt wird, ist das Update abgeschlossen.
```
aws eks describe-update \
--region region-code \
--name my-cluster \
--update-id 3141b835-8103-423a-8e68-12c2521ffa4d
```
Eine Beispielausgabe sieht wie folgt aus.
```
{
"update": {
"id": "3141b835-8103-423a-8e68-12c2521ffa4d",
"status": "Successful",
"type": "AssociateEncryptionConfig",
"params": [
{
"type": "EncryptionConfig",
"value": "[{\"resources\":[\"secrets\"],\"provider\":{\"keyArn\":\"arn:aws: kms:region-code:account:key/key\"}}]"
}
],
"createdAt": 1613754188.734>,
"errors": []
}
}
```
1. Führen Sie den Befehl `describe-cluster` aus, um zu überprüfen, ob die Verschlüsselung in Ihrem Cluster aktiviert ist. Die Antwort enthält eine `EncryptionConfig`-Zeichenfolge.
```
aws eks describe-cluster --region region-code --name my-cluster
```
Nachdem Sie die Verschlüsselung in Ihrem Cluster aktiviert haben, müssen Sie alle vorhandenen Secrets mit dem neuen Schlüssel verschlüsseln:
**Anmerkung**
Wenn Sie `eksctl` verwenden, ist die Ausführung des folgenden Befehls nur dann erforderlich, wenn Sie die automatische Neuverschlüsselung Ihrer Secrets deaktivieren.
```
kubectl get secrets --all-namespaces -o json | kubectl annotate --overwrite -f - kms-encryption-timestamp="time value"
```
**Warnung**
Wenn Sie die [Geheimnisverschlüsselung](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) für einen vorhandenen Cluster aktivieren und der von Ihnen verwendete KMS-Schlüssel jemals gelöscht wird, können Sie den Cluster nicht wiederherstellen. Wenn Sie den KMS-Schlüssel löschen, wird der Cluster dauerhaft auf einen degradierten Zustand festgelegt. Weitere Informationen finden Sie unter [Löschen von AWS KMS-Schlüsseln](https://docs.aws.amazon.com/kms/latest/developerguide/deleting-keys.html).
**Anmerkung**
Standardmäßig erstellt der `create-key` Befehl einen [KMS-Schlüssel mit symmetrischer Verschlüsselung und einer Schlüsselrichtlinie](https://docs.aws.amazon.com/kms/latest/developerguide/symmetric-asymmetric.html), die dem Konto Root-Administratorzugriff auf AWS KMS-Aktionen und -Ressourcen gewährt. Wenn Sie die Berechtigungen begrenzen möchten, müssen Sie sicherstellen, dass die Aktionen `kms:DescribeKey` und `kms:CreateGrant` für die Richtlinie für den Prinzipal zulässig sind, der die API `create-cluster` aufruft.
Für Cluster, die KMS-Umschlagverschlüsselung verwenden, sind `kms:CreateGrant`-Berechtigungen erforderlich. Die Bedingung `kms:GrantIsForAWSResource` wird für die CreateCluster Aktion nicht unterstützt und sollte nicht in KMS-Richtlinien zur Steuerung der `kms:CreateGrant` Berechtigungen von Benutzern verwendet werden, die diese Aktion ausführen CreateCluster.
# Verwendung von AWS-Secrets-Manager-Geheimnissen mit Amazon-EKS-Pods
Um Secrets aus Secrets Manager und Parameter aus Parameter Store als in Amazon-EKS-Pods bereitgestellte Dateien anzuzeigen, können Sie den AWS Secrets and Configuration Provider (ASCP) für die [Kubernetes-Secrets-Store-CSI-Treiber](https://secrets-store-csi-driver.sigs.k8s.io/) verwenden.
Mit dem ASCP können Sie Ihre Secrets in Secrets Manager speichern und verwalten und diese dann über Ihre auf Amazon EKS ausgeführten Workloads abrufen. Sie können IAM-Rollen und -Richtlinien verwenden, um den Zugriff auf Ihre Secrets auf bestimmte Kubernetes-Pods in einem Cluster zu beschränken. Der ASCP ruft die Pod Identity ab und tauscht die Identität gegen eine IAM-Rolle. Der ASCP übernimmt die IAM-Rolle des Pods und kann dann Geheimnisse aus Secrets Manager abrufen, die für diese Rolle autorisiert sind.
Wenn Sie in Secrets Manager die automatische Rotation für Ihre Secrets verwenden, können Sie auch die Secrets-Store-CSI-Treiberrotation verwenden, um sicherzustellen, dass Sie das neueste Secret aus Secrets Manager abrufen.
**Anmerkung**
AWS Fargate (Fargate)-Knotengruppen werden nicht unterstützt.
Weitere Informationen finden Sie unter [Verwenden von Secrets-Manager-Secrets in Amazon EKS](https://docs.aws.amazon.com/secretsmanager/latest/userguide/integrating_csi_driver.html) im AWS-Secrets Manager-Benutzerhandbuch.
# Standardmäßige Umschlagverschlüsselung für alle Kubernetes-API-Daten
Amazon Elastic Kubernetes Service (Amazon EKS) bietet standardmäßige Umschlagverschlüsselung für alle Kubernetes-API-Daten in EKS-Clustern, in denen Kubernetes Version 1.28 oder höher ausgeführt wird.
Die Umschlagverschlüsselung schützt die Daten, die Sie auf dem Kubernetes-API-Server speichern. Die Umschlagverschlüsselung gilt beispielsweise für die Konfiguration Ihres Kubernetes-Clusters, z. B. `ConfigMaps`. Die Umschlagverschlüsselung gilt nicht für Daten auf Knoten oder EBS-Volumes. EKS unterstützte zuvor die Verschlüsselung von Kubernetes-Geheimnissen, und nun erstreckt sich diese Umschlagverschlüsselung auf alle Kubernetes-API-Daten.
Dies bietet eine verwaltete Standarderfahrung, die defense-in-depth für Ihre Kubernetes-Anwendungen implementiert wird und keine Maßnahmen von Ihrer Seite erfordert.
Amazon EKS verwendet AWS [Key Management Service (KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) mit [Kubernetes KMS Provider v2](https://kubernetes.io/docs/tasks/administer-cluster/kms-provider/#configuring-the-kms-provider-kms-v2) für diese zusätzliche Sicherheitsebene mit einem [Amazon Web Services Services-eigenen Schlüssel](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk) und der Option, dass Sie Ihren eigenen vom [Kunden verwalteten Schlüssel](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) (CMK) von KMS verwenden können. AWS
## Grundlegendes zur Umschlagverschlüsselung
Bei der Umschlagverschlüsselung werden Klartextdaten mit einem Datenverschlüsselungsschlüssel (DEK) verschlüsselt, bevor sie an den Datenspeicher (etcd) gesendet werden. Anschließend werden die DEK mit einem KMS-Stammschlüssel verschlüsselt, der in einem zentral verwalteten Remote-KMS-System (AWS KMS) gespeichert ist. Dies ist eine defense-in-depth Strategie, da sie die Daten mit einem Verschlüsselungsschlüssel (DEK) schützt und dann eine weitere Sicherheitsebene hinzufügt, indem dieser DEK mit einem separaten, sicher gespeicherten Verschlüsselungsschlüssel geschützt wird, der als Key Encryption Key (KEK) bezeichnet wird.
## So ermöglicht Amazon EKS die standardmäßige Envelope-Verschlüsselung mit KMS v2 und AWS KMS
Amazon EKS nutzt [KMS v2](https://kubernetes.io/docs/tasks/administer-cluster/kms-provider/#kms-v2), um eine standardmäßige Umschlagverschlüsselung für alle API-Daten in der verwalteten Kubernetes-Steuerebene zu implementieren, bevor diese in der [etcd](https://etcd.io/docs/v3.5/faq/)-Datenbank gespeichert werden. Beim Startup generiert der Cluster-API-Server einen Datenverschlüsselungsschlüssel (DEK) aus einem geheimen Startup-Wert in Kombination mit zufällig generierten Daten. Außerdem ruft der API-Server beim Start das KMS-Plug-In auf, um den DEK-Seed mit einem Remote Key Encryption Key (KEK) von AWS KMS zu verschlüsseln. Dies ist ein einmaliger Aufruf, der beim Startup des API-Servers und bei der KEK-Rotation ausgeführt wird. Der API-Server speichert dann den verschlüsselten DEK-Seed im Cache. Danach verwendet der API-Server den zwischengespeicherten DEK-Seed, um auf der DEKs Grundlage einer Key Derivation Function (KDF) weitere einmalige Verwendungszwecke zu generieren. Jede dieser generierten Ressourcen DEKs wird dann nur einmal verwendet, um eine einzelne Kubernetes-Ressource zu verschlüsseln, bevor sie in etcd gespeichert wird. Durch die Verwendung eines verschlüsselten zwischengespeicherten DEK-Seeds in KMS v2 ist der Prozess der Verschlüsselung von Kubernetes-Ressourcen im API-Server sowohl leistungsfähiger als auch kostengünstiger.
**Standardmäßig gehört dieser KEK AWS, aber Sie können optional Ihren eigenen von KMS mitbringen. AWS **
Das nachfolgende Diagramm veranschaulicht die Generierung und Verschlüsselung eines DEK beim Startup des API-Servers.
![\[Das Diagramm veranschaulicht die Generierung und Verschlüsselung eines DEK beim Startup des API-Servers\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/images/security-generate-dek.png)
Das folgende allgemeine Diagramm veranschaulicht die Verschlüsselung einer Kubernetes-Ressource, bevor sie in etcd gespeichert wird.
![\[Das allgemeine Diagramm veranschaulicht die Verschlüsselung einer Kubernetes-Ressource, bevor sie in etcd gespeichert wird.\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/images/security-encrypt-request.png)
## Häufig gestellte Fragen
### Inwiefern verbessert die standardmäßige Umschlagverschlüsselung die Sicherheitslage meines EKS-Clusters?
Dieses Feature reduziert die Oberfläche und den Zeitraum, in dem Metadaten und Kundeninhalte unverschlüsselt sind. Mit der standardmäßigen Umschlagverschlüsselung befinden sich Metadaten und Kundeninhalte nur vorübergehend in einem unverschlüsselten Zustand im Speicher des kube-apiserver, bevor sie in etcd gespeichert werden. [Der Speicher des Kube-Apiservers ist durch das Nitro-System gesichert.](https://docs.aws.amazon.com/whitepapers/latest/security-design-of-aws-nitro-system/the-components-of-the-nitro-system.html) Amazon EKS verwendet ausschließlich [Nitro-basierte EC2-Instances](https://docs.aws.amazon.com/whitepapers/latest/security-design-of-aws-nitro-system/security-design-of-aws-nitro-system.html) für die verwaltete Kubernetes-Steuerebene. Diese Instances verfügen über Sicherheitskontrollmechanismen, die verhindern, dass Systeme oder Personen auf ihren Speicher zugreifen können.
### Welche Version von Kubernetes muss ich ausführen, um dieses Feature nutzen zu können?
Damit die standardmäßige Umschlagverschlüsselung aktiviert werden kann, muss auf Ihrem Amazon-EKS-Cluster Kubernetes Version 1.28 oder höher ausgeführt werden.
### Sind meine Daten noch sicher, wenn ich eine Kubernetes-Cluster-Version verwende, die dieses Feature nicht unterstützt?
Ja. Bei hat [Sicherheit](https://aws.amazon.com/security/) für AWS uns höchste Priorität. Unsere gesamte digitale Transformation und Innovation basiert auf den höchsten Sicherheitsstandards, und wir sind bestrebt, diese Standards kontinuierlich zu verbessern.
Alle in etcd gespeicherten Daten werden für jeden EKS-Cluster auf Festplattenebene verschlüsselt, unabhängig von der verwendeten Kubernetes-Version. EKS verwendet Root-Schlüssel, die Volume-Verschlüsselungsschlüssel generieren, die vom EKS- Service verwaltet werden. Darüber hinaus wird jeder Amazon-EKS-Cluster in einer isolierten VPC mit clusterspezifischen virtuellen Rechnern ausgeführt. Aufgrund dieser Architektur und unserer Praktiken im Bereich der Betriebssicherheit hat Amazon EKS [mehrere Compliance-Bewertungen und -Standards](https://docs.aws.amazon.com/eks/latest/userguide/compliance.html) erreicht, darunter SOC 1, 2, 3, PCI-DSS, ISO und HIPAA-Konformität. Diese Compliance-Bewertungen und -Standards gelten für alle EKS-Cluster, unabhängig davon, ob sie über eine standardmäßige Umschlagverschlüsselung verfügen oder nicht.
### Wie funktioniert die Umschlagverschlüsselung in Amazon EKS?
Beim Startup generiert der Cluster-API-Server einen Datenverschlüsselungsschlüssel (DEK) aus einem geheimen Startup-Wert in Kombination mit zufällig generierten Daten. Außerdem ruft der API-Server beim Start das KMS-Plug-In auf, um den DEK mit einem Remote Key Encryption Key (KEK) von AWS KMS zu verschlüsseln. Dies ist ein einmaliger Aufruf, der beim Startup des API-Servers und bei der KEK-Rotation ausgeführt wird. Der API-Server speichert dann den verschlüsselten DEK-Seed im Cache. Danach verwendet der API-Server den zwischengespeicherten DEK-Seed, um auf der DEKs Grundlage einer Key Derivation Function (KDF) weitere einmalige Verwendungszwecke zu generieren. Jede dieser generierten Ressourcen DEKs wird dann nur einmal verwendet, um eine einzelne Kubernetes-Ressource zu verschlüsseln, bevor sie in etcd gespeichert wird.
Es ist wichtig zu beachten, dass vom API-Server zusätzliche Aufrufe getätigt werden, um den Zustand und die normale Funktionalität der KMS-Integration zu überprüfen. AWS Diese zusätzlichen Gesundheitschecks sind in Ihrem sichtbar AWS CloudTrail.
### Muss ich irgendwelche Maßnahmen ergreifen oder Berechtigungen ändern, damit dieses Feature in meinem EKS-Cluster funktioniert?
Nein, Sie müssen keine Maßnahmen ergreifen. Umschlagverschlüsselung in Amazon EKS ist nun eine Standardkonfiguration, die in allen Clustern mit Kubernetes Version 1.28 oder höher aktiviert ist. Die AWS KMS-Integration wird durch den Kubernetes-API-Server eingerichtet, der von verwaltet wird. AWS Das bedeutet, dass Sie keine Berechtigungen konfigurieren müssen, um die KMS-Verschlüsselung für Ihren Cluster zu verwenden.
### Wie kann ich feststellen, ob die standardmäßige Umschlagverschlüsselung in meinem Cluster aktiviert ist?
Wenn Sie auf die Verwendung Ihres eigenen CMK umstellen, wird Ihnen die ARN des mit Ihrem Cluster verknüpften KMS-Schlüssels angezeigt. Darüber hinaus können Sie die AWS CloudTrail Ereignisprotokolle anzeigen, die mit der Verwendung des CMK Ihres Clusters verknüpft sind.
Wenn Ihr Cluster einen AWS eigenen Schlüssel verwendet, wird dies in der EKS-Konsole detailliert beschrieben (mit Ausnahme des ARN des Schlüssels).
### Kann ich AWS auf den AWS eigenen Schlüssel zugreifen, der für die Standard-Umschlagverschlüsselung in Amazon EKS verwendet wird?
Nein. AWS verfügt über strenge Sicherheitskontrollen in Amazon EKS, die verhindern, dass Personen auf Klartext-Verschlüsselungsschlüssel zugreifen, die zur Sicherung von Daten in der etcd-Datenbank verwendet werden. Diese Sicherheitsmaßnahmen werden auch auf den AWS eigenen KMS-Schlüssel angewendet.
### Ist die standardmäßige Umschlagverschlüsselung in meinem vorhandenen EKS-Cluster aktiviert?
Wenn Sie einen Amazon-EKS-Cluster mit Kubernetes-Version 1.28 oder höher ausführen, ist die Umschlagverschlüsselung aller Kubernetes-API-Daten aktiviert. Für bestehende Cluster verwendet Amazon EKS den `eks:kms-storage-migrator` RBAC, ClusterRole um Daten, die zuvor nicht in etcd umhüllt waren, in diesen neuen Verschlüsselungsstatus zu migrieren.
### Was bedeutet das, wenn ich die Umschlagverschlüsselung für Geheimnisse in meinem EKS-Cluster bereits aktiviert habe?
Wenn Sie über einen vorhandenen kundenseitig verwalteten Schlüssel (CMK) in KMS verfügen, der zur Umschlagverschlüsselung Ihrer Kubernetes-Geheimnisse verwendet wurde, wird derselbe Schlüssel als KEK für die Umschlagverschlüsselung aller Kubernetes-API-Datentypen in Ihrem Cluster verwendet.
### Entstehen zusätzliche Kosten für den Betrieb eines EKS-Clusters mit standardmäßiger Umschlagverschlüsselung?
Es fallen keine zusätzlichen Kosten für die verwaltete Kubernetes-Steuerebene an, wenn Sie einen [Schlüssel von Amazon Web Services](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk) für die standardmäßige Umschlagverschlüsselung verwenden. Standardmäßig verwendet jeder EKS-Cluster, auf dem Kubernetes Version 1.28 oder höher ausgeführt wird, einen [Schlüssel von Amazon Web Services](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk). Wenn Sie jedoch Ihren eigenen AWS KMS-Schlüssel verwenden, gelten die normalen [KMS-Preise](https://aws.amazon.com/kms/pricing/).
### Wie viel kostet es, meinen eigenen AWS KMS-Schlüssel zur Verschlüsselung von Kubernetes-API-Daten in meinem Cluster zu verwenden?
Sie zahlen 1 USD pro Monat für die Speicherung aller benutzerdefinierten Schlüssel, die Sie erstellen oder in KMS importieren. KMS berechnet Gebühren für Verschlüsselungs- und Entschlüsselungsanfragen. Es gibt ein kostenloses Kontingent von 20 000 Anfragen pro Monat und Konto. Für 10 000 Anfragen über das kostenlose Kontingent hinaus zahlen Sie 0,03 USD pro Monat. Dies gilt für die gesamte KMS-Nutzung für ein Konto, sodass die Kosten für die Verwendung Ihres eigenen AWS KMS-Schlüssels in Ihrem Cluster durch die Verwendung dieses Schlüssels in anderen Clustern oder AWS Ressourcen innerhalb Ihres Kontos beeinflusst werden.
### Werden meine KMS-Gebühren jetzt höher sein, da mein kundenseitig verwalteter Schlüssel (CMK) zur Umschlagverschlüsselung aller Kubernetes-API-Daten und nicht nur von Geheimnissen verwendet wird?
Nein. Unsere Implementierung mit KMS v2 reduziert die Anzahl der Anrufe an AWS KMS erheblich. Dies wird wiederum die mit Ihrem CMK verbundenen Kosten senken, unabhängig davon, ob zusätzliche Kubernetes-Daten in Ihrem EKS-Cluster verschlüsselt oder entschlüsselt werden.
Wie oben beschrieben, wird der generierte DEK-Seed, der für die Verschlüsselung von Kubernetes-Ressourcen verwendet wird, lokal im Cache des Kubernetes-API-Servers gespeichert, nachdem er mit dem KEK aus der Ferne verschlüsselt wurde. Wenn sich der verschlüsselte DEK-Seed nicht im Cache des API-Servers befindet, ruft der API-Server AWS KMS auf, um den DEK-Seed zu verschlüsseln. Der API-Server speichert dann den verschlüsselten DEK-Seed für die zukünftige Verwendung im Cluster im Cache, ohne KMS aufzurufen. In ähnlicher Weise ruft der API-Server bei Entschlüsselungsanforderungen AWS KMS für die erste Entschlüsselungsanforderung auf. Danach wird der entschlüsselte DEK-Seed zwischengespeichert und für future Entschlüsselungsvorgänge verwendet.
Weitere Informationen finden Sie unter [KEP-3299: KMS v2-Verbesserungen in den Kubernetes-Erweiterungen](https://github.com/kubernetes/enhancements/tree/master/keps/sig-auth/3299-kms-v2-improvements) unter. GitHub
### Kann ich denselben CMK-Schlüssel für mehrere Amazon-EKS-Cluster verwenden?
Ja. Um einen Schlüssel erneut zu verwenden, können Sie ihn einem Cluster in derselben Region zuordnen, indem Sie die ARN bei der Erstellung dem Cluster zuweisen. Wenn Sie jedoch denselben CMK für mehrere EKS-Cluster verwenden, sollten Sie die erforderlichen Maßnahmen ergreifen, um eine willkürliche Deaktivierung des CMK zu verhindern. Andernfalls hat ein deaktivierter CMK, der mehreren EKS-Clustern zugeordnet ist, je nach Schlüssel einen größeren Einflussbereich auf die Cluster.
### Was geschieht mit meinem EKS-Cluster, wenn mein CMK nach der Aktivierung der standardmäßigen Umschlagverschlüsselung nicht mehr verfügbar ist?
Wenn Sie einen KMS-Schlüssel deaktivieren, kann dieser für keine [kryptografischen Vorgänge](https://docs.aws.amazon.com/kms/latest/developerguide/kms-cryptography.html#cryptographic-operations) mehr verwendet werden Ohne Zugriff auf einen vorhandenen CMK kann der API-Server keine neu erstellten Kubernetes-Objekte verschlüsseln und speichern sowie zuvor verschlüsselte Kubernetes-Objekte, die in etcd gespeichert sind, entschlüsseln Wenn der CMK deaktiviert ist, wird der Cluster sofort in einen unhealthy/degraded Zustand versetzt, in dem wir unsere [Serviceverpflichtung](https://aws.amazon.com/eks/sla/) erst erfüllen können, wenn Sie den zugehörigen CMK erneut aktivieren.
Wenn ein CMK deaktiviert wird, erhalten Sie Benachrichtigungen über den beeinträchtigten Zustand Ihres EKS-Clusters und die Notwendigkeit, Ihr CMK innerhalb von 30 Tagen nach der Deaktivierung wieder zu aktivieren. Damit können Sie die erfolgreiche Wiederherstellung Ihrer Kubernetes-Steuerebenen-Ressourcen sicherstellen.
### Wie kann ich meinen EKS-Cluster vor den Auswirkungen eines CMK schützen? disabled/deleted
Um Ihre EKS-Cluster vor solchen Vorfällen zu schützen, sollten Ihre Schlüsseladministratoren den Zugriff auf KMS-Schlüsseloperationen mithilfe von IAM-Richtlinien nach dem Prinzip der geringsten Berechtigungen verwalten. Dadurch wird das Risiko einer willkürlichen Deaktivierung oder Löschung von Schlüsseln im Zusammenhang mit EKS-Clustern verringert. Darüber hinaus können Sie einen [CloudWatch Alarm](https://docs.aws.amazon.com/kms/latest/developerguide/deleting-keys-creating-cloudwatch-alarm.html) einrichten, um über den Status Ihres CMK informiert zu werden.
### Wird mein EKS-Cluster wiederhergestellt, wenn ich den CMK erneut aktiviere?
Um eine erfolgreiche Wiederherstellung Ihres EKS-Clusters zu gewährleisten, empfehlen wir nachdrücklich, Ihren CMK innerhalb der ersten 30 Tage nach seiner Deaktivierung wieder zu aktivieren. Die erfolgreiche Wiederherstellung Ihres EKS-Clusters hängt jedoch auch davon ab, ob er aufgrund eines automatischen Kubernetes-Upgrades, das möglicherweise stattfindet, während sich der Cluster in einem Status befindet, Änderungen erfährt, die die API beeinträchtigen. unhealthy/degraded
### Warum wird mein EKS-Cluster nach der Deaktivierung des CMK in einen unhealthy/degraded Zustand versetzt?
Der API-Server der EKS-Steuerebene verwendet einen DEK-Schlüssel, der verschlüsselt und im Speicher des API-Servers zwischengespeichert wird, um alle Objekte während des create/update Betriebs zu verschlüsseln, bevor sie in etcd gespeichert werden. Wenn ein vorhandenes Objekt aus etcd abgerufen wird, verwendet der API-Server denselben zwischengespeicherten DEK-Schlüssel und entschlüsselt das Kubernetes-Ressourcenobjekt. Wenn Sie den CMK deaktivieren, hat dies keine unmittelbaren Auswirkungen auf den API-Server, da der DEK-Schlüssel im Speicher des API-Servers zwischengespeichert ist. Wenn die API-Serverinstanz jedoch neu gestartet wird, hat sie kein zwischengespeichertes DEK und muss AWS KMS für Verschlüsselungs- und Entschlüsselungsvorgänge aufrufen. Ohne CMK schlägt dieser Vorgang mit dem Fehlercode KMS\$1KEY\$1DISABLED fehl, wodurch der erfolgreiche Start des API-Servers verhindert wird.
### Was passiert mit meinem EKS-Cluster, wenn ich meinen CMK lösche?
Das Löschen des zugehörigen CMK-Schlüssels Ihres EKS-Clusters beeinträchtigt dessen Integrität irreparabel. Ohne den CMK Ihres Clusters kann der API-Server keine neuen Kubernetes-Objekte mehr verschlüsseln und speichern sowie zuvor verschlüsselte Kubernetes-Objekte, die in der etcd-Datenbank gespeichert sind, nicht mehr entschlüsseln. Sie sollten mit dem Löschen eines CMK-Schlüssels für Ihren EKS-Cluster nur fortfahren, wenn Sie sicher sind, dass Sie den EKS-Cluster nicht mehr benötigen.
Beachten Sie, dass Ihr Cluster nicht wiederhergestellt werden kann, wenn der CMK nicht gefunden wird (KMS\$1KEY\$1NOT\$1FOUND) oder die Berechtigungen für den mit Ihrem Cluster verknüpften CMK widerrufen werden (KMS\$1GRANT\$1REVOKED). Weitere Informationen zum Clusterstatus und zu Fehlercodes finden Sie unter [Clusterintegritäts FAQs - und Fehlercodes](https://docs.aws.amazon.com/eks/latest/userguide/troubleshooting.html#cluster-health-status) mit Lösungspfaden.
### Fallen mir trotzdem Gebühren für einen degraded/unhealthy EKS-Cluster an, weil ich meinen CMK deaktiviert oder gelöscht habe?
Ja. Obwohl die EKS-Kontrollebene im Falle eines deaktivierten CMK nicht verwendet werden kann, AWS werden weiterhin dedizierte Infrastrukturressourcen ausgeführt, die dem EKS-Cluster zugewiesen sind, bis sie vom Kunden gelöscht werden. Darüber hinaus gilt unsere [Serviceverpflichtung](https://aws.amazon.com/eks/sla/) in einem solchen Fall nicht, da es sich um eine freiwillige Handlung oder Unterlassung des Kunden handelt, die den normalen Zustand und Betrieb Ihres EKS-Clusters beeinträchtigt.
### Kann mein EKS-Cluster automatisch aktualisiert werden, wenn er sich aufgrund eines deaktivierten CMK in einem unhealthy/degraded Zustand befindet?
Ja. Wenn Ihr Cluster jedoch über einen deaktivierten CMK verfügt, haben Sie 30 Tage Zeit, ihn wieder zu aktivieren In diesem Zeitraum von 30 Tagen wird Ihr Kubernetes-Cluster nicht automatisch aktualisiert. Wenn dieser Zeitraum jedoch abläuft und Sie den CMK nicht wieder aktiviert haben, wird der Cluster gemäß dem Kubernetes-Versionslebenszyklus in EKS automatisch auf die nächste Version (n\$11) aktualisiert, die im Standard-Support enthalten ist.
Wir empfehlen nachdrücklich, einen deaktivierten CMK umgehend wieder zu aktivieren, sobald Sie einen betroffenen Cluster bemerken. Es ist wichtig zu beachten, dass EKS diese betroffenen Cluster zwar automatisch aktualisiert, jedoch keine Garantie für eine erfolgreiche Wiederherstellung besteht. Dies trifft insbesondere dann zu, wenn der Cluster mehrere automatische Upgrades durchläuft, da dies Änderungen an der Kubernetes-API und unerwartetes Verhalten im Bootstrap-Prozess des API-Servers zur Folge haben kann.
### Kann ich einen KMS-Schlüssel-Alias verwenden?
Ja. Amazon EKS [unterstützt die Verwendung von KMS-Schlüssel-Aliasen](https://docs.aws.amazon.com/eks/latest/APIReference/API_EncryptionConfig.html#API_EncryptionConfig_Contents). Ein Alias ist ein benutzerfreundlicher Name für einen [KMS-Schlüssel für Amazon Web Service](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#kms_keys). Mit einem Alias können Sie beispielsweise auf einen KMS-Schlüssel als **my-key** anstelle von ** `1234abcd-12ab-34cd-56ef-1234567890ab` ** verweisen.
### Kann ich meine Cluster-Ressourcen weiterhin mit meiner eigenen Kubernetes-Backup-Lösung sichern und wiederherstellen?
Ja. Sie können eine Kubernetes-Backup-Lösung (wie [Velero)](https://velero.io/) für die Notfallwiederherstellung, Datenmigration und Datensicherung von Kubernetes-Clustern verwenden. Wenn Sie eine Kubernetes-Backup-Lösung verwenden, die über den API-Server auf die Cluster-Ressourcen zugreift, werden alle Daten, die die Anwendung abruft, entschlüsselt, bevor sie den Client erreichen. Auf diese Weise können Sie die Cluster-Ressourcen in einem anderen Kubernetes-Cluster wiederherstellen.
# Sicherheitsüberlegungen für Amazon EKS Auto Mode
In diesem Thema werden die Sicherheitsarchitektur, die Steuerungen und die bewährten Verfahren für Amazon EKS Auto Mode beschrieben. Da Unternehmen containerisierte Anwendungen in großem Umfang einsetzen, wird es immer komplexer, eine starke Sicherheitslage aufrechtzuerhalten. EKS Auto Mode implementiert automatisierte Sicherheitskontrollen und lässt sich in AWS-Sicherheitsservices integrieren, um Sie beim Schutz Ihrer Cluster-Infrastruktur, Workloads und Daten zu unterstützen. Durch integrierte Sicherheitsfeatures wie die erzwungene Verwaltung des Knotenlebenszyklus und die automatisierte Bereitstellung von Patches unterstützt Sie EKS Auto Mode dabei, bewährte Sicherheitsverfahren einzuhalten und gleichzeitig den Betriebsaufwand zu reduzieren.
Bevor Sie mit diesem Thema fortfahren, stellen Sie sicher, dass Sie mit den grundlegenden Konzepten von EKS Auto Mode vertraut sind und die Voraussetzungen für die Aktivierung von EKS Auto Mode in Ihren Clustern überprüft haben. Allgemeine Informationen zur Sicherheit von Amazon EKS finden Sie unter [Sicherheit in Amazon EKs](security.md).
Amazon EKS Auto Mode basiert auf den bestehenden Sicherheitsgrundlagen von Amazon EKS und führt zusätzliche automatisierte Sicherheitskontrollen für von EC2 verwaltete Instances ein.
## API-Sicherheit und Authentifizierung
Amazon EKS Auto Mode nutzt AWS-Plattform-Sicherheitsmechanismen, um Aufrufe an die Amazon-EKS-API zu sichern und zu authentifizieren.
+ Der Zugriff auf die Kubernetes-API wird durch EKS-Zugriffseinträge gesichert, die in AWS-IAM-Identitäten integriert sind.
+ Weitere Informationen finden Sie unter [IAM-Benutzern mit EKS-Zugriffseinträgen Zugriff auf Kubernetes gewähren](access-entries.md).
+ Kunden können durch die Konfiguration von EKS-Zugriffseinträgen eine detaillierte Zugriffskontrolle für den Kubernetes-API-Endpunkt implementieren.
## Netzwerksicherheit
Amazon EKS Auto Mode unterstützt mehrere Ebenen der Netzwerksicherheit:
+ **VPC-Integration**
+ Funktioniert innerhalb Ihrer Amazon Virtual Private Cloud (VPC)
+ Unterstützt benutzerdefinierte VPC-Konfigurationen und Subnetz-Layouts
+ Ermöglicht private Netzwerke zwischen Cluster-Komponenten
+ Weitere Informationen finden Sie unter [Verwaltung von Sicherheitsaufgaben für Amazon Virtual Private Cloud](https://docs.aws.amazon.com/vpc/latest/userguide/security.html)
+ **Netzwerkrichtlinien**
+ Nativer Support für Kubernetes-Netzwerkrichtlinien
+ Möglichkeit zur Definition detaillierter Regeln für den Netzwerk-Datenverkehr
+ Weitere Informationen finden Sie unter [Begrenzen Sie den Pod-Datenverkehr mit Kubernetes-Netzwerkrichtlinien.](cni-network-policy.md).
## Sicherheit für verwaltete EC2-Instances
Amazon EKS Auto Mode betreibt verwaltete EC2-Instances mit den folgenden Sicherheitskontrollen:
### EC2-Sicherheit
+ Verwaltete EC2-Instances bieten die gleichen Sicherheitsfeature wie Amazon EC2.
+ Weitere Informationen zu verwalteten EC2-Instances finden Sie unter [Sicherheit in Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security.html).
### Lebenszyklusmanagement von Instances
Von EKS Auto Mode betriebene verwaltete EC2-Instances haben eine maximale Lebensdauer von 21 Tagen. Amazon EKS Auto Mode beendet automatisch Instances, die diese Lebensdauer überschreiten. Diese Lebenszyklusbeschränkung trägt dazu bei, Konfigurationsabweichungen zu verhindern und die Sicherheitslage aufrechtzuerhalten.
### Datenschutz
+ Der Speicher der Amazon-EC2-Instance ist verschlüsselt. Es handelt sich hierbei um Speicher, der direkt mit der Instance verbunden ist. Weitere Informationen finden Sie unter [Datenschutz in Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/data-protection.html).
+ EKS Auto Mode verwaltet die bei der Erstellung an EC2-Instances angefügten Volumes, einschließlich Root- und Daten-Volumes. EKS Auto Mode verwaltet EBS-Volumes, die mit den persistenten Speicherfunktionen von Kubernetes erstellt wurden, nicht vollständig.
### Patch-Management
+ Amazon EKS Auto Mode wendet automatisch Patches auf verwaltete Instances an.
+ Patches beinhalten:
+ Betriebssystemupdates
+ Sicherheits-Patches
+ Komponenten von Amazon EKS Auto Mode
**Anmerkung**
Kunden sind weiterhin für die Sicherung und Aktualisierung der in diesen Instances ausgeführten Workloads verantwortlich.
### Zugriffskontrollen
+ Der direkte Instance-Zugriff ist eingeschränkt:
+ SSH-Zugriff ist nicht verfügbar.
+ Der Zugriff auf AWS Systems Manager Session Manager (SSM) ist nicht verfügbar.
+ Managementoperationen werden über die Amazon-EKS-API und die Kubernetes-API durchgeführt.
## Automatisiertes Ressourcenmanagement
Amazon EKS Auto Mode verwaltet Amazon Elastic Block Store (Amazon EBS)-Volumes, die mit den persistenten Speicherfunktionen von Kubernetes erstellt wurden, nicht vollständig. EKS Auto Mode verwaltet auch keine Elastic Load Balancers (ELB). Amazon EKS Auto Mode automatisiert Routineaufgaben für diese Ressourcen.
### Speichersicherheit
+ AWS empfiehlt, die Verschlüsselung für EBS-Volumes zu aktivieren, die durch persistente Speicher-Features von Kubernetes bereitgestellt werden. Weitere Informationen finden Sie unter [Erstellen einer Speicherklasse](create-storage-class.md).
+ Verschlüsselung im Ruhezustand mit AWS KMS
+ Sie können Ihr AWS-Konto so konfigurieren, dass es die Verschlüsselung neuer EBS-Volumes und Snapshot-Kopien erzwingt, die Sie erstellen. Weitere Informationen finden Sie unter [Amazon-EBS-Verschlüsselung standardmäßig aktivieren](https://docs.aws.amazon.com/ebs/latest/userguide/encryption-by-default.html) im Amazon-EBS-Benutzerhandbuch.
+ Weitere Informationen finden Sie unter [Sicherheit in Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/security.html).
### Load-Balancer-Sicherheit
+ Automatisierte Konfiguration von Elastic Load Balancers
+ Verwaltung von SSL/TLS-Zertifikaten durch Integration des AWS-Zertifikatsmanagers
+ Automatisierung von Sicherheitsgruppen für die Zugriffskontrolle des Load Balancers
+ Weitere Informationen finden Sie unter [Sicherheit in Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/security.html).
## Bewährte Methoden für die Gewährleistung der Sicherheit
Der folgende Abschnitt beschreibt bewährte Sicherheitsmethoden für Amazon EKS Auto Mode.
+ Überprüfen Sie regelmäßig die AWS-IAM-Richtlinien und EKS-Zugriffseinträge.
+ Implementieren Sie Zugriffsmuster mit geringsten Berechtigungen für Workloads.
+ Überwachen Sie die Cluster-Aktivität über AWS CloudTrail und Amazon CloudWatch. Weitere Informationen erhalten Sie unter [API-Aufrufe als AWS-CloudTrail-Ereignisse protokollieren](logging-using-cloudtrail.md) und [Überwachen Sie Clusterdaten mit Amazon CloudWatch](cloudwatch.md).
+ Verwenden Sie AWS Security Hub zur Bewertung der Sicherheitslage.
+ Implementieren Sie Pod-Sicherheitsstandards, die für Ihre Workloads geeignet sind.
# Sicherheitsüberlegungen für EKS-Funktionen
In diesem Thema werden wichtige Sicherheitsaspekte für EKS-Funktionen behandelt, darunter die IAM-Rollenkonfiguration, Kubernetes-Berechtigungen und Architekturmuster für Bereitstellungen mit mehreren Clustern und kontenübergreifendes Ressourcenmanagement. AWS
EKS-Funktionen verwenden eine Kombination aus IAM-Rollen, EKS-Zugriffseinträgen und Kubernetes RBAC, um sicheren Zugriff auf AWS Dienste, Cluster-Kubernetes-Ressourcen und Integrationen mit Secrets Manager und anderen Diensten zu ermöglichen. AWS CodeConnections AWS AWS
## Fähigkeit: IAM-Rolle
Wenn Sie eine Funktion erstellen, geben Sie eine IAM-Fähigkeitsrolle an, die EKS verwendet, um Aktionen in Ihrem Namen auszuführen. Diese Rolle muss:
+ Sie müssen sich im selben AWS Konto befinden wie der Cluster und die Capability-Ressource
+ Verfügen Sie über eine Vertrauensrichtlinie, die es dem `capabilities.eks.amazonaws.com` Dienstprinzipal ermöglicht, die Rolle zu übernehmen
+ Verfügen Sie je nach Ihren Anforderungen über IAM-Berechtigungen, die für den Funktionstyp und den Anwendungsfall geeignet sind. Ausführliche Informationen zu den erforderlichen IAM-Berechtigungen finden Sie unter[Connect zu Git-Repositorys her mit AWS CodeConnections](integration-codeconnections.md), und [Anwendungsgeheimnisse mit AWS Secrets Manager verwalten](integration-secrets-manager.md) [ACK-Berechtigungen konfigurieren](ack-permissions.md)
Es hat sich bewährt, den Umfang der für Ihren speziellen Anwendungsfall erforderlichen Rechte zu berücksichtigen und nur die Berechtigungen zu gewähren, die für Ihre Anforderungen erforderlich sind. Wenn Sie beispielsweise die EKS-Funktion für Kube Resource Orchestrator verwenden, sind möglicherweise keine IAM-Berechtigungen erforderlich, während Sie bei Verwendung der EKS-Funktion für AWS Controller für Kubernetes Vollzugriff auf einen oder mehrere Dienste gewähren können. AWS
**Wichtig**
In einigen Anwendungsfällen kann die Verwendung umfassender Administratorrechte gerechtfertigt sein. Folgen Sie jedoch dem Prinzip der geringsten Rechte, indem Sie nur die für Ihren speziellen Anwendungsfall erforderlichen IAM-Berechtigungen gewähren ARNs und den Zugriff auf bestimmte Ressourcen mithilfe von Bedingungsschlüsseln einschränken, anstatt Platzhalterberechtigungen zu verwenden.
Ausführliche Informationen zum Erstellen und Konfigurieren von Capability-IAM-Rollen finden Sie unter. [IAM-Rolle für Amazon EKS-Funktionen](capability-role.md)
## EKS-Zugriffseinträge
Wenn Sie eine Funktion mit einer IAM-Rolle erstellen, erstellt Amazon EKS automatisch einen Zugriffseintrag für diese Rolle in Ihrem Cluster. Dieser Zugriffseintrag gewährt der Fähigkeit grundlegende Funktionsberechtigungen für Kubernetes.
**Anmerkung**
Zugriffseinträge werden für den Cluster erstellt, in dem die Funktion erstellt wurde. Für Argo-CD-Bereitstellungen auf Remote-Clustern müssen Sie Zugriffseinträge auf diesen Clustern mit den entsprechenden Berechtigungen für die Argo-CD-Funktion erstellen, um Anwendungen bereitzustellen und zu verwalten.
Der Zugriffseintrag umfasst:
+ Die IAM-Rolle ARN als Principal
+ Funktionsspezifische Zugriffsrichtlinien, die grundlegende Kubernetes-Berechtigungen gewähren
+ Angemessener Geltungsbereich (clusterweit oder namespace-bezogen) je nach Funktionstyp
**Anmerkung**
Für Argo CD werden namespace-bezogene Berechtigungen für den in der Capability-Konfiguration angegebenen Namespace gewährt (standardmäßig). `argocd`
**Standardrichtlinien für den Zugriff nach Fähigkeit**
Jeder Funktionstyp gewährt der Funktionsrolle die erforderlichen Berechtigungen, wobei unterschiedliche Standardzugriffsrichtlinien wie folgt festgelegt werden:
**kro**
+ `arn:aws:eks::aws:cluster-access-policy/AmazonEKSKROPolicy`(im Clusterbereich)
Erteilt Berechtigungen zum Überwachen, Verwalten ResourceGraphDefinitions und Erstellen von Instanzen benutzerdefinierter Ressourcen, die von definiert sind. RGDs
**ZURÜCK**
+ `arn:aws:eks::aws:cluster-access-policy/AmazonEKSACKPolicy`(im Clusterbereich)
Erteilt Berechtigungen zum Erstellen, Lesen, Aktualisieren und Löschen von benutzerdefinierten ACK-Ressourcen in allen Namespaces.
**Argo-CD**
+ `arn:aws:eks::aws:cluster-access-policy/AmazonEKSArgoCDClusterPolicy`(im Clusterbereich)
Gewährt Argo CD Berechtigungen auf Clusterebene, um Ressourcen zu ermitteln und Objekte im Clusterbereich zu verwalten.
+ `arn:aws:eks::aws:cluster-access-policy/AmazonEKSArgoCDPolicy`(mit Namespace-Bereich)
Gewährt Argo CD Berechtigungen auf Namespace-Ebene zur Bereitstellung und Verwaltung von Anwendungen. Gültig für den in der Capability-Konfiguration angegebenen Namespace (standardmäßig). `argocd`
Weitere Informationen finden Sie unter[Berechtigungen von Zugriffsrichtlinien überprüfen](access-policy-permissions.md).
## Zusätzliche Kubernetes-Berechtigungen
Für einige Funktionen sind möglicherweise zusätzliche Kubernetes-Berechtigungen erforderlich, die über die standardmäßigen Zugriffsrichtlinien hinausgehen. Sie können diese Berechtigungen auf folgende Weise gewähren:
+ **Richtlinien für den Zugriff**: Ordnen Sie dem Zugriffseintrag zusätzliche verwaltete Richtlinien zu
+ **Kubernetes RBAC**: Erstellen `Role` oder `ClusterRole` Bindungen für den Kubernetes-Benutzer der Funktion
**Geheime ACK-Leserberechtigungen**
Einige ACK-Controller müssen Kubernetes-Geheimnisse lesen, um sensible Daten wie Datenbankpasswörter abzurufen. Die folgenden ACK-Controller benötigen geheimen Lesezugriff:
+ `acm`, `acmpca`, `documentdb`, `memorydb`, `mq`, `rds`, `secretsmanager`
So gewähren Sie geheime Leseberechtigungen:
1. Ordnen Sie die `arn:aws:eks::aws:cluster-access-policy/AmazonEKSSecretReaderPolicy` Zugriffsrichtlinie dem Zugriffseintrag der Funktion zu
1. Richten Sie die Richtlinie auf bestimmte Namespaces ein, in denen ACK-Ressourcen auf geheime Informationen verweisen oder clusterweiten Zugriff gewähren
**Wichtig**
Geheime Leseberechtigungen sind auf die Namespaces beschränkt, die Sie bei der Zuordnung der Zugriffsrichtlinie angeben. Auf diese Weise können Sie einschränken, auf welche Geheimnisse die Fähigkeit zugreifen kann.
**kro, beliebige Ressourcenberechtigungen.**
kro benötigt Berechtigungen zum Erstellen und Verwalten der in Ihrem definierten Ressourcen. ResourceGraphDefinitions Standardmäßig kann Kro nur sich selbst überwachen und verwalten RGDs .
So gewähren Sie Kro-Berechtigungen zum Erstellen von Ressourcen:
**Option 1: Zugriffsrichtlinien**
Ordnen Sie vordefinierte Zugriffsrichtlinien wie `AmazonEKSAdminPolicy` oder `AmazonEKSEditPolicy` dem Zugriffseintrag der Funktion zu.
**Option 2: Kubernetes RBAC**
Erstellen Sie eine`ClusterRoleBinding`, die dem Kubernetes-Benutzer der Funktion die erforderlichen Berechtigungen gewährt:
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: kro-cluster-admin
subjects:
- kind: User
name: arn:aws:sts::111122223333:assumed-role/my-kro-role/KRO
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: cluster-admin
apiGroup: rbac.authorization.k8s.io
```
**Anmerkung**
Der Kubernetes-Benutzername für kro folgt dem Muster: `arn:aws:sts::ACCOUNT_ID:assumed-role/ROLE_NAME/KRO`
Der Sitzungsname `/KRO` (in Großbuchstaben) wird automatisch von der EKS-Kro-Fähigkeit festgelegt.
## Je nach Funktion sind IAM-Berechtigungen erforderlich
**kro (Kube Resource Orchestrator)**
Keine IAM-Berechtigungen erforderlich. Sie können eine Funktionsrolle ohne angehängte Richtlinien erstellen. kro benötigt nur Kubernetes-RBAC-Berechtigungen.
**ACK (Controller für Kubernetes)AWS **
Erfordert Berechtigungen zur Verwaltung der AWS Ressourcen, die ACK erstellt und verwaltet. Sie sollten die Berechtigungen auf bestimmte Dienste, Aktionen und Ressourcen auf der Grundlage Ihrer Anforderungen einschränken. Ausführliche Informationen zur Konfiguration von ACK-Berechtigungen, einschließlich bewährter Produktionsmethoden mit IAM-Rollenselektoren, finden Sie unter. [ACK-Berechtigungen konfigurieren](ack-permissions.md)
**Argo CD**
Standardmäßig sind keine IAM-Berechtigungen erforderlich. Optionale Berechtigungen können erforderlich sein für:
+ AWS Secrets Manager: Wenn die Anmeldeinformationen für das Git-Repository in Secrets Manager gespeichert werden
+ AWS CodeConnections: Bei Verwendung CodeConnections für die Git-Repository-Authentifizierung
+ Amazon ECR: Wenn Sie Helm-Diagramme verwenden, die im OCI-Format in Amazon ECR gespeichert sind
## Bewährte Methoden für die Gewährleistung der Sicherheit
### IAM hat das geringste Privileg
Gewähren Sie Ihren Capability-Ressourcen nur die Berechtigungen, die für Ihren Anwendungsfall erforderlich sind. Dies bedeutet nicht, dass Sie Ihren Fähigkeiten bei Bedarf keine umfassenden Administratorberechtigungen gewähren können. In solchen Fällen sollten Sie den Zugriff auf diese Ressourcen angemessen regeln.
**Fähigkeitsrollen**:
+ **ACK**: Beschränken Sie die IAM-Berechtigungen nach Möglichkeit auf bestimmte AWS Dienste und Ressourcen, die Ihre Teams benötigen, je nach Anwendungsfall und Anforderungen
+ **Argo CD**: Beschränken Sie den Zugriff auf bestimmte Git-Repositorys und Kubernetes-Namespaces
+ **kro**: Erfordert eine Capability-Rolle für die Vertrauensrichtlinie, es sind jedoch keine IAM-Berechtigungen erforderlich (verwendet nur Cluster-RBAC)
**Beispiel**: Geben Sie statt `"Resource": "*"` dessen Muster für bestimmte Ressourcen oder Ressourcengruppen an.
```
"Resource": [
"arn:aws:s3:::my-app-*",
"arn:aws:rds:us-west-2:111122223333:db:prod-*"
]
```
Verwenden Sie IAM-Bedingungsschlüssel, um den Zugriff weiter einzuschränken:
```
"Condition": {
"StringEquals": {
"aws:ResourceTag/Environment": "production"
}
}
```
Weitere Informationen zur IAM-Konfiguration finden Sie im Abschnitt mit den Überlegungen zu den einzelnen Funktionen.
### Namespace-Isolierung für Argo-CD-Geheimnisse
Die verwaltete Argo-CD-Funktion hat Zugriff auf alle Kubernetes-Secrets innerhalb des konfigurierten Namespace (Standard:). `argocd` Um ein optimales Sicherheitsniveau aufrechtzuerhalten, befolgen Sie die folgenden Methoden zur Namespace-Isolierung:
+ Bewahren Sie nur Argo-CD-relevante Geheimnisse im Argo-CD-Namespace auf
+ Vermeiden Sie es, Anwendungsgeheimnisse, die nichts miteinander zu tun haben, im selben Namespace wie Argo-CD zu speichern
+ Verwenden Sie separate Namespaces für Anwendungsgeheimnisse, die für Argo-CD-Operationen nicht erforderlich sind
Diese Isolierung stellt sicher, dass der geheime Zugriff von Argo CD nur auf die Anmeldeinformationen beschränkt ist, die es für die Git-Repository-Authentifizierung und andere Argo-CD-spezifische Operationen benötigt.
### Kubernetes RBAC
Steuern Sie, welche Benutzer und Dienstkonten Funktionsressourcen erstellen und verwalten können. Es hat sich bewährt, Capability-Ressourcen in dedizierten Namespaces mit entsprechenden RBAC-Richtlinien bereitzustellen.
Beispiel: Die RBAC-Rolle funktioniert mit ACK und ermöglicht die S3-Bucket-Ressourcenverwaltung im Namespace: `app-team`
```
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: ack-s3-manager
namespace: app-team
rules:
- apiGroups: ["s3.services.k8s.aws"]
resources: ["buckets"]
verbs: ["get", "list", "create", "update", "delete"]
```
### Audit-Protokollierung
**CloudTrail**: Alle EKS-Capability-API-Operationen (Erstellen, Aktualisieren, Löschen) werden protokolliert. AWS CloudTrail
Aktivieren Sie die CloudTrail Protokollierung, um Folgendes zu verfolgen:
+ Wer hat Funktionen erstellt oder geändert
+ Wann sich die Funktionskonfigurationen geändert haben
+ Welche Funktionsrollen werden verwendet
### Netzwerkzugriff und VPC-Endpunkte
#### Privater Argo CD-API-Zugriff
Sie können den Zugriff auf den Argo CD API-Server einschränken, indem Sie einen oder mehrere VPC-Endpunkte mit dem gehosteten Argo CD-Endpunkt verknüpfen. Dies ermöglicht private Konnektivität innerhalb Ihrer VPC, ohne das öffentliche Internet zu durchqueren. Der VPC-Endpunkt bietet Zugriff sowohl auf die Argo CD-Weboberfläche als auch auf die Argo-CD-API (einschließlich CLI-Zugriff).
**Anmerkung**
VPC-Endpunkte, die mit gehosteten Argo CD-API-Endpunkten verbunden sind (unter Verwendung von eks-Capabilities). *region*.amazonaws.com) unterstützen keine VPC-Endpunktrichtlinien.
#### Bereitstellung auf privaten Clustern
Mit der Argo-CD-Funktion können Anwendungen auf vollständig privaten EKS-Clustern bereitgestellt werden, was einen erheblichen betrieblichen Vorteil bietet, da kein VPC-Peering oder komplexe Netzwerkkonfigurationen erforderlich sind. Beachten Sie beim Entwerfen dieser Architektur jedoch, dass Argo CD die Konfiguration aus Git-Repositorys (die möglicherweise öffentlich sein können) abruft und auf Ihre privaten Cluster anwendet.
Stellen Sie sicher, dass Sie:
+ Verwenden Sie private Git-Repositorys für sensible Workloads
+ Implementieren Sie die richtigen Zugriffskontrollen und Authentifizierung für das Git-Repository
+ Überprüfe und genehmige Änderungen mithilfe von Pull-Requests, bevor du sie zusammenführst
+ Erwägen Sie, die Synchronisierungsfenster von Argo CD zu verwenden, um zu kontrollieren, wann Bereitstellungen erfolgen können
+ Überwachen Sie die Audit-Logs von Argo CD auf unbefugte Konfigurationsänderungen
### Compliance
Die EKS-Funktionen werden vollständig verwaltet und verfügen über die Compliance-Zertifizierungen von Amazon EKS.
Aktuelle Compliance-Informationen finden Sie unter [AWS Services in Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/).
## Nächste Schritte
+ [ACK-Berechtigungen konfigurieren](ack-permissions.md)- Konfigurieren Sie IAM-Berechtigungen für ACK
+ [Kro-Berechtigungen konfigurieren](kro-permissions.md)- Konfigurieren Sie Kubernetes RBAC für Kro
+ [Argo-CD-Berechtigungen konfigurieren](argocd-permissions.md)- Konfigurieren Sie die Identity Center-Integration für Argo CD
+ [Problembehebung bei EKS-Funktionen](capabilities-troubleshooting.md)- Beheben Sie Sicherheits- und Berechtigungsprobleme
# Identitäts- und Zugriffsverwaltung für Amazon EKS
AWS Identity and Access Management (IAM) ist ein AWS Dienst, der einem Administrator hilft, den Zugriff auf AWS Ressourcen sicher zu kontrollieren. IAM-Administratoren kontrollieren, wer *authentifiziert* (angemeldet) und *autorisiert* (mit Berechtigungen ausgestattet) werden kann, um Amazon-EKS-Ressourcen zu nutzen. IAM ist ein AWS Dienst, den Sie ohne zusätzliche Kosten nutzen können.
## Zielgruppe
Wie Sie AWS Identity and Access Management (IAM) verwenden, hängt davon ab, welche Arbeit Sie in Amazon EKS ausführen.
**Service-Benutzer** – Wenn Sie den Amazon–EKS-Service zur Ausführung von Aufgaben verwenden, stellt Ihnen Ihr Administrator die Anmeldeinformationen und Berechtigungen bereit, die Sie benötigen. Je mehr Amazon-EKS-Funktionen Sie für Ihre Arbeit nutzen, desto mehr Berechtigungen benötigen Sie möglicherweise. Wenn Sie die Funktionsweise der Zugriffskontrolle nachvollziehen, wissen Sie bereits, welche Berechtigungen Sie von Ihrem Administrator anzufordern müssen. Unter [Fehlersuche bei IAM](security-iam-troubleshoot.md) finden Sie nützliche Informationen für den Fall, dass Sie keinen Zugriff auf eine Funktion in Amazon EKS haben.
**Service-Administrator** – Wenn Sie in Ihrem Unternehmen für die Amazon-EKS-Ressourcen zuständig sind, haben Sie wahrscheinlich vollständigen Zugriff auf Amazon EKS. Ihre Aufgabe besteht darin, zu bestimmen, auf welche Amazon-EKS-Features und -Ressourcen Ihre Servicebenutzer zugreifen sollen. Anschließend müssen Sie Anforderungen an Ihren IAM-Administrator senden, um die Berechtigungen der Servicebenutzer zu ändern. Lesen Sie die Informationen auf dieser Seite, um die Grundkonzepte von IAM nachzuvollziehen. Weitere Informationen dazu, wie Ihr Unternehmen IAM mit Amazon EKS verwenden kann, finden Sie unter [Funktionsweise von Amazon EKS mit IAM](security-iam-service-with-iam.md).
**IAM-Administrator** – Wenn Sie ein IAM-Administrator sind, möchten Sie vielleicht Details darüber erfahren, wie Sie Richtlinien zur Verwaltung des Zugriffs auf Amazon EKS erstellen können. Beispiele für identitätsbasierte Amazon-EKS-Richtlinien, die Sie in IAM verwenden können, finden Sie unter [Beispiele für identitätsbasierte Amazon-EKS-Richtlinien](security-iam-id-based-policy-examples.md).
## Authentifizierung mit Identitäten
Authentifizierung ist die Art und Weise, wie Sie sich AWS mit Ihren Identitätsdaten anmelden. Sie müssen als Root-Benutzer des AWS Kontos, als IAM-Benutzer oder durch Übernahme einer IAM-Rolle *authentifiziert* (angemeldet AWS) sein.
Sie können sich AWS als föderierte Identität anmelden, indem Sie Anmeldeinformationen verwenden, die über eine Identitätsquelle bereitgestellt wurden. AWS IAM Identity Center (IAM Identity Center) -Benutzer, die Single Sign-On-Authentifizierung Ihres Unternehmens und Ihre Google- oder Facebook-Anmeldeinformationen sind Beispiele für föderierte Identitäten. Wenn Sie sich als Verbundidentität anmelden, hat der Administrator vorher mithilfe von IAM-Rollen einen Identitätsverbund eingerichtet. Wenn Sie über den Verbund darauf zugreifen AWS , übernehmen Sie indirekt eine Rolle.
Je nachdem, welcher Benutzertyp Sie sind, können Sie sich beim AWS-Managementkonsole oder beim AWS Zugangsportal anmelden. Weitere Informationen zur Anmeldung finden Sie unter [So melden Sie sich bei Ihrem AWS Konto an](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) im * AWS Anmelde-Benutzerhandbuch*. AWS
Wenn Sie AWS programmgesteuert darauf zugreifen, AWS stellt es ein Software Development Kit (SDK) und eine Befehlszeilenschnittstelle (CLI) bereit, mit denen Sie Ihre Anfragen mithilfe Ihrer Anmeldeinformationen kryptografisch signieren können. Wenn Sie keine AWS Tools verwenden, müssen Sie Anfragen selbst signieren. Weitere Informationen zur Verwendung der empfohlenen Methode, um Anfragen selbst zu [signieren, finden Sie im *IAM-Benutzerhandbuch* unter AWS API-Anfragen](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-signing.html) signieren.
Unabhängig von der verwendeten Authentifizierungsmethode müssen Sie möglicherweise zusätzliche Sicherheitsinformationen bereitstellen. AWS Empfiehlt beispielsweise, die Multi-Faktor-Authentifizierung (MFA) zu verwenden, um die Sicherheit Ihres Kontos zu erhöhen. *Weitere Informationen finden Sie unter [Multi-Factor Authentication](https://docs.aws.amazon.com/singlesignon/latest/userguide/enable-mfa.html) im * AWS IAM Identity Center User Guide und Using* [Multi-Factor Authentication (MFA) AWS im](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html) IAM-Benutzerhandbuch.*
### AWS Konto (Root-Benutzer)
Wenn Sie ein AWS Konto erstellen, beginnen Sie mit einer einzigen Anmeldeidentität, die vollständigen Zugriff auf alle AWS Dienste und Ressourcen im Konto hat. Diese Identität wird als *Root-Benutzer* des AWS Kontos bezeichnet. Der Zugriff erfolgt, indem Sie sich mit der E-Mail-Adresse und dem Passwort anmelden, mit denen Sie das Konto erstellt haben. Wir raten ausdrücklich davon ab, den Root-Benutzer für alltägliche Aufgaben zu verwenden. Schützen Sie Ihre Root-Benutzer-Anmeldeinformationen. Verwenden Sie diese nur, um die Aufgaben auszuführen, die nur der Root-Benutzer ausführen kann. Eine vollständige Liste der Aufgaben, für die Sie sich als Root-Benutzer anmelden müssen, finden Sie unter [Aufgaben, die Root-Benutzer-Anmeldeinformationen erfordern](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) im *IAM-Benutzerhandbuch*.
### IAM-Benutzer und -Gruppen
Ein [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) ist eine Identität innerhalb Ihres AWS Kontos, die über spezifische Berechtigungen für eine einzelne Person oder Anwendung verfügt. Wenn möglich, empfehlen wir, temporäre Anmeldeinformationen zu verwenden, anstatt IAM-Benutzer zu erstellen, die langfristige Anmeldeinformationen wie Passwörter und Zugriffsschlüssel haben. Bei speziellen Anwendungsfällen, die langfristige Anmeldeinformationen mit IAM-Benutzern erfordern, empfehlen wir jedoch, die Zugriffsschlüssel zu rotieren. Weitere Informationen finden Sie unter [Regelmäßiges Rotieren von Zugriffsschlüsseln für Anwendungsfälle, die langfristige Anmeldeinformationen erfordern](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#rotate-credentials) im *IAM-Benutzerhandbuch*.
Eine [IAM-Gruppe](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) ist eine Identität, die eine Sammlung von IAM-Benutzern angibt. Sie können sich nicht als Gruppe anmelden. Mithilfe von Gruppen können Sie Berechtigungen für mehrere Benutzer gleichzeitig angeben. Gruppen erleichtern die Verwaltung von Berechtigungen für große Benutzergruppen. Sie könnten beispielsweise einer Gruppe einen Namen geben *IAMAdmins*und dieser Gruppe Berechtigungen zur Verwaltung von IAM-Ressourcen erteilen.
Benutzer sind nicht dasselbe wie Rollen. Ein Benutzer ist einer einzigen Person oder Anwendung eindeutig zugeordnet. Eine Rolle kann von allen Personen angenommen werden, die sie benötigen. Benutzer besitzen dauerhafte Anmeldeinformationen. Rollen stellen temporäre Anmeldeinformationen bereit. Weitere Informationen finden Sie unter [Erstellen eines IAM-Benutzers (anstatt einer Rolle)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose) im *IAM-Benutzerhandbuch*.
### IAM-Rollen
Eine [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) ist eine Identität innerhalb Ihres AWS Kontos, die über bestimmte Berechtigungen verfügt. Sie ist einem IAM-Benutzer vergleichbar, jedoch nicht mit einer bestimmten Person verknüpft. Sie können vorübergehend eine IAM-Rolle in der übernehmen, AWS-Managementkonsole indem Sie die Rollen [wechseln](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html). Sie können eine Rolle übernehmen, indem Sie eine AWS CLI- oder AWS API-Operation aufrufen oder eine benutzerdefinierte URL verwenden. Weitere Informationen zu Methoden für die Verwendung von Rollen finden Sie unter [Verwenden von IAM-Rollen](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use.html) im *IAM-Benutzerhandbuch*.
IAM-Rollen mit temporären Anmeldeinformationen sind in folgenden Situationen hilfreich:
+ **Verbundbenutzerzugriff** – Um einer Verbundidentität Berechtigungen zuzuweisen, erstellen Sie eine Rolle und definieren Berechtigungen für die Rolle. Wird eine Verbundidentität authentifiziert, so wird die Identität der Rolle zugeordnet und erhält die von der Rolle definierten Berechtigungen. Informationen zu Rollen für den Verbund finden Sie unter [Erstellen von Rollen für externe Identitätsanbieter](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp.html) im *IAM-Benutzerhandbuch*. Wenn Sie IAM Identity Center verwenden, konfigurieren Sie einen Berechtigungssatz. Wenn Sie steuern möchten, worauf Ihre Identitäten nach der Authentifizierung zugreifen können, korreliert IAM Identity Center den Berechtigungssatz mit einer Rolle in IAM. Informationen zu Berechtigungssätzen finden Sie unter [Berechtigungssätze](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html) im * AWS IAM Identity Center-Benutzerhandbuch*.
+ **Temporäre IAM-Benutzerberechtigungen** – Ein IAM-Benutzer oder eine -Rolle kann eine IAM-Rolle übernehmen, um vorübergehend andere Berechtigungen für eine bestimmte Aufgabe zu erhalten.
+ **Kontoübergreifender Zugriff** – Sie können eine IAM-Rolle verwenden, um einem vertrauenswürdigen Prinzipal in einem anderen Konto den Zugriff auf Ressourcen in Ihrem Konto zu ermöglichen. Rollen stellen die primäre Möglichkeit dar, um kontoübergreifendem Zugriff zu gewähren. Bei einigen AWS Diensten können Sie jedoch eine Richtlinie direkt an eine Ressource anhängen (anstatt eine Rolle als Proxy zu verwenden). Informationen zu den Unterschieden zwischen Rollen und ressourcenbasierten Richtlinien für den kontoübergreifenden Zugriff finden Sie unter [Kontoübergreifender Ressourcenzugriff in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) im *IAM-Benutzerhandbuch*.
+ **Serviceübergreifender Zugriff** — Einige AWS Dienste verwenden Funktionen in anderen AWS Diensten. Wenn Sie beispielsweise in einem Service einen Anruf tätigen, ist es üblich, dass dieser Service Anwendungen in Amazon ausführt EC2 oder Objekte in Amazon S3 speichert. Ein Service kann dies mithilfe der Berechtigungen des aufrufenden Prinzipals, einer Servicerolle oder einer serviceverknüpften Rolle tun.
+ **Forward Access Sessions (FAS)** — Wenn Sie einen IAM-Benutzer oder eine IAM-Rolle verwenden, um Aktionen auszuführen AWS, gelten Sie als Principal. Bei einigen Services könnte es Aktionen geben, die dann eine andere Aktion in einem anderen Service initiieren. FAS verwendet die Berechtigungen des Prinzipals, der einen AWS Dienst aufruft, in Kombination mit dem anfordernden AWS Dienst, um Anfragen an nachgelagerte Dienste zu stellen. FAS-Anfragen werden nur gestellt, wenn ein Dienst eine Anfrage erhält, für deren Abschluss Interaktionen mit anderen AWS Diensten oder Ressourcen erforderlich sind. In diesem Fall müssen Sie über Berechtigungen zum Ausführen beider Aktionen verfügen. Einzelheiten zu den Richtlinien für FAS-Anforderungen finden Sie unter [Zugriffssitzungen weiterleiten](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html).
+ **Servicerolle** – Eine Servicerolle ist eine [IAM-Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html), die ein Service übernimmt, um Aktionen in Ihrem Namen auszuführen. Ein IAM-Administrator kann eine Servicerolle innerhalb von IAM erstellen, ändern und löschen. Weitere Informationen finden Sie im *IAM-Benutzerhandbuch* unter [Erstellen einer Rolle zum Delegieren von Berechtigungen für einen AWS Dienst](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html).
+ **Dienstverknüpfte Rolle** — Eine dienstverknüpfte Rolle ist eine Art von Servicerolle, die mit einem Dienst verknüpft ist. AWS Der Service kann die Rolle übernehmen, um eine Aktion in Ihrem Namen auszuführen. Servicebezogene Rollen werden in Ihrem AWS Konto angezeigt und gehören dem Dienst. Ein IAM-Administrator kann die Berechtigungen für Service-verknüpfte Rollen anzeigen, aber nicht bearbeiten.
+ **Auf Amazon ausgeführte Anwendungen EC2** — Sie können eine IAM-Rolle verwenden, um temporäre Anmeldeinformationen für Anwendungen zu verwalten, die auf einer EC2 Instance ausgeführt werden und AWS CLI- oder AWS API-Anfragen stellen. Dies ist dem Speichern von Zugriffsschlüsseln innerhalb der EC2 Instance vorzuziehen. Um einer EC2 Instanz eine AWS Rolle zuzuweisen und sie allen ihren Anwendungen zur Verfügung zu stellen, erstellen Sie ein Instanzprofil, das an die Instanz angehängt ist. Ein Instanzprofil enthält die Rolle und ermöglicht Programmen, die auf der EC2 Instanz ausgeführt werden, temporäre Anmeldeinformationen abzurufen. Weitere Informationen finden Sie im *IAM-Benutzerhandbuch* [unter Verwenden einer IAM-Rolle zum Erteilen von Berechtigungen für Anwendungen, die auf EC2 Amazon-Instances ausgeführt](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html) werden.
Informationen dazu, wann Sie IAM-Rollen oder IAM-Benutzer verwenden sollten, finden Sie unter [Erstellen einer IAM-Rolle (anstatt eines Benutzers)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose_role) im *IAM-Benutzerhandbuch*.
## Verwalten des Zugriffs mit Richtlinien
Sie kontrollieren den Zugriff, AWS indem Sie Richtlinien erstellen und diese an AWS Identitäten oder Ressourcen anhängen. Eine Richtlinie ist ein Objekt, AWS das, wenn es einer Identität oder Ressource zugeordnet ist, deren Berechtigungen definiert. AWS wertet diese Richtlinien aus, wenn ein Prinzipal (Benutzer, Root-Benutzer oder Rollensitzung) eine Anfrage stellt. Die Berechtigungen in den Richtlinien legen fest, ob eine Anforderung zugelassen oder abgelehnt wird. Die meisten Richtlinien werden AWS als JSON-Dokumente gespeichert. Weitere Informationen zu Struktur und Inhalten von JSON-Richtliniendokumenten finden Sie unter [Übersicht über JSON-Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) im *IAM-Benutzerhandbuch*.
Administratoren können mithilfe von AWS JSON-Richtlinien angeben, wer Zugriff auf was hat. Das heißt, welcher **Prinzipal** **Aktionen** für welche **Ressourcen** und unter welchen **Bedingungen** ausführen kann.
Standardmäßig haben Benutzer, Gruppen und Rollen keine Berechtigungen. Ein IAM-Administrator muss IAM-Richtlinien erstellen, die Benutzern die Berechtigung erteilen, Aktionen für die Ressourcen auszuführen, die sie benötigen. Der Administrator kann dann die IAM-Richtlinien zu Rollen hinzufügen, und Benutzer können die Rollen annehmen.
IAM-Richtlinien definieren Berechtigungen für eine Aktion unabhängig von der Methode, die Sie zur Ausführung der Aktion verwenden. Angenommen, es gibt eine Richtlinie, die Berechtigungen für die `iam:GetRole`-Aktion erteilt. Ein Benutzer mit dieser Richtlinie kann Rolleninformationen von der AWS-Managementkonsole, der AWS CLI oder der AWS API abrufen.
### Identitätsbasierte Richtlinien
Identitätsbasierte Richtlinien sind JSON-Berechtigungsrichtliniendokumente, die Sie einer Identität anfügen können, wie z. B. IAM-Benutzern, -Benutzergruppen oder -Rollen. Diese Richtlinien steuern, welche Aktionen die Benutzer und Rollen für welche Ressourcen und unter welchen Bedingungen ausführen können. Informationen zum Erstellen identitätsbasierter Richtlinien finden Sie unter [Erstellen von IAM-Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) im *IAM-Benutzerhandbuch*.
Identitätsbasierte Richtlinien können weiter als *Inline-Richtlinien* oder *verwaltete Richtlinien* kategorisiert werden. Eingebundene Richtlinien sind direkt in einen einzelnen Benutzer, eine einzelne Gruppe oder eine einzelne Rolle eingebettet. Verwaltete Richtlinien sind eigenständige Richtlinien, die Sie mehreren Benutzern, Gruppen und Rollen in Ihrem AWS Konto zuordnen können. Zu den verwalteten Richtlinien gehören AWS verwaltete Richtlinien und vom Kunden verwaltete Richtlinien. Informationen dazu, wie Sie zwischen einer verwalteten Richtlinie und einer eingebundenen Richtlinie wählen, finden Sie unter [Auswahl zwischen verwalteten und eingebundenen Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#choosing-managed-or-inline) im *IAM-Benutzerhandbuch*.
### Ressourcenbasierte Richtlinien
Ressourcenbasierte Richtlinien sind JSON-Richtliniendokumente, die Sie an eine Ressource anfügen. Beispiele für ressourcenbasierte Richtlinien sind IAM-*Rollen-Vertrauensrichtlinien* und Amazon-S3-*Bucket-Richtlinien*. In Services, die ressourcenbasierte Richtlinien unterstützen, können Service-Administratoren sie verwenden, um den Zugriff auf eine bestimmte Ressource zu steuern. Für die Ressource, an welche die Richtlinie angehängt ist, legt die Richtlinie fest, welche Aktionen ein bestimmter Prinzipal unter welchen Bedingungen für diese Ressource ausführen kann. Sie müssen in einer ressourcenbasierten Richtlinie [einen Prinzipal angeben](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html). Zu den Prinzipalen können Konten, Benutzer, Rollen, Verbundbenutzer oder AWS Dienste gehören.
Ressourcenbasierte Richtlinien sind Richtlinien innerhalb dieses Diensts. Sie können AWS verwaltete Richtlinien von IAM nicht in einer ressourcenbasierten Richtlinie verwenden.
### Zugriffskontrolllisten () ACLs
Zugriffskontrolllisten (ACLs) steuern, welche Principals (Kontomitglieder, Benutzer oder Rollen) über Zugriffsberechtigungen für eine Ressource verfügen. ACLs ähneln ressourcenbasierten Richtlinien, verwenden jedoch nicht das JSON-Richtliniendokumentformat.
Amazon S3, AWS WAF und Amazon VPC sind Beispiele für Dienste, die Unterstützung bieten. ACLs Weitere Informationen finden Sie unter [Übersicht über ACLs die Zugriffskontrollliste (ACL)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html) im *Amazon Simple Storage Service Developer Guide*.
### Weitere Richtlinientypen
AWS unterstützt zusätzliche, weniger verbreitete Richtlinientypen. Mit diesen Richtlinientypen können Sie die maximalen Berechtigungen festlegen, die Ihnen durch die gängigeren Richtlinientypen gewährt werden.
+ **Berechtigungsgrenzen** – Eine Berechtigungsgrenze ist ein erweitertes Feature, mit der Sie die maximalen Berechtigungen festlegen können, die eine identitätsbasierte Richtlinie einer IAM-Entität (IAM-Benutzer oder -Rolle) erteilen kann. Sie können eine Berechtigungsgrenze für eine Entität festlegen. Die resultierenden Berechtigungen sind eine Schnittmenge der identitätsbasierten Richtlinien einer Entität und ihrer Berechtigungsgrenzen. Ressourcenbasierte Richtlinien, die den Benutzer oder die Rolle im Feld `Principal` angeben, werden nicht durch Berechtigungsgrenzen eingeschränkt. Eine explizite Zugriffsverweigerung in einer dieser Richtlinien setzt eine Zugriffserlaubnis außer Kraft. Weitere Informationen über Berechtigungsgrenzen finden Sie unter [Berechtigungsgrenzen für IAM-Entitäten](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) im *IAM-Benutzerhandbuch*.
+ **Dienststeuerungsrichtlinien (SCPs)** — SCPs sind JSON-Richtlinien, die die maximalen Berechtigungen für eine Organisation oder Organisationseinheit (OU) in AWS Organizations festlegen. AWS Organizations ist ein Dienst zur Gruppierung und zentralen Verwaltung mehrerer AWS Konten, die Ihrem Unternehmen gehören. Wenn Sie alle Funktionen in einer Organisation aktivieren, können Sie Richtlinien zur Servicesteuerung (SCPs) auf einige oder alle Ihre Konten anwenden. Das SCP schränkt die Berechtigungen für Entitäten in Mitgliedskonten ein, einschließlich der einzelnen AWS Root-Benutzer. Weitere Informationen zu Organizations und SCPs finden Sie unter [Richtlinien zur Servicesteuerung](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) im * AWS Organizations User Guide*.
+ **Sitzungsrichtlinien** – Sitzungsrichtlinien sind erweiterte Richtlinien, die Sie als Parameter übergeben, wenn Sie eine temporäre Sitzung für eine Rolle oder einen verbundenen Benutzer programmgesteuert erstellen. Die resultierenden Sitzungsberechtigungen sind die Schnittmenge der identitätsbasierten Richtlinien des Benutzers oder der Rolle und der Sitzungsrichtlinien. Berechtigungen können auch aus einer ressourcenbasierten Richtlinie stammen. Eine explizite Zugriffsverweigerung in einer dieser Richtlinien setzt eine Zugriffserlaubnis außer Kraft. Weitere Informationen finden Sie unter [Sitzungsrichtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) im *IAM-Benutzerhandbuch*.
### Mehrere Richtlinientypen
Wenn für eine Anfrage mehrere Arten von Richtlinien gelten, sind die sich daraus ergebenden Berechtigungen schwieriger zu verstehen. Informationen darüber, wie AWS bestimmt wird, ob eine Anfrage zulässig ist, wenn mehrere Richtlinientypen betroffen sind, finden Sie unter [Bewertungslogik für Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) im *IAM-Benutzerhandbuch*.
# Funktionsweise von Amazon EKS mit IAM
Bevor Sie IAM verwenden, um den Zugriff auf Amazon EKS zu verwalten, sollten Sie verstehen, welche IAM-Funktionen für die Verwendung mit Amazon EKS verfügbar sind. Einen allgemeinen Überblick darüber, wie Amazon EKS und andere AWS Services mit IAM zusammenarbeiten, finden Sie im [IAM-Benutzerhandbuch unter AWS Services, die mit *IAM* funktionieren](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html).
**Topics**
+ [
## Identitätsbasierte Amazon-EKS-Richtlinien
](#security-iam-service-with-iam-id-based-policies)
+ [
## Ressourcenbasierte Amazon-EKS-Richtlinien
](#security-iam-service-with-iam-resource-based-policies)
+ [
## Autorisierung auf der Basis von Amazon-EKS-Tags
](#security-iam-service-with-iam-tags)
+ [
## Amazon EKS IAM-Rollen
](#security-iam-service-with-iam-roles)
## Identitätsbasierte Amazon-EKS-Richtlinien
Mit identitätsbasierten IAM-Richtlinien können Sie angeben, welche Aktionen und Ressourcen zugelassen oder abgelehnt werden. Darüber hinaus können Sie die Bedingungen festlegen, unter denen Aktionen zugelassen oder abgelehnt werden. Amazon EKS unterstützt bestimmte Aktionen, Ressourcen und Zustandsschlüssel. Informationen zu sämtlichen Elementen, die Sie in einer JSON-Richtlinie verwenden, finden Sie in der [IAM-Referenz für JSON-Richtlinienelemente](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) im *IAM-Benutzerhandbuch*.
### Aktionen
Administratoren können mithilfe von AWS JSON-Richtlinien angeben, wer Zugriff auf was hat. Das heißt, welcher **Prinzipal** **Aktionen** für welche **Ressourcen** und unter welchen **Bedingungen** ausführen kann.
Das Element `Action` einer JSON-Richtlinie beschreibt die Aktionen, mit denen Sie den Zugriff in einer Richtlinie zulassen oder verweigern können. Richtlinienaktionen haben normalerweise denselben Namen wie der zugehörige AWS API-Vorgang. Es gibt einige Ausnahmen, z. B. *Aktionen, die nur mit Genehmigung durchgeführt werden können* und für die es keine entsprechende API-Operation gibt. Es gibt auch einige Operationen, für die mehrere Aktionen in einer Richtlinie erforderlich sind. Diese zusätzlichen Aktionen werden als *abhängige Aktionen* bezeichnet.
Schließen Sie Aktionen in eine Richtlinie ein, um Berechtigungen zur Durchführung der zugeordneten Operation zu erteilen.
Richtlinienaktionen in Amazon EKS verwenden das folgende Präfix vor der Aktion: `eks:`. Um jemandem beispielsweise die Berechtigung zum Abrufen von Informationen zu einem Amazon-EKS-Cluster zu erteilen, fügen Sie die Aktion `DescribeCluster` in seine Richtlinie ein. Richtlinienanweisungen müssen entweder ein `Action`- oder ein `NotAction`-Element enthalten.
Um mehrere Aktionen in einer einzigen Anweisung anzugeben, trennen Sie sie wie folgt durch Kommata:
```
"Action": ["eks:action1", "eks:action2"]
```
Sie können auch Platzhalter verwenden, um mehrere Aktionen anzugeben. Beispielsweise können Sie alle Aktionen festlegen, die mit dem Wort `Describe` beginnen, einschließlich der folgenden Aktion:
```
"Action": "eks:Describe*"
```
Eine Liste der Amazon-EKS-Aktionen finden Sie unter [Von Amazon Elastic Kubernetes Service definierte Aktionen](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions) in der *Serviceautorisierungsreferenz*.
### Ressourcen
Administratoren können mithilfe von AWS JSON-Richtlinien angeben, wer Zugriff auf was hat. Das heißt, welcher **Prinzipal** **Aktionen** für welche **Ressourcen** und unter welchen **Bedingungen** ausführen kann.
Das JSON-Richtlinienelement `Resource` gibt die Objekte an, auf welche die Aktion angewendet wird. Anweisungen müssen entweder ein – `Resource`oder ein `NotResource`-Element enthalten. Als bewährte Methode geben Sie eine Ressource mit dem zugehörigen [Amazon-Ressourcennamen (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html) an. Sie können dies für Aktionen tun, die einen bestimmten Ressourcentyp unterstützen, der als *Berechtigungen auf Ressourcenebene* bezeichnet wird.
Verwenden Sie für Aktionen, die keine Berechtigungen auf Ressourcenebene unterstützen, z. B. Auflistungsoperationen, einen Platzhalter (\$1), um anzugeben, dass die Anweisung für alle Ressourcen gilt.
```
"Resource": "*"
```
Die Amazon-EKS-Cluster-Ressource verfügt über den folgenden ARN:
```
arn:aws: eks:region-code:account-id:cluster/cluster-name
```
Weitere Informationen zum Format von ARNs finden Sie unter [Amazon-Ressourcennamen (ARNs) und AWS Service-Namespaces](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html).
Um beispielsweise den Cluster mit dem Namen *my-cluster* in Ihrer Anweisung anzugeben, verwenden Sie den folgenden ARN:
```
"Resource": "arn:aws: eks:region-code:111122223333:cluster/my-cluster"
```
Um alle Cluster anzugeben, die zu einem bestimmten Konto und einer bestimmten AWS Region gehören, verwenden Sie den Platzhalter (\$1):
```
"Resource": "arn:aws: eks:region-code:111122223333:cluster/*"
```
Einige Amazon-EKS-Aktionen, z. B. das Erstellen von Ressourcen, können für bestimmte Ressourcen nicht ausgeführt werden. In diesen Fällen müssen Sie den Platzhalter (\$1) verwenden.
```
"Resource": "*"
```
Eine Liste der Amazon EKS-Ressourcentypen und ihrer ARNs Eigenschaften finden Sie unter [Von Amazon Elastic Kubernetes Service definierte Ressourcen in der Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-resources-for-iam-policies) *Authorization Reference*. Um zu erfahren, mit welchen Aktionen Sie den ARN jeder Ressource angeben können, lesen Sie von [Amazon Elastic Kubernetes Service definierte Aktionen](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions).
### Bedingungsschlüssel
Amazon EKS definiert seinen eigenen Satz von Konditionsschlüsseln und unterstützt auch die Verwendung einiger globaler Konditionsschlüssel. Eine Übersicht aller AWS globalen Bedingungsschlüssel finden Sie unter [AWS Global Condition Context Keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) im *IAM-Benutzerhandbuch*.
Sie können Bedingungsschlüssel festlegen, wenn Sie Ihrem Cluster einen OpenID Connect-Anbieter zuordnen. Weitere Informationen finden Sie unter [Beispiel für eine IAM-Richtlinie](authenticate-oidc-identity-provider.md#oidc-identity-provider-iam-policy).
Alle Amazon EC2-Aktionen unterstützen die Bedingungsschlüssel `aws:RequestedRegion` und `ec2:Region`. Weitere Informationen finden Sie unter [Beispiel: Beschränken des Zugriffs auf eine bestimmte AWS Region](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ExamplePolicies_EC2.html#iam-example-region).
Eine Liste der Amazon EKS-Bedingungsschlüssel finden Sie unter [Bedingungsschlüssel für Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-policy-keys) in der *Service-Autorisierungsreferenz*. Um zu erfahren, mit welchen Aktionen und Ressourcen Sie einen Bedingungsschlüssel verwenden können, lesen Sie von [Amazon Elastic Kubernetes Service definierte Aktionen](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions).
### Beispiele
Beispiele für identitätsbasierte Amazon-EKS-Richtlinien finden Sie unter [Beispiele für identitätsbasierte Amazon-EKS-Richtlinien](security-iam-id-based-policy-examples.md).
Wenn Sie einen Amazon-EKS-Cluster erstellen, werden dem [IAM-Prinzipal](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal), der den Cluster erstellt, automatisch `system:masters`-Berechtigungen in der rollenbasierten Konfiguration für Zugriffskontrolle (RBAC) des Clusters in der Amazon-EKS-Steuerebene gewährt. Dieser Prinzipal wird in keiner sichtbaren Konfiguration angezeigt. Achten Sie daher darauf, welcher Prinzipal den Cluster ursprünglich erstellt hat. Um zusätzlichen IAM-Prinzipalen die Möglichkeit zu geben, mit Ihrem Cluster zu interagieren, bearbeiten Sie den `aws-auth ConfigMap` in Kubernetes und erstellen Sie ein Kubernetes-`rolebinding` oder -`clusterrolebinding` mit dem Namen eines `group`, das Sie im `aws-auth ConfigMap` angeben.
Weitere Informationen zur Arbeit mit dem finden Sie ConfigMap unter[Gewähren Sie IAM-Benutzern und -Rollen Zugriff auf Kubernetes APIs](grant-k8s-access.md).
## Ressourcenbasierte Amazon-EKS-Richtlinien
Amazon EKS unterstützt keine ressourcenbasierten Richtlinien.
## Autorisierung auf der Basis von Amazon-EKS-Tags
Sie können Tags an Amazon-EKS-Ressourcen anhängen oder Tags in einer Anforderung an Amazon EKS übergeben. Um den Zugriff auf der Grundlage von Tags zu steuern, geben Sie im Bedingungselement einer[ Richtlinie Tag-Informationen ](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)an, indem Sie die Schlüssel `aws:ResourceTag/key-name `, `aws:RequestTag/key-name `, oder `aws:TagKeys`Bedingung verwenden. Weitere Informationen über die Markierung von Amazon-EKS-Ressourcen finden Sie unter [Organisation von Amazon-EKS-Ressourcen mit Tags](eks-using-tags.md). Weitere Informationen darüber, mit welchen Aktionen Sie Tags in Bedingungsschlüsseln verwenden können, finden Sie unter [Von Amazon EKS definierte Aktionen](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions) in der [Service-Authorization-Referenz](https://docs.aws.amazon.com/service-authorization/latest/reference/reference.html).
## Amazon EKS IAM-Rollen
Eine [IAM-Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) ist eine Entität innerhalb Ihres AWS Kontos, die über bestimmte Berechtigungen verfügt.
### Verwenden temporärer Anmeldeinformationen mit Amazon EKS
Sie können temporäre Anmeldeinformationen verwenden, um sich über einen Verbund anzumelden, eine IAM-Rolle anzunehmen oder eine kontenübergreifende Rolle anzunehmen. Sie erhalten temporäre Sicherheitsanmeldedaten, indem Sie AWS STS-API-Operationen wie [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)oder [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html)aufrufen.
Amazon EKS unterstützt die Verwendung temporärer Anmeldeinformationen.
### Serviceverknüpfte Rollen
[Mit Diensten verknüpfte Rollen](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role) ermöglichen es AWS Diensten, auf Ressourcen in anderen Diensten zuzugreifen, um eine Aktion in Ihrem Namen auszuführen. Serviceverknüpfte Rollen werden in Ihrem IAM-Konto angezeigt und gehören zum Service. Ein Administrator kann die Berechtigungen für serviceverknüpfte Rollen anzeigen, jedoch nicht bearbeiten.
Amazon EKS unterstützt Service-verknüpfte Rollen. Details zum Erstellen oder Verwalten von serviceverknüpften Amazon-EKS-Rollen finden Sie unter [Verwendung von serviceverknüpften Rollen für Amazon EKS](using-service-linked-roles.md).
### Servicerollen
Dieses Feature ermöglicht einem Service das Annehmen einer [Servicerolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-role) in Ihrem Namen. Diese Rolle gewährt dem Service Zugriff auf Ressourcen in anderen Diensten, um eine Aktion in Ihrem Namen auszuführen. Servicerollen werden in Ihrem IAM-Konto angezeigt und gehören zum Konto. Dies bedeutet, dass ein IAM-Administrator die Berechtigungen für diese Rolle ändern kann. Dies kann jedoch die Funktionalität des Services beeinträchtigen.
Amazon EKS unterstützt Servicerollen. Weitere Informationen erhalten Sie unter [Amazon-EKS-Cluster-IAM-Rolle](cluster-iam-role.md) und [Amazon-EKS-Knoten-IAM-Rolle](create-node-role.md).
### Auswählen einer IAM-Rolle in Amazon EKS
Wenn Sie eine Cluster-Ressource in Amazon EKS erstellen, müssen Sie eine Rolle auswählen, damit Amazon EKS in Ihrem Namen auf mehrere andere AWS Ressourcen zugreifen kann. Wenn Sie zuvor eine Servicerolle erstellt haben, stellt Ihnen Amazon EKS eine Liste der Rollen bereit, aus denen Sie auswählen können. Es ist wichtig, eine Rolle auszuwählen, an welche die von Amazon EKS verwalteten Richtlinien angefügt sind. Weitere Informationen erhalten Sie unter [Überprüfen, ob eine Clusterrolle vorhanden ist](cluster-iam-role.md#check-service-role) und [Nach einer vorhandenen Knotenrolle suchen](create-node-role.md#check-worker-node-role).
# Beispiele für identitätsbasierte Amazon-EKS-Richtlinien
Standardmäßig haben IAM-Benutzer und -Rollen nicht die Berechtigung, Amazon-EKS-Ressourcen zu erstellen oder zu ändern. Sie können auch keine Aufgaben mit der AWS-Managementkonsole AWS CLI oder der AWS API ausführen. Ein IAM-Administrator muss IAM-Richtlinien erstellen, die Benutzern und Rollen die Berechtigung zum Ausführen bestimmter API-Operationen für die angegebenen Ressourcen gewähren, die diese benötigen. Der Administrator muss diese Richtlinien anschließend den IAM-Benutzern oder -Gruppen anfügen, die diese Berechtigungen benötigen.
Informationen dazu, wie Sie unter Verwendung dieser beispielhaften JSON-Richtliniendokumente eine identitätsbasierte IAM-Richtlinie erstellen, finden Sie unter [Erstellen von Richtlinien auf der JSON-Registerkarte](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor) im *IAM-Benutzerhandbuch*.
Wenn Sie einen Amazon-EKS-Cluster erstellen, werden dem [IAM-Prinzipal](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal), der den Cluster erstellt, automatisch `system:masters`-Berechtigungen in der rollenbasierten Konfiguration für Zugriffskontrolle (RBAC) des Clusters in der Amazon-EKS-Steuerebene gewährt. Dieser Prinzipal wird in keiner sichtbaren Konfiguration angezeigt. Achten Sie daher darauf, welcher Prinzipal den Cluster ursprünglich erstellt hat. Um zusätzlichen IAM-Prinzipalen die Möglichkeit zu geben, mit Ihrem Cluster zu interagieren, bearbeiten Sie den `aws-auth ConfigMap` in Kubernetes und erstellen Sie ein Kubernetes-`rolebinding` oder -`clusterrolebinding` mit dem Namen eines `group`, das Sie im `aws-auth ConfigMap` angeben.
Weitere Informationen zur Arbeit mit dem ConfigMap finden Sie unter[Gewähren Sie IAM-Benutzern und -Rollen Zugriff auf Kubernetes APIs](grant-k8s-access.md).
**Topics**
+ [
## Best Practices für Richtlinien
](#security-iam-service-with-iam-policy-best-practices)
+ [
## Verwenden der Amazon-EKS-Konsole
](#security-iam-id-based-policy-examples-console)
+ [
## Gewähren der Berechtigung zur Anzeige der eigenen Berechtigungen für IAM-Benutzer
](#security-iam-id-based-policy-examples-view-own-permissions)
+ [
## Erstellen Sie einen Kubernetes-Cluster in der Cloud AWS
](#policy-create-cluster)
+ [
## Kubernetes-Cluster auf einem Outpost erstellen
](#policy-create-local-cluster)
+ [
## Aktualisieren eines Kubernetes-Clusters
](#policy-example1)
+ [
## Auflisten oder Beschreiben aller Cluster
](#policy-example2)
## Best Practices für Richtlinien
Identitätsbasierte Richtlinien können festlegen, ob jemand Amazon-EKS-Ressourcen in Ihrem Konto erstellen, darauf zugreifen oder daraus löschen kann. Diese Aktionen können mit Kosten für Ihr AWS Konto verbunden sein. Beachten Sie beim Erstellen oder Bearbeiten identitätsbasierter Richtlinien die folgenden Richtlinien und Empfehlungen:
+ **Erste Schritte mit AWS verwalteten Richtlinien und Umstellung auf Berechtigungen mit den geringsten Rechten** — Verwenden Sie die * AWS verwalteten Richtlinien*, die Berechtigungen für viele gängige Anwendungsfälle gewähren, um damit zu beginnen, Ihren Benutzern und Workloads Berechtigungen zu gewähren. Sie sind in Ihrem Konto verfügbar. AWS Wir empfehlen Ihnen, die Berechtigungen weiter zu reduzieren, indem Sie vom AWS Kunden verwaltete Richtlinien definieren, die speziell auf Ihre Anwendungsfälle zugeschnitten sind. Weitere Informationen finden Sie unter [Von AWS verwaltete Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) oder [Von AWS verwaltete Richtlinien für Auftragsfunktionen](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) im *IAM-Benutzerhandbuch*.
+ **Anwendung von Berechtigungen mit den geringsten Rechten** – Wenn Sie mit IAM-Richtlinien Berechtigungen festlegen, gewähren Sie nur die Berechtigungen, die für die Durchführung einer Aufgabe erforderlich sind. Sie tun dies, indem Sie die Aktionen definieren, die für bestimmte Ressourcen unter bestimmten Bedingungen durchgeführt werden können, auch bekannt als *die geringsten Berechtigungen*. Weitere Informationen zur Verwendung von IAM zum Anwenden von Berechtigungen finden Sie unter [ Richtlinien und Berechtigungen in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) im *IAM-Benutzerhandbuch*.
+ **Verwenden von Bedingungen in IAM-Richtlinien zur weiteren Einschränkung des Zugriffs** – Sie können Ihren Richtlinien eine Bedingung hinzufügen, um den Zugriff auf Aktionen und Ressourcen zu beschränken. Sie können beispielsweise eine Richtlinienbedingung schreiben, um festzulegen, dass alle Anforderungen mithilfe von SSL gesendet werden müssen. Sie können auch Bedingungen verwenden, um Zugriff auf Serviceaktionen zu gewähren, wenn diese über einen bestimmten AWS Dienst verwendet werden, z. AWS CloudFormation B. Weitere Informationen finden Sie unter [IAM-JSON-Richtlinienelemente: Bedingung](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) im *IAM-Benutzerhandbuch*.
+ **Verwenden von IAM Access Analyzer zur Validierung Ihrer IAM-Richtlinien, um sichere und funktionale Berechtigungen zu gewährleisten** – IAM Access Analyzer validiert neue und vorhandene Richtlinien, damit die Richtlinien der IAM-Richtliniensprache (JSON) und den bewährten IAM-Methoden entsprechen. IAM Access Analyzer stellt mehr als 100 Richtlinienprüfungen und umsetzbare Empfehlungen zur Verfügung, damit Sie sichere und funktionale Richtlinien erstellen können. Weitere Informationen finden Sie unter [Richtlinienvalidierung zum IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) im *IAM-Benutzerhandbuch*.
+ **Multi-Faktor-Authentifizierung (MFA) erforderlich** — Wenn Sie ein Szenario haben, das IAM-Benutzer oder einen Root-Benutzer in Ihrem AWS Konto erfordert, aktivieren Sie MFA für zusätzliche Sicherheit. Um MFA beim Aufrufen von API-Vorgängen anzufordern, fügen Sie Ihren Richtlinien MFA-Bedingungen hinzu. Weitere Informationen finden Sie unter [Konfigurieren eines MFA-geschützten API-Zugriffs](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) im *IAM-Benutzerhandbuch*.
Weitere Informationen zu bewährten Methoden in IAM finden Sie unter [Bewährte Methoden für die Sicherheit in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) im *IAM-Benutzerhandbuch*.
## Verwenden der Amazon-EKS-Konsole
Um auf die Amazon EKS-Konsole zugreifen zu können, muss ein [IAM-Prinzipal](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) über einen Mindestsatz von Berechtigungen verfügen. Diese Berechtigungen ermöglichen es dem Principal, Details zu den Amazon EKS-Ressourcen in Ihrem AWS Konto aufzulisten und einzusehen. Wenn Sie eine identitätsbasierte Richtlinie erstellen, die restriktiver als die mindestens erforderlichen Berechtigungen ist, funktioniert die Konsole für Prinzipals, denen diese Richtlinie zugewiesen ist, nicht wie vorgesehen.
Um sicherzustellen, dass Ihre IAM-Prinzipals die Amazon EKS-Konsole weiterhin verwenden können, erstellen Sie eine Richtlinie mit Ihrem eigenen eindeutigen Namen, z. B. `AmazonEKSAdminPolicy`. Hängen Sie die Richtlinie an die Prinzipale an. Informationen finden Sie im Abschnitt [Hinzufügen und Entfernen von IAM-Identitätsberechtigungen](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html) im *IAM-Benutzerhandbuch*.
**Wichtig**
Mit der folgenden Beispielrichtlinie kann ein Prinzipal Informationen auf der Registerkarte **Konfiguration** in der Konsole anzeigen. Um Informationen auf den Registerkarten „**Übersicht**“ und „**Ressourcen**“ in anzeigen zu können AWS-Managementkonsole, benötigt der Principal außerdem Kubernetes-Berechtigungen. Weitere Informationen finden Sie unter [Erforderliche Berechtigungen](view-kubernetes-resources.md#view-kubernetes-resources-permissions).
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"eks:*"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "*",
"Condition": {
"StringEquals": {
"iam:PassedToService": "eks.amazonaws.com"
}
}
}
]
}
```
Sie müssen keine Mindestkonsolenberechtigungen für Principals gewähren, die nur die AWS CLI oder die AWS API aufrufen. Stattdessen sollten Sie nur Zugriff auf die Aktionen zulassen, die der API-Operation entsprechen, die Sie ausführen möchten.
## Gewähren der Berechtigung zur Anzeige der eigenen Berechtigungen für IAM-Benutzer
In diesem Beispiel wird gezeigt, wie Sie eine Richtlinie erstellen, die IAM-Benutzern die Berechtigung zum Anzeigen der eingebundenen Richtlinien und verwalteten Richtlinien gewährt, die ihrer Benutzeridentität angefügt sind. Diese Richtlinie umfasst Berechtigungen zum Ausführen dieser Aktion auf der Konsole oder programmgesteuert mithilfe der AWS CLI oder AWS API.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
## Erstellen Sie einen Kubernetes-Cluster in der Cloud AWS
Diese Beispielrichtlinie umfasst die Mindestberechtigungen, die erforderlich sind, um einen Amazon EKS-Cluster mit *my-cluster* dem Namen *us-west-2* AWS Region zu erstellen. Sie können die AWS Region durch die AWS Region ersetzen, in der Sie einen Cluster erstellen möchten. Wenn Sie eine Warnung sehen, **die besagt, dass die Aktionen in Ihrer Richtlinie keine Berechtigungen auf Ressourcenebene unterstützen und Sie sich für die entscheiden `All resources` müssen** AWS-Managementkonsole, können Sie diese problemlos ignorieren. Wenn Ihr Konto bereits über die *AWSServiceRoleForAmazonEKS*-Rolle verfügt, können Sie die `iam:CreateServiceLinkedRole`-Aktion aus der Richtlinie entfernen. Wenn Sie jemals einen Amazon-EKS-Cluster in Ihrem Konto erstellt haben, ist diese Rolle bereits vorhanden, sofern Sie sie nicht gelöscht haben.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "eks:CreateCluster",
"Resource": "arn:aws:eks:us-west-2:111122223333:cluster/my-cluster"
},
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::111122223333:role/aws-service-role/eks.amazonaws.com/AWSServiceRoleForAmazonEKS",
"Condition": {
"ForAnyValue:StringEquals": {
"iam:AWSServiceName": "eks"
}
}
},
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::111122223333:role/cluster-role-name"
}
]
}
```
## Kubernetes-Cluster auf einem Outpost erstellen
Diese Beispielrichtlinie umfasst die Mindestberechtigungen, die erforderlich sind, um einen lokalen Amazon EKS-Cluster mit *my-cluster* dem Namen eines Außenpostens in der *us-west-2* AWS Region zu erstellen. Sie können die AWS Region durch die AWS Region ersetzen, in der Sie einen Cluster erstellen möchten. Wenn Sie eine Warnung sehen, **die besagt, dass die Aktionen in Ihrer Richtlinie keine Berechtigungen auf Ressourcenebene unterstützen und Sie sich für die entscheiden `All resources` müssen** AWS-Managementkonsole, können Sie diese problemlos ignorieren. Wenn Ihr Konto bereits über die `AWSServiceRoleForAmazonEKSLocalOutpost`-Rolle verfügt, können Sie die `iam:CreateServiceLinkedRole`-Aktion aus der Richtlinie entfernen. Wenn Sie jemals einen lokalen Amazon-EKS-Cluster auf einem Outpost in Ihrem Konto erstellt haben, ist diese Rolle bereits vorhanden, sofern Sie sie nicht gelöscht haben.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "eks:CreateCluster",
"Resource": "arn:aws:eks:us-west-2:111122223333:cluster/my-cluster"
},
{
"Action": [
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"iam:GetRole"
],
"Resource": "*",
"Effect": "Allow"
},
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::111122223333:role/aws-service-role/outposts.eks-local.amazonaws.com/AWSServiceRoleForAmazonEKSLocalOutpost"
},
{
"Effect": "Allow",
"Action": [
"iam:PassRole",
"iam:ListAttachedRolePolicies"
],
"Resource": "arn:aws:iam::111122223333:role/cluster-role-name"
},
{
"Action": [
"iam:CreateInstanceProfile",
"iam:TagInstanceProfile",
"iam:AddRoleToInstanceProfile",
"iam:GetInstanceProfile",
"iam:DeleteInstanceProfile",
"iam:RemoveRoleFromInstanceProfile"
],
"Resource": "arn:aws:iam::*:instance-profile/eks-local-*",
"Effect": "Allow"
}
]
}
```
## Aktualisieren eines Kubernetes-Clusters
Diese Beispielrichtlinie umfasst die Mindestberechtigungen, die zum Aktualisieren eines Clusters mit dem Namen der *my-cluster* Region us-west-2 AWS erforderlich sind.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "eks:UpdateClusterVersion",
"Resource": "arn:aws:eks:us-west-2:111122223333:cluster/my-cluster"
}
]
}
```
## Auflisten oder Beschreiben aller Cluster
Diese Beispielrichtlinie enthält die benötigten Mindestberechtigungen zum Auflisten und Beschreiben aller Cluster in Ihrem Konto. Ein [IAM-Prinzipal](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) muss in der Lage sein, Cluster aufzulisten und zu beschreiben, um den `update-kubeconfig` AWS CLI-Befehl verwenden zu können.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"eks:DescribeCluster",
"eks:ListClusters"
],
"Resource": "*"
}
]
}
```
# Verwendung von serviceverknüpften Rollen für Amazon EKS
Amazon Elastic Kubernetes Service verwendet [serviceverknüpfte Rollen](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role) für AWS Identity and Access Management (IAM). Eine servicegebundene Rolle ist eine einzigartige Art von IAM-Rolle, die direkt mit Amazon EKS verknüpft ist. Serviceverknüpfte Rollen werden von Amazon EKS vordefiniert und schließen alle Berechtigungen ein, die der Service zum Aufrufen anderer AWS-Services in Ihrem Namen erfordert.
**Topics**
+ [
# Verwenden von Rollen für Amazon-EKS-Cluster
](using-service-linked-roles-eks.md)
+ [
# Verwenden von Rollen für Amazon-EKS-Knotengruppen
](using-service-linked-roles-eks-nodegroups.md)
+ [
# Verwenden von Rollen für Amazon-EKS-Fargate-Profile
](using-service-linked-roles-eks-fargate.md)
+ [
# Verbinden eines Kubernetes-Clusters mithilfe von Rollen mit Amazon EKS
](using-service-linked-roles-eks-connector.md)
+ [
# Verwenden von Rollen für lokale Amazon-EKS-Cluster in Outpost
](using-service-linked-roles-eks-outpost.md)
+ [
# Verwendung von Rollen für das Amazon-EKS-Dashboard
](using-service-linked-roles-eks-dashboard.md)
# Verwenden von Rollen für Amazon-EKS-Cluster
Amazon Elastic Kubernetes Service verwendet [serviceverknüpfte Rollen](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role) für AWS Identity and Access Management (IAM). Eine servicegebundene Rolle ist eine einzigartige Art von IAM-Rolle, die direkt mit Amazon EKS verknüpft ist. Serviceverknüpfte Rollen werden von Amazon EKS vordefiniert und schließen alle Berechtigungen ein, die der Service zum Aufrufen anderer AWS-Services in Ihrem Namen erfordert.
Eine serviceverknüpfte Rolle macht die Einrichtung von Amazon EKS einfacher, da Sie die erforderlichen Berechtigungen nicht manuell hinzufügen müssen. Amazon EKS definiert die Berechtigungen seiner mit dem Service verbundenen Rollen, und sofern nicht anders definiert, kann nur Amazon EKS seine Rollen übernehmen. Die definierten Berechtigungen umfassen die Vertrauens- und Berechtigungsrichtlinie. Diese Berechtigungsrichtlinie kann keinen anderen IAM-Entitäten zugewiesen werden.
Sie können eine serviceverknüpfte Rolle erst löschen, nachdem ihre verwandten Ressourcen gelöscht wurden. Dies schützt Ihre Amazon-EKS-Ressourcen, da Sie nicht versehentlich die Zugriffsberechtigung für die Ressourcen entfernen können.
Informationen zu anderen Services, die serviceverknüpfte Rollen unterstützen, finden Sie unter [AWS-Services, die mit IAM funktionieren](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html). Suchen Sie nach den Services, für die **Ja** in der Spalte **Serviceverknüpfte Rolle** angegeben ist. Wählen Sie über einen Link **Ja** aus, um die Dokumentation zu einer servicegebundenen Rolle für diesen Service anzuzeigen.
## Serviceverknüpfte Rollenberechtigungen für Amazon EKS
Amazon ESK verwendet die serviceverknüpfte Rolle mit dem Namen `AWSServiceRoleForAmazonEKS`. Diese Rolle ermöglicht es Amazon EKS, Cluster in Ihrem Konto zu verwalten. Die angehängten Richtlinien ermöglichen es der Rolle, die folgenden Ressourcen zu verwalten: Netzwerkschnittstellen, Sicherheitsgruppen, Protokolle und VPCs.
**Anmerkung**
Die serviceverknüpfte `AWSServiceRoleForAmazonEKS`-Rolle unterscheidet sich von der Rolle, die für die Clustererstellung erforderlich ist. Weitere Informationen finden Sie unter [Amazon-EKS-Cluster-IAM-Rolle](cluster-iam-role.md).
Die serviceverknüpfte Rolle `AWSServiceRoleForAmazonEKS` vertraut darauf, dass die folgenden Services die Rolle annehmen:
+ `eks.amazonaws.com`
Die Richtlinie für Rollenberechtigungen erlaubt Amazon EKS, die folgenden Aktionen auf den angegebenen Ressourcen durchzuführen:
+ [AmazonEKSServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServiceRolePolicy.html)
Sie müssen Berechtigungen konfigurieren, damit eine juristische Stelle von IAM (z. B. Benutzer, Gruppe oder Rolle) eine serviceverknüpfte Rolle erstellen, bearbeiten oder löschen kann. Weitere Informationen finden Sie unter [Serviceverknüpfte Rollenberechtigung](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) im *IAM-Benutzerhandbuch*.
## Erstellen einer serviceverknüpften Rolle für Amazon EKS
Sie müssen eine serviceverknüpfte Rolle nicht manuell erstellen. Wenn Sie ein Cluster in der AWS-Managementkonsole, der AWS-CLI oder AWS-API ausführen, erstellt Amazon EKS die serviceverknüpfte Rolle für Sie.
Wenn Sie diese serviceverknüpfte Rolle löschen und sie dann erneut erstellen müssen, können Sie dasselbe Verfahren anwenden, um die Rolle in Ihrem Konto neu anzulegen. Wenn Sie einen Cluster anlegen, legt Amazon EKS die servicegebundene Rolle wieder für Sie an.
## Bearbeiten einer serviceverknüpften Rolle für Amazon EKS
Amazon EKS verhindert die Bearbeitung der serviceverknüpften Rolle `AWSServiceRoleForAmazonEKS`. Da möglicherweise verschiedene Entitäten auf die Rolle verweisen, kann der Rollenname nach dem Erstellen einer servicegebundenen Rolle nicht mehr geändert werden. Sie können jedoch die Beschreibung der Rolle mit IAM bearbeiten. Weitere Informationen finden Sie unter [Bearbeiten einer serviceverknüpften Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) im *IAM-Benutzerhandbuch*.
## Löschen einer serviceverknüpften Rolle für Amazon EKS
Wenn Sie ein Feature oder einen Dienst, die bzw. der eine serviceverknüpften Rolle erfordert, nicht mehr benötigen, sollten Sie diese Rolle löschen. Auf diese Weise haben Sie keine ungenutzte juristische Stelle, die nicht aktiv überwacht oder verwaltet wird. Sie müssen jedoch Ihre serviceverknüpfte Rolle zunächst bereinigen, bevor Sie sie manuell löschen können.
### Bereinigen einer serviceverknüpften Rolle
Bevor mit IAM eine serviceverknüpfte Rolle löschen können, müssen Sie zunächst alle von der Rolle verwendeten Ressourcen löschen.
**Anmerkung**
Wenn der Amazon-EKS-Service die Rolle verwendet, wenn Sie versuchen, die Ressourcen zu löschen, schlägt der Löschvorgang möglicherweise fehl. Wenn das passiert, warten Sie einige Minuten und versuchen Sie es erneut.
1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters).
1. Wählen Sie im linken Navigationsbereich die Option **Cluster** aus.
1. Wenn Ihr Cluster über Knotengruppen oder Fargate-Profile verfügt, müssen Sie diese löschen, bevor Sie den Cluster löschen können. Weitere Informationen erhalten Sie unter [Verwaltete Knotengruppe aus Ihrem Cluster löschen](delete-managed-node-group.md) und [Fargate-Profil löschen](delete-fargate-profile.md).
1. Wählen Sie auf der Seite **Cluster** den Cluster aus, den Sie löschen möchten, und wählen Sie **Löschen**.
1. Geben Sie den Namen des Clusters im Bestätigungsfenster zum Löschen ein, und wählen Sie dann **Bestätigen**.
1. Wiederholen Sie diesen Vorgang für alle anderen Cluster in Ihrem Konto. Warten Sie, bis alle Löschoperationen abgeschlossen sind.
### Manuelles Löschen der -serviceverknüpften Rolle
Sie können die serviceverknüpfte Rolle `AWSServiceRoleForAmazonEKS` über die IAM–Konsole, die AWS-CLI oder die API AWS löschen. Weitere Informationen finden Sie unter [Löschen einer serviceverknüpften Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) im *IAM-Benutzerhandbuch*.
## Unterstützte Regionen für Amazon EKS serviceverknüpfte Rollen
Amazon EKS unterstützt die Verwendung von serviceverknüpften Rollen in allen Regionen, in denen der Service verfügbar ist. Weitere Informationen finden Sie unter [Amazon-EKS-Endpunkte und -Kontingente](https://docs.aws.amazon.com/general/latest/gr/eks.html).
# Verwenden von Rollen für Amazon-EKS-Knotengruppen
Amazon EKS verwendet [serviceverknüpfte Rollen](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role) von AWS AWS Identity and Access Management (IAM). Eine servicegebundene Rolle ist eine einzigartige Art von IAM-Rolle, die direkt mit Amazon EKS verknüpft ist. Serviceverknüpfte Rollen werden von Amazon EKS vordefiniert und schließen alle Berechtigungen ein, die der Service zum Aufrufen anderer AWS-Services in Ihrem Namen erfordert.
Eine serviceverknüpfte Rolle macht die Einrichtung von Amazon EKS einfacher, da Sie die erforderlichen Berechtigungen nicht manuell hinzufügen müssen. Amazon EKS definiert die Berechtigungen seiner mit dem Service verbundenen Rollen, und sofern nicht anders definiert, kann nur Amazon EKS seine Rollen übernehmen. Die definierten Berechtigungen umfassen die Vertrauens- und Berechtigungsrichtlinie. Diese Berechtigungsrichtlinie kann keinen anderen IAM-Entitäten zugewiesen werden.
Sie können eine serviceverknüpfte Rolle erst löschen, nachdem ihre verwandten Ressourcen gelöscht wurden. Dies schützt Ihre Amazon-EKS-Ressourcen, da Sie nicht versehentlich die Zugriffsberechtigung für die Ressourcen entfernen können.
Informationen zu anderen Services, die serviceverknüpfte Rollen unterstützen, finden Sie unter [AWS-Services, die mit IAM funktionieren](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html). Suchen Sie nach den Services, für die **Ja** in der Spalte **Serviceverknüpfte Rolle** angegeben ist. Wählen Sie über einen Link **Ja** aus, um die Dokumentation zu einer servicegebundenen Rolle für diesen Service anzuzeigen.
## Serviceverknüpfte Rollenberechtigungen für Amazon EKS
Amazon ESK verwendet die serviceverknüpfte Rolle mit dem Namen `AWSServiceRoleForAmazonEKSNodegroup`. Mit dieser Rolle kann Amazon EKS die Knotengruppen in Ihrem Konto verwalten. Die angefügte `AWSServiceRoleForAmazonEKSNodegroup`-Richtlinie ermöglichen es der Rolle, die folgenden Ressourcen zu verwalten: Auto-Scaling-Gruppen, Sicherheitsgruppen, Startvorlagen und IAM-Instance-Profile. Weitere Informationen finden Sie unter [AWS verwaltete Richtlinie: AWSService RoleForAmazon EKSNodegroup](security-iam-awsmanpol.md#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup).
Die serviceverknüpfte Rolle `AWSServiceRoleForAmazonEKSNodegroup` vertraut darauf, dass die folgenden Services die Rolle annehmen:
+ `eks-nodegroup.amazonaws.com`
Die Richtlinie für Rollenberechtigungen erlaubt Amazon EKS, die folgenden Aktionen auf den angegebenen Ressourcen durchzuführen:
+ [AWSServiceRoleForAmazonEKSNodegroup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSServiceRoleForAmazonEKSNodegroup.html)
Sie müssen Berechtigungen konfigurieren, damit eine juristische Stelle von IAM (z. B. Benutzer, Gruppe oder Rolle) eine serviceverknüpfte Rolle erstellen, bearbeiten oder löschen kann. Weitere Informationen finden Sie unter [Serviceverknüpfte Rollenberechtigung](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) im *IAM-Benutzerhandbuch*.
## Erstellen einer serviceverknüpften Rolle für Amazon EKS
Sie müssen eine serviceverknüpfte Rolle nicht manuell erstellen. Wenn Sie CreateNodegroup in der AWS-Managementkonsole, der AWS-CLI oder AWS-API ausführen, erstellt Amazon EKS die serviceverknüpfte Rolle für Sie.
**Wichtig**
Diese serviceverknüpfte Rolle kann in Ihrem Konto erscheinen, wenn Sie eine Aktion in einem anderen Service abgeschlossen haben, der die von dieser Rolle unterstützten Funktionen verwendet. Wenn Sie den Amazon EKS-Service vor dem 1. Januar 2017 verwendet haben, als dieser serviceverknüpfte Rollen unterstützt, hat Amazon EKS die AWSServiceRoleForAmazonEKSNodegroup-Rolle in Ihrem Konto erstellt. Weitere Informationen finden Sie unter [In meinem IAM-Konto wird eine neue Rolle angezeigt](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared).
### Erstellen einer serviceverknüpften Rolle in Amazon EKS (AWS-API)
Sie müssen eine serviceverknüpfte Rolle nicht manuell erstellen. Wenn Sie eine verwaltete Knotengruppe in der AWS-Managementkonsole, der AWS-CLI oder AWS-API erstellen, erstellt Amazon EKS die serviceverknüpfte Rolle für Sie.
Wenn Sie diese serviceverknüpfte Rolle löschen und sie dann erneut erstellen müssen, können Sie dasselbe Verfahren anwenden, um die Rolle in Ihrem Konto neu anzulegen. Wenn Sie eine andere verwaltete Knotengruppe erstellen, erstellt Amazon EKS die serviceverknüpfte Rolle erneut für Sie.
## Bearbeiten einer serviceverknüpften Rolle für Amazon EKS
Amazon EKS verhindert die Bearbeitung der serviceverknüpften Rolle `AWSServiceRoleForAmazonEKSNodegroup`. Da möglicherweise verschiedene Entitäten auf die Rolle verweisen, kann der Rollenname nach dem Erstellen einer servicegebundenen Rolle nicht mehr geändert werden. Sie können jedoch die Beschreibung der Rolle mit IAM bearbeiten. Weitere Informationen finden Sie unter [Bearbeiten einer serviceverknüpften Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) im *IAM-Benutzerhandbuch*.
## Löschen einer serviceverknüpften Rolle für Amazon EKS
Wenn Sie ein Feature oder einen Dienst, die bzw. der eine serviceverknüpften Rolle erfordert, nicht mehr benötigen, sollten Sie diese Rolle löschen. Auf diese Weise haben Sie keine ungenutzte juristische Stelle, die nicht aktiv überwacht oder verwaltet wird. Sie müssen jedoch Ihre serviceverknüpfte Rolle zunächst bereinigen, bevor Sie sie manuell löschen können.
### Bereinigen einer serviceverknüpften Rolle
Bevor mit IAM eine serviceverknüpfte Rolle löschen können, müssen Sie zunächst alle von der Rolle verwendeten Ressourcen löschen.
**Anmerkung**
Wenn der Amazon-EKS-Service die Rolle verwendet, wenn Sie versuchen, die Ressourcen zu löschen, schlägt der Löschvorgang möglicherweise fehl. Wenn das passiert, warten Sie einige Minuten und versuchen Sie es erneut.
1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters).
1. Wählen Sie im linken Navigationsbereich die Option **Cluster** aus.
1. Wählen Sie die Registerkarte **Compute** (Datenverarbeitung) aus.
1. Wählen Sie im Abschnitt **Node groups** (Knotengruppen) die zu löschende Knotengruppe aus.
1. Geben Sie den Namen der Knotengruppe im Bestätigungsfenster zum Löschen ein und wählen Sie dann **Bestätigen**.
1. Wiederholen Sie diesen Vorgang für alle anderen Knotengruppen im Cluster. Warten Sie, bis alle Löschoperationen abgeschlossen sind.
### Manuelles Löschen der -serviceverknüpften Rolle
Sie können die serviceverknüpfte Rolle `AWSServiceRoleForAmazonEKSNodegroup` über die IAM–Konsole, die AWS-CLI oder die API AWS löschen. Weitere Informationen finden Sie unter [Löschen einer serviceverknüpften Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) im *IAM-Benutzerhandbuch*.
## Unterstützte Regionen für Amazon EKS serviceverknüpfte Rollen
Amazon EKS unterstützt die Verwendung von serviceverknüpften Rollen in allen Regionen, in denen der Service verfügbar ist. Weitere Informationen finden Sie unter [Amazon-EKS-Endpunkte und -Kontingente](https://docs.aws.amazon.com/general/latest/gr/eks.html).
# Verwenden von Rollen für Amazon-EKS-Fargate-Profile
Amazon EKS verwendet [serviceverknüpfte Rollen](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role) von AWS AWS Identity and Access Management (IAM). Eine servicegebundene Rolle ist eine einzigartige Art von IAM-Rolle, die direkt mit Amazon EKS verknüpft ist. Serviceverknüpfte Rollen werden von Amazon EKS vordefiniert und schließen alle Berechtigungen ein, die der Service zum Aufrufen anderer AWS-Services in Ihrem Namen erfordert.
Eine serviceverknüpfte Rolle macht die Einrichtung von Amazon EKS einfacher, da Sie die erforderlichen Berechtigungen nicht manuell hinzufügen müssen. Amazon EKS definiert die Berechtigungen seiner mit dem Service verbundenen Rollen, und sofern nicht anders definiert, kann nur Amazon EKS seine Rollen übernehmen. Die definierten Berechtigungen umfassen die Vertrauens- und Berechtigungsrichtlinie. Diese Berechtigungsrichtlinie kann keinen anderen IAM-Entitäten zugewiesen werden.
Sie können eine serviceverknüpfte Rolle erst löschen, nachdem ihre verwandten Ressourcen gelöscht wurden. Dies schützt Ihre Amazon-EKS-Ressourcen, da Sie nicht versehentlich die Zugriffsberechtigung für die Ressourcen entfernen können.
Informationen zu anderen Services, die serviceverknüpfte Rollen unterstützen, finden Sie unter [AWS-Services, die mit IAM funktionieren](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html). Suchen Sie nach den Services, für die **Ja** in der Spalte **Serviceverknüpfte Rolle** angegeben ist. Wählen Sie über einen Link **Ja** aus, um die Dokumentation zu einer servicegebundenen Rolle für diesen Service anzuzeigen.
## Serviceverknüpfte Rollenberechtigungen für Amazon EKS
Amazon ESK verwendet die serviceverknüpfte Rolle mit dem Namen `AWSServiceRoleForAmazonEKSForFargate`. Die Rolle ermöglicht Amazon EKS Fargate, das für Fargate Pods erforderliche VPC-Netzwerk zu konfigurieren. Die angehängten Richtlinien ermöglichen es der Rolle, Elastic Network Interfaces zu erstellen und zu löschen und Elastic Network Interfaces und Ressourcen zu beschreiben.
Die serviceverknüpfte Rolle `AWSServiceRoleForAmazonEKSForFargate` vertraut darauf, dass die folgenden Services die Rolle annehmen:
+ `eks-fargate.amazonaws.com`
Die Richtlinie für Rollenberechtigungen erlaubt Amazon EKS, die folgenden Aktionen auf den angegebenen Ressourcen durchzuführen:
+ [AmazonEKSForFargateServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSForFargateServiceRolePolicy.html)
Sie müssen Berechtigungen konfigurieren, damit eine juristische Stelle von IAM (z. B. Benutzer, Gruppe oder Rolle) eine serviceverknüpfte Rolle erstellen, bearbeiten oder löschen kann. Weitere Informationen finden Sie unter [Serviceverknüpfte Rollenberechtigung](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) im *IAM-Benutzerhandbuch*.
## Erstellen einer serviceverknüpften Rolle für Amazon EKS
Sie müssen eine serviceverknüpfte Rolle nicht manuell erstellen. Wenn Sie ein Fargate-Profil in der AWS-Managementkonsole, der AWS-CLI oder der AWS-API erstellen, erstellt Amazon EKS die serviceverknüpfte Rolle für Sie.
**Wichtig**
Diese serviceverknüpfte Rolle kann in Ihrem Konto erscheinen, wenn Sie eine Aktion in einem anderen Service abgeschlossen haben, der die von dieser Rolle unterstützten Features verwendet. Wenn Sie den Amazon-EKS-Service vor dem 13. Dezember 2019 verwendet haben, als dieser Service-verknüpfte Rollen unterstützt, hat Amazon EKS die AWSServiceRoleForAmazonEKSForFargate-Rolle in Ihrem Konto erstellt. Weitere Informationen finden Sie unter [Eine neue Rolle ist in meinem IAM-Konto erschienen](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared).
### Erstellen einer serviceverknüpften Rolle in Amazon EKS (AWS-API)
Sie müssen eine serviceverknüpfte Rolle nicht manuell erstellen. Wenn Sie ein Fargate-Profil in der AWS-Managementkonsole, der AWS-CLI oder der AWS-API erstellen, erstellt Amazon EKS die serviceverknüpfte Rolle für Sie.
Wenn Sie diese serviceverknüpfte Rolle löschen und sie dann erneut erstellen müssen, können Sie dasselbe Verfahren anwenden, um die Rolle in Ihrem Konto neu anzulegen. Wenn Sie eine andere verwaltete Knotengruppe erstellen, erstellt Amazon EKS die serviceverknüpfte Rolle erneut für Sie.
## Bearbeiten einer serviceverknüpften Rolle für Amazon EKS
Amazon EKS verhindert die Bearbeitung der serviceverknüpften Rolle `AWSServiceRoleForAmazonEKSForFargate`. Da möglicherweise verschiedene Entitäten auf die Rolle verweisen, kann der Rollenname nach dem Erstellen einer servicegebundenen Rolle nicht mehr geändert werden. Sie können jedoch die Beschreibung der Rolle mit IAM bearbeiten. Weitere Informationen finden Sie unter [Bearbeiten einer serviceverknüpften Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) im *IAM-Benutzerhandbuch*.
## Löschen einer serviceverknüpften Rolle für Amazon EKS
Wenn Sie ein Feature oder einen Dienst, die bzw. der eine serviceverknüpften Rolle erfordert, nicht mehr benötigen, sollten Sie diese Rolle löschen. Auf diese Weise haben Sie keine ungenutzte juristische Stelle, die nicht aktiv überwacht oder verwaltet wird. Sie müssen jedoch Ihre serviceverknüpfte Rolle zunächst bereinigen, bevor Sie sie manuell löschen können.
### Bereinigen einer serviceverknüpften Rolle
Bevor mit IAM eine serviceverknüpfte Rolle löschen können, müssen Sie zunächst alle von der Rolle verwendeten Ressourcen löschen.
**Anmerkung**
Wenn der Amazon-EKS-Service die Rolle verwendet, wenn Sie versuchen, die Ressourcen zu löschen, schlägt der Löschvorgang möglicherweise fehl. Wenn das passiert, warten Sie einige Minuten und versuchen Sie es erneut.
1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters).
1. Wählen Sie im linken Navigationsbereich **Cluster** aus.
1. Wählen Sie auf der Seite **Cluster (Cluster)** den Cluster aus.
1. Wählen Sie die Registerkarte **Compute** (Datenverarbeitung) aus.
1. Wenn im Abschnitt **Fargate profiles** (Fargate-Profile) Fargate-Profile vorhanden sind, wählen Sie jedes einzeln aus und wählen Sie dann **Delete** (Löschen).
1. Geben Sie den Namen des Profils im Bestätigungsfenster zum Löschen ein, und wählen Sie dann **Bestätigen**.
1. Wiederholen Sie diesen Vorgang für alle anderen Fargate-Profile im Cluster und für alle anderen Cluster in Ihrem Konto.
### Manuelles Löschen der -serviceverknüpften Rolle
Verwenden Sie die IAM-Konsole, die AWS CLI oder die AWS-API, um die serviceverknüpfte Rolle AWSServiceRoleForAmazonEKSForFargate zu löschen. Weitere Informationen finden Sie unter [Löschen einer serviceverknüpften Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) im *IAM-Benutzerhandbuch*.
## Unterstützte Regionen für Amazon EKS serviceverknüpfte Rollen
Amazon EKS unterstützt die Verwendung von serviceverknüpften Rollen in allen Regionen, in denen der Service verfügbar ist. Weitere Informationen finden Sie unter [Amazon-EKS-Endpunkte und -Kontingente](https://docs.aws.amazon.com/general/latest/gr/eks.html).
# Verbinden eines Kubernetes-Clusters mithilfe von Rollen mit Amazon EKS
Amazon EKS verwendet [dienstbezogene](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role) Rollen für AWS Identity and Access Management (IAM). Eine servicegebundene Rolle ist eine einzigartige Art von IAM-Rolle, die direkt mit Amazon EKS verknüpft ist. Servicebezogene Rollen sind von Amazon EKS vordefiniert und beinhalten alle Berechtigungen, die der Service benötigt, um andere AWS Services in Ihrem Namen aufzurufen.
Eine serviceverknüpfte Rolle macht die Einrichtung von Amazon EKS einfacher, da Sie die erforderlichen Berechtigungen nicht manuell hinzufügen müssen. Amazon EKS definiert die Berechtigungen seiner mit dem Service verbundenen Rollen, und sofern nicht anders definiert, kann nur Amazon EKS seine Rollen übernehmen. Die definierten Berechtigungen umfassen die Vertrauens- und Berechtigungsrichtlinie. Diese Berechtigungsrichtlinie kann keinen anderen IAM-Entitäten zugewiesen werden.
Sie können eine serviceverknüpfte Rolle erst löschen, nachdem ihre verwandten Ressourcen gelöscht wurden. Dies schützt Ihre Amazon-EKS-Ressourcen, da Sie nicht versehentlich die Zugriffsberechtigung für die Ressourcen entfernen können.
Informationen zu anderen Services, die serviceverknüpfte Rollen unterstützen, finden Sie unter [AWS -Services, die mit IAM funktionieren](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html). Suchen Sie nach den Services, für die **Ja** in der Spalte **Serviceverknüpfte Rolle** angegeben ist. Wählen Sie über einen Link **Ja** aus, um die Dokumentation zu einer servicegebundenen Rolle für diesen Service anzuzeigen.
## Serviceverknüpfte Rollenberechtigungen für Amazon EKS
Amazon ESK verwendet die serviceverknüpfte Rolle mit dem Namen `AWSServiceRoleForAmazonEKSConnector`. Diese Rolle ermöglicht es Amazon EKS, Kubernetes-Cluster zu verbinden. Die angefügten Richtlinien ermöglichen es der Rolle, die erforderlichen Ressourcen für die Verbindung mit Ihrem registrierten Kubernetes-Cluster zu verwalten.
Die serviceverknüpfte Rolle `AWSServiceRoleForAmazonEKSConnector` vertraut darauf, dass die folgenden Services die Rolle annehmen:
+ `eks-connector.amazonaws.com`
Die Richtlinie für Rollenberechtigungen erlaubt Amazon EKS, die folgenden Aktionen auf den angegebenen Ressourcen durchzuführen:
+ [AmazonEKSConnectorServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSConnectorServiceRolePolicy.html)
Sie müssen Berechtigungen konfigurieren, damit eine juristische Stelle von IAM (z. B. Benutzer, Gruppe oder Rolle) eine serviceverknüpfte Rolle erstellen, bearbeiten oder löschen kann. Weitere Informationen finden Sie unter [Serviceverknüpfte Rollenberechtigung](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) im *IAM-Benutzerhandbuch*.
Diese Rolle verwendet SSM-Berechtigungen (Systems Manager), um sichere Verbindungen herzustellen und verbundene Kubernetes-Cluster zu verwalten.
## Erstellen einer serviceverknüpften Rolle für Amazon EKS
Sie müssen keine serviceverknüpfte Rolle manuell erstellen, um eine Verbindung mit einem Cluster herzustellen. Wenn Sie einen Cluster in der AWS-Managementkonsole, der AWS CLI oder der AWS API verbinden`eksctl`, erstellt Amazon EKS die serviceverknüpfte Rolle für Sie.
Wenn Sie diese serviceverknüpfte Rolle löschen und sie dann erneut erstellen müssen, können Sie dasselbe Verfahren anwenden, um die Rolle in Ihrem Konto neu anzulegen. Wenn Sie einen Cluster verbinden, legt Amazon EKS die servicegebundene Rolle wieder für Sie an.
## Bearbeiten einer serviceverknüpften Rolle für Amazon EKS
Amazon EKS verhindert die Bearbeitung der serviceverknüpften Rolle `AWSServiceRoleForAmazonEKSConnector`. Da möglicherweise verschiedene Entitäten auf die Rolle verweisen, kann der Rollenname nach dem Erstellen einer servicegebundenen Rolle nicht mehr geändert werden. Sie können jedoch die Beschreibung der Rolle mit IAM bearbeiten. Weitere Informationen finden Sie unter [Bearbeiten einer serviceverknüpften Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) im *IAM-Benutzerhandbuch*.
## Löschen einer serviceverknüpften Rolle für Amazon EKS
Wenn Sie ein Feature oder einen Dienst, die bzw. der eine serviceverknüpften Rolle erfordert, nicht mehr benötigen, sollten Sie diese Rolle löschen. Auf diese Weise haben Sie keine ungenutzte juristische Stelle, die nicht aktiv überwacht oder verwaltet wird. Sie müssen jedoch Ihre serviceverknüpfte Rolle zunächst bereinigen, bevor Sie sie manuell löschen können.
### Bereinigen einer serviceverknüpften Rolle
Bevor mit IAM eine serviceverknüpfte Rolle löschen können, müssen Sie zunächst alle von der Rolle verwendeten Ressourcen löschen.
**Anmerkung**
Wenn der Amazon-EKS-Service die Rolle verwendet, wenn Sie versuchen, die Ressourcen zu löschen, schlägt der Löschvorgang möglicherweise fehl. Wenn das passiert, warten Sie einige Minuten und versuchen Sie es erneut.
1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters).
1. Wählen Sie im linken Navigationsbereich **Cluster** aus.
1. Wählen Sie auf der Seite **Cluster (Cluster)** den Cluster aus.
1. Wählen Sie die Registerkarte **Abmelden** und dann die Registerkarte **OK**.
### Manuelles Löschen der serviceverknüpften Rolle
Verwenden Sie die IAM-Konsole, die AWS CLI oder die AWS API, um die AWSService RoleForAmazon EKSConnector serviceverknüpfte Rolle zu löschen. Weitere Informationen finden Sie unter [Löschen einer serviceverknüpften Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) im *IAM-Benutzerhandbuch*.
# Verwenden von Rollen für lokale Amazon-EKS-Cluster in Outpost
Amazon Elastic Kubernetes Service verwendet [serviceverknüpfte Rollen](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role) für AWS Identity and Access Management (IAM). Eine servicegebundene Rolle ist eine einzigartige Art von IAM-Rolle, die direkt mit Amazon EKS verknüpft ist. Serviceverknüpfte Rollen werden von Amazon EKS vordefiniert und schließen alle Berechtigungen ein, die der Service zum Aufrufen anderer AWS-Services in Ihrem Namen erfordert.
Eine serviceverknüpfte Rolle macht die Einrichtung von Amazon EKS einfacher, da Sie die erforderlichen Berechtigungen nicht manuell hinzufügen müssen. Amazon EKS definiert die Berechtigungen seiner mit dem Service verbundenen Rollen, und sofern nicht anders definiert, kann nur Amazon EKS seine Rollen übernehmen. Die definierten Berechtigungen umfassen die Vertrauens- und Berechtigungsrichtlinie. Diese Berechtigungsrichtlinie kann keinen anderen IAM-Entitäten zugewiesen werden.
Sie können eine serviceverknüpfte Rolle erst löschen, nachdem ihre verwandten Ressourcen gelöscht wurden. Dies schützt Ihre Amazon-EKS-Ressourcen, da Sie nicht versehentlich die Zugriffsberechtigung für die Ressourcen entfernen können.
Informationen zu anderen Services, die serviceverknüpfte Rollen unterstützen, finden Sie unter [AWS-Services, die mit IAM funktionieren](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html). Suchen Sie nach den Services, für die **Ja** in der Spalte **Serviceverknüpfte Rolle** angegeben ist. Wählen Sie über einen Link **Ja** aus, um die Dokumentation zu einer servicegebundenen Rolle für diesen Service anzuzeigen.
## Serviceverknüpfte Rollenberechtigungen für Amazon EKS
Amazon ESK verwendet die serviceverknüpfte Rolle mit dem Namen `AWSServiceRoleForAmazonEKSLocalOutpost`. Mit dieser Rolle können Sie Amazon EKS dazu konfigurieren, lokale Cluster in Ihrem Konto zu verwalten. Die angehängten Richtlinien ermöglichen es der Rolle, die folgenden Ressourcen zu verwalten: Netzwerkschnittstellen, Sicherheitsgruppen, Protokolle und Amazon-EC2-Instances.
**Anmerkung**
Die serviceverknüpfte `AWSServiceRoleForAmazonEKSLocalOutpost`-Rolle unterscheidet sich von der Rolle, die für die Clustererstellung erforderlich ist. Weitere Informationen finden Sie unter [Amazon-EKS-Cluster-IAM-Rolle](cluster-iam-role.md).
Die serviceverknüpfte Rolle `AWSServiceRoleForAmazonEKSLocalOutpost` vertraut darauf, dass die folgenden Services die Rolle annehmen:
+ `outposts.eks-local.amazonaws.com`
Die Richtlinie für Rollenberechtigungen erlaubt Amazon EKS, die folgenden Aktionen auf den angegebenen Ressourcen durchzuführen:
+ [AmazonEKSServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServiceRolePolicy.html)
Sie müssen Berechtigungen konfigurieren, damit eine juristische Stelle von IAM (z. B. Benutzer, Gruppe oder Rolle) eine serviceverknüpfte Rolle erstellen, bearbeiten oder löschen kann. Weitere Informationen finden Sie unter [Serviceverknüpfte Rollenberechtigung](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) im *IAM-Benutzerhandbuch*.
## Erstellen einer serviceverknüpften Rolle für Amazon EKS
Sie müssen eine serviceverknüpfte Rolle nicht manuell erstellen. Wenn Sie ein Cluster in der AWS-Managementkonsole, der AWS-CLI oder AWS-API ausführen, erstellt Amazon EKS die serviceverknüpfte Rolle für Sie.
Wenn Sie diese serviceverknüpfte Rolle löschen und sie dann erneut erstellen müssen, können Sie dasselbe Verfahren anwenden, um die Rolle in Ihrem Konto neu anzulegen. Wenn Sie einen Cluster anlegen, legt Amazon EKS die servicegebundene Rolle wieder für Sie an.
## Bearbeiten einer serviceverknüpften Rolle für Amazon EKS
Amazon EKS verhindert die Bearbeitung der serviceverknüpften Rolle `AWSServiceRoleForAmazonEKSLocalOutpost`. Nachdem Sie eine serviceverknüpfte Rolle erstellt haben, können Sie den Namen der Rolle nicht mehr ändern, da verschiedene Entitäten auf die Rolle verweisen könnten. Sie können jedoch die Beschreibung der Rolle mit IAM bearbeiten. Weitere Informationen finden Sie unter [Bearbeiten einer serviceverknüpften Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) im *IAM-Benutzerhandbuch*.
## Löschen einer serviceverknüpften Rolle für Amazon EKS
Wenn Sie ein Feature oder einen Dienst, die bzw. der eine serviceverknüpften Rolle erfordert, nicht mehr benötigen, sollten Sie diese Rolle löschen. Auf diese Weise haben Sie keine ungenutzte juristische Stelle, die nicht aktiv überwacht oder verwaltet wird. Sie müssen jedoch Ihre serviceverknüpfte Rolle zunächst bereinigen, bevor Sie sie manuell löschen können.
### Bereinigen einer serviceverknüpften Rolle
Bevor mit IAM eine serviceverknüpfte Rolle löschen können, müssen Sie zunächst alle von der Rolle verwendeten Ressourcen löschen.
**Anmerkung**
Wenn der Amazon-EKS-Service die Rolle verwendet, wenn Sie versuchen, die Ressourcen zu löschen, schlägt der Löschvorgang möglicherweise fehl. Wenn das passiert, warten Sie einige Minuten und versuchen Sie es erneut.
1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters).
1. Wählen Sie im linken Navigationsbereich **Clusters** (Cluster) für Amazon EKS aus.
1. Wenn Ihr Cluster über Knotengruppen oder Fargate-Profile verfügt, müssen Sie diese löschen, bevor Sie den Cluster löschen können. Weitere Informationen erhalten Sie unter [Verwaltete Knotengruppe aus Ihrem Cluster löschen](delete-managed-node-group.md) und [Fargate-Profil löschen](delete-fargate-profile.md).
1. Wählen Sie auf der Seite **Cluster** den Cluster aus, den Sie löschen möchten, und wählen Sie **Löschen**.
1. Geben Sie den Namen des Clusters im Bestätigungsfenster zum Löschen ein, und wählen Sie dann **Bestätigen**.
1. Wiederholen Sie diesen Vorgang für alle anderen Cluster in Ihrem Konto. Warten Sie, bis alle Löschoperationen abgeschlossen sind.
### Manuelles Löschen der -serviceverknüpften Rolle
Sie können die serviceverknüpfte Rolle `AWSServiceRoleForAmazonEKSLocalOutpost` über die IAM–Konsole, die AWS-CLI oder die API AWS löschen. Weitere Informationen finden Sie unter [Löschen einer serviceverknüpften Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) im *IAM-Benutzerhandbuch*.
## Unterstützte Regionen für Amazon EKS serviceverknüpfte Rollen
Amazon EKS unterstützt die Verwendung von serviceverknüpften Rollen in allen Regionen, in denen der Service verfügbar ist. Weitere Informationen finden Sie unter [Amazon-EKS-Endpunkte und -Kontingente](https://docs.aws.amazon.com/general/latest/gr/eks.html).
# Verwendung von Rollen für das Amazon-EKS-Dashboard
Das Amazon-EKS-Dashboard verwendet diese serviceverknüpfte Rolle, um Informationen über Cluster-Ressourcen aus mehreren Regionen und Konten zu aggregieren. Das Dashboard lässt sich in AWS Organizations integrieren, um Informationen zu mehreren Konten in Ihrem Unternehmen sicher zu lesen.
Weitere Informationen zum Amazon-EKS-Dashboard finden Sie unter [Anzeigen aggregierter Daten zu Cluster-Ressourcen mit dem EKS-Dashboard](cluster-dashboard.md).
## Hintergrund
Amazon EKS verwendet [serviceverknüpfte Rollen](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role) von AWS AWS Identity and Access Management (IAM). Eine servicegebundene Rolle ist eine einzigartige Art von IAM-Rolle, die direkt mit Amazon EKS verknüpft ist. Serviceverknüpfte Rollen werden von Amazon EKS vordefiniert und schließen alle Berechtigungen ein, die der Service zum Aufrufen anderer AWS-Services in Ihrem Namen erfordert.
Eine serviceverknüpfte Rolle macht die Einrichtung von Amazon EKS einfacher, da Sie die erforderlichen Berechtigungen nicht manuell hinzufügen müssen. Amazon EKS definiert die Berechtigungen seiner mit dem Service verbundenen Rollen, und sofern nicht anders definiert, kann nur Amazon EKS seine Rollen übernehmen. Die definierten Berechtigungen umfassen die Vertrauens- und Berechtigungsrichtlinie. Diese Berechtigungsrichtlinie kann keinen anderen IAM-Entitäten zugewiesen werden.
Sie können eine serviceverknüpfte Rolle erst löschen, nachdem ihre verwandten Ressourcen gelöscht wurden. Dies schützt Ihre Amazon-EKS-Ressourcen, da Sie nicht versehentlich die Zugriffsberechtigung für die Ressourcen entfernen können.
Informationen zu anderen Services, die serviceverknüpfte Rollen unterstützen, finden Sie unter [AWS-Services, die mit IAM funktionieren](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html). Suchen Sie nach den Services, für die **Ja** in der Spalte **Serviceverknüpfte Rolle** angegeben ist. Wählen Sie über einen Link **Ja** aus, um die Dokumentation zu einer servicegebundenen Rolle für diesen Service anzuzeigen.
## Serviceverknüpfte Rollenberechtigungen für Amazon EKS
Amazon ESK verwendet die serviceverknüpfte Rolle mit dem Namen `AWSServiceRoleForAmazonEKSDashboard`. Mit dieser Rolle kann Amazon EKS das EKS-Dashboard generieren und anzeigen, einschließlich aggregierter Information zu Cluster-Ressourcen. Die angefügte `AmazonEKSDashboardServiceRolePolicy`-Richtlinie ermöglichen es der Rolle, die folgenden Ressourcen zu verwalten: Auto-Scaling-Gruppen, Sicherheitsgruppen, Startvorlagen und IAM-Instance-Profile. Weitere Informationen finden Sie unter [AWS verwaltete Richtlinie: Amazon EKSDashboard ServiceRolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSDashboardServiceRolePolicy).
Die serviceverknüpfte Rolle `AWSServiceRoleForAmazonEKSDashboard` vertraut darauf, dass die folgenden Services die Rolle annehmen:
+ `dashboard.eks.amazonaws.com`
Die neueste Version des JSON-Richtliniendokuments finden Sie unter [AmazonEKSDashboardServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSDashboardServiceRolePolicy.html#AmazonEKSDashboardServiceRolePolicy-json) im Referenzhandbuch zu von AWSverwalteten Richtlinien.
Sie müssen Berechtigungen konfigurieren, damit eine juristische Stelle von IAM (z. B. Benutzer, Gruppe oder Rolle) eine serviceverknüpfte Rolle erstellen, bearbeiten oder löschen kann. Weitere Informationen finden Sie unter [Serviceverknüpfte Rollenberechtigung](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) im *IAM-Benutzerhandbuch*.
## Erstellen einer serviceverknüpften Rolle für Amazon EKS
Sie müssen eine serviceverknüpfte Rolle nicht manuell erstellen. Wenn Sie das Dashboard in der AWS-Konsole aktivieren, erstellt Amazon EKS die serviceverknüpfte Rolle für Sie.
Weitere Informationen zum Aktivieren des EKS-Dashboards finden Sie unter [Konfiguration der EKS-Dashboard-Integration mit AWS Organizations](cluster-dashboard-orgs.md).
**Wichtig**
Diese serviceverknüpfte Rolle kann in Ihrem Konto erscheinen, wenn Sie eine Aktion in einem anderen Service abgeschlossen haben, der die von dieser Rolle unterstützten Features verwendet.
## Bearbeiten einer serviceverknüpften Rolle für Amazon EKS
Amazon EKS verhindert die Bearbeitung der serviceverknüpften Rolle `AWSServiceRoleForAmazonEKSDashboard`. Da möglicherweise verschiedene Entitäten auf die Rolle verweisen, kann der Rollenname nach dem Erstellen einer servicegebundenen Rolle nicht mehr geändert werden. Sie können jedoch die Beschreibung der Rolle mit IAM bearbeiten. Weitere Informationen finden Sie unter [Bearbeiten einer serviceverknüpften Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) im *IAM-Benutzerhandbuch*.
## Löschen einer serviceverknüpften Rolle für Amazon EKS
Wenn Sie ein Feature oder einen Dienst, die bzw. der eine serviceverknüpften Rolle erfordert, nicht mehr benötigen, sollten Sie diese Rolle löschen. Auf diese Weise haben Sie keine ungenutzte juristische Stelle, die nicht aktiv überwacht oder verwaltet wird. Sie müssen jedoch Ihre serviceverknüpfte Rolle zunächst bereinigen, bevor Sie sie manuell löschen können.
### Bereinigen einer serviceverknüpften Rolle
Bevor mit IAM eine serviceverknüpfte Rolle löschen können, müssen Sie zunächst alle von der Rolle verwendeten Ressourcen löschen.
**Anmerkung**
Wenn der Amazon-EKS-Service die Rolle verwendet, wenn Sie versuchen, die Ressourcen zu löschen, schlägt der Löschvorgang möglicherweise fehl. Wenn das passiert, warten Sie einige Minuten und versuchen Sie es erneut.
Weitere Informationen zum Deaktivieren des EKS-Dashboards finden Sie unter [Konfiguration der EKS-Dashboard-Integration mit AWS Organizations](cluster-dashboard-orgs.md).
### Manuelles Löschen der -serviceverknüpften Rolle
Sie können die serviceverknüpfte Rolle `AWSServiceRoleForAmazonEKSDashboard` über die IAM–Konsole, die AWS-CLI oder die API AWS löschen. Weitere Informationen finden Sie unter [Löschen einer serviceverknüpften Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) im *IAM-Benutzerhandbuch*.
## Unterstützte Regionen für Amazon EKS serviceverknüpfte Rollen
Amazon EKS unterstützt die Verwendung von serviceverknüpften Rollen in allen Regionen, in denen der Service verfügbar ist. Weitere Informationen finden Sie unter [Amazon-EKS-Endpunkte und -Kontingente](https://docs.aws.amazon.com/general/latest/gr/eks.html).
# IAM-Rolle für die Ausführung von Amazon-EKS-Pods
Die Amazon EKS Pod-Ausführungsrolle ist erforderlich, um Pods auf der AWS Fargate-Infrastruktur auszuführen.
Wenn Ihr Cluster Pods auf der AWS Fargate-Infrastruktur erstellt, müssen die Komponenten, die auf der Fargate-Infrastruktur ausgeführt werden, in AWS APIs Ihrem Namen Aufrufe tätigen. Auf diese Weise können sie Aktionen wie das Abrufen von Container-Images aus Amazon ECR oder das Weiterleiten von Protokollen an andere AWS Dienste ausführen. Die Amazon-EKS-Pod-Ausführungsrolle stellt die entsprechenden IAM-Berechtigungen bereit.
Wenn Sie ein Fargate-Profil erstellen, müssen Sie eine Pod-Ausführungsrolle für die Amazon-EKS-Komponenten angeben, die in der Fargate-Infrastruktur mit dem Profil ausgeführt werden. Diese Rolle wird zur Autorisierung der [Rollenbasierten Zugriffskontrolle](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) (RBAC) von Kubernetes des Clusters hinzugefügt. Auf diese Weise kann sich das `kubelet`, das in der Fargate-Infrastruktur ausgeführt wird, bei Ihrem Amazon-EKS-Cluster registrieren, sodass es als Knoten in Ihrem Cluster angezeigt werden kann.
**Anmerkung**
Das Fargate-Profil muss eine andere IAM-Rolle haben als EC2 Amazon-Knotengruppen.
**Wichtig**
Die im Fargate-Pod ausgeführten Container können nicht die IAM-Berechtigungen annehmen, die einer Pod-Ausführungsrolle zugeordnet sind. Um den Containern in Ihrem Fargate-Pod Zugriff auf andere AWS Dienste zu gewähren, müssen Sie [IAM-Rollen für Dienstkonten](iam-roles-for-service-accounts.md) verwenden.
[Bevor Sie ein Fargate-Profil erstellen, müssen Sie eine IAM-Rolle bei Amazon erstellen. EKSFargate PodExecutionRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSFargatePodExecutionRolePolicy.html)
## Auf eine korrekt konfigurierte Pod-Ausführungsrolle prüfen
Mit dem folgenden Verfahren können Sie feststellen, ob Ihr Konto bereits über eine korrekt konfigurierte Amazon-EKS-Pod-Ausführungsrolle verfügt. Um Sicherheitsprobleme durch verwirrte Stellvertreter zu vermeiden, ist es wichtig, dass die Rolle den Zugriff basierend auf `SourceArn` beschränkt. Sie können die Ausführungsrolle nach Bedarf ändern, um Fargate-Profile auch auf anderen Clustern zu unterstützen.
1. Öffnen Sie die IAM-Konsole unter. https://console.aws.amazon.com/iam/
1. Wählen Sie im linken Navigationsbereich **Roles** aus.
1. Suchen Sie auf der Seite **Rollen** in der Liste der Rollen für **Amazon EKSFargate PodExecutionRole**. Wenn die Rolle nicht vorhanden ist, finden Sie unter [Erstellen der Amazon-EKS-Pod-Ausführungsrolle](#create-pod-execution-role) Informationen zum Erstellen der Rolle. Wenn die Rolle vorhanden ist, wählen Sie sie aus.
1. Gehen Sie auf der **EKSFargatePodExecutionRoleAmazon-Seite** wie folgt vor:
1. Wählen Sie **Berechtigungen**.
1. Stellen Sie sicher, dass die von **EKSFargatePodExecutionRolePolicyAmazon** verwaltete Richtlinie mit der Rolle verknüpft ist.
1. Wählen Sie **Trust Relationships (Vertrauensbeziehungen)** aus.
1. Wählen Sie **Edit trust policy** (Vertrauensrichtlinie bearbeiten) aus.
1. Prüfen Sie auf der Seite **Edit trust policy** (Vertrauensrichtlinie bearbeiten), dass die Vertrauensbeziehung die folgende Richtlinie und eine Zeile für Fargate-Profile in Ihrem Cluster enthält. Wenn ja, wählen Sie **Cancel** (Abbrechen) aus.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:eks:us-east-1:111122223333:fargateprofile/my-cluster/*"
}
},
"Principal": {
"Service": "eks-fargate-pods.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
Wenn die Richtlinie übereinstimmt, aber keine Zeile mit den Fargate-Profilen in Ihrem Cluster enthält, können Sie die folgende Zeile oben im `ArnLike`-Objekt hinzufügen. *region-code*Ersetzen Sie es durch die AWS Region, in der sich Ihr Cluster befindet, *111122223333* durch Ihre Konto-ID und *my-cluster* durch den Namen Ihres Clusters.
```
"aws:SourceArn": "arn:aws: eks:region-code:111122223333:fargateprofile/my-cluster/*",
```
Wenn die Richtlinie nicht übereinstimmt, kopieren Sie die vollständige vorherige Richtlinie in das Formular und wählen Sie **Richtlinie aktualisieren** aus. *region-code*Ersetzen Sie durch die AWS Region, in der sich Ihr Cluster befindet. Wenn Sie dieselbe Rolle in allen AWS Regionen Ihres Kontos verwenden möchten, *region-code* ersetzen Sie es durch`*`. Ersetzen Sie *111122223333* durch Ihre Konto-ID und *my-cluster* durch den Namen Ihres Clusters. Wenn Sie dieselbe Rolle für alle Cluster in Ihrem Konto verwenden möchten, ersetzen Sie *my-cluster* durch `*`.
## Erstellen der Amazon-EKS-Pod-Ausführungsrolle
Wenn Sie noch nicht über die Amazon EKS-Pod-Ausführungsrolle für Ihren Cluster verfügen, können Sie die AWS-Managementkonsole oder die AWS CLI verwenden, um sie zu erstellen.
AWS-Managementkonsole
1. Öffnen Sie die IAM-Konsole unter https://console.aws.amazon.com/iam/.
1. Wählen Sie im linken Navigationsbereich **Roles** aus.
1. Klicken Sie auf der Seite **Roles (Rollen)** auf **Create role (Rolle erstellen)**.
1. Gehen Sie auf der Seite **Select trusted entity** (Vertrauenswürdige Entität auswählen) wie folgt vor:
1. Wählen Sie im Abschnitt **Vertrauenswürdiger Entitätstyp** die Option ** AWS Service** aus.
1. Wählen Sie aus der Dropdownliste **Anwendungsfälle für andere AWS Dienste** die Option **EKS** aus.
1. Wählen Sie **EKS – Fargate-Pod** aus.
1. Wählen Sie **Weiter** aus.
1. Wählen Sie auf der Seite **Add permissions** (Berechtigungen hinzufügen) die Option **Next** (Weiter) aus.
1. Gehen Sie auf der Seite **Name, review, and create** (Benennen, überprüfen und erstellen) wie folgt vor:
1. Geben Sie unter **Role name** (Rollenname) einen eindeutigen Namen für die Rolle ein, z. B. `AmazonEKSFargatePodExecutionRole`.
1. Fügen Sie der Rolle unter **Tags hinzufügen (optional)** Metadaten hinzu, indem Sie Tags als Schlüssel-Wert-Paare anfügen. Weitere Informationen zur Verwendung von Tags in IAM finden Sie unter [Markieren von IAM-Ressourcen](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html) im *IAM-Benutzerhandbuch*.
1. Wählen Sie **Rolle erstellen** aus.
1. Suchen Sie auf der Seite **Rollen** in der Liste der Rollen für **Amazon EKSFargate PodExecutionRole**. Wählen Sie die Rolle aus.
1. Gehen Sie auf der **EKSFargatePodExecutionRoleAmazon-Seite** wie folgt vor:
1. Wählen Sie **Trust Relationships (Vertrauensbeziehungen)** aus.
1. Wählen Sie **Edit trust policy** (Vertrauensrichtlinie bearbeiten) aus.
1. Führen Sie auf der Seite **Edit trust policy** (Vertrauensrichtlinie bearbeiten) die folgenden Schritte aus:
1. Kopieren Sie die folgenden Inhalte in das Formular unter **Edit trust policy** (Vertrauensrichtlinie bearbeiten). *region-code*Ersetzen Sie es durch die AWS Region, in der sich Ihr Cluster befindet. Wenn Sie dieselbe Rolle in allen AWS Regionen Ihres Kontos verwenden möchten, *region-code* ersetzen Sie es durch`*`. Ersetzen Sie *111122223333* durch Ihre Konto-ID und *my-cluster* durch den Namen Ihres Clusters. Wenn Sie dieselbe Rolle für alle Cluster in Ihrem Konto verwenden möchten, ersetzen Sie *my-cluster* durch `*`.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:eks:us-east-1:111122223333:fargateprofile/my-cluster/*"
}
},
"Principal": {
"Service": "eks-fargate-pods.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Wählen Sie **Update policy**.
AWS CLI
1. Kopieren Sie den folgenden Inhalt in eine Datei namens `pod-execution-role-trust-policy.json`. *region-code*Ersetzen Sie durch die AWS Region, in der sich Ihr Cluster befindet. Wenn Sie dieselbe Rolle in allen AWS Regionen Ihres Kontos verwenden möchten, *region-code* ersetzen Sie es durch`*`. Ersetzen Sie *111122223333* durch Ihre Konto-ID und *my-cluster* durch den Namen Ihres Clusters. Wenn Sie dieselbe Rolle für alle Cluster in Ihrem Konto verwenden möchten, ersetzen Sie *my-cluster* durch `*`.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:eks:us-east-1:111122223333:fargateprofile/my-cluster/*"
}
},
"Principal": {
"Service": "eks-fargate-pods.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Erstellen Sie eine IAM-Rolle für die Pod-Ausführung.
```
aws iam create-role \
--role-name AmazonEKSFargatePodExecutionRole \
--assume-role-policy-document file://"pod-execution-role-trust-policy.json"
```
1. Hängen Sie die erforderliche von Amazon EKS verwaltete IAM-Richtlinie an die Rolle an.
```
aws iam attach-role-policy \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSFargatePodExecutionRolePolicy \
--role-name AmazonEKSFargatePodExecutionRole
```
# Amazon-EKS-Konnektor-IAM-Rolle
Sie können Kubernetes-Cluster verbinden, um sie in Ihrem anzuzeigen. AWS-Managementkonsole Um eine Verbindung zu einem Kubernetes-Cluster herzustellen, erstellen Sie eine IAM-Rolle.
## Überprüfen auf eine vorhandene EKS-Connector-Rolle
Mit dem folgenden Verfahren können Sie feststellen, ob Ihr Konto bereits über die Amazon-EKS-Konnektorrolle verfügt.
1. Öffnen Sie die IAM-Konsole unter. https://console.aws.amazon.com/iam/
1. Wählen Sie im linken Navigationsbereich **Roles** aus.
1. Suchen Sie in der Liste der Rollen nach `AmazonEKSConnectorAgentRole`. Wenn keine Rolle mit `AmazonEKSConnectorAgentRole` vorhanden ist, informieren Sie sich unter [Erstellen der Rolle des Amazon-EKS-Connector-Agenten](#create-connector-role), wie Sie die Rolle erstellen können. Wenn eine Rolle mit `AmazonEKSConnectorAgentRole` vorhanden ist, wählen Sie die Rolle aus, um die angefügten Richtlinien anzuzeigen.
1. Wählen Sie **Berechtigungen**.
1. Stellen Sie sicher, dass die von **Amazon EKSConnector AgentPolicy** verwaltete Richtlinie der Rolle zugeordnet ist. Wenn die Richtlinie angefügt ist, ist Ihre Amazon-EKS-Connector-Rolle ordnungsgemäß konfiguriert.
1. Wählen Sie **Vertrauensstellungen** und dann **Vertrauensrichtlinie bearbeiten** aus.
1. Überprüfen Sie, dass die Vertrauensstellung die folgende Richtlinie enthält. Wenn die Vertrauensstellung mit der folgenden Richtlinie übereinstimmt, wählen Sie **Abbrechen** aus. Andernfalls kopieren Sie die Richtlinie in das Fenster **Vertrauensrichtlinie bearbeiten** und wählen Sie **Richtlinie aktualisieren** aus.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"ssm.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
## Erstellen der Rolle des Amazon-EKS-Connector-Agenten
Sie können das AWS-Managementkonsole oder verwenden AWS CloudFormation , um die Connector-Agent-Rolle zu erstellen.
AWS CLI
1. Erstellen Sie eine Datei mit dem Namen `eks-connector-agent-trust-policy.json`, die die folgende JSON enthält, die für die IAM-Rolle verwendet werden soll.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"ssm.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Erstellen Sie eine Datei mit dem Namen `eks-connector-agent-policy.json`, die die folgende JSON enthält, die für die IAM-Rolle verwendet werden soll.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "SsmControlChannel",
"Effect": "Allow",
"Action": [
"ssmmessages:CreateControlChannel"
],
"Resource": "arn:aws:eks:*:*:cluster/*"
},
{
"Sid": "ssmDataplaneOperations",
"Effect": "Allow",
"Action": [
"ssmmessages:CreateDataChannel",
"ssmmessages:OpenDataChannel",
"ssmmessages:OpenControlChannel"
],
"Resource": "*"
}
]
}
```
1. Erstellen Sie die Agentenrolle von Amazon EKS Connector mithilfe der Vertrauensrichtlinie und Richtlinie, die Sie in den vorherigen Listenelementen erstellt haben.
```
aws iam create-role \
--role-name AmazonEKSConnectorAgentRole \
--assume-role-policy-document file://eks-connector-agent-trust-policy.json
```
1. Hängen Sie die Richtlinie an Ihre Amazon-EKS-Connector-Agentenrolle an.
```
aws iam put-role-policy \
--role-name AmazonEKSConnectorAgentRole \
--policy-name AmazonEKSConnectorAgentPolicy \
--policy-document file://eks-connector-agent-policy.json
```
AWS CloudFormation
1. Speichern Sie die folgende AWS CloudFormation Vorlage in einer Textdatei auf Ihrem lokalen System.
**Anmerkung**
Diese Vorlage erstellt auch die mit dem Service verknüpfte Rolle, die andernfalls beim Aufruf der `registerCluster`-API erstellt würde. Details dazu finden Sie unter [Verbinden eines Kubernetes-Clusters mithilfe von Rollen mit Amazon EKS](using-service-linked-roles-eks-connector.md).
```
---
AWSTemplateFormatVersion: '2010-09-09'
Description: 'Provisions necessary resources needed to register clusters in EKS'
Parameters: {}
Resources:
EKSConnectorSLR:
Type: AWS::IAM::ServiceLinkedRole
Properties:
AWSServiceName: eks-connector.amazonaws.com
EKSConnectorAgentRole:
Type: AWS::IAM::Role
Properties:
AssumeRolePolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Action: [ 'sts:AssumeRole' ]
Principal:
Service: 'ssm.amazonaws.com'
EKSConnectorAgentPolicy:
Type: AWS::IAM::Policy
Properties:
PolicyName: EKSConnectorAgentPolicy
Roles:
- {Ref: 'EKSConnectorAgentRole'}
PolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: 'Allow'
Action: [ 'ssmmessages:CreateControlChannel' ]
Resource:
- Fn::Sub: 'arn:${AWS::Partition}:eks:*:*:cluster/*'
- Effect: 'Allow'
Action: [ 'ssmmessages:CreateDataChannel', 'ssmmessages:OpenDataChannel', 'ssmmessages:OpenControlChannel' ]
Resource: "*"
Outputs:
EKSConnectorAgentRoleArn:
Description: The agent role that EKS connector uses to communicate with AWS services.
Value: !GetAtt EKSConnectorAgentRole.Arn
```
1. Öffnen Sie die [AWS CloudFormation -Konsole](https://console.aws.amazon.com/cloudformation/).
1. Wählen Sie **Stack erstellen** mit neuen Ressourcen (Standard).
1. Wählen Sie für **Specify template (Vorlage festlegen)** **Upload a template file (Vorlagendatei hochladen)** aus und wählen Sie dann **Choose file (Datei wählen)**.
1. Wählen Sie die zuvor erstellte Datei und klicken Sie dann auf **Next (Weiter)**.
1. Geben Sie für **Stack name (Stack-Name)** einen Namen für Ihre Rolle ein, wie z. B. `eksConnectorAgentRole`. Klicken Sie dann auf **Next (Weiter)**.
1. Wählen Sie auf der Seite **Configure stack options** (Stack-Optionen konfigurieren) **Next** (Weiter) aus.
1. Überprüfen Sie auf der Seite **Überprüfen** Ihre Informationen, bestätigen Sie, dass der Stack IAM-Ressourcen erstellen kann, und wählen Sie dann **Erstellen** aus.
# AWS verwaltete Richtlinien für Amazon Elastic Kubernetes Service
Eine AWS verwaltete Richtlinie ist eine eigenständige Richtlinie, die von erstellt und verwaltet wird AWS. AWS Verwaltete Richtlinien sind so konzipiert, dass sie Berechtigungen für viele gängige Anwendungsfälle bereitstellen, sodass Sie damit beginnen können, Benutzern, Gruppen und Rollen Berechtigungen zuzuweisen.
Beachten Sie, dass AWS verwaltete Richtlinien für Ihre speziellen Anwendungsfälle möglicherweise keine Berechtigungen mit den geringsten Rechten gewähren, da sie allen AWS Kunden zur Verfügung stehen. Wir empfehlen Ihnen, die Berechtigungen weiter zu reduzieren, indem Sie [vom Kunden verwaltete Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) definieren, die speziell auf Ihre Anwendungsfälle zugeschnitten sind.
Sie können die in AWS verwalteten Richtlinien definierten Berechtigungen nicht ändern. Wenn die in einer AWS verwalteten Richtlinie definierten Berechtigungen AWS aktualisiert werden, wirkt sich das Update auf alle Prinzidentitäten (Benutzer, Gruppen und Rollen) aus, denen die Richtlinie zugeordnet ist. AWS aktualisiert eine AWS verwaltete Richtlinie höchstwahrscheinlich, wenn ein neuer AWS Dienst gestartet wird oder neue API-Operationen für bestehende Dienste verfügbar werden.
Weitere Informationen finden Sie unter [Von AWS verwaltete Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) im *IAM-Benutzerhandbuch*.
## AWS verwaltete Richtlinie: Amazoneks\$1CNI\$1Policy
Sie können die `AmazonEKS_CNI_Policy` an Ihre IAM-Entitäten anhängen. Bevor Sie eine Amazon-EC2-Knotengruppe erstellen, muss diese Richtlinie entweder an die [Knoten-IAM-Rolle](create-node-role.md) oder an eine IAM-Rolle angefügt werden, die speziell vom Amazon-VPC-CNI-Plugin für Kubernetes verwendet wird. Dies dient dazu, Aktionen in Ihrem Namen auszuführen. Wir empfehlen, dass Sie die Richtlinie einer Rolle anfügen, die nur vom Plugin verwendet wird. Weitere Informationen erhalten Sie unter [Pods mit dem Amazon VPC CNI zuweisen IPs](managing-vpc-cni.md) und [Konfiguration des Amazon-VPC-CNI-Plugins für die Verwendung von IRSA](cni-iam-role.md).
**Details zu Berechtigungen**
Diese Richtlinie enthält die folgenden Berechtigungen, die es Amazon EKS ermöglichen, die folgenden Aufgaben auszuführen:
+ ** `ec2:*NetworkInterface` und `ec2:*PrivateIpAddresses` ** – Ermöglicht dem Amazon-VPC-CNI-Plugin, Aktionen wie die Bereitstellung von Elastic Network Interfaces und IP-Adressen für Pods auszuführen, um Netzwerke für Anwendungen bereitzustellen, die in Amazon EKS ausgeführt werden.
+ ** `ec2`-Leseaktionen** – Ermöglicht dem Amazon-VPC-CNI-Plugin, Aktionen wie das Beschreiben von Instances und Subnetzen auszuführen, um die Anzahl der freien IP-Adressen in Ihren Amazon-VPC-Subnetzen anzuzeigen. Das VPC CNI kann die freien IP-Adressen in jedem Subnetz verwenden, um die Subnetze mit den meisten freien IP-Adressen für die Erstellung einer elastischen Netzwerkschnittstelle auszuwählen.
Die neueste Version des JSON-Richtliniendokuments finden Sie unter [AmazonEKS\$1CNI\$1Policy im Managed Policy Reference Guide](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKS_CNI_Policy.html#AmazonEKS_CNI_Policy-json). AWS
## AWS verwaltete Richtlinie: EKSCluster Amazon-Richtlinie
Sie können `AmazonEKSClusterPolicy` an Ihre IAM-Entitäten anhängen. Bevor Sie einen Cluster erstellen, müssen Sie über eine [Cluster-IAM-Rolle](cluster-iam-role.md) mit dieser angehängten Richtlinie verfügen. Kubernetes-Cluster, die von Amazon EKS verwaltet werden, rufen in Ihrem Namen andere AWS Services auf. Sie tun dies, um die Ressourcen zu verwalten, die Sie mit dem Service verwenden.
Diese Richtlinie enthält die folgenden Berechtigungen, die es Amazon EKS ermöglichen, die folgenden Aufgaben auszuführen:
+ ** `autoscaling` ** – Lesen und aktualisieren Sie die Konfiguration einer Auto-Scaling-Gruppe. Diese Berechtigungen werden von Amazon EKS nicht verwendet, verbleiben jedoch aus Gründen der Abwärtskompatibilität in der Richtlinie.
+ ** `ec2` ** – Arbeiten Sie mit Volumes und Netzwerkressourcen, die Amazon-EC2-Knoten zugeordnet sind. Dies ist erforderlich, damit die Kubernetes-Steuerebene Instances zu einem Cluster verbinden und von persistenten Kubernetes-Volumes angeforderte Amazon-EBS-Volumes dynamisch bereitstellen und verwalten kann.
+ ** `ec2` ** – Löschen Sie elastische Netzwerkschnittstellen, die vom VPC CNI erstellt wurden. Dies ist erforderlich, damit EKS elastische Netzwerkschnittstellen bereinigen kann, die zurückbleiben, wenn das VPC CNI unerwartet beendet wird.
+ ** `elasticloadbalancing` ** – Arbeiten Sie mit Elastic Load Balancern und fügen Sie ihnen Knoten als Ziele hinzu. Dies ist erforderlich, damit die Kubernetes-Steuerebene von Kubernetes-Diensten angeforderte Elastic Load Balancer dynamisch bereitstellen kann.
+ ** `iam` ** – Erstellen Sie eine serviceverknüpfte Rolle. Dies ist erforderlich, damit die Kubernetes-Steuerebene von Kubernetes-Services angeforderte Elastic Load Balancer dynamisch bereitstellen kann.
+ **`kms`**— Liest einen Schlüssel von AWS KMS. Dies ist erforderlich, damit die Kubernetes-Steuerebene die [Secrets-Verschlüsselung](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) von Kubernetes-Secrets unterstützt, die in `etcd` gespeichert sind.
Die neueste Version des JSON-Richtliniendokuments finden Sie unter [Amazon EKSCluster Policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html#AmazonEKSClusterPolicy-json) im AWS Managed Policy Reference Guide.
## AWS verwaltete Richtlinie: Amazon EKSDashboard ConsoleReadOnly
Sie können `AmazonEKSDashboardConsoleReadOnly` an Ihre IAM-Entitäten anhängen.
Diese Richtlinie enthält die folgenden Berechtigungen, die es Amazon EKS ermöglichen, die folgenden Aufgaben auszuführen:
+ ** `eks` ** – Nur-Lese-Zugriff auf EKS-Dashboard-Daten, Ressourcen und Informationen zu Cluster-Versionen. Dies ermöglicht die Anzeige von EKS-bezogenen Metriken und Details zur Cluster-Konfiguration.
+ **`organizations`**- Schreibgeschützter Zugriff auf Unternehmensinformationen AWS , einschließlich:
+ Anzeigen von Organisationsdetails und Servicezugriff
+ Auflisten von Organisations-Roots, Konten und Organisationseinheiten
+ Anzeigen der Organisationsstruktur
Die neueste Version des JSON-Richtliniendokuments finden Sie [bei Amazon EKSDashboard ConsoleReadOnly](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSDashboardConsoleReadOnly.html#AmazonEKSDashboardConsoleReadOnly-json) im AWS Managed Policy Reference Guide.
## AWS verwaltete Richtlinie: Amazon EKSFargate PodExecutionRolePolicy
Sie können `AmazonEKSFargatePodExecutionRolePolicy` an Ihre IAM-Entitäten anhängen. Bevor Sie ein Fargate-Profil erstellen können, müssen Sie eine Fargate-Pod-Ausführungsrolle erstellen und diese Richtlinie an diese anfügen. Weitere Informationen erhalten Sie unter [Schritt 2: Fargate-Pod-Ausführungsrolle erstellen](fargate-getting-started.md#fargate-sg-pod-execution-role) und [Festlegung, welche Pods beim Start AWS Fargate verwenden](fargate-profile.md).
Diese Richtlinie gewährt der Rolle die Berechtigungen, die den Zugriff auf andere AWS Serviceressourcen ermöglichen, die für die Ausführung von Amazon EKS-Pods auf Fargate erforderlich sind.
**Details zu Berechtigungen**
Diese Richtlinie enthält die folgenden Berechtigungen, die es Amazon EKS ermöglichen, die folgenden Aufgaben auszuführen:
+ ** `ecr` ** – Ermöglicht Pods, die auf Fargate ausgeführt werden, Container-Images abzurufen, die in Amazon ECR gespeichert sind.
Die neueste Version des JSON-Richtliniendokuments finden Sie [bei Amazon EKSFargate PodExecutionRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSFargatePodExecutionRolePolicy.html#AmazonEKSFargatePodExecutionRolePolicy-json) im AWS Managed Policy Reference Guide.
## AWS verwaltete Richtlinie: Amazon EKSConnector ServiceRolePolicy
Sie können `AmazonEKSConnectorServiceRolePolicy` nicht an Ihre IAM-Entitäten anfügen. Diese Richtlinie ist mit einer servicegebundenen Rolle verknüpft, die es Amazon EKS ermöglicht, Aktionen in Ihrem Namen durchzuführen. Weitere Informationen finden Sie unter [Verbinden eines Kubernetes-Clusters mithilfe von Rollen mit Amazon EKS](using-service-linked-roles-eks-connector.md).
Diese Rolle ermöglicht es Amazon EKS, Kubernetes-Cluster zu verbinden. Die angefügten Richtlinien ermöglichen es der Rolle, die erforderlichen Ressourcen für die Verbindung mit Ihrem registrierten Kubernetes-Cluster zu verwalten.
**Details zu Berechtigungen**
Diese Richtlinie enthält die folgenden Berechtigungen, die es Amazon EKS ermöglichen, die folgenden Aufgaben auszuführen.
+ **`SSM Management`**— SSM-Aktivierungen erstellen, beschreiben und löschen und verwaltete Instances deregistrieren. Dies ermöglicht grundlegende Systems Manager Manager-Operationen.
+ **`Session Management`**— Starten Sie SSM-Sitzungen speziell für EKS-Cluster und führen Sie nicht interaktive Befehle mithilfe des AmazonEKS-Dokuments aus.
+ **`IAM Role Passing`**— Übergeben Sie IAM-Rollen speziell an den SSM-Dienst. Dies wird durch eine Bedingung gesteuert, die die übergebenen Rollen auf beschränkt. `ssm.amazonaws.com`
+ **`EventBridge Rules`**— Erstellen Sie EventBridge Regeln und Ziele, aber nur, wenn diese von verwaltet werden. `eks-connector.amazonaws.com` Regeln sind speziell auf AWS SSM als Ereignisquelle beschränkt.
Die neueste Version des JSON-Richtliniendokuments finden Sie [bei Amazon EKSConnector ServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSConnectorServiceRolePolicy.html) im AWS Managed Policy Reference Guide.
## AWS verwaltete Richtlinie: Amazon EKSFor FargateServiceRolePolicy
Sie können `AmazonEKSForFargateServiceRolePolicy` nicht an Ihre IAM-Entitäten anfügen. Diese Richtlinie ist mit einer servicegebundenen Rolle verknüpft, die es Amazon EKS ermöglicht, Aktionen in Ihrem Namen durchzuführen. Weitere Informationen finden Sie unter `AWSServiceRoleforAmazonEKSForFargate`.
Diese Richtlinie erteilt Amazon EKS die erforderlichen Berechtigungen zum Ausführen von Fargate-Aufgaben. Die Richtlinie wird nur verwendet, wenn Sie über Fargate-Knoten verfügen.
**Details zu Berechtigungen**
Diese Richtlinie enthält die folgenden Berechtigungen, die es Amazon EKS ermöglichen, die folgenden Aufgaben auszuführen.
+ ** `ec2` ** – Erstellen und löschen Sie Elastic Network Interfaces und beschreiben Sie Elastic Network Interfaces und Ressourcen. Dies ist erforderlich, damit der Amazon-EKS-Fargate-Service das für Fargate-Pods erforderliche VPC-Netzwerk konfigurieren kann.
Die neueste Version des JSON-Richtliniendokuments finden Sie [bei Amazon EKSFor FargateServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSForFargateServiceRolePolicy.html#AmazonEKSForFargateServiceRolePolicy-json) im AWS Managed Policy Reference Guide.
## AWS verwaltete Richtlinie: EKSCompute Amazon-Richtlinie
Sie können `AmazonEKSComputePolicy` an Ihre IAM-Entitäten anhängen. Sie können diese Richtlinie an Ihre [Cluster-IAM-Rolle](cluster-iam-role.md) anfügen, um die Ressourcen zu erweitern, die EKS in Ihrem Konto verwalten kann.
Diese Richtlinie gewährt die erforderlichen Berechtigungen für Amazon EKS zum Erstellen und Verwalten von EC2-Instances für den EKS-Cluster sowie die erforderlichen IAM-Berechtigungen zum Konfigurieren von EC2. Außerdem gewährt diese Richtlinie Amazon EKS die Berechtigung, die serviceverknüpfte EC2-Spot-Rolle in Ihrem Namen zu erstellen.
### Details zu Berechtigungen
Diese Richtlinie enthält die folgenden Berechtigungen, die es Amazon EKS ermöglichen, die folgenden Aufgaben auszuführen:
+ ** `ec2`-Berechtigungen**:
+ `ec2:CreateFleet` und `ec2:RunInstances` – Ermöglicht das Erstellen von EC2-Instances und die Verwendung spezifischer EC2-Ressourcen (Images, Sicherheitsgruppen, Subnetze) für EKS-Cluster-Knoten.
+ `ec2:CreateLaunchTemplate` – Ermöglicht das Erstellen von EC2-Startvorlagen für EKS-Cluster-Knoten.
+ Die Richtlinie enthält auch Bedingungen, um die Verwendung dieser EC2-Berechtigungen auf Ressourcen zu beschränken, die mit dem EKS-Cluster-Namen und anderen relevanten Tags gekennzeichnet sind.
+ `ec2:CreateTags` – Ermöglicht das Hinzufügen von Tags zu EC2-Ressourcen, die mit den Aktionen `CreateFleet`, `RunInstances`, und `CreateLaunchTemplate` erstellt wurden.
+ ** `iam`-Berechtigungen**:
+ `iam:AddRoleToInstanceProfile` – Ermöglicht das Hinzufügen einer IAM-Rolle zum EKS-Rechen-Instance-Profil.
+ `iam:PassRole` – Ermöglicht die Übergabe der erforderlichen IAM-Rollen an den EC2-Service.
Die neueste Version des JSON-Richtliniendokuments finden Sie unter [Amazon EKSCompute Policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSComputePolicy.html#AmazonEKSComputePolicy-json) im AWS Managed Policy Reference Guide.
## AWS verwaltete Richtlinie: EKSNetworking Amazon-Richtlinie
Sie können `AmazonEKSNetworkingPolicy` an Ihre IAM-Entitäten anhängen. Sie können diese Richtlinie an Ihre [Cluster-IAM-Rolle](cluster-iam-role.md) anfügen, um die Ressourcen zu erweitern, die EKS in Ihrem Konto verwalten kann.
Diese Richtlinie dient dazu, Amazon EKS die erforderlichen Berechtigungen zum Erstellen und Verwalten von Netzwerkschnittstellen für den EKS-Cluster zu gewähren, sodass die Steuerebene und die Worker-Knoten ordnungsgemäß kommunizieren und funktionieren können.
### Details zu Berechtigungen
Diese Richtlinie gewährt die folgenden Berechtigungen, damit Amazon EKS Netzwerkschnittstellen für den Cluster verwalten kann:
+ ** `ec2`-Netzwerkschnittstellen-Berechtigungen**:
+ `ec2:CreateNetworkInterface` – Ermöglicht das Erstellen von EC2-Netzwerkschnittstellen.
+ Die Richtlinie enthält Bedingungen, um die Verwendung dieser Berechtigung auf Netzwerkschnittstellen zu beschränken, die mit dem EKS-Cluster-Namen und dem Kubernetes CNI-Knotennamen gekennzeichnet sind.
+ `ec2:CreateTags` – Ermöglicht das Hinzufügen von Tags zu den durch die `CreateNetworkInterface`-Aktion erstellten Netzwerkschnittstellen.
+ ** Berechtigungen zur `ec2`-Netzwerkschnittstellenverwaltung:**:
+ `ec2:AttachNetworkInterface`,`ec2:ModifyNetworkInterfaceAttribute`, `ec2:DetachNetworkInterface` - Ermöglicht das Anhängen, Ändern von Netzwerkschnittstellenattributen und das Trennen von Netzwerkschnittstellen an EC2-Instances.
+ `ec2:UnassignPrivateIpAddresses`, `ec2:UnassignIpv6Addresses`, `ec2:AssignPrivateIpAddresses`, `ec2:AssignIpv6Addresses` – Ermöglicht die Verwaltung der IP-Adresszuweisungen der Netzwerkschnittstellen.
+ Diese Berechtigungen sind auf Netzwerkschnittstellen beschränkt, die mit dem EKS-Cluster-Namen gekennzeichnet sind.
Die neueste Version des JSON-Richtliniendokuments finden Sie unter [Amazon EKSNetworking Policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSNetworkingPolicy.html#AmazonEKSNetworkingPolicy-json) im AWS Managed Policy Reference Guide.
## AWS verwaltete Richtlinie: Amazon EKSBlock StoragePolicy
Sie können `AmazonEKSBlockStoragePolicy` an Ihre IAM-Entitäten anhängen. Sie können diese Richtlinie an Ihre [Cluster-IAM-Rolle](cluster-iam-role.md) anfügen, um die Ressourcen zu erweitern, die EKS in Ihrem Konto verwalten kann.
Diese Richtlinie gewährt Amazon EKS die erforderlichen Berechtigungen zum Erstellen, Verwalten und Verwalten von EC2-Volumes und Snapshots für den EKS-Cluster. Auf diese Weise können die Steuerebene und die Worker-Knoten persistenten Speicher bereitstellen und verwenden, wie es für Kubernetes-Workloads erforderlich ist.
### Details zu Berechtigungen
Diese IAM-Richtlinie gewährt die folgenden Berechtigungen, damit Amazon EKS EC2-Volumes und Snapshots verwalten kann:
+ ** Berechtigung für die Verwaltung von `ec2`-Volumes**:
+ `ec2:AttachVolume`, `ec2:DetachVolume`, `ec2:ModifyVolume`, `ec2:EnableFastSnapshotRestores` – Ermöglicht das Anfügen, Entfernen, Ändern und Aktivieren einer schnellen Snapshot-Wiederherstellung für EC2-Volumes.
+ Diese Berechtigungen sind auf Volumes beschränkt, die mit dem EKS-Cluster-Namen gekennzeichnet sind.
+ `ec2:CreateTags` – Ermöglicht das Hinzufügen von Tags zu den EC2-Volumes und Snapshots, die durch die Aktionen `CreateVolume` und `CreateSnapshot` erstellt wurden.
+ ** Berechtigungen zur Erstellung von `ec2`-Volumes**:
+ `ec2:CreateVolume` – Ermöglicht die Erstellung neuer EC2-Volumes.
+ Die Richtlinie enthält Bedingungen, welche die Verwendung dieser Berechtigung auf Volumes beschränken, die mit dem EKS-Cluster-Namen und anderen relevanten Tags gekennzeichnet sind.
+ `ec2:CreateSnapshot` – Ermöglicht die Erstellung neuer EC2-Volume-Snapshots.
+ Die Richtlinie enthält Bedingungen, welche die Verwendung dieser Berechtigung auf Snapshots beschränken, die mit dem EKS-Cluster-Namen und anderen relevanten Tags gekennzeichnet sind.
Die neueste Version des JSON-Richtliniendokuments finden Sie [bei Amazon EKSBlock StoragePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSBlockStoragePolicy.html#AmazonEKSBlockStoragePolicy-json) im AWS Managed Policy Reference Guide.
## AWS verwaltete Richtlinie: Amazon EKSLoad BalancingPolicy
Sie können `AmazonEKSLoadBalancingPolicy` an Ihre IAM-Entitäten anhängen. Sie können diese Richtlinie an Ihre [Cluster-IAM-Rolle](cluster-iam-role.md) anfügen, um die Ressourcen zu erweitern, die EKS in Ihrem Konto verwalten kann.
Diese IAM-Richtlinie gewährt Amazon EKS die erforderlichen Berechtigungen für die Zusammenarbeit mit verschiedenen AWS Services zur Verwaltung von Elastic Load Balancers (ELBs) und verwandten Ressourcen.
### Details zu Berechtigungen
Die wichtigsten durch diese Richtlinie gewährten Berechtigungen sind:
+ ** `elasticloadbalancing` **: Ermöglicht das Erstellen, Ändern und Verwalten von Elastic Load Balancern und Zielgruppen. Dies umfasst Berechtigungen zum Erstellen, Aktualisieren und Löschen von Load Balancern, Zielgruppen, Listenern und Regeln.
+ ** `ec2` **: Ermöglicht das Erstellen und Verwalten von Sicherheitsgruppen, die für die Kubernetes-Steuerebene erforderlich sind, um Instances einem Cluster hinzuzufügen und Amazon-EBS-Volumes zu verwalten. Ermöglicht auch die Beschreibung und Auflistung von EC2-Ressourcen wie Instances, Subnetzen VPCs, Sicherheitsgruppen und anderen Netzwerkressourcen.
+ **`iam`**: Ermöglicht die Erstellung einer serviceverknüpften Rolle für Elastic Load Balancing, die für die dynamische Bereitstellung durch die Kubernetes-Steuerebene erforderlich ist. ELBs
+ **`kms`**: Ermöglicht das Lesen eines Schlüssels aus AWS KMS, der erforderlich ist, damit die Kubernetes-Steuerebene die Verschlüsselung von in etcd gespeicherten Kubernetes-Geheimnissen unterstützt.
+ **`wafv2`**und **`shield`**: Ermöglicht das Zuordnen und Trennen von ACLs Webanwendungen und das Erstellen/Löschen von AWS Shield-Schutzmaßnahmen für die Elastic Load Balancer.
+ ** `cognito-idp` **, ** `acm` ** und ** `elasticloadbalancing` **: Gewährt Berechtigungen zum Beschreiben von Benutzerpool-Clients, zum Auflisten und Beschreiben von Zertifikaten sowie zum Beschreiben von Zielgruppen, die für die Kubernetes-Steuerebene zur Verwaltung der Elastic Load Balancers erforderlich sind.
Die Richtlinie umfasst auch mehrere Bedingungsprüfungen, um sicherzustellen, dass die Berechtigungen mithilfe des Tags `eks:eks-cluster-name` auf den spezifischen verwalteten EKS-Cluster beschränkt sind.
Die neueste Version des JSON-Richtliniendokuments finden Sie [bei Amazon EKSLoad BalancingPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSLoadBalancingPolicy.html#AmazonEKSLoadBalancingPolicy-json) im AWS Managed Policy Reference Guide.
## AWS verwaltete Richtlinie: Amazon EKSMCPRead OnlyAccess
Sie können `AmazonEKSMCPReadOnlyAccess` an Ihre IAM-Entitäten anhängen. Diese Richtlinie bietet Lesezugriff auf Amazon EKS-Ressourcen und zugehörige AWS Services, sodass der Amazon EKS Model Context Protocol (MCP) -Server Beobachtbarkeits- und Fehlerbehebungsvorgänge durchführen kann, ohne Änderungen an Ihrer Infrastruktur vornehmen zu müssen.
**Details zu Berechtigungen**
Diese Richtlinie umfasst die folgenden Berechtigungen, mit denen Principals die folgenden Aufgaben ausführen können:
+ **`eks`**Ermöglicht Prinzipalen, EKS-Cluster, Knotengruppen, Add-Ons, Zugriffseinträge und Einblicke zu beschreiben und aufzulisten und auf die Kubernetes-API für schreibgeschützte Operationen zuzugreifen.
+ **`iam`**Ermöglicht Prinzipalen das Abrufen von Informationen über IAM-Rollen, -Richtlinien und deren Anlagen, um die mit EKS-Ressourcen verknüpften Berechtigungen zu verstehen.
+ **`ec2`**Ermöglicht es Prinzipalen VPCs, Subnetze und Routing-Tabellen zu beschreiben, um die Netzwerkkonfiguration von EKS-Clustern zu verstehen.
+ **`sts`**Ermöglicht Prinzipalen das Abrufen von Anruferidentitätsinformationen zu Authentifizierungs- und Autorisierungszwecken.
+ **`logs`**Ermöglicht es den Prinzipalen, Abfragen zu starten und Abfrageergebnisse zur Problembehandlung und Überwachung aus CloudWatch Protokollen abzurufen.
+ **`cloudwatch`**Ermöglicht Prinzipalen das Abrufen von Metrikdaten zur Überwachung der Cluster- und Workload-Leistung.
+ **`eks-mcp`**Ermöglicht Principals, MCP-Operationen aufzurufen und schreibgeschützte Tools innerhalb des Amazon EKS MCP-Servers aufzurufen.
Die neueste Version des JSON-Richtliniendokuments finden Sie [bei Amazon EKSMCPRead OnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSMCPReadOnlyAccess.html) im AWS Managed Policy Reference Guide.
## AWS verwaltete Richtlinie: EKSService Amazon-Richtlinie
Sie können `AmazonEKSServicePolicy` an Ihre IAM-Entitäten anhängen. Für Cluster, die vor dem 16. April 2020 erstellt wurden, mussten Sie eine IAM-Rolle erstellen und diese Richtlinie anhängen. Cluster, die am oder nach dem 16. April 2020 erstellt wurden, erfordern weder die Erstellung einer Rolle noch die Zuweisung dieser Richtlinie. Wenn Sie einen Cluster mithilfe eines IAM-Prinzipals erstellen, der über die `iam:CreateServiceLinkedRole` entsprechende Berechtigung verfügt, wird die mit dem Dienst verknüpfte [AWSServiceRoleforAmazonEKS-Rolle](using-service-linked-roles-eks.md#service-linked-role-permissions-eks) automatisch für Sie erstellt. Der serviceverknüpften Rolle ist die [verwaltete Richtlinie: Amazon EKSService RolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy) zugeordnet.
Diese Richtlinie ermöglicht Amazon EKS, die erforderlichen Ressourcen für den Betrieb von Amazon-EKS-Clustern zu erstellen und zu verwalten.
**Details zu Berechtigungen**
Diese Richtlinie enthält die folgenden Berechtigungen, die es Amazon EKS ermöglichen, die folgenden Aufgaben auszuführen.
+ ** `eks` ** – Aktualisieren Sie die Kubernetes-Version Ihres Clusters, nachdem Sie ein Update initiiert haben. Diese Berechtigung wird von Amazon EKS nicht verwendet, verbleibt jedoch aus Gründen der Abwärtskompatibilität in der Richtlinie.
+ ** `ec2` ** – Arbeiten Sie mit Elastic Network Interfaces und anderen Netzwerkressourcen und Tags. Dies wird von Amazon EKS benötigt, um ein Netzwerk zu konfigurieren, das die Kommunikation zwischen Knoten und der Kubernetes-Steuerebene erleichtert. Lesen Sie die Informationen zu Sicherheitsgruppen. Aktualisieren Sie Tags für Sicherheitsgruppen.
+ ** `route53` ** – Verknüpfen Sie eine VPC mit einer gehosteten Zone. Dies wird von Amazon EKS benötigt, um ein privates Endpunktnetzwerk für Ihren Kubernetes-Cluster-API-Server zu aktivieren.
+ ** `logs` ** – Protokollereignisse Dies ist erforderlich, damit Amazon EKS die Protokolle der Kubernetes-Steuerebene an senden kann. CloudWatch
+ ** `iam` ** – Erstellen Sie eine serviceverknüpfte Rolle. Dies ist erforderlich, damit Amazon EKS die serviceverknüpfte [Serviceverknüpfte Rollenberechtigungen für Amazon EKS](using-service-linked-roles-eks.md#service-linked-role-permissions-eks)-Rolle in Ihrem Namen erstellt.
Die neueste Version des JSON-Richtliniendokuments finden Sie unter [Amazon EKSService Policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServicePolicy.html#AmazonEKSServicePolicy-json) im AWS Managed Policy Reference Guide.
## AWS verwaltete Richtlinie: Amazon EKSService RolePolicy
Sie können `AmazonEKSServiceRolePolicy` nicht an Ihre IAM-Entitäten anfügen. Diese Richtlinie ist mit einer servicegebundenen Rolle verknüpft, die es Amazon EKS ermöglicht, Aktionen in Ihrem Namen durchzuführen. Weitere Informationen finden Sie unter [Serviceverknüpfte Rollenberechtigungen für Amazon EKS](using-service-linked-roles-eks.md#service-linked-role-permissions-eks). Wenn Sie einen Cluster mithilfe eines IAM-Prinzipals erstellen, der über die `iam:CreateServiceLinkedRole` entsprechende Berechtigung verfügt, wird die mit dem Dienst verknüpfte [AWSServiceRoleforAmazonEKS-Rolle](using-service-linked-roles-eks.md#service-linked-role-permissions-eks) automatisch für Sie erstellt, und diese Richtlinie wird ihr angehängt.
Diese Richtlinie ermöglicht es der serviceverknüpften Rolle, AWS Dienste in Ihrem Namen aufzurufen.
**Details zu Berechtigungen**
Diese Richtlinie enthält die folgenden Berechtigungen, die es Amazon EKS ermöglichen, die folgenden Aufgaben auszuführen.
+ ** `ec2` ** – Erstellen und Beschreiben Sie Elastic Network Interfaces und Amazon-EC2-Instances, der Cluster-Sicherheitsgruppe und der VPC, die für die Cluster-Erstellung erforderlich sind. Weitere Informationen finden Sie unter [Anforderungen der Amazon-EKS-Sicherheitsgruppe für Cluster anzeigen](sec-group-reqs.md). Lesen Sie die Informationen zu Sicherheitsgruppen. Aktualisieren Sie Tags für Sicherheitsgruppen. Weitere Informationen zu On-Demand-Kapazitätsreservierungen. Lesen Sie die VPC-Konfiguration einschließlich Routentabellen und Netzwerk ACLs , um Konfigurationsprobleme im Rahmen von Cluster-Insights zu erkennen.
+ ** `ec2` Auto Mode** – Beenden Sie vom EKS Auto Mode erstellte EC2-Instances. Weitere Informationen finden Sie unter [Automatisieren der Cluster-Infrastruktur mit dem EKS-Automatikmodus](automode.md).
+ ** `iam` ** – Listen Sie alle verwalteten Richtlinien auf, die einer IAM-Rolle zugeordnet sind. Dies ist erforderlich, damit Amazon EKS alle verwalteten Richtlinien und Berechtigungen auflisten und validieren kann, die zum Erstellen von Clustern erforderlich sind.
+ **Eine VPC mit einer gehosteten Zone verknüpfen** – Dies wird von Amazon EKS benötigt, um ein privates Endpunktnetzwerk für Ihren Kubernetes-Cluster-API-Server zu aktivieren.
+ **Ereignis protokollieren** — Dies ist erforderlich, damit Amazon EKS die Protokolle der Kubernetes-Steuerebene an senden kann. CloudWatch
+ **Metrik angeben** — Dies ist erforderlich, damit Amazon EKS die Protokolle der Kubernetes-Steuerebene an senden kann. CloudWatch
+ ** `eks` ** – Verwalten Sie Cluster-Zugriffseinträge und -Richtlinien, um detailliert zu steuern, wer auf EKS-Ressourcen zugreifen und welche Aktionen ausführen darf. Dazu gehört auch die Zuordnung von Standardzugriffsrichtlinien für Rechen-, Netzwerk-, Load Balancing- und Speichervorgänge.
+ ** `elasticloadbalancing` ** – Erstellen, verwalten und löschen Sie Load Balancer und deren Komponenten (Listener, Zielgruppen, Zertifikate), die EKS-Clustern zugeordnet sind. Zeigen Sie die Attribute und den Integritätsstatus des Load Balancers an.
+ **`events`**- Erstellen und verwalten Sie EventBridge Regeln für die Überwachung von EC2- und AWS Health-Ereignissen im Zusammenhang mit EKS-Clustern und ermöglichen Sie so automatisierte Reaktionen auf Infrastrukturänderungen und Integritätswarnungen.
+ ** `iam` ** – Verwalten Sie EC2-Instance-Profile mit dem Präfix „eks“, einschließlich Erstellung, Löschung und Rollenzuordnung, die für die EKS-Knotenverwaltung erforderlich ist. Ermöglicht die Beschreibung eines beliebigen Instanzprofils, sodass Benutzer benutzerdefinierte Instanzprofile für ihre Worker-Knoten definieren können.
+ **`pricing`**`shield`****- Greifen Sie auf AWS Preisinformationen und den Shield-Schutzstatus zu, was Kostenmanagement und erweiterte Sicherheitsfunktionen für EKS-Ressourcen ermöglicht.
+ **Ressourcen-Bereinigung** – Löschen Sie während Cluster-Bereinigungsvorgängen sicher EKS-gekennzeichnete Ressourcen, einschließlich Volumes, Snapshots, Startvorlagen und Netzwerkschnittstellen.
Die neueste Version des JSON-Richtliniendokuments finden Sie [bei Amazon EKSService RolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServiceRolePolicy.html#AmazonEKSServiceRolePolicy-json) im AWS Managed Policy Reference Guide.
## AWS verwaltete Richtlinie: Amazon EKSVPCResource Controller
Sie können die `AmazonEKSVPCResourceController`-Richtlinie an Ihre IAM-Identitäten anfügen. Wenn Sie [Sicherheitsgruppen für Pods](security-groups-for-pods.md) verwenden, müssen Sie diese Richtlinie an Ihre [Amazon-EKS-Cluster-IAM-Rolle](cluster-iam-role.md) anfügen, um Aktionen in Ihrem Namen auszuführen.
Diese Richtlinie gewährt der Clusterrolle Berechtigungen zum Verwalten von Elastic Network Interfaces und IP-Adressen für Knoten.
**Details zu Berechtigungen**
Diese Richtlinie enthält die folgenden Berechtigungen, die es Amazon EKS ermöglichen, die folgenden Aufgaben auszuführen:
+ ** `ec2` ** – Verwalten Sie Elastic Network Interfaces und IP-Adressen, um Pod-Sicherheitsgruppen und Windows-Knoten zu unterstützen.
Die neueste Version des JSON-Richtliniendokuments finden Sie unter [Amazon EKSVPCResource Controller](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSVPCResourceController.html#AmazonEKSVPCResourceController-json) im AWS Managed Policy Reference Guide.
## AWS verwaltete Richtlinie: Amazon EKSWorker NodePolicy
Sie können die `AmazonEKSWorkerNodePolicy` an Ihre IAM-Entitäten anhängen. Sie müssen diese Richtlinie an eine [Knoten-IAM-Rolle](create-node-role.md) anhängen, die Sie angeben, wenn Sie Amazon EC2-Knoten erstellen, die es Amazon EKS ermöglichen, Aktionen in Ihrem Namen auszuführen. Wenn Sie eine Knotengruppe mit `eksctl` erstellen, wird die Knoten-IAM-Rolle erstellt und diese Richtlinie automatisch an die Rolle angehängt.
Diese Richtlinie gewährt Amazon EKS Amazon EC2-Knoten Berechtigungen zum Herstellen einer Verbindung mit Amazon-EKS-Clustern.
**Details zu Berechtigungen**
Diese Richtlinie enthält die folgenden Berechtigungen, die es Amazon EKS ermöglichen, die folgenden Aufgaben auszuführen:
+ ** `ec2` ** – Lesen Sie Informationen zum Instance-Volumen und zum Netzwerk. Dies ist erforderlich, damit Kubernetes-Knoten Informationen zu Amazon-EC2-Ressourcen beschreiben können, die für den Knoten erforderlich sind, um dem Amazon-EKS-Cluster beizutreten.
+ ** `eks` ** – Beschreiben Sie optional den Cluster als Teil des Knoten-Bootstrappings.
+ ** `eks-auth:AssumeRoleForPodIdentity` ** – Erlauben Sie das Abrufen von Anmeldeinformationen für EKS-Workloads auf dem Knoten. Dies ist erforderlich, damit EKS Pod Identity ordnungsgemäß funktioniert.
Die neueste Version des JSON-Richtliniendokuments finden Sie [bei Amazon EKSWorker NodePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSWorkerNodePolicy.html#AmazonEKSWorkerNodePolicy-json) im AWS Managed Policy Reference Guide.
## AWS verwaltete Richtlinie: Amazon EKSWorker NodeMinimalPolicy
Sie können die AmazonEKS WorkerNodeMinimalPolicy an Ihre IAM-Entitäten anhängen. Sie können diese Richtlinie an eine Knoten-IAM-Rolle anfügen, die Sie angeben, wenn Sie Amazon EC2-Knoten erstellen, die es Amazon EKS ermöglichen, Aktionen in Ihrem Namen auszuführen.
Diese Richtlinie gewährt Amazon EKS Amazon EC2-Knoten Berechtigungen zum Herstellen einer Verbindung mit Amazon-EKS-Clustern. Diese Richtlinie hat im Vergleich zu Amazon weniger Berechtigungen EKSWorkerNodePolicy.
**Details zu Berechtigungen**
Diese Richtlinie enthält die folgenden Berechtigungen, die es Amazon EKS ermöglichen, die folgenden Aufgaben auszuführen:
+ `eks-auth:AssumeRoleForPodIdentity` – Erlauben Sie das Abrufen von Anmeldeinformationen für EKS-Workloads auf dem Knoten. Dies ist erforderlich, damit EKS Pod Identity ordnungsgemäß funktioniert.
Die neueste Version des JSON-Richtliniendokuments finden Sie [bei Amazon EKSWorker NodePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSWorkerNodeMinimalPolicy.html#AmazonEKSWorkerNodeMinimalPolicy-json) im AWS Managed Policy Reference Guide.
## AWS verwaltete Richtlinie: AWSService RoleForAmazon EKSNodegroup
Sie können `AWSServiceRoleForAmazonEKSNodegroup` nicht an Ihre IAM-Entitäten anfügen. Diese Richtlinie ist mit einer servicegebundenen Rolle verknüpft, die es Amazon EKS ermöglicht, Aktionen in Ihrem Namen durchzuführen. Weitere Informationen finden Sie unter [Serviceverknüpfte Rollenberechtigungen für Amazon EKS](using-service-linked-roles-eks-nodegroups.md#service-linked-role-permissions-eks-nodegroups).
Diese Richtlinie gewährt der `AWSServiceRoleForAmazonEKSNodegroup`-Rolle Berechtigungen, die es ihr ermöglichen, Amazon EC2-Knotengruppen in Ihrem Konto zu erstellen und zu verwalten.
**Details zu Berechtigungen**
Diese Richtlinie enthält die folgenden Berechtigungen, die es Amazon EKS ermöglichen, die folgenden Aufgaben auszuführen:
+ ** `ec2` ** – Arbeiten Sie mit Sicherheitsgruppen, Tags, Kapazitätsreservierungen und Startvorlagen. Dies ist für von Amazon EKS verwaltete Knotengruppen erforderlich, um die Zugriffskonfiguration auf Distanz zu ermöglichen und Kapazitätsreservierungen zu beschreiben, die in verwalteten Knotengruppen verwendet werden können. Darüber hinaus erstellen von Amazon EKS verwaltete Knotengruppen in Ihrem Namen eine Startvorlage. Dies dient zum Konfigurieren der Amazon EC2 Auto Scaling-Gruppe, die jede verwaltete Knotengruppe unterstützt.
+ ** `iam` ** – Erstellen einer serviceverknüpften Rolle und Übergeben einer Rolle. Dies ist für von Amazon EKS verwaltete Knotengruppen erforderlich, um Instance-Profile für die Rolle zu verwalten, die beim Erstellen einer verwalteten Knotengruppe übergeben wird. Dieses Instance-Profil wird von Amazon-EC2-Instances verwendet, die als Teil einer verwalteten Knotengruppe gestartet werden. Amazon EKS muss serviceverknüpfte Rollen für andere Services wie Amazon EC2 Auto Scaling-Gruppen erstellen. Diese Berechtigungen werden bei der Erstellung einer verwalteten Knotengruppe verwendet.
+ ** `autoscaling` ** – Arbeiten Sie mit Sicherheitsgruppen für Auto Scaling. Dies ist für von Amazon EKS verwaltete Knotengruppen erforderlich, um die Amazon EC2 Auto Scaling-Gruppe zu verwalten, die jede verwaltete Knotengruppe unterstützt. Es wird auch verwendet, um Funktionen wie das Entfernen von Pods zu unterstützen, wenn Knoten während Knotengruppen-Updates beendet oder recycelt werden, und die Verwaltung von Warm-Pools, die auf verwalteten Knotengruppen konfiguriert sind.
Die neueste Version des JSON-Richtliniendokuments finden Sie [AWSServiceRoleForAmazonEKSNodegroup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSServiceRoleForAmazonEKSNodegroup.html#AWSServiceRoleForAmazonEKSNodegroup-json)im Referenzhandbuch für AWS verwaltete Richtlinien.
## AWS verwaltete Richtlinie: Amazon EKSDashboard ServiceRolePolicy
Sie können `AmazonEKSDashboardServiceRolePolicy` nicht an Ihre IAM-Entitäten anfügen. Diese Richtlinie ist mit einer servicegebundenen Rolle verknüpft, die es Amazon EKS ermöglicht, Aktionen in Ihrem Namen durchzuführen. Weitere Informationen finden Sie unter [Serviceverknüpfte Rollenberechtigungen für Amazon EKS](using-service-linked-roles-eks-dashboard.md#service-linked-role-permissions-eks-dashboard).
Diese Richtlinie gewährt der `AWSServiceRoleForAmazonEKSDashboard`-Rolle Berechtigungen, die es ihr ermöglichen, Amazon EC2-Knotengruppen in Ihrem Konto zu erstellen und zu verwalten.
**Details zu Berechtigungen**
Diese Richtlinie enthält die folgenden Berechtigungen, die den Zugriff zur Ausführung dieser Aufgaben ermöglichen:
+ **`organizations`**— Informationen zur Struktur und zu den Konten Ihrer AWS Organizations anzeigen. Dies enthält Berechtigungen zum Auflisten von Konten in Ihrer Organisation, zum Anzeigen von Organisationseinheiten und Stammverzeichnissen, zum Auflisten von delegierten Administratoren, zum Anzeigen von Services, die Zugriff auf Ihre Organisation haben, sowie zum Abrufen detaillierter Informationen über Ihre Organisation und Konten.
Die neueste Version des JSON-Richtliniendokuments finden Sie [bei Amazon EKSDashboard ServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSDashboardServiceRolePolicy.html#AmazonEKSDashboardServiceRolePolicy-json) im AWS Managed Policy Reference Guide.
## AWS verwaltete Richtlinie: EBSCSIDriver Amazon-Richtlinie
Die `AmazonEBSCSIDriverPolicy` Richtlinie ermöglicht es dem Amazon EBS Container Storage Interface (CSI) -Treiber, Volumes in Ihrem Namen zu erstellen, zu ändern, zu kopieren, anzuhängen, zu trennen und zu löschen. Dazu gehören auch das Ändern von Tags in vorhandenen Volumes und das Aktivieren von Fast Snapshot Restore (FSR) in EBS-Volumes. Sie gewährt dem EBS CSI-Treiber auch die Berechtigung, Snapshots zu erstellen, zu sperren, wiederherzustellen und zu löschen und Ihre Instances, Volumes und Snapshots aufzulisten.
Die neueste Version des JSON-Richtliniendokuments finden Sie [bei Amazon EBSCSIDriver ServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEBSCSIDriverPolicy.html#AmazonEBSCSIDriverPolicy-json) im AWS Managed Policy Reference Guide.
## AWS verwaltete Richtlinie: EFSCSIDriver Amazon-Richtlinie
Die `AmazonEFSCSIDriverPolicy`-Richtlinie ermöglicht es dem Amazon EFS Container Storage Interface (CSI), Zugriffspunkte in Ihrem Namen zu erstellen und zu löschen. Es gewährt dem Amazon-EFS-CSI-Treiber außerdem Berechtigungen zum Auflisten Ihrer Zugriffspunkte, Dateisysteme, Mount-Ziele und Amazon-EC2-Verfügbarkeitszonen.
Die neueste Version des JSON-Richtliniendokuments finden Sie [bei Amazon EFSCSIDriver ServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEFSCSIDriverPolicy.html#AmazonEFSCSIDriverPolicy-json) im AWS Managed Policy Reference Guide.
## AWS verwaltete Richtlinie: Amazon EKSLocal OutpostClusterPolicy
Sie können diese Richtlinie mit IAM-Entitäten verknüpfen. Bevor Sie einen lokalen Cluster erstellen, müssen Sie diese Richtlinie Ihrer [Cluster-Rolle](cluster-iam-role.md) anfügen. Kubernetes-Cluster, die von Amazon EKS verwaltet werden, rufen in Ihrem Namen andere AWS Services auf. Sie tun dies, um die Ressourcen zu verwalten, die Sie mit dem Service verwenden.
Die `AmazonEKSLocalOutpostClusterPolicy` umfasst folgende Berechtigungen.
+ ** `ec2`-Leseaktionen** – Ermöglicht es Steuerebenen-Instances, Eigenschaften von Availability Zones, Routing-Tabellen, Instances und Netzwerkschnittstellen zu beschreiben. Erforderliche Berechtigungen für Amazon-EC2-Instances, um dem Cluster erfolgreich als Steuerebene-Instances beizutreten.
+ ** `ssm` ** – Ermöglicht Amazon EC2 Systems Manager eine Verbindung mit der Instance auf Steuerebene, die von Amazon EKS für die Kommunikation und Verwaltung des lokalen Clusters in Ihrem Konto verwendet wird.
+ **`logs`**— Ermöglicht Instances, Logs an Amazon zu übertragen CloudWatch.
+ **`secretsmanager`**— Ermöglicht Instances das sichere Abrufen und Löschen von Bootstrap-Daten für die Kontrollebeneninstanzen aus AWS Secrets Manager.
+ ** `ecr` ** – Ermöglicht Pods und Containern, die auf Instances auf der Steuerebene ausgeführt werden, das Abrufen von Container-Images, die in Amazon Elastic Container Registry gespeichert sind.
Die neueste Version des JSON-Richtliniendokuments finden Sie [bei Amazon EKSLocal OutpostClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSLocalOutpostClusterPolicy.html#AmazonEKSLocalOutpostClusterPolicy-json) im AWS Managed Policy Reference Guide.
## AWS verwaltete Richtlinie: Amazon EKSLocal OutpostServiceRolePolicy
Sie können diese Richtlinie Ihren IAM-Entitäten nicht anfügen. Wenn Sie einen Cluster mit einem IAM-Prinzipal erstellen, der über die `iam:CreateServiceLinkedRole` entsprechende Berechtigung verfügt, erstellt Amazon EKS automatisch die serviceverknüpfte [AWSServiceRoleforAmazonEKSLocalOutpost-Rolle](using-service-linked-roles-eks-outpost.md) für Sie und fügt ihr diese Richtlinie hinzu. Diese Richtlinie ermöglicht es der serviceverknüpften Rolle, in Ihrem Namen AWS Dienste für lokale Cluster aufzurufen.
Die `AmazonEKSLocalOutpostServiceRolePolicy` umfasst folgende Berechtigungen.
+ ** `ec2` ** – Ermöglicht Amazon EKS die Zusammenarbeit mit Sicherheits-, Netzwerk- und anderen Ressourcen, um Instances der Steuerebene in Ihrem Konto erfolgreich zu starten und zu verwalten.
+ ** `ssm`, `ssmmessages` ** – Ermöglicht Amazon EC2 Systems Manager eine Verbindung mit der Instances auf Steuerebene, die von Amazon EKS für die Kommunikation und Verwaltung des lokalen Clusters in Ihrem Konto verwendet wird.
+ ** `iam` ** – Ermöglicht Amazon EKS die Verwaltung des Instance-Profils, das den Instances auf Steuerebene zugeordnet ist.
+ **`secretsmanager`**- Ermöglicht Amazon EKS, Bootstrap-Daten für die Instances der Kontrollebene in AWS Secrets Manager zu übertragen, sodass sie beim Instance-Bootstrapping sicher referenziert werden können.
+ ** `outposts` ** – Ermöglicht Amazon EKS, Outpost-Informationen von Ihrem Konto abzurufen, um einen lokalen Cluster in einem Outpost erfolgreich zu starten.
Die neueste Version des JSON-Richtliniendokuments finden Sie [bei Amazon EKSLocal OutpostServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSLocalOutpostServiceRolePolicy.html#AmazonEKSLocalOutpostServiceRolePolicy-json) im AWS Managed Policy Reference Guide.
## Amazon EKS-Updates für AWS verwaltete Richtlinien
Sehen Sie sich Details zu Aktualisierungen der AWS verwalteten Richtlinien für Amazon EKS an, seit dieser Service begonnen hat, diese Änderungen zu verfolgen.
Um Benachrichtigungen über alle Änderungen an den Quelldateien dieser spezifischen Dokumentationsseite zu erhalten, können Sie die folgende URL mit einem RSS-Reader abonnieren:
```
https://github.com/awsdocs/amazon-eks-user-guide/commits/mainline/latest/ug/security/iam-reference/security-iam-awsmanpol.adoc.atom
```
| Änderungen | Beschreibung | Date |
| --- | --- | --- |
| Berechtigung zu [AWS verwaltete Richtlinie: EKSNetworking Amazon-Richtlinie](#security-iam-awsmanpol-AmazonEKSNetworkingPolicy) hinzugefügt. | Die `ec2:ModifyNetworkInterfaceAttribute` Erlaubnis wurde hinzugefügt in`AmazonEKSNetworkingPolicy`. Dadurch kann Amazon EKS Auto Mode Controller Netzwerkschnittstellenattribute für EC2-Instances ändern. | 3. Februar 2026 |
| Berechtigungen zu [AWS verwaltete Richtlinie: AWSService RoleForAmazon EKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup) hinzugefügt. | Hinzugefügt`autoscaling:PutWarmPool`,`autoscaling:DeleteWarmPool`, und `autoscaling:DescribeWarmPool` Berechtigungen für. `AWSServiceRoleForAmazonEKSNodegroup` Auf diese Weise können Amazon EKS Managed Nodegroups die zugrunde liegenden ASG-Warm-Pool-Ressourcen während des gesamten Knotengruppen-Lebenszyklus verwalten. | 17. Februar 2026 |
| Berechtigung zu [AWS verwaltete Richtlinie: Amazon EKSService RolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy) hinzugefügt. | Die Präfixanforderung „eks“ im Namen des Zielinstanzprofils für die `iam:GetInstanceProfile` Berechtigung in wurde entfernt. `AmazonEKSServiceRolePolicy` Dadurch kann Amazon EKS Auto Mode benutzerdefinierte Instance-Profile validieren und verwenden, NodeClasses ohne dass das Namenspräfix „eks“ erforderlich ist. | 2. Februar 2026 |
| Berechtigungen zur [EBSCSIDriverAmazon-Richtlinie](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy) hinzugefügt. | Es wurde die `ec2:LockSnapshot` Berechtigung hinzugefügt, dem EBS-CSI-Treiber das direkte Sperren von EBS-Snapshots zu ermöglichen. | 15. Januar 2026 |
| Einführung von [AWS verwaltete Richtlinie: Amazon EKSMCPRead OnlyAccess](#security-iam-awsmanpol-amazoneksmcpreadonlyaccess). | Amazon EKS führte eine neue verwaltete Richtlinie ein`AmazonEKSMCPReadOnlyAccess`, um schreibgeschützte Tools auf dem Amazon EKS MCP-Server für Beobachtbarkeit und Fehlerbehebung zu aktivieren. | 21. November 2025 |
| Berechtigungen zur [EBSCSIDriverAmazon-Richtlinie](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy) hinzugefügt. | Es wurde die `ec2:CopyVolumes` Berechtigung hinzugefügt, dem EBS-CSI-Treiber das direkte Kopieren von EBS-Volumes zu ermöglichen. | 17. November 2025 |
| Berechtigung zu [AWS verwaltete Richtlinie: Amazon EKSService RolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy) hinzugefügt. | Hinzugefügt `ec2:DescribeRouteTables` und `ec2:DescribeNetworkAcls` Berechtigungen für`AmazonEKSServiceRolePolicy`. Auf diese Weise kann Amazon EKS im Rahmen von Cluster-Erkenntnissen Konfigurationsprobleme mit VPC-Routing-Tabellen und Netzwerken ACLs für Hybridknoten erkennen. | 22. Oktober 2025 |
| Berechtigung zu [AWSServiceRoleForAmazonEKSConnector](using-service-linked-roles-eks-connector.md) hinzugefügt | `ssmmessages:OpenDataChannel`Erlaubnis hinzugefügt zu `AmazonEKSConnectorServiceRolePolicy` | 15. Oktober 2025 |
| Berechtigung zu [AWS verwaltete Richtlinie: Amazon EKSService RolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy) hinzugefügt | Diese Rolle kann die neue Zugriffsrichtlinie `AmazonEKSEventPolicy` anfügen. Eingeschränkte Berechtigungen für `ec2:DeleteLaunchTemplate` und `ec2:TerminateInstances`. | 26. August 2025 |
| Berechtigung zu [AWS verwaltete Richtlinie: Amazon EKSLocal OutpostServiceRolePolicy](#security-iam-awsmanpol-amazonekslocaloutpostservicerolepolicy) hinzugefügt | `ssmmessages:OpenDataChannel`-Berechtigung zu `AmazonEKSLocalOutpostServiceRolePolicy` hinzugefügt. | 26. Juni 2025 |
| Berechtigung zu [AWS verwaltete Richtlinie: EKSCompute Amazon-Richtlinie](#security-iam-awsmanpol-AmazonEKSComputePolicy) hinzugefügt. | Aktualisierte Ressourcenberechtigungen für die Aktionen `ec2:RunInstances` und `ec2:CreateFleet`, um Kapazitätsreservierungen ` arn:aws: ec2:*:*:capacity-reservation/*` einzuschließen. Dadurch kann Amazon EKS Auto Mode Instances starten, indem die EC2-On-Demand-Kapazitätsreservierungen in Ihrem Konto verwendet werden. `iam:CreateServiceLinkedRole` hinzugefügt, um Amazon EKS Auto Mode zu ermöglichen, die serviceverknüpfte EC2-Spot-Rolle `AWSServiceRoleForEC2Spot` in Ihrem Namen zu erstellen. | 20. Juni 2025 |
| Die Erlaubnis wurde [Amazon](#security-iam-awsmanpol-amazoneksservicerolepolicy) hinzugefügt EKSServiceRolePolicy. | `ec2:DescribeCapacityReservations`-Berechtigung hinzugefügt, um Amazon EKS Auto Mode das Starten von Instances mithilfe der EC2-On-Demand-Kapazitätsreservierungen in Ihrem Konto zu ermöglichen. | 20. Juni 2025 |
| Einführung von [AWS verwaltete Richtlinie: Amazon EKSDashboard ConsoleReadOnly](#security-iam-awsmanpol-amazoneksdashboardconsolereadonly). | Neue `AmazonEKSDashboardConsoleReadOnly`-Richtlinie eingeführt. | 19. Juni 2025 |
| Einführung von [AWS verwaltete Richtlinie: Amazon EKSDashboard ServiceRolePolicy](#security-iam-awsmanpol-AmazonEKSDashboardServiceRolePolicy). | Neue `AmazonEKSDashboardServiceRolePolicy`-Richtlinie eingeführt. | 21. Mai 2025 |
| Berechtigungen zur [EKSClusterAmazon-Richtlinie](#security-iam-awsmanpol-amazoneksclusterpolicy) hinzugefügt. | `ec2:DeleteNetworkInterfaces`-Berechtigung hinzugefügt, um Amazon EKS das Löschen von Elastic Network Interfaces zu ermöglichen, die zurückbleiben, wenn das VPC CNI unerwartet beendet wird. | 16. April 2025 |
| Die Erlaubnis wurde [Amazon](#security-iam-awsmanpol-amazoneksservicerolepolicy) hinzugefügt EKSServiceRolePolicy. | Es wurden `ec2:AuthorizeSecurityGroupEgress` Berechtigungen hinzugefügt`ec2:RevokeSecurityGroupEgress`, die es AI/ML EKS-Kunden ermöglichen, als Teil der Version EKS 1.33 Sicherheitsgruppenausgangsregeln zur standardmäßigen EKS-Cluster-SG hinzuzufügen, die mit EFA kompatibel sind. | 14. April 2025 |
| Berechtigungen für [Amazon](#security-iam-awsmanpol-amazoneksservicerolepolicy) hinzugefügt EKSServiceRolePolicy. | Berechtigung zum Beenden von EC2-Instances hinzugefügt, die von EKS Auto Mode erstellt wurden. | 28. Februar 2025 |
| Berechtigungen zur [EBSCSIDriverAmazon-Richtlinie](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy) hinzugefügt. | Eine neue Anweisung wurde hinzugefügt, die den EBS CSI-Treiber zur Wiederherstellung aller Snapshots autorisiert. Dies war zuvor durch die vorhandene Richtlinie zulässig, aufgrund einer Änderung in der Handhabung von IAM für `CreateVolume` ist jedoch eine neue explizite Anweisung erforderlich. Dem EBS CSI-Treiber wurde die Möglichkeit hinzugefügt, Tags auf vorhandenen Volumes zu ändern. Der EBS-CSI-Treiber kann Tags vorhandener Volumes über Parameter in VolumeAttributesClasses Kubernetes ändern. Dem EBS-CSI-Treiber wurde die Möglichkeit hinzugefügt, Fast Snapshot Restore (FSR) in EBS-Volumes zu aktivieren. Der EBS-CSI-Treiber kann FSR auf neuen Volumes über Parameter in Kubernetes-Speicherklassen aktivieren. | 13. Januar 2025 |
| Berechtigungen zu [AWS verwaltete Richtlinie: Amazon EKSLoad BalancingPolicy](#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy) hinzugefügt. | `AmazonEKSLoadBalancingPolicy` wurde aktualisiert, um die Auflistung und Beschreibung von Netzwerk- und IP-Adressressourcen zu ermöglichen. | 26. Dezember 2024 |
| Berechtigungen zu [AWS verwaltete Richtlinie: AWSService RoleForAmazon EKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup) hinzugefügt. | `AWSServiceRoleForAmazonEKSNodegroup` für Kompatibilität mit chinesischen Regionen aktualisiert. | 22. November 2024 |
| Berechtigungen zu [AWS verwaltete Richtlinie: Amazon EKSLocal OutpostClusterPolicy](#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy) hinzugefügt | Es wurde eine `ec2:DescribeAvailabilityZones` Berechtigung hinzugefügt, `AmazonEKSLocalOutpostClusterPolicy` damit der AWS Cloud Controller Manager auf der Cluster-Steuerebene die Availability Zone identifizieren kann, in der sich jeder Knoten befindet. | 21. November 2024 |
| Berechtigungen zu [AWS verwaltete Richtlinie: AWSService RoleForAmazon EKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup) hinzugefügt. | Die `AWSServiceRoleForAmazonEKSNodegroup`-Richtlinie wurde so aktualisiert, dass Instances, die von Amazon EKS verwalteten Knotengruppen erstellt wurden, `ec2:RebootInstances` zulassen können. Die `ec2:CreateTags`-Berechtigungen für Amazon-EC2-Ressourcen wurden eingeschränkt. | 20. November 2024 |
| Berechtigungen zu [AWS verwaltete Richtlinie: Amazon EKSService RolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy) hinzugefügt. | EKS hat die AWS verwaltete Richtlinie aktualisiert`AmazonEKSServiceRolePolicy`. Berechtigungen für EKS-Zugriffsrichtlinien, Load-Balancer-Verwaltung und automatische Bereinigung von Cluster-Ressourcen hinzugefügt. | 16. November 2024 |
| Einführung von [AWS verwaltete Richtlinie: EKSCompute Amazon-Richtlinie](#security-iam-awsmanpol-AmazonEKSComputePolicy). | EKS hat die AWS verwaltete Richtlinie aktualisiert`AmazonEKSComputePolicy`. Aktualisierte Ressourcenberechtigungen für die Aktion `iam:AddRoleToInstanceProfile`. | 7. November 2024 |
| Einführung von [AWS verwaltete Richtlinie: EKSCompute Amazon-Richtlinie](#security-iam-awsmanpol-AmazonEKSComputePolicy). | AWS führte das ein`AmazonEKSComputePolicy`. | 1. November 2024 |
| Berechtigungen zu `AmazonEKSClusterPolicy` hinzugefügt | Berechtigung `ec2:DescribeInstanceTopology` hinzugefügt, damit Amazon EKS Topologieinformationen als Beschriftungen an den Knoten anfügen kann. | 1. November 2024 |
| Einführung von [AWS verwaltete Richtlinie: Amazon EKSBlock StoragePolicy](#security-iam-awsmanpol-AmazonEKSBlockStoragePolicy). | AWS führte die ein`AmazonEKSBlockStoragePolicy`. | 30. Oktober 2024 |
| Einführung von [AWS verwaltete Richtlinie: Amazon EKSLoad BalancingPolicy](#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy). | AWS führte die ein`AmazonEKSLoadBalancingPolicy`. | 30. Oktober 2024 |
| Berechtigungen für [Amazon](#security-iam-awsmanpol-amazoneksservicerolepolicy) hinzugefügt EKSServiceRolePolicy. | Es wurden `cloudwatch:PutMetricData` Berechtigungen hinzugefügt, die es Amazon EKS ermöglichen, Metriken auf Amazon zu veröffentlichen CloudWatch. | 29. Oktober 2024 |
| Einführung von [AWS verwaltete Richtlinie: EKSNetworking Amazon-Richtlinie](#security-iam-awsmanpol-AmazonEKSNetworkingPolicy). | AWS führte das ein`AmazonEKSNetworkingPolicy`. | 28. Oktober 2024 |
| Berechtigungen zu `AmazonEKSServicePolicy` und `AmazonEKSServiceRolePolicy` hinzugefügt. | `ec2:GetSecurityGroupsForVpc` und zugehörige Tag-Berechtigungen hinzugefügt, damit EKS Sicherheitsgruppeninformationen lesen und zugehörige Tags aktualisieren kann. | 10. Oktober 2024 |
| [Amazon](#security-iam-awsmanpol-AmazonEKSWorkerNodeMinimalPolicy) eingeführt EKSWorkerNodeMinimalPolicy. | AWS führte das ein`AmazonEKSWorkerNodeMinimalPolicy`. | 3. Oktober 2024 |
| Berechtigungen zu [AWSServiceRoleForAmazonEKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup) hinzugefügt. | `autoscaling:ResumeProcesses`- und `autoscaling:SuspendProcesses`-Berechtigungen hinzugefügt, damit Amazon EKS `AZRebalance` in von Amazon EKS verwalteten Auto-Scaling-Gruppen anhalten und fortsetzen kann. | 21. August 2024 |
| Berechtigungen zu [AWSServiceRoleForAmazonEKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup) hinzugefügt. | `ec2:DescribeCapacityReservations`-Berechtigung hinzugefügt, um Amazon EKS das Beschreiben der Kapazitätsreservierung im Benutzerkonto zu ermöglichen. `autoscaling:PutScheduledUpdateGroupAction`-Berechtigung hinzugefügt, um die Einstellung der geplanten Skalierung für `CAPACITY_BLOCK`-Knotengruppen zu ermöglichen. | 27. Juni 2024 |
| [AmazonEKS\$1CNI\$1Policy](#security-iam-awsmanpol-amazoneks-cni-policy) – Aktualisierung einer vorhandenen Richtlinie | Amazon EKS hat neue `ec2:DescribeSubnets`-Berechtigungen hinzugefügt, damit das Amazon-VPC-CNI-Plugin für Kubernetes die Anzahl der freien IP-Adressen in Ihren Amazon-VPC-Subnetzen sehen kann. Das VPC CNI kann die freien IP-Adressen in jedem Subnetz verwenden, um die Subnetze mit den meisten freien IP-Adressen für die Erstellung einer elastischen Netzwerkschnittstelle auszuwählen. | 4. März 2024 |
| [Amazon EKSWorker NodePolicy](#security-iam-awsmanpol-amazoneksworkernodepolicy) — Aktualisierung einer bestehenden Richtlinie | Amazon EKS wurden neue Berechtigungen hinzugefügt, die EKS-Pod-Identitäten zulassen. Der Amazon EKS Pod Identity-Agent verwendet die Knotenrolle. | 26. November 2023 |
| Einführung der [EFSCSIDriverAmazon-Richtlinie](#security-iam-awsmanpol-amazonefscsidriverservicerolepolicy). | AWS führte die ein`AmazonEFSCSIDriverPolicy`. | 26. Juli 2023 |
| Berechtigungen zur [EKSClusterAmazon-Richtlinie](#security-iam-awsmanpol-amazoneksclusterpolicy) hinzugefügt. | Die `ec2:DescribeAvailabilityZones`-Berechtigung wurde hinzugefügt, damit Amazon EKS die AZ-Details während der automatischen Subnetzerkennung beim Erstellen von Load Balancern abrufen kann. | 07. Februar 2023 |
| Die Versicherungsbedingungen in den [EBSCSIDriverAmazon-Richtlinien](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy) wurden aktualisiert. | Ungültige Richtlinienbedingungen mit Platzhalterzeichen im `StringLike`-Schlüsselfeld wurden entfernt. Außerdem wurde eine neue Bedingung `ec2:ResourceTag/kubernetes.io/created-for/pvc/name: "*"` zu `ec2:DeleteVolume` hinzugefügt, die es dem EBS-CSI-Treiber ermöglicht, vom In-Tree-Plugin erstellte Volumes zu löschen. | 17. November 2022 |
| Berechtigungen für [Amazon](#security-iam-awsmanpol-amazonekslocaloutpostservicerolepolicy) hinzugefügt EKSLocalOutpostServiceRolePolicy. | `ec2:DescribeVPCAttribute`, `ec2:GetConsoleOutput` und `ec2:DescribeSecret` wurden hinzugefügt, um eine bessere Validierung der Voraussetzungen und eine bessere Kontrolle des Lebenszyklus zu ermöglichen. Außerdem wurden `ec2:DescribePlacementGroups` und `"arn:aws: ec2:*:*:placement-group/*"` zu `ec2:RunInstances` hinzugefügt, um die Platzierungskontrolle der Steuerebene von Amazon-EC2-Instances auf Outposts zu unterstützen. | 24. Oktober 2022 |
| Aktualisieren Sie die Amazon Elastic Container Registry-Berechtigungen in [Amazon EKSLocal OutpostClusterPolicy](#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy). | Die Aktion `ecr:GetDownloadUrlForLayer` wurde von allen Ressourcenabschnitten in einen Bereich mit begrenztem Umfang verschoben. Ressource ` arn:aws: ecr:*:*:repository/eks/ ` wurde hinzugefügt. Entfernen Sie die Ressource ` arn:aws: ecr:`. Diese Ressource wird durch die hinzugefügte ` arn:aws: ecr:*:*:repository/eks/*`-Ressource abgedeckt. | 20. Oktober 2022 |
| Berechtigungen für [Amazon](#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy) hinzugefügt EKSLocalOutpostClusterPolicy. | Das ` arn:aws: ecr:*:*:repository/kubelet-config-updater` Repository der Amazon-Elastic-Container-Registry wurde hinzugefügt, damit die Cluster-Steuerebenen-Instances einige `kubelet`-Argumente aktualisieren können. | 31. August 2022 |
| [Amazon](#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy) eingeführt EKSLocalOutpostClusterPolicy. | AWS führte das ein`AmazonEKSLocalOutpostClusterPolicy`. | 24. August 2022 |
| [Amazon](#security-iam-awsmanpol-amazonekslocaloutpostservicerolepolicy) eingeführt EKSLocalOutpostServiceRolePolicy. | AWS führte das ein`AmazonEKSLocalOutpostServiceRolePolicy`. | 23. August 2022 |
| Einführung der [EBSCSIDriverAmazon-Richtlinie](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy). | AWS führte die ein`AmazonEBSCSIDriverPolicy`. | 4. April 2022 |
| Berechtigungen für [Amazon](#security-iam-awsmanpol-amazoneksworkernodepolicy) hinzugefügt EKSWorkerNodePolicy. | Hinzugefügt`ec2:DescribeInstanceTypes`, um Amazon EKS-Optimized zu aktivieren AMIs , das Eigenschaften auf Instance-Ebene auto erkennen kann. | 21. März 2022 |
| Berechtigungen zu [AWSServiceRoleForAmazonEKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup) hinzugefügt. | `autoscaling:EnableMetricsCollection`-Berechtigung hinzugefügt, um Amazon EKS die Aktivierung der Kennzahlenerfassung zu ermöglichen. | 13. Dezember 2021 |
| Berechtigungen zur [EKSClusterAmazon-Richtlinie](#security-iam-awsmanpol-amazoneksclusterpolicy) hinzugefügt. | `ec2:DescribeAccountAttributes`-, `ec2:DescribeAddresses`- und `ec2:DescribeInternetGateways`-Berechtigungen hinzugefügt, damit Amazon EKS eine serviceverknüpfte Rolle für einen Network Load Balancer erstellen kann. | 17. Juni 2021 |
| Amazon EKS hat mit der Nachverfolgung von Änderungen begonnen. | Amazon EKS hat damit begonnen, Änderungen für seine AWS verwalteten Richtlinien nachzuverfolgen. | 17. Juni 2021 |
# Fehlersuche bei IAM
In diesem Thema werden einige häufige Fehler bei der Verwendung von Amazon EKS mit IAM sowie deren Lösung behandelt.
## AccessDeniedException
Wenn Sie `AccessDeniedException` beim Aufrufen eines AWS API-Vorgangs eine Meldung erhalten, verfügen die von Ihnen verwendeten [IAM-Prinzipalanmeldedaten](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) nicht über die erforderlichen Berechtigungen, um diesen Aufruf durchzuführen.
```
An error occurred (AccessDeniedException) when calling the DescribeCluster operation:
User: arn:aws: iam::111122223333:user/user_name is not authorized to perform:
eks:DescribeCluster on resource: arn:aws: eks:region:111122223333:cluster/my-cluster
```
In der vorigen Beispielmeldung hat der Benutzer keine Berechtigung zum Aufruf der API-Operation `DescribeCluster` von Amazon EKS. Um einem IAM-Prinzipal Amazon-EKS-Administratorrechte zu erteilen, lesen Sie [Beispiele für identitätsbasierte Amazon-EKS-Richtlinien](security-iam-id-based-policy-examples.md).
Weitere allgemeine Informationen zu IAM finden Sie unter[Steuern des Zugriffs mit Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_controlling.html)im*IAM User Guide*aus.
## Sie können keine **Knoten** auf der Registerkarte „**Compute**“ oder etwas anderes auf der Registerkarte „**Ressourcen**“ sehen und Sie erhalten eine Fehlermeldung in AWS-Managementkonsole
Möglicherweise sehen Sie eine Konsolenfehlermeldung, die folgendermaßen lautet: `Your current user or role does not have access to Kubernetes objects on this EKS cluster`. Stellen Sie sicher, dass der [IAM-Prizipalbenutzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal), AWS-Managementkonsole mit dem Sie den verwenden, über die erforderlichen Berechtigungen verfügt. Weitere Informationen finden Sie unter [Erforderliche Berechtigungen](view-kubernetes-resources.md#view-kubernetes-resources-permissions).
## Die aws-auth-`ConfigMap` gewährt keinen Zugriff auf den Cluster
Der [AWS IAM Authenticator](https://github.com/kubernetes-sigs/aws-iam-authenticator) lässt keinen Pfad in dem Rollen-ARN zu, der in der `ConfigMap` verwendet wird. Entfernen Sie daher den Pfad, bevor Sie `rolearn` angeben. Sie können beispielsweise ` arn:aws: iam::111122223333:role/team/developers/eks-admin ` in ` arn:aws: iam::111122223333:role/eks-admin ` ändern.
## Ich bin nicht berechtigt, iam auszuführen: PassRole
Wenn Sie die Fehlermeldung erhalten, dass Sie nicht zur Ausführung der `iam:PassRole`-Aktion autorisiert sind, müssen Ihre Richtlinien aktualisiert werden, um eine Rolle an Amazon EKS übergeben zu können.
Bei einigen AWS Diensten können Sie eine bestehende Rolle an diesen Dienst übergeben, anstatt eine neue Servicerolle oder eine dienstverknüpfte Rolle zu erstellen. Hierzu benötigen Sie Berechtigungen für die Übergabe der Rolle an den Service.
Der folgende Beispielfehler tritt auf, wenn ein IAM-Benutzer mit dem Namen `marymajor` versucht, die Konsole zu verwenden, um eine Aktion in Amazon EKS auszuführen. Die Aktion erfordert jedoch, dass der Service über Berechtigungen verfügt, die durch eine Servicerolle gewährt werden. Mary besitzt keine Berechtigungen für die Übergabe der Rolle an den Dienst.
```
User: {arn-aws}iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
In diesem Fall müssen die Richtlinien von Mary aktualisiert werden, um die `iam:PassRole`-Aktion ausführen zu können.
Wenn Sie Hilfe benötigen, wenden Sie sich an Ihren AWS Administrator. Ihr Administrator hat Ihnen Ihre Anmeldeinformationen zur Verfügung gestellt.
## Ich möchte Personen außerhalb meines AWS Kontos den Zugriff auf meine Amazon EKS-Ressourcen ermöglichen
Sie können eine Rolle erstellen, mit der Benutzer in anderen Konten oder Personen außerhalb Ihrer Organisation auf Ihre Ressourcen zugreifen können. Sie können festlegen, wem die Übernahme der Rolle anvertraut wird. Für Dienste, die ressourcenbasierte Richtlinien oder Zugriffskontrolllisten (ACLs) unterstützen, können Sie diese Richtlinien verwenden, um Personen Zugriff auf Ihre Ressourcen zu gewähren.
Weitere Informationen dazu finden Sie hier:
+ Informationen dazu, ob Amazon EKS diese Features unterstützt, finden Sie unter [Funktionsweise von Amazon EKS mit IAM](security-iam-service-with-iam.md).
+ *Informationen dazu, wie Sie den Zugriff auf Ihre Ressourcen mit Ihren AWS Konten gewähren können, finden Sie im IAM-Benutzerhandbuch unter [Gewähren des Zugriffs für einen IAM-Benutzer in einem anderen AWS Konto, das Sie besitzen](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html).*
+ Informationen dazu, wie Sie AWS Konten von Drittanbietern Zugriff auf Ihre Ressourcen gewähren, finden Sie im *IAM-Benutzerhandbuch* [unter Zugriff auf AWS Konten, die Dritten gehören](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html).
+ Informationen dazu, wie Sie über einen Identitätsverbund Zugriff gewähren, finden Sie unter [Gewähren von Zugriff für extern authentifizierte Benutzer (Identitätsverbund)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) im *IAM-Benutzerhandbuch*.
+ Informationen zum Unterschied zwischen der Verwendung von Rollen und ressourcenbasierten Richtlinien für den kontoübergreifenden Zugriff finden Sie unter [Kontoübergreifender Ressourcenzugriff in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) im *IAM-Benutzerhandbuch*.
## Pod-Container erhalten folgenden Fehler: `An error occurred (SignatureDoesNotMatch) when calling the GetCallerIdentity operation: Credential should be scoped to a valid region`
Ihre Container erhalten diesen Fehler, wenn Ihre Anwendung explizit Anfragen an den globalen AWS STS-Endpunkt (`https://sts.amazonaws`) sendet und Ihr Kubernetes-Dienstkonto für die Verwendung eines regionalen Endpunkts konfiguriert ist. Sie können das Problem mit einer der folgenden Optionen beheben:
+ Aktualisieren Sie Ihren Anwendungscode, um explizite Aufrufe an den globalen AWS STS-Endpunkt zu entfernen.
+ Aktualisieren Sie Ihren Anwendungscode, um explizite Anrufe an regionale Endpunkte wie `https://sts.us-west-2.amazonaws.com` zu senden. Ihre Anwendung sollte über eine integrierte Redundanz verfügen, sodass bei einem Ausfall des Dienstes in der AWS Region eine andere AWS Region ausgewählt werden kann. Weitere Informationen finden Sie im IAM-Benutzerhandbuch unter [AWS STS in einer AWS Region verwalten](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html).
+ Konfigurieren Sie Ihre Servicekonten so, dass sie den globalen Endpunkt verwenden. Cluster verwenden standardmäßig den regionalen Endpunkt. Weitere Informationen finden Sie unter [Konfiguration des Endpunkts des AWS-Sicherheitstoken-Service für ein Servicekonto](configure-sts-endpoint.md).
# Amazon-EKS-Cluster-IAM-Rolle
Für jeden Cluster ist eine IAM-Rolle für Amazon-EKS-Cluster erforderlich. Von Amazon EKS verwaltete Kubernetes-Cluster verwenden diese Rolle zur Verwaltung von Knoten, und der [veraltete Cloud-Anbieter](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/#legacy-cloud-provider) nutzt diese Rolle, um Load Balancer mit Elastic Load Balancing für Services zu erstellen.
Bevor Sie Amazon-EKS-Cluster erstellen können, müssen Sie eine IAM-Rolle mit einer der folgenden IAM-Richtlinien erstellen:
+ [EKSClusterAmazon-Richtlinie](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html)
+ Eine benutzerdefinierten IAM-Richtlinie. Die folgenden Mindestberechtigungen ermöglichen es dem Kubernetes-Cluster, Knoten zu verwalten, erlauben es dem [alten Cloud-Anbieter](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/#legacy-cloud-provider) jedoch nicht, Load Balancer mit Elastic Load Balancing zu erstellen. Ihre benutzerdefinierte IAM-Richtlinie muss mindestens folgende Berechtigungen haben:
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": "arn:aws:ec2:*:*:instance/*",
"Condition": {
"ForAnyValue:StringLike": {
"aws:TagKeys": "kubernetes.io/cluster/*"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeVpcs",
"ec2:DescribeDhcpOptions",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeInstanceTopology",
"kms:DescribeKey"
],
"Resource": "*"
}
]
}
```
**Anmerkung**
Vor dem 3. Oktober 2023 war eine [EKSClusterAmazon-Richtlinie](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html) für die IAM-Rolle für jeden Cluster erforderlich.
Vor dem 16. April 2020 waren [EKSServiceAmazon-Richtlinien](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServicePolicy.html) und [EKSClusterAmazon-Richtlinien](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html) erforderlich, und der vorgeschlagene Name für die Rolle lautete`eksServiceRole`. Mit der `AWSServiceRoleForAmazonEKS` serviceverknüpften Rolle ist die [EKSServiceAmazon-Richtlinienrichtlinie](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServicePolicy.html) für Cluster, die am oder nach dem 16. April 2020 erstellt wurden, nicht mehr erforderlich.
## Überprüfen, ob eine Clusterrolle vorhanden ist
Mit dem folgenden Verfahren können Sie feststellen, ob Ihr Konto bereits über die Amazon-EKS-Clusterrolle verfügt.
1. Öffnen Sie die IAM-Konsole unter. https://console.aws.amazon.com/iam/
1. Wählen Sie im linken Navigationsbereich **Roles** aus.
1. Suchen Sie in der Liste der Rollen nach `eksClusterRole`. Wenn keine Rolle mit `eksClusterRole` vorhanden ist, informieren Sie sich unter [Erstellen der Amazon-EKS-Cluster-Rolle](#create-service-role), wie Sie die Rolle erstellen können. Wenn eine Rolle mit `eksClusterRole` vorhanden ist, wählen Sie die Rolle aus, um die angefügten Richtlinien anzuzeigen.
1. Wählen Sie **Berechtigungen**.
1. Stellen Sie sicher, dass die von **Amazon EKSCluster Policy** verwaltete Richtlinie der Rolle zugeordnet ist. Wenn die Richtlinie angefügt ist, ist Ihre Amazon-EKS-Clusterrolle korrekt konfiguriert.
1. Wählen Sie **Vertrauensstellungen** und dann **Vertrauensrichtlinie bearbeiten** aus.
1. Überprüfen Sie, dass die Vertrauensstellung die folgende Richtlinie enthält. Wenn die Vertrauensstellung mit der folgenden Richtlinie übereinstimmt, wählen Sie **Abbrechen** aus. Andernfalls kopieren Sie die Richtlinie in das Fenster **Vertrauensrichtlinie bearbeiten** und wählen Sie **Richtlinie aktualisieren** aus.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
## Erstellen der Amazon-EKS-Cluster-Rolle
Sie können die AWS-Managementkonsole oder die AWS CLI verwenden, um die Clusterrolle zu erstellen.
AWS-Managementkonsole
1. Öffnen Sie die IAM-Konsole unter https://console.aws.amazon.com/iam/.
1. Wählen Sie **Roles (Rollen)** und anschließend **Create Role (Rolle erstellen)** aus.
1. Wählen Sie unter **Vertrauenswürdiger Entitätstyp** die Option ** AWS Dienst** aus.
1. Wählen Sie aus der Dropdownliste **Anwendungsfälle für andere AWS Dienste** die Option **EKS** aus.
1. Wählen Sie **EKS – Cluster** für Ihren Anwendungsfall und dann **Weiter** aus.
1. Wählen Sie auf der Registerkarte **Add permissions** (Berechtigungen hinzufügen) die Option **Next** (Weiter) aus.
1. Geben Sie unter **Role name** (Rollenname) einen eindeutigen Namen für die Rolle ein, z. B. `eksClusterRole`.
1. Geben Sie unter **Beschreibung** einen beschreibenden Text, wie z. B. `Amazon EKS - Cluster role`, ein.
1. Wählen Sie **Rolle erstellen** aus.
AWS CLI
1. Kopieren Sie den folgenden Inhalt in eine Datei namens *cluster-trust-policy.json*.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Erstellen Sie die -Rolle. Sie können *eksClusterRole* mit einem beliebigen Namen ersetzen, den Sie wählen.
```
aws iam create-role \
--role-name eksClusterRole \
--assume-role-policy-document file://"cluster-trust-policy.json"
```
1. Fügen Sie der Rolle die erforderliche IAM-Richtlinie an.
```
aws iam attach-role-policy \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSClusterPolicy \
--role-name eksClusterRole
```
# Amazon-EKS-Knoten-IAM-Rolle
Der Amazon EKS Node `kubelet` Daemon ruft in Ihrem Namen AWS APIs an. Knoten erhalten über ein IAM-Instance-Profil und zugehörige Richtlinien Berechtigungen für diese API-Aufrufe. Bevor Sie Knoten starten und in einem Cluster registrieren können, müssen Sie eine IAM-Rolle erstellen, die diese Knoten beim Start verwenden können. Diese Anforderung gilt für Knoten, die mit dem von Amazon bereitgestellten Amazon EKS-optimierten AMI oder mit einem anderen Knoten AMIs , den Sie verwenden möchten, gestartet wurden. Darüber hinaus gilt diese Anforderung sowohl für verwaltete Knotengruppen als auch für selbstverwaltete Knoten.
**Anmerkung**
Sie können nicht dieselbe Rolle verwenden, die zum Erstellen von Clustern verwendet wurde.
Bevor Sie Knoten erstellen, müssen Sie eine IAM-Rolle mit folgenden Berechtigungen erstellen:
+ Berechtigungen für `kubelet` die Beschreibung von EC2 Amazon-Ressourcen in der VPC, wie sie in der [EKSWorkerNodePolicyAmazon-Richtlinie](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSWorkerNodePolicy.html) vorgesehen sind. Diese Richtlinie stellt auch die Berechtigungen für den Amazon EKS Pod Identity Agent bereit.
+ Berechtigungen für die `kubelet` Verwendung von Container-Images aus Amazon Elastic Container Registry (Amazon ECR), wie sie beispielsweise in der [EC2ContainerRegistryPullOnlyAmazon-Richtlinie](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEC2ContainerRegistryPullOnly.html) vorgesehen sind. Die Berechtigungen zur Verwendung von Container-Images aus Amazon Elastic Container Registry (Amazon ECR) sind erforderlich, da die integrierten Add-Ons für Netzwerke Pods ausführen, die Container-Images von Amazon ECR verwenden.
+ (Optional) Berechtigungen für den Amazon EKS Pod Identity Agent zum Verwenden der Aktion `eks-auth:AssumeRoleForPodIdentity`, um Anmeldeinformationen für Pods abzurufen. Wenn Sie [Amazon](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSWorkerNodePolicy.html) nicht verwenden EKSWorkerNodePolicy, müssen Sie diese Genehmigung zusätzlich zu den EC2 Berechtigungen zur Verwendung von EKS Pod Identity erteilen.
+ (Optional) Wenn Sie IRSA oder EKS Pod Identity nicht verwenden, um Berechtigungen für die VPC-CNI-Pods zu gewähren, müssen Sie Berechtigungen für das VPC-CNI in der Instance-Rolle bereitstellen. Sie können entweder die [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKS_CNI_Policy.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKS_CNI_Policy.html)verwaltete Richtlinie (wenn Sie Ihren Cluster mit der `IPv4` Familie erstellt haben) oder eine von [Ihnen erstellte IPv6 Richtlinie](cni-iam-role.md#cni-iam-role-create-ipv6-policy) (wenn Sie Ihren Cluster mit der `IPv6` Familie erstellt haben) verwenden. Anstatt die Richtlinie jedoch an diese Rolle anzuhängen, empfehlen wir Ihnen, die Richtlinie an eine separate Rolle anzuhängen, die speziell für das Amazon VPC CNI-Add-on verwendet wird. Weitere Informationen zum Erstellen einer separaten Rolle für das Amazon VPC CNI-Add-on finden Sie unter [Konfiguration des Amazon-VPC-CNI-Plugins für die Verwendung von IRSA](cni-iam-role.md).
**Anmerkung**
Die EC2 Amazon-Knotengruppen müssen eine andere IAM-Rolle als das Fargate-Profil haben. Weitere Informationen finden Sie unter [IAM-Rolle für die Ausführung von Amazon-EKS-Pods](pod-execution-role.md).
## Nach einer vorhandenen Knotenrolle suchen
Mit dem folgenden Verfahren können Sie feststellen, ob Ihr Konto bereits über die Amazon-EKS-Knotenrolle verfügt.
1. Öffnen Sie die IAM-Konsole unter. https://console.aws.amazon.com/iam/
1. Wählen Sie im linken Navigationsbereich **Roles** aus.
1. Suchen Sie in der Liste der Rollen nach `eksNodeRole`, `AmazonEKSNodeRole` oder `NodeInstanceRole`. Wenn eine Rolle mit einem dieser Namen nicht existiert, erfahren Sie unter [Erstellen der Amazon-EKS-Knoten-IAM-Rolle](#create-worker-node-role), wie Sie die Rolle erstellen. Wenn eine Rolle mit `eksNodeRole`, `AmazonEKSNodeRole` oder `NodeInstanceRole` vorhanden ist, wählen Sie die Rolle aus, um die angehängten Richtlinien anzuzeigen.
1. Wählen Sie **Berechtigungen**.
1. Stellen Sie sicher, dass die von **Amazon EKSWorker NodePolicy** **und Amazon EC2 ContainerRegistryPullOnly** verwalteten Richtlinien an die Rolle angehängt sind oder dass eine benutzerdefinierte Richtlinie mit den Mindestberechtigungen angehängt ist.
**Anmerkung**
Wenn die **AmazonEKS\$1CNI\$1Policy**-Richtlinie an die Rolle angehängt ist, empfehlen wir, sie zu entfernen und einer IAM-Rolle anzuhängen, die stattdessen dem `aws-node`-Kubernetes-Servicekonto zugeordnet ist. Weitere Informationen finden Sie unter [Konfiguration des Amazon-VPC-CNI-Plugins für die Verwendung von IRSA](cni-iam-role.md).
1. Wählen Sie **Trust Relationships** (Vertrauensstellungen) und dann **Edit trust policy** (Vertrauensrichtlinie bearbeiten) aus.
1. Überprüfen Sie, dass die Vertrauensstellung die folgende Richtlinie enthält. Wenn die Vertrauensstellung mit der folgenden Richtlinie übereinstimmt, wählen Sie **Abbrechen** aus. Andernfalls kopieren Sie die Richtlinie in das Fenster **Vertrauensrichtlinie bearbeiten** und wählen Sie **Richtlinie aktualisieren** aus.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Principal": {
"Service": [
"ec2.amazonaws.com"
]
}
}
]
}
```
## Erstellen der Amazon-EKS-Knoten-IAM-Rolle
Sie können die Node-IAM-Rolle mit der AWS-Managementkonsole oder der AWS CLI erstellen.
AWS-Managementkonsole
1. Öffnen Sie die IAM-Konsole unter. https://console.aws.amazon.com/iam/
1. Wählen Sie im linken Navigationsbereich **Roles** aus.
1. Klicken Sie auf der Seite **Roles (Rollen)** auf **Create role (Rolle erstellen)**.
1. Gehen Sie auf der Seite **Select trusted entity** (Vertrauenswürdige Entität auswählen) wie folgt vor:
1. Wählen Sie im Abschnitt **Vertrauenswürdiger Entitätstyp** die Option ** AWS Service** aus.
1. Wählen Sie unter **Use case** (Anwendungsfall) **EC2** aus.
1. Wählen Sie **Weiter** aus.
1. Führen Sie auf der Seite **Add permissions** (Berechtigungen hinzufügen) die folgenden Schritte aus:
1. Geben Sie im Feld **Filter policies (Filterrichtlinien)** `AmazonEKSWorkerNodePolicy` ein.
1. Aktivieren Sie EKSWorker NodePolicy in den Suchergebnissen das Kontrollkästchen links neben **Amazon**.
1. Wählen Sie **Clear filters** (Filter löschen) aus.
1. Geben Sie im Feld **Filter policies (Filterrichtlinien)** `AmazonEC2ContainerRegistryPullOnly` ein.
1. Aktivieren Sie EC2 ContainerRegistryPullOnly in den Suchergebnissen das Kontrollkästchen links neben **Amazon**.
Entweder die von **Amazoneks\$1CNI\$1Policy** verwaltete Richtlinie oder eine von Ihnen erstellte [IPv6 Richtlinie](cni-iam-role.md#cni-iam-role-create-ipv6-policy) muss ebenfalls entweder dieser Rolle oder einer anderen Rolle zugewiesen werden, die dem Kubernetes-Dienstkonto zugeordnet ist. `aws-node` Wir empfehlen, die Richtlinie der Rolle zuzuweisen, die dem Kubernetes-Dienstkonto zugeordnet ist, anstatt sie dieser Rolle zuzuweisen. Weitere Informationen finden Sie unter [Konfiguration des Amazon-VPC-CNI-Plugins für die Verwendung von IRSA](cni-iam-role.md).
1. Wählen Sie **Weiter** aus.
1. Gehen Sie auf der Seite **Name, review, and create** (Benennen, überprüfen und erstellen) wie folgt vor:
1. Geben Sie unter **Role name** (Rollenname) einen eindeutigen Namen für die Rolle ein, z. B. `AmazonEKSNodeRole`.
1. Ersetzen Sie unter **Description** (Beschreibung) den aktuellen Text durch beschreibenden Text wie beispielsweise `Amazon EKS - Node role`.
1. Fügen Sie der Rolle unter **Tags hinzufügen (optional)** Metadaten hinzu, indem Sie Tags als Schlüssel-Wert-Paare anfügen. Weitere Informationen zur Verwendung von Tags in IAM finden Sie unter [Markieren von IAM-Ressourcen](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html) im *IAM-Benutzerhandbuch*.
1. Wählen Sie **Rolle erstellen** aus.
AWS CLI
1. Führen Sie den folgenden Befehl aus, um die Datei `node-role-trust-relationship.json` zu erstellen.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Principal": {
"Service": [
"ec2.amazonaws.com"
]
}
}
]
}
```
1. Erstellen Sie die IAM-Rolle.
```
aws iam create-role \
--role-name AmazonEKSNodeRole \
--assume-role-policy-document file://"node-role-trust-relationship.json"
```
1. Hängen Sie die beiden erforderlichen verwalteten IAM-Richtlinien an die IAM-Rolle an.
```
aws iam attach-role-policy \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSWorkerNodePolicy \
--role-name AmazonEKSNodeRole
aws iam attach-role-policy \
--policy-arn arn:aws: iam::aws:policy/AmazonEC2ContainerRegistryPullOnly \
--role-name AmazonEKSNodeRole
```
1. Hängen Sie eine der folgenden IAM-Richtlinien an die IAM-Rolle an, je nachdem, mit welcher IP-Familie Sie Ihren Cluster erstellt haben. Die Richtlinie muss an diese Rolle oder an eine Rolle angefügt werden, die dem Kubernetes `aws-node`-Servicekonto zugeordnet ist, das für das Amazon-VPC-CNI-Plugin verwendet wird. Wir empfehlen, die Richtlinie der Rolle zuzuweisen, die dem Kubernetes-Servicekonto zugeordnet ist. Um die Richtlinie der Rolle zuzuweisen, die dem Kubernetes-Servicekonto zugeordnet ist, siehe [Konfiguration des Amazon-VPC-CNI-Plugins für die Verwendung von IRSA](cni-iam-role.md).
+ IPv4
```
aws iam attach-role-policy \
--policy-arn arn:aws: iam::aws:policy/AmazonEKS_CNI_Policy \
--role-name AmazonEKSNodeRole
```
+ IPv6
1. Kopieren Sie den folgenden Text und speichern Sie ihn in einer Datei mit dem Namen `vpc-cni-ipv6-policy.json`.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:AssignIpv6Addresses",
"ec2:DescribeInstances",
"ec2:DescribeTags",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeInstanceTypes"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": [
"arn:aws:ec2:*:*:network-interface/*"
]
}
]
}
```
1. Erstellen Sie die IAM-Richtlinie.
```
aws iam create-policy --policy-name AmazonEKS_CNI_IPv6_Policy --policy-document file://vpc-cni-ipv6-policy.json
```
1. Fügen Sie die IAM-Richtlinie an die IAM-Rolle an. Ersetzen Sie *111122223333* durch Ihre Konto-ID.
```
aws iam attach-role-policy \
--policy-arn arn:aws: iam::111122223333:policy/AmazonEKS_CNI_IPv6_Policy \
--role-name AmazonEKSNodeRole
```
# IAM-Rolle für Cluster von Amazon EKS Auto Mode
Für jeden Cluster ist eine IAM-Rolle für Amazon-EKS-Cluster erforderlich. Von Amazon EKS verwaltete Kubernetes-Cluster nutzen diese Rolle, um Routineaufgaben für Speicher, Netzwerk und automatische Skalierung von Rechenleistung zu automatisieren.
Bevor Sie Amazon-EKS-Cluster erstellen können, müssen Sie eine IAM-Rolle mit den für EKS Auto Mode erforderlichen Richtlinien erstellen. Sie können entweder die vorgeschlagenen AWS IAM-verwalteten Richtlinien anhängen oder benutzerdefinierte Richtlinien mit entsprechenden Berechtigungen erstellen.
+ [EKSComputeAmazon-Richtlinie](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSComputePolicy)
+ [AmazonEKSBlockStoragePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSBlockStoragePolicy)
+ [AmazonEKSLoadBalancingPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy)
+ [EKSNetworkingAmazon-Richtlinie](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSNetworkingPolicy)
+ [EKSClusterAmazon-Richtlinie](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksclusterpolicy)
## Überprüfen, ob eine Clusterrolle vorhanden ist
Mit dem folgenden Verfahren können Sie feststellen, ob Ihr Konto bereits über die Amazon-EKS-Clusterrolle verfügt.
1. Öffnen Sie die IAM-Konsole unter https://console.aws.amazon.com/iam/.
1. Wählen Sie im linken Navigationsbereich **Roles** aus.
1. Suchen Sie in der Liste der Rollen nach `AmazonEKSAutoClusterRole`. Wenn eine Rolle, die `AmazonEKSAutoClusterRole` enthält, nicht vorhanden ist, befolgen Sie die Anweisungen im nächsten Abschnitt, um die Rolle zu erstellen. Wenn eine Rolle mit `AmazonEKSAutoClusterRole` vorhanden ist, wählen Sie die Rolle aus, um die angefügten Richtlinien anzuzeigen.
1. Wählen Sie **Berechtigungen**.
1. Stellen Sie sicher, dass die von **Amazon EKSCluster Policy** verwaltete Richtlinie der Rolle zugeordnet ist. Wenn die Richtlinie angefügt ist, ist Ihre Amazon-EKS-Clusterrolle korrekt konfiguriert.
1. Wählen Sie **Vertrauensstellungen** und dann **Vertrauensrichtlinie bearbeiten** aus.
1. Überprüfen Sie, dass die Vertrauensstellung die folgende Richtlinie enthält. Wenn die Vertrauensstellung mit der folgenden Richtlinie übereinstimmt, wählen Sie **Abbrechen** aus. Andernfalls kopieren Sie die Richtlinie in das Fenster **Vertrauensrichtlinie bearbeiten** und wählen Sie **Richtlinie aktualisieren** aus.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
**Anmerkung**
AWS benötigt den Namen `AmazonEKSAutoClusterRole` für diese Rolle nicht.
## Erstellen der Amazon-EKS-Cluster-Rolle
Sie können die AWS-Managementkonsole oder die AWS CLI verwenden, um die Clusterrolle zu erstellen.
### AWS-Managementkonsole
1. Öffnen Sie die IAM-Konsole unter https://console.aws.amazon.com/iam/.
1. Wählen Sie **Roles (Rollen)** und anschließend **Create Role (Rolle erstellen)** aus.
1. Wählen Sie unter **Vertrauenswürdiger Entitätstyp** die Option ** AWS Dienst** aus.
1. Wählen Sie aus der Dropdownliste **Anwendungsfälle für andere AWS Dienste** die Option **EKS** aus.
1. Wählen Sie **EKS – Cluster** für Ihren Anwendungsfall und dann **Weiter** aus.
1. Wählen Sie auf der Registerkarte **Berechtigungen hinzufügen** die Richtlinien aus und klicken Sie dann auf **Weiter**.
+ [EKSComputeAmazon-Richtlinie](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSComputePolicy)
+ [AmazonEKSBlockStoragePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSBlockStoragePolicy)
+ [AmazonEKSLoadBalancingPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy)
+ [EKSNetworkingAmazon-Richtlinie](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSNetworkingPolicy)
+ [EKSClusterAmazon-Richtlinie](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksclusterpolicy)
1. Geben Sie unter **Rollenname** einen eindeutigen Namen für die Rolle ein, z. B. `AmazonEKSAutoClusterRole`.
1. Geben Sie unter **Beschreibung** einen beschreibenden Text, wie z. B. `Amazon EKS - Cluster role`, ein.
1. Wählen Sie **Rolle erstellen** aus.
### AWS CLI
1. Kopieren Sie den folgenden Inhalt in eine Datei namens *cluster-trust-policy.json*.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
1. Erstellen Sie die -Rolle. Sie können *AmazonEKSAutoClusterRole* mit einem beliebigen Namen ersetzen, den Sie wählen.
```
aws iam create-role \
--role-name AmazonEKSAutoClusterRole \
--assume-role-policy-document file://"cluster-trust-policy.json"
```
1. Fügen Sie der Rolle die erforderlichen IAM-Richtlinien an:
**EKSClusterAmazon-Richtlinie**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSClusterPolicy
```
**EKSComputeAmazon-Richtlinie**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSComputePolicy
```
**Amazon EKSBlock StoragePolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSBlockStoragePolicy
```
**Amazon EKSLoad BalancingPolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSLoadBalancingPolicy
```
**EKSNetworkingAmazon-Richtlinie**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSNetworkingPolicy
```
# IAM-Rolle für Knoten im Amazon EKS Auto Mode
**Anmerkung**
Sie können nicht dieselbe Rolle verwenden, die zum Erstellen von Clustern verwendet wurde.
Bevor Sie Knoten erstellen, müssen Sie eine IAM-Rolle mit den folgenden Richtlinien oder entsprechenden Berechtigungen erstellen:
+ [AmazonEKSWorkerNodeMinimalPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSWorkerNodeMinimalPolicy)
+ [AmazonEC2ContainerRegistryPullOnly](https://docs.aws.amazon.com/AmazonECR/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonEC2ContainerRegistryPullOnly)
## Nach einer vorhandenen Knotenrolle suchen
Mit dem folgenden Verfahren können Sie feststellen, ob Ihr Konto bereits über die Amazon-EKS-Knotenrolle verfügt.
1. Öffnen Sie die IAM-Konsole unter https://console.aws.amazon.com/iam/.
1. Wählen Sie im linken Navigationsbereich **Roles** aus.
1. Suchen Sie in der Liste der Rollen nach `AmazonEKSAutoNodeRole`. Wenn eine Rolle mit einem dieser Namen nicht vorhanden ist, lesen Sie die Anweisungen zum Erstellen der Rolle im nächsten Abschnitt. Wenn eine Rolle mit `AmazonEKSAutoNodeRole` vorhanden ist, wählen Sie die Rolle aus, um die angehängten Richtlinien anzuzeigen.
1. Wählen Sie **Berechtigungen**.
1. Stellen Sie sicher, dass die oben genannten erforderlichen Richtlinien oder entsprechende benutzerdefinierte Richtlinien angefügt sind.
1. Wählen Sie **Vertrauensstellungen** und dann **Vertrauensrichtlinie bearbeiten** aus.
1. Überprüfen Sie, dass die Vertrauensstellung die folgende Richtlinie enthält. Wenn die Vertrauensstellung mit der folgenden Richtlinie übereinstimmt, wählen Sie **Abbrechen** aus. Andernfalls kopieren Sie die Richtlinie in das Fenster **Vertrauensrichtlinie bearbeiten** und wählen Sie **Richtlinie aktualisieren** aus.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
## Erstellen der Amazon-EKS-Knoten-IAM-Rolle
Sie können die Node-IAM-Rolle mit der AWS-Managementkonsole oder der AWS CLI erstellen.
### AWS-Managementkonsole
1. Öffnen Sie die IAM-Konsole unter. https://console.aws.amazon.com/iam/
1. Wählen Sie im linken Navigationsbereich **Roles** aus.
1. Klicken Sie auf der Seite **Roles (Rollen)** auf **Create role (Rolle erstellen)**.
1. Gehen Sie auf der Seite **Select trusted entity** (Vertrauenswürdige Entität auswählen) wie folgt vor:
1. Wählen Sie im Abschnitt **Vertrauenswürdiger Entitätstyp** die Option ** AWS Service** aus.
1. Wählen Sie unter **Use case** (Anwendungsfall) **EC2** aus.
1. Wählen Sie **Weiter** aus.
1. Fügen Sie auf der Seite **Berechtigungen hinzufügen** die folgenden Richtlinien hinzu:
+ [AmazonEKSWorkerNodeMinimalPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSWorkerNodeMinimalPolicy)
+ [AmazonEC2ContainerRegistryPullOnly](https://docs.aws.amazon.com/AmazonECR/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonEC2ContainerRegistryPullOnly)
1. Gehen Sie auf der Seite **Name, review, and create** (Benennen, überprüfen und erstellen) wie folgt vor:
1. Geben Sie unter **Role name** (Rollenname) einen eindeutigen Namen für die Rolle ein, z. B. `AmazonEKSAutoNodeRole`.
1. Ersetzen Sie unter **Description** (Beschreibung) den aktuellen Text durch beschreibenden Text wie beispielsweise `Amazon EKS - Node role`.
1. Fügen Sie der Rolle unter **Tags hinzufügen (optional)** Metadaten hinzu, indem Sie Tags als Schlüssel-Wert-Paare anfügen. Weitere Informationen zur Verwendung von Tags in IAM finden Sie unter [Markieren von IAM-Ressourcen](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html) im *IAM-Benutzerhandbuch*.
1. Wählen Sie **Rolle erstellen** aus.
### AWS CLI
**Knoten-IAM-Rolle erstellen**
Verwenden Sie die **node-trust-policyJSON-Datei** aus dem vorherigen Schritt, um zu definieren, welche Entitäten die Rolle übernehmen können. Führen Sie den folgenden Befehl aus, um die Knoten-IAM-Rolle zu erstellen:
```
aws iam create-role \
--role-name AmazonEKSAutoNodeRole \
--assume-role-policy-document file://node-trust-policy.json
```
**Rollen-ARN beachten**
Rufen Sie nach dem Erstellen der Rolle die ARN der Knoten-IAM-Rolle ab und speichern Sie sie. Sie benötigen diese ARN in den nachfolgenden Schritten. Um die ARN abzurufen, verwenden Sie den folgenden Befehl.
```
aws iam get-role --role-name AmazonEKSAutoNodeRole --query "Role.Arn" --output text
```
**Erforderliche Richtlinien anfügen**
Fügen Sie der Node-IAM-Rolle die folgenden AWS verwalteten Richtlinien hinzu, um die erforderlichen Berechtigungen bereitzustellen:
Um Amazon anzuhängen EKSWorkerNodeMinimalPolicy:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoNodeRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSWorkerNodeMinimalPolicy
```
Um Amazon anzuhängen EC2ContainerRegistryPullOnly:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoNodeRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEC2ContainerRegistryPullOnly
```
# IAM-Rolle für Amazon EKS-Funktionen
EKS-Funktionen erfordern die Konfiguration einer Capability-IAM-Rolle (oder Fähigkeitsrolle). Capabilities verwenden diese Rolle, um Aktionen für AWS Dienste auszuführen und über automatisch erstellte Zugriffseinträge auf Kubernetes-Ressourcen in Ihrem Cluster zuzugreifen.
Bevor Sie bei der Funktionserstellung eine Funktionsrolle angeben können, müssen Sie die IAM-Rolle mit den entsprechenden Vertrauensrichtlinien und Berechtigungen für den Funktionstyp erstellen. Sobald diese IAM-Rolle erstellt wurde, kann sie für eine beliebige Anzahl von Funktionsressourcen wiederverwendet werden.
## Anforderungen an die Rolle der Fähigkeit
Die Fähigkeitsrolle muss die folgenden Anforderungen erfüllen:
+ Die Rolle muss sich in demselben AWS Konto befinden wie der Cluster und die Capability-Ressource
+ Die Rolle muss über eine Vertrauensrichtlinie verfügen, die es dem EKS-Capabilities-Service ermöglicht, die Rolle zu übernehmen
+ Die Rolle muss über Berechtigungen verfügen, die dem Funktionstyp und den Anforderungen des Anwendungsfalls entsprechen (siehe[Berechtigungen nach Funktionstyp](#capability-permissions))
## Vertrauensrichtlinie für Funktionsrollen
Alle Funktionsrollen müssen die folgende Vertrauensrichtlinie beinhalten:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "capabilities.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
Diese Vertrauensrichtlinie ermöglicht EKS:
+ Übernehmen Sie die Rolle zur Durchführung von AWS API-Vorgängen
+ Taggen Sie Sitzungen zu Prüf- und Nachverfolgungszwecken
## Berechtigungen nach Funktionstyp
Die erforderlichen IAM-Berechtigungen hängen davon ab, welche Funktion Sie verwenden und welches Bereitstellungsmodell Sie verwenden.
**Anmerkung**
Bei Produktionsbereitstellungen, bei denen IAM-Rollenselektoren mit ACK verwendet werden, oder bei Verwendung von Kro- oder Argo-CD ohne AWS Serviceintegration sind für die Capability Role möglicherweise keine IAM-Berechtigungen erforderlich, die über die Vertrauensrichtlinie hinausgehen.
**kro (Kube Resource Orchestrator)**
Es sind keine IAM-Berechtigungen erforderlich. Sie können eine Funktionsrolle ohne angehängte Richtlinien erstellen. kro benötigt lediglich Kubernetes-RBAC-Berechtigungen, um Kubernetes-Ressourcen zu erstellen und zu verwalten.
** AWS Controller für Kubernetes (ACK)**
ACK unterstützt zwei Berechtigungsmodelle:
+ **Einfache Einrichtung (Entwicklung/Testen)**: Fügen Sie AWS Dienstberechtigungen direkt zur Capability-Rolle hinzu. Dies eignet sich gut für den Einstieg, für Bereitstellungen mit einem Konto oder wenn alle Benutzer dieselben Berechtigungen benötigen.
+ Bewährte **Methode für die Produktion**: Verwenden Sie IAM-Rollenselektoren, um den Zugriff mit den geringsten Rechten zu implementieren. Bei diesem Ansatz benötigt die Capability-Rolle nur die `sts:AssumeRole` Erlaubnis, dienstspezifische Rollen anzunehmen. Sie fügen der Capability-Rolle selbst keine AWS Dienstberechtigungen (wie S3 oder RDS) hinzu — diese Berechtigungen werden einzelnen IAM-Rollen gewährt, die bestimmten Namespaces zugeordnet sind.
IAM-Rollenselektoren ermöglichen:
+ Isolierung von Berechtigungen auf Namespace-Ebene
+ Kontoübergreifende Ressourcenverwaltung
+ Teamspezifische IAM-Rollen
+ Sicherheitsmodell mit den geringsten Rechten
Beispiel für eine Capability Role Policy für den IAM Role Selector-Ansatz:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": [
"arn:aws:iam::111122223333:role/ACK-S3-Role",
"arn:aws:iam::111122223333:role/ACK-RDS-Role",
"arn:aws:iam::444455556666:role/ACKCrossAccountRole"
]
}
]
}
```
Eine ausführliche Konfiguration der ACK-Berechtigungen einschließlich IAM-Rollenselektoren finden Sie unter. [ACK-Berechtigungen konfigurieren](ack-permissions.md)
**Argo-CD**
Standardmäßig sind keine IAM-Berechtigungen erforderlich. Optionale Berechtigungen können erforderlich sein für:
+ ** AWS Secrets Manager**: Wenn Sie Secrets Manager zum Speichern von Git-Repository-Anmeldeinformationen verwenden
+ ** AWS CodeConnections**: Bei Verwendung CodeConnections für die Git-Repository-Authentifizierung
Beispielrichtlinie für Secrets Manager und CodeConnections:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"secretsmanager:GetSecretValue",
"secretsmanager:DescribeSecret"
],
"Resource": "arn:aws:secretsmanager:region:account-id:secret:argocd/*"
},
{
"Effect": "Allow",
"Action": [
"codeconnections:UseConnection",
"codeconnections:GetConnection"
],
"Resource": "arn:aws:codeconnections:region:account-id:connection/*"
}
]
}
```
Ausführliche Informationen zu den Argo-CD-Genehmigungsanforderungen finden Sie unter[Überlegungen zu Argo CD](argocd-considerations.md).
## Suchen Sie nach einer vorhandenen Capability-Rolle
Mithilfe des folgenden Verfahrens können Sie überprüfen, ob Ihr Konto bereits über eine für Ihren Anwendungsfall geeignete Capability IAM-Rolle verfügt.
1. Öffnen Sie die IAM-Konsole unter. https://console.aws.amazon.com/iam/
1. Wählen Sie im linken Navigationsbereich **Roles** aus.
1. Suchen Sie in der Rollenliste nach dem Namen Ihrer Funktionsrolle (z. B. `ACKCapabilityRole` oder`ArgoCDCapabilityRole`).
1. Wenn eine Rolle vorhanden ist, wählen Sie sie aus, um die angehängten Richtlinien und die Vertrauensstellung anzuzeigen.
1. Wählen Sie **Vertrauensstellungen** und dann **Vertrauensrichtlinie bearbeiten** aus.
1. Stellen Sie sicher, dass die Vertrauensstellung der [Capability Trust-Richtlinie](#capability-trust-policy) entspricht. Wenn sie nicht übereinstimmt, aktualisieren Sie die Vertrauensrichtlinie.
1. Wählen Sie **Berechtigungen** aus und stellen Sie sicher, dass die Rolle über die entsprechenden Berechtigungen für Ihren Funktionstyp und Ihren Anwendungsfall verfügt.
## Eine Capability-IAM-Rolle erstellen
Sie können die AWS-Managementkonsole oder die AWS CLI verwenden, um eine Capability-Rolle zu erstellen.
** AWS-Managementkonsole **
1. Öffnen Sie die IAM-Konsole unter https://console.aws.amazon.com/iam/.
1. Wählen Sie **Roles (Rollen)** und anschließend **Create Role (Rolle erstellen)** aus.
1. Wählen Sie unter **Vertrauenswürdiger Entitätstyp** die Option **Benutzerdefinierte Vertrauensrichtlinie** aus.
1. Kopieren Sie die [Capability Trust Policy](#capability-trust-policy) und fügen Sie sie in den Trust Policy Editor ein.
1. Wählen Sie **Weiter** aus.
1. Wählen Sie auf der Registerkarte „**Berechtigungen hinzufügen**“ Richtlinien aus, die Ihrem Funktionstyp entsprechen, oder erstellen Sie sie (siehe[Berechtigungen nach Funktionstyp](#capability-permissions)). Für Kro können Sie diesen Schritt überspringen.
1. Wählen Sie **Weiter** aus.
1. Geben Sie **unter Rollenname** einen eindeutigen Namen für Ihre Rolle ein, z. B. `ACKCapabilityRole``ArgoCDCapabilityRole`, oder`kroCapabilityRole`.
1. Geben Sie unter **Beschreibung** einen beschreibenden Text, wie z. B. `Amazon EKS - ACK capability role`, ein.
1. Wählen Sie **Rolle erstellen** aus.
** AWS -CLI**
1. Kopieren Sie die [Capability Trust-Richtlinie](#capability-trust-policy) in eine Datei mit dem Namen`capability-trust-policy.json`.
1. Erstellen Sie die Rolle. `ACKCapabilityRole`Ersetzen Sie sie durch den gewünschten Rollennamen.
```
aws iam create-role \
--role-name ACKCapabilityRole \
--assume-role-policy-document file://capability-trust-policy.json
```
1. Hängen Sie die erforderlichen IAM-Richtlinien an die Rolle an. Fügen Sie für ACK Richtlinien für die AWS Dienste hinzu, die Sie verwalten möchten. Fügen Sie für Argo CD Richtlinien für Secrets Manager oder bei CodeConnections Bedarf hinzu. Für Kro können Sie diesen Schritt überspringen.
Beispiel für ACK mit S3-Berechtigungen:
```
aws iam put-role-policy \
--role-name ACKCapabilityRole \
--policy-name S3Management \
--policy-document file://s3-policy.json
```
## Behebung von Problemen mit Funktionsrollen
**Die Erstellung von Funktionen schlägt mit der Meldung „Ungültige IAM-Rolle“ fehl**
Vergewissern Sie sich, dass folgende Bedingungen erfüllt sind:
+ Die Rolle ist in demselben Konto wie der Cluster vorhanden
+ Die Vertrauensrichtlinie entspricht der [Capability Trust-Richtlinie](#capability-trust-policy)
+ Sie haben die `iam:PassRole` Erlaubnis für die Rolle
**Die Funktion zeigt Berechtigungsfehler**
Vergewissern Sie sich, dass folgende Bedingungen erfüllt sind:
+ Die Rolle verfügt über die erforderlichen IAM-Berechtigungen für den Fähigkeitstyp
+ Der Zugriffseintrag für die Rolle ist auf dem Cluster vorhanden
+ Zusätzliche Kubernetes-Berechtigungen werden bei Bedarf konfiguriert (siehe) [Zusätzliche Kubernetes-Berechtigungen](capabilities-security.md#additional-kubernetes-permissions)
**ACK-Ressourcen schlagen mit der Fehlermeldung „Zugriff verweigert“ fehl**
Vergewissern Sie sich, dass folgende Bedingungen erfüllt sind:
+ Die Rolle verfügt über die erforderlichen IAM-Berechtigungen für Ihren Anwendungsfall
+ Stellen Sie bei ACK-Controllern, die auf geheime Daten verweisen, sicher, dass Sie den `AmazonEKSSecretReaderPolicy` Geltungsbereich der Zugriffsrichtlinie den entsprechenden Namespaces zugeordnet haben.
Weitere Anleitungen zur Fehlerbehebung finden Sie unter. [Sicherheitsüberlegungen für EKS-Funktionen](capabilities-security.md)