Como corrigir as descobertas da Proteção do EKS - Amazon GuardDuty
Possíveis problemas de configuraçãoComo corrigir usuários do Kubernetes possivelmente comprometidosComo corrigir pods do Kubernetes possivelmente comprometidosComo corrigir imagens de contêiner possivelmente comprometidasComo corrigir pods do Kubernetes potencialmente comprometidos

Como corrigir as descobertas da Proteção do EKS

O Amazon GuardDuty gera descobertas que indicam possíveis problemas de segurança do Kubernetes quando a proteção do EKS está habilitada em sua conta. Para obter mais informações, consulte Proteção do EKS. As seções a seguir descrevem as etapas de correção recomendadas para qualquer uma das situações. As ações de remediação específicas são descritas na entrada desse tipo específico de descoberta. Você pode acessar as informações completas sobre um tipo de descoberta selecionando-o na tabela Tipos de descobertas ativas.

Se algum dos tipos de descoberta damproteção EKS tiver sido gerado com inesperadamente, considere adicionar Regras de supressão no GuardDuty para evitar futuros alertas.

Diferentes tipos de ataques e problemas de configuração podem acionar as descobertas da Proteção EKS no GuardDuty. Este guia ajuda você a identificar as principais causas das descobertas do GuardDuty em seu cluster e descreve as diretrizes de remediação apropriadas. A seguir estão as principais causas que levaram às descobertas do Kuberneted no GuardDuty:

nota

Antes da versão 1.14 do Kubernetes, o grupo system:unauthenticated era associado aos ClusterRoles system:discovery e system:basic-user por padrão. Isso pode permitir o acesso não intencional de usuários anônimos. As atualizações de cluster não revogam essas permissões, o que significa que, mesmo que você tenha atualizado seu cluster para a versão 1.14 ou posterior, essas permissões ainda podem estar em vigor. Recomendamos que você desassocie essas permissões do grupo system:unauthenticated.

Para obter mais informações sobre como remover essas permissões, consulte Proteger clusters do Amazon EKS com práticas recomendadas no Guia do usuário do Amazon EKS.

Possíveis problemas de configuração

Se uma descoberta indicar um problema de configuração, consulte a seção de correção dessa descoberta para obter orientação sobre como resolver esse problema específico. Para obter mais informações, consulte os tipos de descoberta a seguir que indicam problemas de configuração:

Como corrigir usuários do Kubernetes possivelmente comprometidos

Uma descoberta do GuardDuty pode indicar um usuário comprometido do Kubernetes quando um usuário identificado na descoberta executou uma ação inesperada da API. Você pode identificar o usuário na seção de detalhes do usuário do Kubernetes de um detalhe da descoberta no console ou no resource.kubernetesDetails.kubernetesUserDetails do JSON das descobertas. Esses detalhes do usuário incluem user name, uid e os grupos do Kubernetes aos quais o usuário pertence.

Se o usuário estava acessando a workload usando uma entidade do IAM, você pode usar a seção Access Key details para identificar os detalhes de um usuário ou perfil do IAM. Consulte os seguintes tipos de usuário e suas diretrizes de correção.

nota

Você pode usar o Amazon Detective para investigar melhor o perfil do IAM ou o usuário identificado na descoberta. Ao visualizar os detalhes da descoberta no console do GuardDuty, escolha Investigar no Detective. Em seguida, selecione usuário ou perfil do AWS nos itens listados para investigá-lo no Detective.

Administrador integrado do Kubernetes: o usuário padrão atribuído pelo Amazon EKS à identidade do IAM que criou o cluster. Esse tipo de usuário é identificado pelo nome do usuário kubernetes-admin.

Para revogar o acesso de um administrador integrado do Kubernetes:

Usuário autenticado pelo OIDC: um usuário recebeu acesso por meio de um provedor do OIDC. Normalmente, um usuário do OIDC tem um endereço de e-mail como nome de usuário. Você pode verificar se o cluster usa o OIDC com o seguinte comando: aws eks list-identity-provider-configs --cluster-name your-cluster-name

Para revogar o acesso de um usuário autenticado pelo OIDC:

  1. Alterne as credenciais desse usuário no provedor OIDC.

  2. Alterne todos os segredos aos quais o usuário teve acesso.

Usuário definido por AWS-Auth ConfigMap: um usuário do IAM que recebeu acesso por meio de um AWS-auth ConfigMap. Para obter mais informações, consulte Gerenciar usuários ou perfis do IAM para seu cluster no Guia do usuário do Amazon EKS. É possível revisar as permissões usando este comando: kubectl edit configmaps aws-auth --namespace kube-system

Para revogar o acesso de um usuário do AWS ConfigMap:

  1. Use o comando a seguir para abrir o ConfigMap. 

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

  2. Identifique a função ou a entrada do usuário na seção mapRoles ou mapUsers com o mesmo nome de usuário relatado na seção de detalhes do usuário do Kubernetes de sua descoberta do GuardDuty. Veja o exemplo a seguir, em que o usuário administrador foi identificado em uma descoberta. 

    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. Remova esse usuário do ConfigMap. Veja o exemplo a seguir em que o usuário administrador foi removido.

    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 userType for Usuário ou for uma Função que foi assumida por um usuário:

    1. Gire a chave de acesso desse usuário.

    2. Alterne todos os segredos aos quais o usuário teve acesso.

    3. Revise as informações em Minha conta da AWS pode estar comprometida para obter mais detalhes.

Se a descoberta não tiver uma seção resource.accessKeyDetails, o usuário é uma conta de serviço do Kubernetes.

Conta de serviço: a conta de serviço fornece uma identidade para pods e pode ser identificada por um nome de usuário com o seguinte formato: system:serviceaccount:namespace:service_account_name.

Para revogar o acesso a uma conta de serviço:

  1. Alterne as credenciais da conta de serviço.

  2. Revise a orientação sobre comprometimento de pods na seção a seguir.

Como corrigir pods do Kubernetes possivelmente comprometidos

Quando o GuardDuty especifica detalhes de um pod ou recurso de workload dentro da seção resource.kubernetesDetails.kubernetesWorkloadDetails, esse pod ou recurso de workload provavelmente está comprometido. Uma descoberta do GuardDuty pode indicar que um único pod foi comprometido ou que vários pods foram comprometidos por meio de um recurso de nível superior. Consulte os seguintes cenários de comprometimento para obter orientação sobre como identificar o pod ou os pods que foram comprometidos.

Comprometimento de pods individuais

Se o campo type dentro da seção resource.kubernetesDetails.kubernetesWorkloadDetails for pods, a descoberta identifica um único pod. O campo de nome é o name dos pods e o campo namespace é seu namespace.

Para informações sobre como identificar o nó de processamento que executa os pods, consulte Identificar o nó de processamento e pods ofensivos no Guia de práticas recomendadas do Amazon EKS.

Pods comprometidos por meio de recursos de workload

Se o campo type dentro da seção resource.kubernetesDetails.kubernetesWorkloadDetails identificar um Recurso de workload, como um Deployment, é provável que todos os pods desse recurso de workload tenham sido comprometidos.

Para obter informações sobre como identificar todos os pods do recurso de workload e os nós nos quais estão sendo executados, consulte Identificar os nós de processamento e pods ofensivos usando o nome de workload no Guia de práticas recomendadas do Amazon EKS.

Pods comprometidos por meio da conta de serviço

Se uma descoberta do GuardDuty identificar uma conta de serviço na seção resource.kubernetesDetails.kubernetesUserDetails, é provável que os pods que usam a conta de serviço identificada estejam comprometidos. O nome de usuário relatado por uma descoberta é uma conta de serviço se tiver o seguinte formato: system:serviceaccount:namespace:service_account_name.

Para obter informações sobre como identificar todos os pods usando a conta de serviço e os nós nos quais estão sendo executados, consulte Identificar os nós de processamento e pods ofensivos usando o nome da conta de serviço no Guia de práticas recomendadas do Amazon EKS.

Depois de identificar todos os pods comprometidos e os nós em que eles estão sendo executados, consulte Isolar o pod criando uma política de rede que negue todo o tráfego de entrada e saída do pod no Guia de práticas recomendadas do Amazon EKS.

Para corrigir um pod possivelmente comprometido:

  1. Identifique a vulnerabilidade que comprometeu os pods.

  2. Implemente a correção para essa vulnerabilidade e inicie novos pods de substituição.

  3. Exclua os pods vulneráveis.

    Para obter mais informações, consulte Reimplantar o recurso de workload ou o pod comprometido no Guia de práticas recomendadas do Amazon EKS.

Se o nó de processamento tiver recebido um perfil do IAM que permite que os pods tenham acesso a outros recursos da AWS, remova essas funções da instância para evitar mais danos causados pelo ataque. Da mesma forma, se o pod tiver recebido uma função do IAM, avalie se você pode remover com segurança as políticas do IAM da função sem afetar outras workloads.

Como corrigir imagens de contêiner possivelmente comprometidas

Quando uma descoberta do GuardDuty indica um comprometimento do pod, a imagem usada para iniciar o pod pode ser mal-intencionada ou estar comprometida. As descobertas do GuardDuty identificam a imagem do contêiner dentro do campo resource.kubernetesDetails.kubernetesWorkloadDetails.containers.image. Você pode determinar se a imagem é mal-intencionada examinando-a em busca de malware.

Para corrigir uma imagem de contêiner potencialmente comprometida:

  1. Pare de usar a imagem imediatamente e remova-a do seu repositório de imagens.

  2. Identifique todos os pods usando a imagem possivelmente comprometida.

    Para obter mais informações, consulte Identificar nós de processamento e pods com imagens comprometidas ou vulneráveis no Guia de práticas recomendadas do Amazon EKS.

  3. Isole os pods potencialmente comprometidos, alterne as credenciais e colete dados para análise. Para obter mais informações, consulte Isolar o pod criando uma política de rede que negue todo o tráfego de entrada e saída para o pod no Guia de práticas recomendadas do Amazon EKS.

  4. Identifique todos os pods usando a imagem potencialmente comprometida.

Como corrigir pods do Kubernetes potencialmente comprometidos

Uma descoberta do GuardDuty pode indicar um comprometimento do nó caso o usuário identificado na descoberta represente a identidade do nó ou a descoberta indique o uso de um contêiner privilegiado.

A identidade do usuário é um nó de processamento se o campo nome de usuário tiver o seguinte formato: system:node:node name. Por exemplo, system:node:ip-192-168-3-201.ec2.internal. Isso indica que o adversário obteve acesso ao nó e está usando as credenciais do nó para se comunicar com o endpoint da API do Kubernetes.

Uma descoberta indica o uso de um contêiner privilegiado se um ou mais dos contêineres listados na descoberta tiver o campo de descoberta resource.kubernetesDetails.kubernetesWorkloadDetails.containers.securityContext.privileged definido como True.

Para corrigir um nó possivelmente comprometido:

  1. Isole o pod comprometido, alterne as credenciais e colete dados para análise.

    Para obter mais informações, consulte Isolar o pod criando uma política de rede que negue todo o tráfego de entrada e saída para o pod no Guia de práticas recomendadas do Amazon EKS.

  2. Identifique as contas de serviço usadas por todos os pods em execução no nó potencialmente comprometido. Revise suas permissões e alterne as contas de serviço, se necessário.

  3. Encerre o nó possivelmente comprometido.