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 , EFS und FSx for Lustre. 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. 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 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. 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: <file_system_id>

Der FSx CSI-Treiber 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: <kms_arn>

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

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

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

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/

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 und Hashicorp's Vault. 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 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.

Da die Verwendung von externen Secrets Stores zugenommen hat, ist auch der Bedarf an deren Integration in Kubernetes gestiegen. Der Secret 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, 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.

Weitere Informationen zum AWS Secrets & Configuration Provider (ASCP) finden Sie in den folgenden Ressourcen:

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