Unterstützung für die Verbesserung dieser Seite beitragen
Um zu diesem Benutzerhandbuch beizutragen, klicken Sie auf den Link Diese Seite auf GitHub bearbeiten, der sich im rechten Bereich jeder Seite befindet.
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 Standardumgebung, die eine tiefgreifende Verteidigung für Ihre Kubernetes-Anwendungen implementiert und keine Maßnahmen Ihrerseits erfordert.
Amazon EKS verwendet AWS Key Management Service (KMS) mit dem Kubernetes-KMS-Anbieter v2
Grundlegendes zur Umschlagverschlüsselung
Bei der Umschlagverschlüsselung werden Klartextdaten vor der Übertragung an den Datenspeicher (usw.) mit einem Datenverschlüsselungsschlüssel (DEK) verschlüsselt. Anschließend wird der DEK mit einem Root-KMS-Schlüssel verschlüsselt, der in einem zentral verwalteten KMS-System (AWS KMS) aus der Ferne gespeichert ist. Dies ist eine mehrstufige Verteidigungsstrategie, da die Daten zunächst mit einem Verschlüsselungsschlüssel (DEK) geschützt werden. Zusätzlich wird dieser DEK durch einen separaten, sicher gespeicherten Verschlüsselungsschlüssel (KEK) geschützt.
So ermöglicht Amazon EKS die standardmäßige Umschlagverschlüsselung mit KMS v2 und AWS KMS
Amazon EKS nutzt KMS v2
Standardmäßig gehört dieser KEK AWS, Sie können jedoch optional Ihren eigenen von AWS KMS mitbringen.
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 ausschließlich 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. Bei AWS hat Sicherheit 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. Beim Startup ruft der API-Server das KMS-Plugin auf, um den DEK mit einem Fern-Verschlüsselungsschlüssel (KEK) aus 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. Anschließend verwendet der API-Server den zwischengespeicherten DEK-Seed, um andere einmalig verwendbare DEKs basierend auf einer Schlüsselableitungsfunktion (KDF) zu generieren. Jeder dieser generierten 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 AWS KMS-Integration zu überprüfen. Diese zusätzlichen Zustandsprüfungen sind in Ihrem AWS CloudTrail sichtbar.
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 von AWS verwalteten Kubernetes-API-Server hergestellt. 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 der Verwendung des CMK Ihres Clusters zugeordnet sind.
Wenn Ihr Cluster einen AWS-eigenen Schlüssel verwendet, wird dies in der EKS-Konsole detailliert aufgeführt (ohne die ARN des Schlüssels).
Kann AWS auf den AWS-eigenen Schlüssel zugreifen, der für die standardmäßige 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 können, die zur Sicherung von Daten in der etcd-Datenbank verwendet werden. Diese Sicherheitsmaßnahmen gelten auch für den AWS-eigenen KMS-Schlüssel.
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. Bei vorhandenen Clustern verwendet Amazon EKS die eks:kms-storage-migrator-BAC-ClusterRole, um Daten, die zuvor in etcd nicht mit Umschlagverschlüsselung verschlüsselt 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 regulären KMS-Preise
Wie hoch sind die Kosten für die Verwendung meines eigenen AWS-KMS-Schlüssels zur Verschlüsselung von Kubernetes-API-Daten in meinem Cluster?
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 eines Kontos. Die Kosten für die Verwendung Ihres eigenen AWS-KMS-Schlüssels in Ihrem Cluster werden also durch die Verwendung dieses Schlüssels in anderen Clustern oder AWS-Ressourcen innerhalb Ihres Kontos beeinflusst.
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 an AWS KMS gerichteten Aufrufe 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. Befindet sich der verschlüsselte DEK-Seed nicht im Cache des API-Servers, 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 für Entschlüsselungsanfragen AWS KMS für die erste Entschlüsselungsanfrage auf. Danach wird der entschlüsselte DEK-Seed zwischengespeichert und für zukünftige Entschlüsselungsvorgänge verwendet.
Weitere Informationen finden Sie unter KEP-3299: KMS-v2-Verbesserungen
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 fehlerhaften/beeinträchtigten Zustand versetzt. In diesem Fall können 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 deaktivierten/gelöschten CMK schützen?
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. Zusätzlich können Sie einen CloudWatch-Alarm einrichten, um über den Status Ihres CMK benachrichtigt 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 es aufgrund eines automatischen Kubernetes-Upgrades, das während eines fehlerhaften/beeinträchtigten Cluster-Zustands stattfinden kann, zu API-Änderungen kommt.
Warum befindet sich mein EKS-Cluster nach der Deaktivierung des CMK in einem fehlerhaften/beeinträchtigten Zustand?
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 Erstellungs-/Aktualisierungsvorgängen 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. Beim Neustart der API-Server-Instance ist jedoch kein zwischengespeicherter DEK vorhanden und für Verschlüsselungs- und Entschlüsselungsvorgänge muss AWS KMS aufgerufen werden. 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 zur Cluster-Integrität und zu Fehlercodes finden Sie unter Häufig gestellte Fragen zur Cluster-Integrität und Fehlercodes mit Lösungspfaden.
Werden mir weiterhin Kosten für einen beeinträchtigten/fehlerhaften EKS-Cluster in Rechnung gestellt, weil ich meinen CMK deaktiviert oder gelöscht habe?
Ja. Obwohl die EKS-Steuerebene im Falle eines deaktivierten CMK nicht verwendet werden kann, führt AWS weiterhin dedizierte Infrastrukturressourcen aus, die dem EKS-Cluster zugewiesen sind, bis dieser vom Kunden gelöscht wird. Darüber hinaus gilt unsere Serviceverpflichtung
Kann mein EKS-Cluster automatisch aktualisiert werden, wenn er sich aufgrund eines deaktivierten CMK in einem fehlerhaften/beeinträchtigten 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)
