Como corrigir os resultados do Monitoramento de logs de auditoria do EKS

GuardDuty A Amazon gera descobertas que indicam possíveis problemas de segurança do Kubernetes quando o EKS Audit Log Monitoring está ativado em sua conta. Para ter mais informações, consulte Monitoramento de logs de auditoria 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 do Monitoramento de logs de auditoria do EKS tiver sido gerado com expecthabilita, considere adicionar Regras de supressão para evitar futuros alertas.

Diferentes tipos de ataques e problemas de configuração podem acionar as descobertas do GuardDuty Kubernetes. 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:

• Possíveis problemas de configuração

• Remediando usuários potencialmente comprometidos do Kubernetes

• Corrigindo pods do Kubernetes potencialmente comprometidos

• Correção de nós Kubernetes potencialmente comprometidos

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

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 Melhores práticas de segurança para o Amazon EKS 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:

• Policy:Kubernetes/AnonymousAccessGranted

• Policy:Kubernetes/ExposedDashboard

• Policy:Kubernetes/AdminAccessToDefaultServiceAccount

• Policy:Kubernetes/KubeflowDashboardExposed

• Qualquer descoberta que termine em SuccessfulAnonymousAccess

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 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 resources.eksClusterDetails.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 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 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:

• Identifique o userType da seção Access Key details.

  • Se o userType é Perfil e o perfil pertencer a um perfil de instância do EC2:

    • Identifique essa instância e siga as instruções em Correção de uma instância potencialmente comprometida do Amazon EC2.

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

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.

AWS-Auth ConfigMap defined user — Um usuário do IAM que recebeu acesso por meio de um AWS-auth. ConfigMap Para obter mais informações, consulte Como gerenciar usuários ou perfis do IAM 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 seção MapRoles ou MapUsers com o mesmo nome de usuário relatado na seção de detalhes do usuário do Kubernetes da 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 melhores práticas do Amazon EKS 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 função do IAM que permite 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 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.

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 melhores práticas do Amazon EKS.

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 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ó 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 melhores práticas 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ó potencialmente comprometido.