Correzione dei risultati EKS della protezione - Amazon GuardDuty
Potenziali problemi di configurazioneRiparare gli utenti Kubernetes potenzialmente compromessiRiparazione dei pod Kubernetes potenzialmente compromessiRiparazione delle immagini dei container potenzialmente compromesseRiparazione dei nodi Kubernetes potenzialmente compromessi

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

Correzione dei risultati EKS della protezione

Amazon GuardDuty genera risultati che indicano potenziali problemi di sicurezza di Kubernetes quando la EKS protezione è abilitata per il tuo account. Per ulteriori informazioni, consulta EKSProtezione. 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 risultati della EKS protezione è stato generato in modo prevedibile, puoi prendere in considerazione l'aggiunta Regole di soppressione in GuardDuty per prevenire avvisi futuri.

Diversi tipi di attacchi e problemi di configurazione possono innescare i risultati GuardDuty EKS della protezione. Questa guida 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:

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:

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 inaspettata. API Puoi identificare l'utente nella sezione dei dettagli utente di Kubernetes di un risultato nella console o nei risultati. resources.eksClusterDetails.kubernetesDetails.kubernetesUserDetails JSON 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'IAMentità, puoi utilizzare la Access Key details sezione per identificare i dettagli di un ruolo o di un IAM utente. Consulta i seguenti tipi di utente e le linee guida per la correzione.

Nota

Puoi utilizzare Amazon Detective per indagare ulteriormente sul IAM ruolo o sull'utente identificato nella scoperta. 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'IAMidentità che ha creato il cluster. Questo tipo di utente è identificato dal nome utente kubernetes-admin.

Per revocare l'accesso a un amministratore Kubernetes integrato:

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

Per revocare l'accesso di un utente OIDC autenticato:

  1. Ruota le credenziali di quell'utente nel provider. OIDC

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

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

Per revocare l'accesso di un AWS ConfigMap utente:

  1. Utilizzate il seguente comando per aprire. ConfigMap 

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

  2. Identifica il ruolo o la voce utente mapUsersnella sezione mapRoleso 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 EKS best practice di Amazon per isolare il pod, ruotarne le credenziali e raccogliere dati per l'analisi forense.

Per rimediare a 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 IAM ruolo 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 IAM ruolo, valuta se puoi rimuovere in sicurezza le IAM policy 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 EKS best practice di Amazon.

  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 sta utilizzando le credenziali del nodo per comunicare con l'endpoint Kubernetes. API

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 EKS best practice di Amazon.

  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.