Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Crittografia dei dati e gestione dei segreti

Crittografia dei dati a riposo

Esistono tre diverse opzioni AWS-native di archiviazione che puoi utilizzare con Kubernetes: EBS , EFS e FSx for Lustre. Tutti e tre offrono la crittografia di dati a riposo utilizzando una chiave gestita dal servizio o una chiave cliente principale (CMK). Per EBS è possibile utilizzare il driver di archiviazione integrato nell'albero o il driver EBS CSI. https://github.com/kubernetes-sigs/aws-ebs-csi-driver Entrambi includono parametri per la crittografia dei volumi e la fornitura di un CMK. Per EFS, è possibile utilizzare il driver EFS CSI, tuttavia, a differenza di EBS, il driver EFS CSI non supporta il provisioning dinamico. Se si desidera utilizzare EFS con EKS, è necessario eseguire il provisioning e configurare la crittografia at-rest per il file system prima di creare un PV. Per ulteriori informazioni sulla crittografia dei file EFS, consulta Encrypting Data at Rest. Oltre a offrire la crittografia a riposo, EFS e FSx for Lustre includono un'opzione per crittografare i dati in transito. FSx for Lustre esegue questa operazione per impostazione predefinita. Per EFS, puoi aggiungere la crittografia del trasporto aggiungendo il tls parametro a mountOptions nel tuo PV come in questo esempio:

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>

Il driver FSx CSI supporta il provisioning dinamico dei file system Lustre. Per impostazione predefinita, crittografa i dati con una chiave gestita dal servizio, sebbene sia possibile fornire la propria CMK come in questo esempio:

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>

Crittografa i dati inattivi

La crittografia dei dati inattivi è considerata una best practice. Se non sei sicuro che la crittografia sia necessaria, crittografa i tuoi dati.

Ruota periodicamente i tuoi CMK

Configura KMS per ruotare automaticamente i tuoi CMK. In questo modo le tue chiavi verranno ruotate una volta all'anno e le vecchie chiavi verranno salvate a tempo indeterminato in modo che i dati possano ancora essere decrittografati. Per ulteriori informazioni, consulta Rotating customer master keys https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html

Usa i punti di accesso EFS per semplificare l'accesso ai set di dati condivisi

Se disponi di set di dati condivisi con autorizzazioni di file POSIX diverse o desideri limitare l'accesso a una parte del file system condiviso creando diversi punti di montaggio, prendi in considerazione l'utilizzo dei punti di accesso EFS. Per saperne di più sull'utilizzo degli access point, vedi https://docs.aws.amazon.com/efs/latest/ug/efs-access-points.html. Today, se vuoi usare un access point (AP) dovrai fare riferimento all'AP nel parametro del PV. volumeHandle

Gestione dei segreti

I segreti di Kubernetes vengono utilizzati per archiviare informazioni sensibili, come certificati utente, password o chiavi API. Sono mantenuti in etcd come stringhe codificate in base 64. Su EKS, i volumi EBS per i nodi etcd sono crittografati con crittografia EBS. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html Un pod può recuperare gli oggetti segreti di Kubernetes facendo riferimento al segreto nel. podSpec Questi segreti possono essere mappati su una variabile di ambiente o montati come volume. Per ulteriori informazioni sulla creazione di segreti, vedere https://kubernetes.io/docs/concepts/configuration/secret/.

Usa AWS KMS per la crittografia in busta dei segreti di Kubernetes

Ciò consente di crittografare i tuoi segreti con una chiave di crittografia dei dati (DEK) univoca. Il DEK viene quindi crittografato utilizzando una chiave di crittografia a chiave (KEK) di AWS KMS che può essere ruotata automaticamente in base a una pianificazione ricorrente. Con il plug-in KMS per Kubernetes, tutti i segreti di Kubernetes vengono archiviati in etcd in testo cifrato anziché in testo normale e possono essere decrittografati solo dal server API Kubernetes. Per ulteriori dettagli, consulta la sezione Utilizzo del provider di crittografia EKS support for defense in depth

Verifica l'uso di Kubernetes Secrets

Su EKS, attiva la registrazione di controllo e crea un filtro CloudWatch metrico e un allarme per avvisarti quando viene utilizzato un segreto (opzionale). Di seguito è riportato un esempio di filtro metrico per il log di controllo di Kubernetes,. {($.verb="get") && ($.objectRef.resource="secret")} Puoi anche utilizzare le seguenti query con Log Insights: CloudWatch

fields @timestamp, @message
| sort @timestamp desc
| limit 100
| stats count(*) by objectRef.name as secret
| filter verb="get" and objectRef.resource="secrets"

La query precedente mostrerà il numero di volte in cui è stato effettuato l'accesso a un segreto in un determinato periodo di tempo.

fields @timestamp, @message
| sort @timestamp desc
| limit 100
| filter verb="get" and objectRef.resource="secrets"
| display objectRef.namespace, objectRef.name, user.username, responseStatus.code

Questa query mostrerà il segreto, insieme allo spazio dei nomi e al nome utente dell'utente che ha tentato di accedere al segreto e al codice di risposta.

Ruota periodicamente i tuoi segreti

Kubernetes non ruota automaticamente i segreti. Se devi ruotare i segreti, prendi in considerazione l'utilizzo di un archivio segreto esterno, ad esempio Vault o AWS Secrets Manager.

Usa namespace separati per isolare i segreti di diverse applicazioni

Se disponi di segreti che non possono essere condivisi tra le applicazioni in uno spazio dei nomi, crea uno spazio dei nomi separato per tali applicazioni.

Usa i montaggi dei volumi anziché le variabili di ambiente

I valori delle variabili di ambiente possono apparire involontariamente nei log. I segreti montati come volumi vengono istanziati come volumi tmpfs (un file system supportato da RAM) che vengono rimossi automaticamente dal nodo quando il pod viene eliminato.

Utilizza un provider di segreti esterno

Esistono diverse valide alternative all'utilizzo dei segreti di Kubernetes, tra cui AWS Secrets Manager e Hashicorp's Vault. https://www.hashicorp.com/blog/injecting-vault-secrets-into-kubernetes-pods-via-a-sidecar/ Questi servizi offrono funzionalità come controlli di accesso granulari, crittografia avanzata e rotazione automatica dei segreti che non sono disponibili con Kubernetes Secrets. Sealed Secrets di Bitnami è un altro approccio che utilizza la crittografia asimmetrica per creare «segreti sigillati». Una chiave pubblica viene utilizzata per crittografare il segreto mentre la chiave privata utilizzata per decrittografare il segreto viene conservata all'interno del cluster, consentendo di archiviare in modo sicuro i segreti sigillati in sistemi di controllo del codice sorgente come Git. Per ulteriori informazioni, consulta Gestire la distribuzione dei segreti in Kubernetes utilizzando Sealed Secrets.

Con l'aumento dell'uso di archivi segreti esterni, è cresciuta anche la necessità di integrarli con Kubernetes. The Secret Store CSI Driver è un progetto comunitario che utilizza il modello di driver CSI per recuperare i segreti da archivi segreti esterni. Attualmente, il driver supporta AWS Secrets Manager, Azure, Vault e GCP. Il provider AWS supporta sia AWS Secrets Manager che AWS Parameter Store. Può anche essere configurato per ruotare i segreti quando scadono e può sincronizzare i segreti di AWS Secrets Manager con Kubernetes Secrets. La sincronizzazione dei segreti può essere utile quando è necessario fare riferimento a un segreto come variabile di ambiente invece di leggerlo da un volume.

Per ulteriori informazioni su AWS Secrets & Configuration Provider (ASCP), consulta le seguenti risorse:

external-secrets è un altro modo per utilizzare un archivio segreto esterno con Kubernetes. Come il driver CSI, external-secrets funziona su una varietà di backend diversi, incluso AWS Secrets Manager. La differenza è che, invece di recuperare i segreti dall'archivio segreto esterno, external-secrets copia i segreti da questi backend a Kubernetes come Secrets. Ciò ti consente di gestire i segreti utilizzando il tuo archivio segreto preferito e di interagire con i segreti in un certo senso. Kubernetes-native

Strumenti e risorse