**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.
# 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"
}
}
}
]
}
```