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.
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) mit Kubernetes KMS Provider v2
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
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 folgende allgemeine Diagramm veranschaulicht die Verschlüsselung einer Kubernetes-Ressource, bevor sie in etcd gespeichert wird.
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-apiserver wird durch das Nitro-System gesichert. Amazon EKS verwendet nur Nitro-basierte EC2 Instances 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. Sicherheit hat AWS bei uns höchste Priorität
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 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 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. Wenn Sie jedoch Ihren eigenen AWS KMS-Schlüssel verwenden, gelten die normalen KMS-Preise
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
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 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
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 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_KEY_DISABLED 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_KEY_NOT_FOUND) oder die Berechtigungen für den mit Ihrem Cluster verknüpften CMK widerrufen werden (KMS_GRANT_REVOKED). Weitere Informationen zum Clusterstatus und zu Fehlercodes finden Sie unter Clusterintegritäts FAQs - und Fehlercodes 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
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+1) 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. Ein Alias ist ein benutzerfreundlicher Name für einen KMS-Schlüssel für Amazon Web Service. 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)
