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.
# Datenverschlüsselung und Verwaltung von Geheimnissen
## Verschlüsselung im Ruhezustand
[Es gibt drei verschiedene AWS-native Speicheroptionen, die Sie mit Kubernetes verwenden können: [EBS, [EFS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html) und for Lustre. FSx](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html) Alle drei bieten Verschlüsselung im Ruhezustand mithilfe eines vom Service verwalteten Schlüssels oder eines Customer-Hauptschlüssels (CMK). Für EBS können Sie den In-Tree-Speichertreiber oder den [EBS-CSI-Treiber](https://github.com/kubernetes-sigs/aws-ebs-csi-driver) verwenden. Beide enthalten Parameter für die Verschlüsselung von Volumes und die Bereitstellung eines CMK. Für EFS können Sie den [EFS-CSI-Treiber](https://github.com/kubernetes-sigs/aws-efs-csi-driver) verwenden. Im Gegensatz zu EBS unterstützt der EFS-CSI-Treiber jedoch kein dynamisches Provisioning. Wenn Sie EFS mit EKS verwenden möchten, müssen Sie die Verschlüsselung im Ruhezustand für das Dateisystem bereitstellen und konfigurieren, bevor Sie eine PV erstellen. Weitere Informationen zur EFS-Dateiverschlüsselung finden Sie unter [Daten im Ruhezustand verschlüsseln](https://docs.aws.amazon.com/efs/latest/ug/encryption-at-rest.html). EFS und FSx for Lustre bieten nicht nur Verschlüsselung im Ruhezustand, sondern bieten auch eine Option zur Verschlüsselung von Daten während der Übertragung. FSx for Lustre tut dies standardmäßig. Für EFS können Sie Transportverschlüsselung hinzufügen, indem Sie den `tls` Parameter zu `mountOptions` in Ihrem PV hinzufügen, wie in diesem Beispiel:
```
apiVersion: v1
kind: PersistentVolume
metadata:
name: efs-pv
spec:
capacity:
storage: 5Gi
volumeMode: Filesystem
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
storageClassName: efs-sc
mountOptions:
- tls
csi:
driver: efs.csi.aws.com
volumeHandle:
```
Der [FSx CSI-Treiber](https://github.com/kubernetes-sigs/aws-fsx-csi-driver) unterstützt die dynamische Bereitstellung von Lustre-Dateisystemen. Es verschlüsselt Daten standardmäßig mit einem vom Dienst verwalteten Schlüssel, es besteht jedoch die Möglichkeit, Ihr eigenes CMK bereitzustellen, wie in diesem Beispiel:
```
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: fsx-sc
provisioner: fsx.csi.aws.com
parameters:
subnetId: subnet-056da83524edbe641
securityGroupIds: sg-086f61ea73388fb6b
deploymentType: PERSISTENT_1
kmsKeyId:
```
**Wichtig**
Seit dem 28. Mai 2020 werden alle Daten, die auf das ephemere Volume in EKS Fargate-Pods geschrieben werden, standardmäßig mit einem branchenüblichen kryptografischen AES-256-Algorithmus verschlüsselt. Es sind keine Änderungen an Ihrer Anwendung erforderlich, da die Verschlüsselung und Entschlüsselung vom Service nahtlos übernommen werden.
### Verschlüsseln Sie Daten im Ruhezustand
Das Verschlüsseln von Daten im Ruhezustand wird als bewährte Methode angesehen. Wenn Sie sich nicht sicher sind, ob eine Verschlüsselung erforderlich ist, verschlüsseln Sie Ihre Daten.
### Rotieren Sie Ihre regelmäßig CMKs
Konfigurieren Sie KMS so, dass Ihr automatisch rotiert wird CMKs. Dadurch werden Ihre Schlüssel einmal im Jahr rotiert, während alte Schlüssel auf unbestimmte Zeit gespeichert werden, sodass Ihre Daten weiterhin entschlüsselt werden können. Weitere Informationen finden Sie unter [Rotieren von Kundenhauptschlüsseln](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html)
### Verwenden Sie EFS-Zugriffspunkte, um den Zugriff auf gemeinsam genutzte Datensätze zu vereinfachen
Wenn Sie gemeinsam genutzte Datensätze mit unterschiedlichen POSIX-Dateiberechtigungen haben oder den Zugriff auf einen Teil des gemeinsam genutzten Dateisystems einschränken möchten, indem Sie verschiedene Einhängepunkte erstellen, sollten Sie die Verwendung von EFS-Zugriffspunkten in Betracht ziehen. Weitere Informationen zum Arbeiten mit Access Points finden Sie unter https://docs.aws.amazon.com/efs/ latest/ug/efs -access-points.html. Wenn Sie heute einen Access Point (AP) verwenden möchten, müssen Sie den AP im `volumeHandle` PV-Parameter referenzieren.
**Wichtig**
Ab dem 23. März 2021 unterstützt der EFS-CSI-Treiber die dynamische Bereitstellung von EFS Access Points. Access Points sind anwendungsspezifische Einstiegspunkte in ein EFS-Dateisystem, die es einfacher machen, ein Dateisystem zwischen mehreren Pods gemeinsam zu nutzen. Jedes EFS-Dateisystem kann bis zu 120 haben PVs. Weitere Informationen finden Sie unter [Einführung in Amazon EFS CSI Dynamic Provisioning](https://aws.amazon.com/blogs/containers/introducing-efs-csi-dynamic-provisioning/).
## Verwaltung von Secrets
Kubernetes-Secrets werden verwendet, um vertrauliche Informationen wie Benutzerzertifikate, Passwörter oder API-Schlüssel zu speichern. Sie werden in etcd als Base64-kodierte Zeichenketten gespeichert. [Auf EKS sind die EBS-Volumes für etcd-Knoten mit EBS-Verschlüsselung verschlüsselt.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html) Ein Pod kann geheime Objekte von Kubernetes abrufen, indem er auf das Geheimnis in der verweist. `podSpec` Diese Geheimnisse können entweder einer Umgebungsvariablen zugeordnet oder als Volume bereitgestellt werden. Weitere Informationen zum Erstellen von Geheimnissen finden Sie unter https://kubernetes. io/docs/concepts/configuration/secret/.
**Warnung**
Auf Geheimnisse in einem bestimmten Namespace kann von allen Pods im Namespace des Geheimnisses verwiesen werden.
**Warnung**
Der Node Authorizer ermöglicht es dem Kubelet, alle auf dem Knoten montierten Geheimnisse zu lesen.
### Verwenden Sie AWS KMS für die Envelope-Verschlüsselung von Kubernetes-Geheimnissen
Auf diese Weise können Sie Ihre Geheimnisse mit einem eindeutigen Datenverschlüsselungsschlüssel (DEK) verschlüsseln. Das DEK wird dann mit einem Key Encryption Key (KEK) von AWS KMS verschlüsselt, der nach einem wiederkehrenden Zeitplan automatisch rotiert werden kann. Mit dem KMS-Plugin für Kubernetes werden alle Kubernetes-Geheimnisse in etcd im Chiffretext statt im Klartext gespeichert und können nur vom Kubernetes-API-Server entschlüsselt werden. [Weitere Informationen finden Sie unter Verwenden der Unterstützung von EKS-Verschlüsselungsanbietern für Verteidigungszwecke](https://aws.amazon.com/blogs/containers/using-eks-encryption-provider-support-for-defense-in-depth/)
### Prüfen Sie die Verwendung von Kubernetes Secrets
Aktivieren Sie in EKS die Auditprotokollierung und erstellen Sie einen CloudWatch Metrikfilter und einen Alarm, um Sie zu benachrichtigen, wenn ein Geheimnis verwendet wird (optional). Im Folgenden finden Sie ein Beispiel für einen Metrikfilter für das Kubernetes-Audit-Log. `{($.verb="get") && ($.objectRef.resource="secret")}` Sie können auch die folgenden Abfragen mit CloudWatch Log Insights verwenden:
```
fields @timestamp, @message
| sort @timestamp desc
| limit 100
| stats count(*) by objectRef.name as secret
| filter verb="get" and objectRef.resource="secrets"
```
Die obige Abfrage zeigt an, wie oft innerhalb eines bestimmten Zeitraums auf ein Geheimnis zugegriffen wurde.
```
fields @timestamp, @message
| sort @timestamp desc
| limit 100
| filter verb="get" and objectRef.resource="secrets"
| display objectRef.namespace, objectRef.name, user.username, responseStatus.code
```
Diese Abfrage zeigt das Geheimnis zusammen mit dem Namespace und dem Benutzernamen des Benutzers, der versucht hat, auf das Geheimnis zuzugreifen, sowie den Antwortcode an.
### Wechseln Sie Ihre Geheimnisse regelmäßig
Kubernetes rotiert Geheimnisse nicht automatisch. Wenn Sie geheime Daten rotieren müssen, sollten Sie die Verwendung eines externen geheimen Speichers in Betracht ziehen, z. B. Vault oder AWS Secrets Manager.
### Verwenden Sie separate Namespaces, um Geheimnisse aus verschiedenen Anwendungen zu isolieren
Wenn Sie über Geheimnisse verfügen, die nicht von Anwendungen in einem Namespace gemeinsam genutzt werden können, erstellen Sie einen separaten Namespace für diese Anwendungen.
### Verwenden Sie Volume-Mounts anstelle von Umgebungsvariablen
Die Werte von Umgebungsvariablen können unbeabsichtigt in Protokollen erscheinen. Als Volumes gemountete Geheimnisse werden als TMPFS-Volumes (ein RAM-gestütztes Dateisystem) instanziiert, die automatisch aus dem Knoten entfernt werden, wenn der Pod gelöscht wird.
### Verwenden Sie einen externen Geheimdienstanbieter
[Es gibt mehrere praktikable Alternativen zur Verwendung von Kubernetes-Secrets, darunter [AWS Secrets Manager](https://aws.amazon.com/secrets-manager/) und Hashicorp's Vault.](https://www.hashicorp.com/blog/injecting-vault-secrets-into-kubernetes-pods-via-a-sidecar/) Diese Services bieten Funktionen wie detaillierte Zugriffskontrollen, starke Verschlüsselung und automatische Rotation von Geheimnissen, die mit Kubernetes Secrets nicht verfügbar sind. Bitnamis [Sealed Secrets](https://github.com/bitnami-labs/sealed-secrets) ist ein weiterer Ansatz, der asymmetrische Verschlüsselung verwendet, um „versiegelte Geheimnisse“ zu erstellen. Ein öffentlicher Schlüssel wird verwendet, um das Geheimnis zu verschlüsseln, während der private Schlüssel, der zum Entschlüsseln des Geheimnisses verwendet wird, innerhalb des Clusters aufbewahrt wird, sodass Sie versiegelte Geheimnisse sicher in Quellcodeverwaltungssystemen wie Git speichern können. Weitere Informationen finden Sie unter [Verwaltung der Bereitstellung von Geheimnissen in Kubernetes mithilfe von Sealed Secrets](https://aws.amazon.com/blogs/opensource/managing-secrets-deployment-in-kubernetes-using-sealed-secrets/).
In dem Maße, wie die Verwendung externer Secret-Stores zugenommen hat, ist auch die Notwendigkeit gestiegen, sie in Kubernetes zu integrieren. Der [Secret Store CSI Driver](https://github.com/kubernetes-sigs/secrets-store-csi-driver) ist ein Community-Projekt, das das CSI-Treibermodell verwendet, um Geheimnisse aus externen geheimen Speichern abzurufen. Derzeit unterstützt der Treiber [AWS Secrets Manager](https://github.com/aws/secrets-store-csi-driver-provider-aws), Azure, Vault und GCP. Der AWS-Anbieter unterstützt sowohl AWS Secrets Manager als **auch** AWS Parameter Store. Es kann auch so konfiguriert werden, dass Secrets nach Ablauf rotiert werden und AWS Secrets Manager Manager-Geheimnisse mit Kubernetes Secrets synchronisiert werden. Die Synchronisation von Geheimnissen kann nützlich sein, wenn Sie auf ein Geheimnis als Umgebungsvariable verweisen müssen, anstatt es aus einem Volume zu lesen.
**Anmerkung**
Wenn der CSI-Treiber für den geheimen Speicher ein Geheimnis abrufen muss, übernimmt er die IRSA-Rolle, die dem Pod zugewiesen ist, der auf ein Geheimnis verweist. [Den Code für diesen Vorgang finden Sie hier.](https://github.com/aws/secrets-store-csi-driver-provider-aws/blob/main/auth/auth.go)
Weitere Informationen zum AWS Secrets & Configuration Provider (ASCP) finden Sie in den folgenden Ressourcen:
+ [So verwenden Sie den AWS Secrets Configuration Provider mit dem Kubernetes Secret Store CSI-Treiber](https://aws.amazon.com/blogs/security/how-to-use-aws-secrets-configuration-provider-with-kubernetes-secrets-store-csi-driver/)
+ [Integration von Secrets Manager Manager-Geheimnissen mit dem Kubernetes Secrets Store CSI-Treiber](https://docs.aws.amazon.com/secretsmanager/latest/userguide/integrating_csi_driver.html)
[external-secrets](https://github.com/external-secrets/external-secrets) ist eine weitere Möglichkeit, einen externen geheimen Speicher mit Kubernetes zu verwenden. Wie der CSI-Treiber funktioniert external-Secrets gegen eine Vielzahl verschiedener Backends, einschließlich AWS Secrets Manager. Der Unterschied besteht darin, dass external-secrets keine Geheimnisse aus dem externen Geheimspeicher abruft, sondern Geheimnisse aus diesen Backends als Secrets nach Kubernetes kopiert. Auf diese Weise können Sie Geheimnisse mithilfe Ihres bevorzugten geheimen Speichers verwalten und auf Kubernetes-native Weise mit Geheimnissen interagieren.
## Tools und Ressourcen
+ [Amazon EKS Security Immersion Workshop — Datenverschlüsselung und Geheimnismanagement](https://catalog.workshops.aws/eks-security-immersionday/en-US/13-data-encryption-and-secret-management)