Corrigindo as descobertas EKS de proteção - Amazon GuardDuty
Possíveis problemas de configuraçãoRemediando usuários potencialmente comprometidos do KubernetesCorrigindo pods do Kubernetes potencialmente comprometidosCorreção de imagens de contêineres potencialmente comprometidasCorreção de nós Kubernetes potencialmente comprometidos

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Corrigindo as descobertas EKS de proteção

GuardDuty A Amazon gera descobertas que indicam possíveis problemas de segurança do Kubernetes quando a EKS Proteção está ativada para sua conta. Para obter mais informações, consulte EKSProteção. 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 de EKS proteção tiver sido gerado com expectativa, considere adicionar Regras de supressão em GuardDuty para evitar futuros alertas.

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

nota

Antes da versão 1.14 do Kubernetes, o system:unauthenticated grupo era associado e por padrão. system:discovery system:basic-user ClusterRoles 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 a remoção dessas permissões, consulte as melhores práticas de segurança para a Amazon EKS no Guia EKS do usuário da Amazon.

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:

Remediando usuários potencialmente comprometidos do Kubernetes

Uma GuardDuty descoberta pode indicar um usuário comprometido do Kubernetes quando um usuário identificado na descoberta executou uma ação inesperada. API Você pode identificar o usuário na seção de detalhes do usuário do Kubernetes de uma descoberta no console ou nas resources.eksClusterDetails.kubernetesDetails.kubernetesUserDetails descobertas. JSON 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 carga de trabalho usando uma IAM entidade, você pode usar a Access Key details seção para identificar os detalhes de uma IAM função ou usuário. Consulte os seguintes tipos de usuário e suas diretrizes de correção.

nota

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

Administrador integrado do Kubernetes — O usuário padrão atribuído pela Amazon EKS à IAM identidade 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:

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

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

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

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

AWS-Auth ConfigMap defined user — Um IAM usuário que recebeu acesso por meio de um AWS-auth. ConfigMap Para obter mais informações, consulte Gerenciando usuários ou IAM funções para seu cluster no guia do usuário do &EKS;. É possível revisar as permissões usando este comando: kubectl edit configmaps aws-auth --namespace kube-system

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

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

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

  2. Identifique a função ou a entrada do usuário na mapUsersseção mapRolesou com o mesmo nome de usuário relatado na seção de detalhes do usuário do Kubernetes de sua descoberta. 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 AWS conta 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.

Corrigindo pods do Kubernetes potencialmente comprometidos

Quando GuardDuty especifica detalhes de um pod ou recurso de carga de trabalho dentro da resource.kubernetesDetails.kubernetesWorkloadDetails seção, esse pod ou recurso de carga de trabalho foi potencialmente comprometido. Uma GuardDuty descoberta 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 obter informações sobre como identificar o nó de trabalho que executa os pods, consulte Identificar os pods ofensivos e o nó de trabalho.

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 carga de trabalho e os nós nos quais eles estão sendo executados, consulte Identificar os pods e os nós de trabalho incorretos usando o nome da carga de trabalho.

Pods comprometidos por meio da conta de serviço

Se uma GuardDuty descoberta identificar uma conta de serviço na resource.kubernetesDetails.kubernetesUserDetails seção, é 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 eles estão sendo executados, consulte Identificar os pods e os nós de trabalho incorretos usando o nome da conta de serviço.

Depois de identificar todos os pods comprometidos e os nós nos quais eles estão sendo executados, consulte o guia de EKS melhores práticas da Amazon para isolar o pod, alternar suas credenciais e coletar dados para análise forense.

Para corrigir um pod potencialmente 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 pod comprometido ou o recurso de carga de trabalho.

Se o node de trabalho tiver recebido uma IAM função que permita que os pods tenham acesso a outros AWS recursos, remova essas funções da instância para evitar mais danos causados pelo ataque. Da mesma forma, se uma IAM função foi atribuída ao pod, avalie se você pode remover com segurança as IAM políticas da função sem afetar outras cargas de trabalho.

Correção de imagens de contêineres potencialmente comprometidas

Quando uma GuardDuty descoberta indica um comprometimento do pod, a imagem usada para iniciar o pod pode ser potencialmente maliciosa ou estar comprometida. GuardDuty as descobertas identificam a imagem do contêiner dentro do resource.kubernetesDetails.kubernetesWorkloadDetails.containers.image campo. 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 potencialmente comprometida.

    Para obter mais informações, consulte Identificar pods com imagens de contêiner e nós de trabalho potencialmente vulneráveis ou comprometidos.

  3. Isole os pods potencialmente comprometidos, alterne as credenciais e colete dados para análise. Para obter mais informações, consulte o guia de EKS melhores práticas da Amazon.

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

Correção de nós Kubernetes potencialmente comprometidos

Uma GuardDuty descoberta pode indicar um comprometimento do nó se o usuário identificado na descoberta representar a identidade do nó ou se a descoberta indicar 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 do API 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ó potencialmente comprometido:

  1. Isole o pod, alterne suas credenciais e colete dados para análise forense.

    Para obter mais informações, consulte o guia de EKS melhores práticas da Amazon.

  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ó potencialmente comprometido.