**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 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.