View a markdown version of this page

Correzione dei risultati di EKS Protection - Amazon GuardDuty
Potenziali problemi di configurazioneCorrezione degli utenti Kubernetes potenzialmente compromessiCorrezione dei pod Kubernetes potenzialmente compromessiCorrezione delle immagini dei container potenzialmente compromesseCorrezione 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 di EKS Protection

Amazon GuardDuty genera risultati che indicano potenziali problemi di sicurezza di Kubernetes quando EKS Protection è abilitato per il tuo account. Per ulteriori informazioni, consulta Protezione 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 dei tipi di risultati di EKS Protection è stato generato in anticipo, puoi prendere in considerazione l'aggiunta Regole di soppressione in GuardDuty per evitare avvisi futuri.

Diversi tipi di attacchi e problemi di configurazione possono innescare i risultati di GuardDuty EKS Protection. Questa guida ti aiuta a identificare le cause principali dei GuardDuty riscontri relativi al tuo cluster e delinea le linee guida appropriate per porvi rimedio. Le cause principali che hanno portato ai risultati di GuardDuty Kubernetes sono le seguenti:

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 Secure Amazon EKS clusters with best practice 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:

Correzione degli 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 resource.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 risultato nella GuardDuty console, scegli Investigate in Detective. Quindi seleziona AWS l'utente o il ruolo dagli elementi elencati per esaminarlo in Detective.

Built-in Amministratore Kubernetes: 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:

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-Utente con autenticazione ConfigMap definita: un utente IAM a cui è stato concesso l'accesso tramite un -auth. AWS ConfigMap Per ulteriori informazioni, consulta Gestione degli utenti o dei ruoli IAM per il tuo cluster nella Amazon EKS User Guide. 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. Usa il seguente comando per aprire il. 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 di quello riportato nella sezione dei dettagli utente di Kubernetes della tua ricerca. 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. Consulta 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.

Correzione dei pod Kubernetes potenzialmente compromessi

Quando GuardDuty specifica i dettagli di un pod o di una risorsa del 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 tramite 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 Identify the offending pod and worker node nella Amazon EKS Best Practices Guide.

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 offensivi utilizzando il nome del carico di lavoro nella Amazon EKS Best Practices Guide.

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 che utilizzano l'account di servizio e i nodi su cui sono in esecuzione, consulta Identificare i pod e i nodi di lavoro offensivi utilizzando il nome dell'account di servizio nella Amazon EKS Best Practices Guide.

Dopo aver identificato tutti i pod compromessi e i nodi su cui sono in esecuzione, consulta Isolare il pod creando una policy di rete che neghi tutto il traffico in ingresso e in uscita verso il pod nella Amazon EKS Best Practices Guide.

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 un pod o una risorsa di carico di lavoro compromessi nella Amazon EKS Best Practices Guide.

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

Correzione delle immagini dei container potenzialmente compromesse

Quando una GuardDuty scoperta 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 e nodi di lavoro vulnerabili o compromessi nella Amazon EKS Best Practices Guide.

  3. Isola i pod potenzialmente compromessi, ruota le credenziali e raccogli dati per l'analisi. Per ulteriori informazioni, consulta Isolare il pod creando una policy di rete che neghi tutto il traffico in ingresso e in uscita verso il pod nella Amazon EKS Best Practices Guide.

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

Correzione 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 porre rimedio a un nodo potenzialmente compromesso:

  1. Isolare il pod, ruotarne le credenziali e raccogliere dati per l'analisi forense.

    Per ulteriori informazioni, consulta Isolare il pod creando una policy di rete che neghi tutto il traffico in ingresso e in uscita verso il pod nella Amazon EKS Best Practices Guide.

  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.