Discovery: pode obter a verificação de objetos Kubernetes confidenciais

Este documento descreve um tipo de deteção de ameaças no Security Command Center. As conclusões de ameaças são geradas por detetores de ameaças quando detetam uma potencial ameaça nos seus recursos da nuvem. Para ver uma lista completa das conclusões de ameaças disponíveis, consulte o Índice de conclusões de ameaças.

Vista geral

Um interveniente potencialmente malicioso tentou determinar que objetos confidenciais no GKE pode consultar através do 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

A Deteção de ameaças com base em eventos é a origem desta descoberta.

Como responder

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

Passo 1: reveja os detalhes da descoberta

  1. Abra a Discovery: Can get sensitive Kubernetes object checkdescoberta conforme indicado em Rever descobertas.

  2. Nos detalhes da descoberta, no separador Resumo, tome nota dos valores dos seguintes campos:

    • Em O que foi detetado:
      • Revisões de acesso do Kubernetes: as informações de revisão de acesso pedidas com base no recurso do Kubernetes SelfSubjectAccessReview.
      • Email principal: a conta que fez a chamada.
    • Em Recurso afetado:
      • Nome a apresentar do recurso: o cluster do Kubernetes onde a ação ocorreu.
    • Em Links relacionados:
      • URI do Cloud Logging: link para as entradas do Logging.

Passo 2: verifique os registos

  1. No separador Resumo do painel de detalhes da descoberta, clique no link URI do Cloud Logging para abrir o explorador de registos.

  2. Na página carregada, verifique outras ações realizadas pelo principal através dos seguintes filtros:

    • resource.labels.cluster_name="CLUSTER_NAME"

    • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

      Substitua o seguinte:

    • CLUSTER_NAME: o valor que anotou no campo Nome a apresentar do recurso nos detalhes da descoberta.

    • PRINCIPAL_EMAIL: o valor que anotou no campo Email principal nos detalhes da descoberta.

Passo 3: pesquise métodos de ataque e resposta

  1. Reveja as entradas da framework MITRE ATT&CK para este tipo de descoberta: Descoberta
  2. Confirme a sensibilidade do objeto consultado e determine se existem outros sinais de atividade maliciosa por parte do principal nos registos.

  3. Se a conta que indicou na linha Email principal nos detalhes de localização não for uma conta de serviço, contacte o proprietário da conta para confirmar se o proprietário legítimo realizou a ação.

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

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

O que se segue?