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 geheimer Daten
## Verschlüsselung im Ruhezustand
Es gibt drei verschiedene AWS-native Speicheroptionen, die Sie mit Kubernetes verwenden können: [ EBS ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html)[, ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html) EFS und [ FSx for Lustre. ](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 Kunden-Masterschlüssels (CMK). Für EBS können Sie den In-Tree-Speichertreiber oder den [ EBS-CSI-Treiber verwenden. ](https://github.com/kubernetes-sigs/aws-ebs-csi-driver) 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 keine dynamische Bereitstellung. 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 [ Verschlüsseln von Daten im Ruhezustand. ](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 zum Verschlüsseln von Daten während der Übertragung. FSx for Lustre tut dies standardmäßig. Für EFS können Sie eine Transportverschlüsselung hinzufügen, indem Sie den `tls` Parameter wie `mountOptions` in diesem Beispiel zu Ihrem PV hinzufügen:
```
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. Er verschlüsselt Daten standardmäßig mit einem dienstverwalteten Schlüssel, obwohl es eine Option gibt, Ihren eigenen 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 in den EKS Fargate-Pods auf das ephemere Volume geschrieben werden, standardmäßig mit einem branchenüblichen kryptografischen Algorithmus verschlüsselt. AES-256 Es sind keine Änderungen an Ihrer Anwendung erforderlich, da die Verschlüsselung und Entschlüsselung vom Dienst nahtlos abgewickelt 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 CMKs regelmäßig
Konfigurieren Sie KMS so, dass Ihre CMKs automatisch rotieren. 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 [ Rotation von Kunden-Masterschlü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. Heute. Wenn Sie einen Access Point (AP) verwenden möchten, müssen Sie im PV-Parameter auf den AP verweisen. `volumeHandle`
**Wichtig**
Seit 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 PVs haben. Weitere Informationen finden Sie unter [ Einführung der dynamischen Bereitstellung ](https://aws.amazon.com/blogs/containers/introducing-efs-csi-dynamic-provisioning/) von Amazon EFS CSI.
## Verwaltung von Secrets
Kubernetes-Geheimnisse 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 werden die EBS-Volumes für etcd-Knoten mit EBS-Verschlüsselung verschlüsselt. [https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html) Ein Pod kann geheime Kubernetes-Objekte abrufen, indem er auf das Geheimnis in der verweist. `podSpec` Diese Geheimnisse können entweder einer Umgebungsvariablen zugeordnet oder als Volume gemountet werden. Weitere Informationen zum Erstellen von Geheimnissen finden Sie unter https://kubernetes.io/docs/concepts/configuration/secret/.
**Warnung**
Auf Geheimnisse in einem bestimmten Namespace können alle Pods im Namespace des Secrets verweisen.
**Warnung**
Der Node Authorizer ermöglicht es dem Kubelet, alle auf dem Knoten gemounteten Geheimnisse zu lesen.
### Verwenden Sie AWS KMS für die Umschlagverschlü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 Schlüsselverschlüsselungsschlüssel (KEK) von AWS KMS verschlüsselt, der automatisch nach einem wiederkehrenden Zeitplan 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 des EKS-Verschlüsselungsanbieters für eine gründliche Verteidigung [https://aws.amazon.com/blogs/containers/using-eks-encryption-provider-support-for-defense-in-depth/](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, der Sie warnt, wenn ein geheimes Passwort 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, und dem Antwortcode an.
### Rotieren Sie Ihre Geheimnisse regelmäßig
Kubernetes rotiert Secrets nicht automatisch. Wenn Sie Geheimnisse rotieren müssen, sollten Sie erwägen, einen externen Geheimspeicher zu verwenden, z. B. Vault oder AWS Secrets Manager.
### Verwenden Sie separate Namespaces, um Geheimnisse aus verschiedenen Anwendungen zu isolieren
Wenn Sie Geheimnisse haben, 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 beim Löschen des Pods automatisch vom Knoten entfernt werden.
### Verwenden Sie einen externen Geheimdienstanbieter
Es gibt mehrere praktikable Alternativen zur Verwendung von Kubernetes-Geheimnissen, 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/](https://www.hashicorp.com/blog/injecting-vault-secrets-into-kubernetes-pods-via-a-sidecar/) Diese Dienste bieten Funktionen wie fein abgestimmte Zugriffskontrollen, starke Verschlüsselung und automatische Rotation von Geheimnissen, die bei Kubernetes Secrets nicht verfügbar sind. [Sealed Secrets von Bitnami ](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 zur Entschlüsselung 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 geheimer Geheimnisse in Kubernetes mithilfe von Sealed Secrets](https://aws.amazon.com/blogs/opensource/managing-secrets-deployment-in-kubernetes-using-sealed-secrets/).
Da die Verwendung von externen Secrets Stores zugenommen hat, ist auch der Bedarf an deren Integration in Kubernetes gestiegen. 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 Geheimspeichern 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. Er kann auch so konfiguriert werden, dass Secrets rotiert werden, wenn sie ablaufen, und dass AWS Secrets Manager-Geheimnisse mit Kubernetes Secrets synchronisiert werden können. Die Synchronisation von Geheimnissen kann nützlich sein, wenn Sie ein Geheimnis als Umgebungsvariable referenzieren müssen, anstatt es von 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/credential_provider/)
Weitere Informationen zum AWS Secrets & Configuration Provider (ASCP) finden Sie in den folgenden Ressourcen:
+ [Wie verwende ich 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-Geheimnissen in den 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 Secret Store mit Kubernetes zu verwenden. Wie der CSI-Treiber funktioniert external-secrets mit einer Vielzahl verschiedener Backends, einschließlich AWS Secrets Manager. Der Unterschied besteht darin, dass external-Secrets Geheimnisse von diesen Backends als Secrets als Secrets nach Kubernetes kopiert, anstatt Secrets aus dem externen Secret Store abzurufen. Auf diese Weise können Sie Secrets mithilfe Ihres bevorzugten Secret Stores verwalten und auf eine bestimmte Weise mit Geheimnissen interagieren. Kubernetes-native
## Tools und Ressourcen
+ [Amazon EKS Security Immersion Workshop — Datenverschlüsselung und Geheimnisverwaltung ](https://catalog.workshops.aws/eks-security-immersionday/en-US/13-data-encryption-and-secret-management)