Descoberta: pode receber verificações de objetos sensíveis do Kubernetes.

Este documento descreve um tipo de descoberta de ameaça no Security Command Center. As descobertas de ameaças são geradas por detectores de ameaças quando eles detectam uma ameaça potencial nos seus recursos da nuvem. Para uma lista completa das descobertas de ameaças disponíveis, consulte o índice de descobertas de ameaças.

Visão geral

Uma pessoa mal-intencionada tentou determinar quais objetos confidenciais no GKE eles podem consultar usando o comando kubectl auth can-i get. Especificamente, o ator executou qualquer um dos seguintes comandos:

  • kubectl auth can-i get '*'
  • kubectl auth can-i get secrets
  • kubectl auth can-i get clusterroles/cluster-admin

Como responder

Para responder a essa descoberta, faça o seguinte:

Etapa 1: verificar os detalhes da descoberta

  1. Abra uma descoberta Discovery: Can get sensitive Kubernetes object check, conforme direcionado em Como verificar descobertas.

  2. No painel Detalhes da descoberta, na guia Resumo, observe os valores dos seguintes campos:

    • Em O que foi detectado:
      • Avaliações de acesso do Kubernetes: as informações solicitadas para a análise de acesso, com base no recurso SelfSubjectAccessReview do k8s.
      • E-mail principal: a conta que fez a chamada.
    • Em Recurso afetado:
      • Nome de exibição do recurso: o cluster do Kubernetes em que a ação ocorreu.
    • Em Links relacionados:
      • URI do Cloud Logging: link para as entradas do Logging.

Etapa 2: verificar os registros

  1. Na guia "Resumo" do painel de detalhes da descoberta, clique no link URI do Cloud Logging para abrir o Explorador de registros.

  2. Na página carregada, verifique se há outras ações realizadas pelo principal usando os seguintes filtros:

    • resource.labels.cluster_name="CLUSTER_NAME"

    • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

      Substitua:

    • CLUSTER_NAME: o valor que você anotou no campo Nome de exibição do recurso nos detalhes da descoberta.

    • PRINCIPAL_EMAIL: o valor que você anotou no campo E-mail principal nos detalhes da descoberta.

Etapa 3: pesquisar métodos de ataque e resposta

  1. Verifique as entradas do framework do MITRE ATT&CK em busca deste tipo de descoberta: Descoberta
  2. Confirme a confidencialidade do objeto consultado e determine se há outros sinais de atividade maliciosa pelo principal nos registros.

  3. Se a conta que você anotou na linha E-mail principal nos detalhes da descoberta não for uma conta de serviço, entre em contato com o proprietário dela para confirmar se o proprietário legítimo conduziu a ação.

    Se o e-mail principal for uma conta de serviço (IAM ou Kubernetes), identifique a origem da revisão de acesso para determinar a legitimidade.

  4. Para desenvolver um plano de resposta, combine os resultados da investigação com a pesquisa do MITRE.

A seguir