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 a riposo

Esistono tre diverse opzioni di storage AWS native che puoi utilizzare con Kubernetes: EBS, EFS e for Lustre. FSx Tutti e tre offrono la crittografia di dati a riposo utilizzando una chiave gestita dal servizio o una chiave cliente principale (CMK). Per EBS puoi utilizzare il driver di storage in-tree o il driver EBS CSI. 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 desideri utilizzare EFS con EKS, dovrai fornire e configurare la crittografia a riposo 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 at-rest, EFS e FSx for Lustre includono un'opzione per crittografare i dati in transito. FSx for Lustre lo fa per impostazione predefinita. Per EFS, puoi aggiungere la crittografia di 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 disponibile un'opzione per 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 il CMKs

Configura KMS per ruotare automaticamente il tuo. CMKs In questo modo le chiavi verranno ruotate una volta all'anno, salvando quelle vecchie a tempo indeterminato, in modo che i dati possano ancora essere decifrati. Per ulteriori informazioni, consulta Rotazione delle chiavi master del cliente.

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

Se disponi di set di dati condivisi con permessi di file POSIX diversi o desideri limitare l'accesso a parte del file system condiviso creando punti di montaggio diversi, prendi in considerazione l'utilizzo di punti di accesso EFS. Per ulteriori informazioni sull'utilizzo dei punti di accesso, consulta -access-points.html. https://docs.aws.amazon.com/efs/ latest/ug/efs Oggi, se si desidera utilizzare un punto di accesso (AP), è necessario fare riferimento all'AP nel volumeHandle parametro del PV.

Gestione dei segreti

I segreti di Kubernetes vengono utilizzati per archiviare informazioni sensibili, come certificati utente, password o chiavi API. Vengono mantenute in etcd come stringhe codificate in base64. Su EKS, i volumi EBS per i nodi etcd sono crittografati con la crittografia EBS. Un pod può recuperare un oggetto segreto di Kubernetes facendo riferimento al segreto in. 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ò ti consente di crittografare i tuoi segreti con una chiave di crittografia dei dati unica (DEK). Il DEK viene quindi crittografato utilizzando una chiave di crittografia (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 semplice e possono essere decrittografati solo dal server API Kubernetes. Per ulteriori dettagli, consulta Utilizzo del supporto del provider di crittografia EKS per una difesa approfondita

Verifica l'uso di Kubernetes Secrets

Su EKS, attiva la registrazione degli audit 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 registro 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 entro un periodo di tempo specifico.

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

Utilizzate i montaggi di volume 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 basato su RAM) che vengono rimossi automaticamente dal nodo quando il pod viene eliminato.

Utilizza un provider di segreti esterno

Esistono diverse alternative valide all'utilizzo dei segreti di Kubernetes, tra cui AWS Secrets Manager e Hashicorp's Vault. Questi servizi offrono funzionalità come controlli granulari degli accessi, 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, consentendoti di archiviare in modo sicuro i segreti sigillati in sistemi di controllo del codice sorgente come Git. Per ulteriori informazioni, consulta Gestione della 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. Secret Store CSI Driver è un progetto comunitario che utilizza il modello di driver CSI per recuperare 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 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 anziché leggerlo da un volume.

Per ulteriori informazioni su AWS Secrets & Configuration Provider (ASCP), fai riferimento alle 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, anziché recuperare i segreti dall'archivio segreto esterno, external-secrets copia i segreti da questi backend su Kubernetes come segreti. Ciò ti consente di gestire i segreti utilizzando il tuo archivio segreto preferito e di interagire con i segreti in modo nativo di Kubernetes.

Strumenti e risorse