Correzione degli esiti del monitoraggio dei log di audit EKS

Amazon GuardDuty genera risultati che indicano potenziali problemi di sicurezza di Kubernetes quando EKS Audit Log Monitoring è abilitato per il tuo account. Per ulteriori informazioni, consulta Monitoraggio dei log di audit EKS. Le sezioni seguenti descrivono le operazioni di correzione consigliate per questi scenari. Le operazioni correttive sono descritte nella voce relativa al tipo di esito specifico. Puoi accedere alle informazioni complete su un tipo di esito selezionandolo dalla tabella relativa ai tipi di esiti attivi.

Se uno qualsiasi dei tipi di esiti del monitoraggio dei log di audit EKS è stato generato per un'attività prevista, puoi prendere in considerazione l'aggiunta di Regole di eliminazione per evitare di ricevere avvisi in futuro.

Diversi tipi di attacchi e problemi di configurazione possono innescare GuardDuty i risultati di Kubernetes. Questa guida ti aiuta a identificare le cause principali delle GuardDuty rilevazioni relative al cluster e delinea le linee guida appropriate per la correzione. Le seguenti sono le cause principali che hanno portato ai risultati di GuardDuty Kubernetes:

• Potenziali problemi di configurazione

• Riparare gli utenti Kubernetes potenzialmente compromessi

• Riparazione dei pod Kubernetes potenzialmente compromessi

• Riparazione dei nodi Kubernetes potenzialmente compromessi

• Riparazione delle immagini dei container potenzialmente compromesse

Nota

Prima della versione 1.14 di Kubernetes, il system:unauthenticated gruppo era associato a e per impostazione predefinita. system:discovery system:basic-user ClusterRoles Ciò potrebbe consentire l'accesso non intenzionale a utenti anonimi. Gli aggiornamenti del cluster non revocano le autorizzazioni, quindi potrebbero essere ancora valide anche se hai aggiornato il cluster alla versione 1.14 o successiva. Ti consigliamo di disassociare queste autorizzazioni dal gruppo system:unauthenticated.

Per ulteriori informazioni sulla rimozione di queste autorizzazioni, consulta le best practice di sicurezza per Amazon EKS nella Amazon EKS User Guide.

Potenziali problemi di configurazione

Se un esito indica un problema di configurazione, consulta la sezione sulla correzione di tale esito per indicazioni su come risolvere il problema. Per ulteriori informazioni, consulta i seguenti tipi di esiti che indicano problemi di configurazione:

• Policy:Kubernetes/AnonymousAccessGranted

• Policy:Kubernetes/ExposedDashboard

• Policy:Kubernetes/AdminAccessToDefaultServiceAccount

• Policy:Kubernetes/KubeflowDashboardExposed

• Qualsiasi scoperta che finisce con SuccessfulAnonymousAccess

Riparare gli utenti Kubernetes potenzialmente compromessi

Un GuardDuty risultato può indicare un utente Kubernetes compromesso quando un utente identificato nel risultato ha eseguito un'azione API inaspettata. Puoi identificare l'utente nella sezione Dettagli utente Kubernetes dei dettagli di un esito nella console o nei resources.eksClusterDetails.kubernetesDetails.kubernetesUserDetails del file JSON degli esiti. Questi dettagli utente includono user name, uid e i gruppi Kubernetes a cui appartiene l'utente.

Se l'utente accedeva al carico di lavoro utilizzando un'entità IAM, puoi utilizzare la sezione Access Key details per identificare i dettagli di un ruolo o di un utente IAM. Consulta i seguenti tipi di utente e le linee guida per la correzione.

Nota

Puoi utilizzare Amazon Detective per esaminare ulteriormente il ruolo o l'utente IAM identificato nell'esito. Mentre visualizzi i dettagli del ritrovamento GuardDuty sulla console, scegli Investiga in Detective. Quindi seleziona AWS l'utente o il ruolo dagli elementi elencati per esaminarlo in Detective.

Amministratore Kubernetes integrato: l'utente predefinito assegnato da Amazon EKS all'identità IAM che ha creato il cluster. Questo tipo di utente è identificato dal nome utente kubernetes-admin.

Per revocare l'accesso a un amministratore Kubernetes integrato:

• Identifica il userType nella sezione Access Key details.

  • Se il userType è un Ruolo e il ruolo appartiene a un ruolo dell'istanza EC2:

    • Identifica l'istanza e segui le istruzioni riportate in Correzione di un'istanza Amazon EC2 potenzialmente compromessa.

  • Se il userType è un Utente o un Ruolo assunto da un utente:

    1. Ruota la chiave di accesso dell'utente.

    2. Ruota tutti i segreti a cui l'utente ha avuto accesso.

    3. Controlla le informazioni in Il mio AWS account potrebbe essere compromesso per ulteriori dettagli.

Utente autenticato OIDC: un utente a cui è stato concesso l'accesso tramite un provider OIDC. In genere un utente OIDC ha un indirizzo e-mail come nome utente. Puoi verificare se il cluster utilizza OIDC con il comando seguente: aws eks list-identity-provider-configs --cluster-name your-cluster-name

Per revocare l'accesso a un utente autenticato OIDC:

1. Ruota le credenziali dell'utente nel provider OIDC.

2. Ruota tutti i segreti a cui l'utente ha avuto accesso.

AWS-Auth ConfigMap defined user: un utente IAM a cui è stato concesso l'accesso tramite un -auth. AWSConfigMap Per maggiori informazioni, consulta Gestione di utenti o ruoli IAM per il cluster nella guida per l'utente &EKS. Puoi esaminarne le autorizzazioni utilizzando il comando seguente: kubectl edit configmaps aws-auth --namespace kube-system

Per revocare l'accesso di un utente: AWS ConfigMap

1. Utilizzate il seguente comando per aprire. ConfigMap

   kubectl edit configmaps aws-auth --namespace kube-system

2. Identifica il ruolo o la voce utente nella sezione MapRoles o MapUsers con lo stesso nome utente riportato nella sezione dei dettagli utente di Kubernetes del tuo risultato. GuardDuty Consulta l'esempio seguente, in cui l'utente amministratore è stato identificato in un esito.

   apiVersion: v1
   data:
     mapRoles: |
       - rolearn: arn:aws:iam::444455556666:role/eksctl-my-cluster-nodegroup-standard-wo-NodeInstanceRole-1WP3NUE3O6UCF
         user name: system:node:EC2_PrivateDNSName
         groups:
           - system:bootstrappers
           - system:nodes
     mapUsers: |
       - userarn: arn:aws:iam::123456789012:user/admin
         username: admin
         groups:
           - system:masters
       - userarn: arn:aws:iam::111122223333:user/ops-user
         username: ops-user
         groups:
           - system:masters

3. Rimuovi quell'utente da. ConfigMap Consulta l'esempio seguente, in cui l'utente amministratore è stato rimosso.

   apiVersion: v1
   data:
     mapRoles: |
       - rolearn: arn:aws:iam::111122223333:role/eksctl-my-cluster-nodegroup-standard-wo-NodeInstanceRole-1WP3NUE3O6UCF
         username: system:node:{{EC2PrivateDNSName}}
         groups:
           - system:bootstrappers
           - system:nodes
     mapUsers: |
       - userarn: arn:aws:iam::111122223333:user/ops-user
         username: ops-user
         groups:
           - system:masters

4. Se il userType è un Utente o un Ruolo assunto da un utente:

   1. Ruota la chiave di accesso dell'utente.

   2. Ruota tutti i segreti a cui l'utente ha avuto accesso.

   3. Controlla le informazioni in Il mio AWS account potrebbe essere compromesso per ulteriori dettagli.

Se l'esito non ha una sezione resource.accessKeyDetails, l'utente è un account di servizio Kubernetes.

Account di servizio: l'account di servizio fornisce un'identità per i pod e può essere identificato da un nome utente con il formato seguente: system:serviceaccount:namespace:service_account_name.

Per revocare l'accesso a un account di servizio:

1. Ruota le credenziali dell'account di servizio.

2. Consulta le linee guida sulla compromissione dei pod nella sezione seguente.

Riparazione dei pod Kubernetes potenzialmente compromessi

Quando si GuardDuty specificano i dettagli di un pod o di una risorsa di carico di lavoro all'interno della resource.kubernetesDetails.kubernetesWorkloadDetails sezione, quel pod o risorsa del carico di lavoro è stato potenzialmente compromesso. Un GuardDuty risultato può indicare che un singolo pod è stato compromesso o che più pod sono stati compromessi a causa di una risorsa di livello superiore. Consulta i seguenti scenari di compromissione per indicazioni su come identificare il pod o i pod che sono stati compromessi.

Compromissione di pod singoli

Se il campo type all'interno della sezione resource.kubernetesDetails.kubernetesWorkloadDetails è pod, l'esito identifica un singolo pod. Il campo nome è il name del pod e il campo namespace è il relativo spazio del nome.

Per informazioni sull'identificazione del nodo di lavoro che esegue i pod, consulta Identificare i pod e il nodo di lavoro in questione.

Pod compromessi tramite una risorsa del carico di lavoro

Se il campo type all'interno della sezione resource.kubernetesDetails.kubernetesWorkloadDetails identifica una Risorsa del carico di lavoro, ad esempio un'Deployment, è probabile che tutti i pod all'interno della risorsa del carico di lavoro siano stati compromessi.

Per informazioni sull'identificazione di tutti i pod della risorsa del carico di lavoro e dei nodi su cui sono in esecuzione, consulta Identificare i pod e i nodi di lavoro pericolosi utilizzando il nome del carico di lavoro.

I pod sono stati compromessi tramite un account di servizio

Se un GuardDuty risultato identifica un account di servizio nella resource.kubernetesDetails.kubernetesUserDetails sezione, è probabile che i pod che utilizzano l'account di servizio identificato siano compromessi. Il nome utente riportato da un esito è un account di servizio se ha il formato seguente: system:serviceaccount:namespace:service_account_name.

Per informazioni sull'identificazione di tutti i pod e i nodi di lavoro che utilizzano l'account di servizio e i nodi su cui sono in esecuzione, consulta Identificare i pod e i nodi di lavoro pericolosi utilizzando il nome dell'account di servizio.

Dopo aver identificato tutti i pod compromessi e i nodi su cui sono in esecuzione, consulta la guida alle best practice di Amazon EKS per isolare il pod, ruotarne le credenziali e raccogliere dati per l'analisi forense.

Per riparare un pod potenzialmente compromesso:

1. Identifica la vulnerabilità che ha compromesso i pod.

2. Implementa la correzione di tale vulnerabilità e avvia nuovi pod sostitutivi.

3. Eliminare i pod vulnerabili.

   Per ulteriori informazioni, consulta Ridistribuire il pod o la risorsa del carico di lavoro compromessa.

Se al nodo di lavoro è stato assegnato un ruolo IAM che consente ai Pods di accedere ad altre AWS risorse, rimuovi tali ruoli dall'istanza per evitare ulteriori danni causati dall'attacco. Allo stesso modo, se al pod è stato assegnato un ruolo IAM, valuta se puoi rimuovere in sicurezza le policy IAM dal ruolo senza influire sugli altri carichi di lavoro.

Riparazione delle immagini dei container potenzialmente compromesse

Quando un GuardDuty risultato indica una compromissione del pod, l'immagine utilizzata per avviare il pod potrebbe essere potenzialmente dannosa o compromessa. GuardDuty i risultati identificano l'immagine del contenitore all'interno del resource.kubernetesDetails.kubernetesWorkloadDetails.containers.image campo. Puoi determinare se l'immagine è dannosa scansionandola alla ricerca di malware.

Per correggere un'immagine del contenitore potenzialmente compromessa:

1. Interrompi immediatamente l'utilizzo dell'immagine e rimuovila dal tuo repository di immagini.

2. Identifica tutti i pod utilizzando l'immagine potenzialmente compromessa.

   Per ulteriori informazioni, consulta Identificare i pod con immagini di container e nodi di lavoro potenzialmente vulnerabili o compromessi.

3. Isola i pod potenzialmente compromessi, ruota le credenziali e raccogli dati per l'analisi. Per ulteriori informazioni, consulta la guida alle best practice di Amazon EKS.

4. Elimina tutti i pod utilizzando l'immagine potenzialmente compromessa.

Riparazione dei nodi Kubernetes potenzialmente compromessi

Un GuardDuty risultato può indicare una compromissione del nodo se l'utente identificato nel risultato rappresenta l'identità di un nodo o se il risultato indica l'uso di un contenitore privilegiato.

L'identità utente è un nodo worker se il campo nome utente ha il seguente formato: system:node:node name. Ad esempio, system:node:ip-192-168-3-201.ec2.internal. Ciò indica che l'avversario ha ottenuto l'accesso al nodo e ne utilizza le credenziali per comunicare con l'endpoint dell'API Kubernetes.

Un esito indica l'uso di un container privilegiato se il campo resource.kubernetesDetails.kubernetesWorkloadDetails.containers.securityContext.privileged dell'esito di uno o più container elencati nell'esito è impostato su True.

Per riparare un nodo potenzialmente compromesso:

1. Isola il pod, ruota le sue credenziali e raccogli dati per l'analisi forense.

   Per ulteriori informazioni, consulta la guida alle best practice di Amazon EKS.

2. Identifica gli account di servizio utilizzati da tutti i pod in esecuzione sul nodo potenzialmente compromesso. Controlla le relative autorizzazioni e, se necessario, ruota gli account di servizio.

3. Termina il nodo potenzialmente compromesso.