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 und for Lustre. FSx 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-Treibertls
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: <file_system_id>
Der FSx CSI-Treiber
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>
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.
Wechseln 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
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
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. 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 können alle Pods im Namespace des Geheimnisses verweisen.
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
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
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
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.
Weitere Informationen zum AWS Secrets & Configuration Provider (ASCP) finden Sie in den folgenden Ressourcen:
external-secrets