Best practice di crittografia per Amazon EKS - AWS Guida prescrittiva

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

Best practice di crittografia per Amazon EKS

Amazon Elastic Kubernetes Service (Amazon EKS) ti aiuta a eseguire AWS Kubernetes senza dover installare o gestire il tuo piano di controllo o i tuoi nodi Kubernetes. In Kubernetes, i segreti ti aiutano a gestire informazioni sensibili come certificati utente, password o chiavi API. Per impostazione predefinita, questi segreti vengono archiviati in modo non crittografato nell'archivio dati sottostante del server API, denominato etcd. Su Amazon EKS, i volumi Amazon Elastic Block Store (Amazon EBS) etcd per i nodi sono crittografati con la crittografia Amazon EBS. Qualsiasi utente con accesso all'API o accesso a etcd può recuperare o modificare un segreto. Inoltre, chiunque sia autorizzato a creare un pod in uno spazio dei nomi può utilizzare tale accesso per leggere qualsiasi segreto in quello spazio dei nomi. Puoi crittografare questi segreti inattivi in Amazon EKS utilizzando AWS KMS keys chiavi gestite o chiavi AWS gestite dal cliente. Un approccio alternativo all'utilizzo etcd consiste nell'utilizzare AWS Secrets and Config Provider (ASCP) (GitHub repository). ASCP si integra con IAM e con le policy basate sulle risorse per limitare l'accesso ai segreti solo all'interno di specifici pod Kubernetes all'interno di un cluster.

Puoi utilizzare i seguenti servizi di AWS archiviazione con Kubernetes:

  • Per Amazon EBS, puoi utilizzare il driver di storage in-tree o il driver Amazon EBS CSI. Entrambi includono parametri per la crittografia dei volumi e la fornitura di una chiave gestita dal cliente.

  • Per Amazon Elastic File System (Amazon EFS) è possibile utilizzare il driver CSI per Amazon EFS con supporto per il provisioning dinamico e statico.

Prendi in considerazione le seguenti best practice di crittografia per questo servizio:

  • Se utilizzi etcd, che archivia oggetti segreti non crittografati per impostazione predefinita, procedi come segue per proteggere i segreti:

    • Crittografia di dati a riposo del segreto (documentazione Kubernetes).

    • Utilizzalo AWS KMS per la crittografia su busta dei segreti di Kubernetes. Ciò ti consente di crittografare i tuoi segreti con una chiave dati unica. È possibile utilizzare una AWS KMS chiave di crittografia per crittografare la chiave dati. È possibile ruotare automaticamente la chiave di crittografia della chiave in base a una pianificazione ricorrente. Con il AWS KMS plug-in per Kubernetes, tutti i segreti di Kubernetes vengono archiviati in testo cifrato. etcd Possono essere decrittografati solo dal server API Kubernetes. Per ulteriori informazioni, consulta Utilizzo del supporto del provider di crittografia Amazon EKS per una difesa approfondita e Crittografia dei segreti di Kubernetes sui cluster esistenti. AWS KMS

    • Abilita o configura l'autorizzazione tramite regole di controllo degli accessi basata su ruoli (RBAC) che limitano la lettura e la scrittura del segreto. Limita le autorizzazioni per creare nuovi segreti o sostituire quelli esistenti. Per ulteriori informazioni, consulta la sezione Panoramica dell'autorizzazione (documentazione di Kubernetes).

    • Se stai definendo più container in un pod e solo uno di questi container deve accedere a un segreto, definisci il montaggio del volume in modo che gli altri container non abbiano accesso a quel segreto. I segreti montati come volumi vengono istanziati come volumi tmpfs e vengono rimossi automaticamente dal nodo quando il pod viene eliminato. Puoi anche usare variabili di ambiente, ma ti sconsigliamo questo approccio perché i valori delle variabili di ambiente possono apparire nei log. Per ulteriori informazioni, consulta la sezione Segreti (documentazione di Kubernetes).

    • Quando possibile, evita di concedere l'accesso alle richieste watch e list di segreti all'interno di uno spazio dei nomi. Nell'API Kubernetes, queste richieste sono potenti perché consentono al client di ispezionare i valori di ogni segreto in quello spazio dei nomi.

    • Consenti l'accesso a etcd solo agli amministratori del cluster, incluso l'accesso in sola lettura.

    • In caso di più istanze etcd, assicurati che etcd utilizzi TLS per la comunicazione tra peer etcd.

  • Se utilizzi ASCP, procedi come segue per proteggere i segreti:

  • Per contribuire a mitigare il rischio di fughe di dati dalle variabili di ambiente, ti consigliamo di utilizzare il driver CSI and AWS Secrets Manager Config Provider for Secret Store (). GitHub Questo driver consente di fare in modo che i segreti archiviati in Secrets Manager e i parametri archiviati in Parameter Store vengano visualizzati come file montati nei pod Kubernetes.

    Nota

    AWS Fargate non è supportato.

  • Crea un filtro e un allarme Amazon CloudWatch Metrics per inviare avvisi per operazioni specificate dall'amministratore, come l'eliminazione segreta o l'uso di una versione segreta nel periodo di attesa per l'eliminazione. Per ulteriori informazioni, consulta la sezione Creazione di un allarme basato sul rilevamento di anomalie.