Valide as ligações da Google ao plano de controlo do GKE

.

Esta página descreve como validar as ligações estabelecidas pelo pessoal da Google ao plano de controlo do cluster do Google Kubernetes Engine (GKE) através da correlação dos registos do GKE com os registos da Transparência de acesso.

Os registos da Transparência de acesso registam as ações que o pessoal da Google realiza quando acede ao seu conteúdo. Este guia destina-se a administradores de segurança que pretendem uma validação adicional dos conteúdos dos registos da Transparência de acesso e das aprovações da Aprovação de acesso associadas através da correlação com origens de registos adicionais do GKE. Esta validação é totalmente opcional e não é necessária para proteger o seu plano de controlo.

Certifique-se de que conhece os seguintes conceitos:

Esta página descreve uma parte de um conjunto de funcionalidades opcionais do plano de controlo no GKE que lhe permitem realizar tarefas como validar a sua postura de segurança do plano de controlo ou configurar a encriptação e a assinatura de credenciais no plano de controlo através de chaves que gere. Para mais detalhes, consulte o artigo Acerca da autoridade do plano de controlo do GKE.

Por predefinição, Google Cloud aplica várias medidas de segurança ao plano de controlo gerido. Esta página descreve as capacidades opcionais que lhe dão mais visibilidade ou controlo sobre o plano de controlo do GKE.

Acerca do acesso da Google a instâncias do plano de controlo do cluster

Durante as sessões de resolução de problemas ou por outros motivos empresariais justificados, o pessoal da Google, como os engenheiros de fiabilidade do site e os funcionários do apoio ao cliente da Google Cloud, pode precisar de acesso administrativo às instâncias do Compute Engine que alojam o seu plano de controlo. Consoante o seu pacote de apoio técnico do serviço de apoio ao cliente e a configuração, a Transparência de acesso fornece registos de auditoria detalhados para este acesso administrativo. A aprovação de acesso permite-lhe exigir aprovação explícita antes de qualquer funcionário da Google poder aceder aos seus recursos. Para saber mais acerca do acesso administrativo e das ferramentas que pode usar para autorizar o acesso e registar alterações, consulte o artigo Acesso administrativo para funcionários da Google.

Registos de acesso do plano de controlo

Quando ativa a autoridade do plano de controlo do GKE, o GKE gera registos de acesso ao plano de controlo que pode usar opcionalmente para fazer referência cruzada aos registos de auditoria gerados pela Transparência de acesso e pela Aprovação de acesso. O GKE adiciona registos de acesso ao plano de controlo ao contentor _Default no Logging para registar ligações de rede recebidas e eventos SSH específicos nas instâncias do plano de controlo. Tem de ativar a autoridade do plano de controlo do GKE no seu projeto para gerar registos de acesso do plano de controlo para os seus clusters.

O GKE gera os seguintes registos de acesso para o plano de controlo:

O volume de registos de ligação do plano de controlo depende de fatores como o número de nós no cluster, o número de instâncias do plano de controlo (os clusters regionais têm mais instâncias do plano de controlo do que os clusters zonais) e a frequência com que as suas cargas de trabalho chamam o servidor da API Kubernetes. O volume de registos SSH é pequeno e depende do número de reinícios de nós.

Para validar as ligações ao seu plano de controlo, encontra os registos de acesso do plano de controlo para o seu cluster e faz a correspondência desses registos com os registos de auditoria da Transparência de acesso e da Aprovação de acesso. Isto permite-lhe confirmar que todas as ligações SSH às instâncias do plano de controlo foram o resultado de acesso administrativo autorizado por parte do pessoal da Google. Quando ativa a autoridade do plano de controlo do GKE para o seu cluster, todo o acesso SSH por parte do pessoal da Google ao seu plano de controlo é não interativo, o que significa que todas as ligações SSH executam um único comando que autoriza.

Preços

Aplicam-se as seguintes considerações de preços:

Antes de começar

Antes de começar, certifique-se de que realizou as seguintes tarefas:

  • Ative a API Google Kubernetes Engine.
    • Ative a API Google Kubernetes Engine
  • Se quiser usar a CLI gcloud para esta tarefa, instale-a e, em seguida, inicialize-a. Se instalou anteriormente a CLI gcloud, execute o comando gcloud components update para obter a versão mais recente. As versões anteriores da CLI gcloud podem não suportar a execução dos comandos neste documento.

  • Ative a Cloud Logging API.

    Roles required to enable APIs

    To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

    Enable the API

  • Ative a transparência de acesso para a sua organização. Para ver instruções, consulte o artigo Ativar a Transparência de acesso.

  • Opcionalmente, ative a aprovação de acesso para o seu projeto e selecione o serviço do GKE. Para obter instruções, consulte o artigo Reveja e aprove os pedidos de acesso através da chave de assinatura gerida pela Google.

  • Certifique-se de que o seu ambiente é elegível para usar as funcionalidades de autoridade do plano de controlo do GKE. Para ativar estas funcionalidades, contacte a sua Google Cloud equipa de vendas.

Requisitos

Os registos de acesso do plano de controlo requerem a versão 1.31.1-gke.1846000 ou posterior do GKE.

Funções e autorizações necessárias

Para receber as autorizações de que precisa para ativar a geração de registos e aceder e processar registos, peça ao seu administrador que lhe conceda as seguintes funções de IAM:

Para mais informações sobre a atribuição de funções, consulte o artigo Faça a gestão do acesso a projetos, pastas e organizações.

Também pode conseguir as autorizações necessárias através de funções personalizadas ou outras funções predefinidas.

Ative os registos de acesso do plano de controlo do cluster do GKE

Pode ativar a geração de registos de acesso do plano de controlo para clusters do modo Autopilot e do modo Standard ativando o componente de registo correspondente. Para mais informações sobre os tipos de registos do plano de controlo, consulte o artigo Ver registos do GKE.

Os nomes dos componentes de registo suportados para os registos de acesso do plano de controlo são os seguintes:

  • Registos SSH do plano de controlo: KCP_SSHD
  • Registos de ligação do plano de controlo: KCP_CONNECTION

Ative os registos de acesso do plano de controlo num novo cluster

O exemplo seguinte cria um cluster no modo Autopilot com ambos os tipos de registos de acesso do plano de controlo ativados. Para ativar apenas um tipo de registo de acesso do plano de controlo, omita o nome do componente correspondente do comando.

gcloud container clusters create-auto CLUSTER_NAME \
    --location=LOCATION \
    --logging=SYSTEM,KCP_SSHD,KCP_CONNECTION

Substitua o seguinte:

  • CLUSTER_NAME: o nome do novo cluster.
  • LOCATION: a localização na qual criar o cluster.

Para especificar componentes de registo quando cria um cluster através da API GKE, no método projects.locations.clusters.create, defina os valores correspondentes no objeto LoggingConfig do recurso Cluster.

Ative os registos de acesso do plano de controlo num cluster existente

Para atualizar a configuração de registo de um cluster existente para ativar os registos de acesso do plano de controlo, tem de fazer o seguinte:

  1. Encontre os componentes de registo existentes que o seu cluster usa.
  2. Identifique os valores correspondentes a especificar na flag --logging na CLI gcloud para manter esses componentes de registo ativados.
  3. Atualize a configuração de registo do cluster para ativar os registos de acesso do painel de controlo juntamente com a configuração de registo existente.

Os valores especificados para a flag --logging no comando gcloud container clusters update são diferentes dos valores apresentados quando descreve o cluster.

  1. Verifique a configuração de registo existente do cluster:

    gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --flatten=loggingConfig \
    --format='csv[delimiter=",",no-heading](componentConfig.enableComponents)'

    O resultado é semelhante ao seguinte:

    SYSTEM_COMPONENTS,WORKLOADS,APISERVER,SCHEDULER,CONTROLLER_MANAGER

  2. Identifique os valores da CLI gcloud para a flag --logging que correspondem à configuração do componente de registo da saída do passo anterior. Para ver uma lista dos valores da CLI gcloud que correspondem a componentes de registo específicos, consulte a tabela Registos disponíveis.

  3. Atualize a configuração de registo com registos de acesso do plano de controlo:

    gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --logging=SYSTEM,EXISTING_LOGS,KCP_ACCESS_LOGS

    Substitua o seguinte:

    • EXISTING_LOGS: uma lista separada por vírgulas de componentes de registo que o seu cluster já usa. Certifique-se de que especifica os valores da CLI gcloud que correspondem a estes componentes de registo, retirados da tabela Registos disponíveis.

    • KCP_ACCESS_LOGS: uma lista separada por vírgulas dos tipos de registos de acesso do plano de controlo a ativar para o cluster, da seguinte forma:

      • Para registos SSH do plano de controlo, especifique KCP_SSHD.
      • Para registos de ligação do plano de controlo, especifique KCP_CONNECTION.

Para especificar os componentes de registo quando atualiza um cluster através da API GKE, no método projects.locations.clusters.update, defina os valores dos componentes de registo existentes e novos no objeto LoggingConfig do recurso ClusterUpdate.

Exemplo de atualização do cluster para ativar os registos de acesso ao painel de controlo

Considere um cluster para o qual o comando gcloud container clusters describe tem a seguinte configuração de registo:

SYSTEM_COMPONENTS,WORKLOADS,APISERVER,SCHEDULER,CONTROLLER_MANAGER

O seguinte comando de atualização do cluster ativa ambos os tipos de registos de acesso ao plano de controlo, mantendo a configuração de registo existente para este cluster de exemplo:

gcloud container clusters update example-cluster \
    --location=us-central1 \
    --logging=SYSTEM,WORKLOAD,API_SERVER,SCHEDULER,CONTROLLER_MANAGER,KCP_SSHD,KCP_CONNECTION

Consulte os registos de acesso do plano de controlo com os registos da Transparência de acesso

Para validar o acesso ao painel de controlo de um cluster, obtenha os registos de ligação do painel de controlo, os registos SSH do painel de controlo e os registos da Transparência de acesso desse cluster:

  1. Na Google Cloud consola, abra a página Explorador de registos.

    Aceda ao Explorador de registos

  2. Para obter todos os registos de um cluster específico, incluindo os registos de acesso do plano de controlo e os registos da Transparência de acesso, execute a seguinte consulta:

    (logName="projects/PROJECT_ID/logs/container.googleapis.com%2Fkcp-connection"
resource.labels.cluster_name="CLUSTER_NAME"
jsonPayload.connection.dest_port="22")
OR
(logName="projects/PROJECT_ID/logs/container.googleapis.com%2Fkcp-sshd"
resource.labels.cluster_name="CLUSTER_NAME")
OR
(logName="projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Faccess_transparency"
json_payload.accesses.methodName="GoogleInternal.SSH.Master"
json_payload.accesses.resourceName="//container.googleapis.com/projects/PROJECT_NUMBER/locations/LOCATION/clusters/CLUSTER_NAME")

A saída deve apresentar todos os seguintes tipos de registos para o seu cluster:

  • Registo da Transparência de acesso
  • Registo de ligação do plano de controlo
  • Registos de SSH para cada sessão de SSH

Faça verificações de validação

A verificação principal consiste em verificar se vê todos os tipos de registos para quaisquer ligações SSH quando executa a consulta de registo da secção anterior. Cada registo da Transparência de acesso deve ter um registo de ligação do plano de controlo correspondente e um ou mais registos SSH. Estes registos destinam-se a ações que os humanos realizam nas instâncias do plano de controlo, pelo que o volume de registos deve ser pequeno.

Opcionalmente, pode realizar as seguintes verificações adicionais do conteúdo do registo:

  1. Para cada registo SSH do plano de controlo, verifique se existe um registo da Transparência de acesso num intervalo de 15 minutos antes da data/hora do registo SSH. Este período tem em conta o encerramento final da sessão SSH que ocorre vários minutos após a ligação inicial ter sido registada pela Transparência de acesso.
  2. Para cada registo de ligação do plano de controlo, verifique se existe um registo de transparência de acesso num intervalo de 5 minutos antes da data/hora do registo de ligação do plano de controlo.

  3. Se usar a Aprovação de acesso para o seu cluster, verifique se cada registo da Transparência de acesso tem um campo accessApprovals correspondente. Compare este campo com os pedidos de aprovação de acesso para o seu cluster.

    Para receber pedidos de aprovação de acesso para o seu projeto, consulte o artigo Veja o histórico de pedidos de aprovação de acesso. A aprovação do acesso pode estar sujeita a exclusões.

  4. Opcionalmente, valide a assinatura da aprovação de acesso assinada associada ao registo da Transparência de acesso.

Detalhes do registo de acesso do plano de controlo

Esta secção fornece detalhes e exemplos dos registos de acesso do plano de controlo que o GKE gera quando o pessoal da Google se liga às suas instâncias do plano de controlo.

Registos de ligação do plano de controlo

O GKE adiciona um registo de ligação do plano de controlo para cada nova ligação de rede recebida a uma instância do plano de controlo. Estes registos incluem detalhes específicos, como os seguintes:

  • Portas e endereços IP de origem e destino
  • Direção e protocolo de ligação

O exemplo seguinte mostra um registo de ligação do plano de controlo:

{
  insertId: "z1eq8wonio335a5h",
  jsonPayload: {
    instance: {
      vm_name: "gke-dee49f0d6fa34ce3a2ac-f513-d195-vm",
      zone: "us-central1-c"
    },
    cluster: {
      cluster_id: "CLUSTER_ID",
      cluster_urn: "//container.googleapis.com/projects/PROJECT_NUMBER/locations/us-central1-c/clusters/CLUSTER_NAME"
    },
    connection: {
      state: "NEW",
      src_ip: "192.0.2.100",
      src_port: 32774,
      dest_ip: "203.0.113.12",
      dest_port: 22,
      direction: "INGRESS"
      protocol: "TCP"
    },
  }
  logName: "projects/PROJECT_ID/logs/container.googleapis.com%2Fkcp-connection",
  receiveTimestamp: "2024-04-11T04:08:01.883070399Z",
  resource: {
    labels: {
      cluster_name: "CLUSTER_NAME",
      location: "us-central1-c",
      project_id: "PROJECT_ID"
    }
    type: "gke_cluster",
  }
  severity: "NOTICE",
  timestamp: "2024-04-11T04:07:59.019330Z"
}

Os seguintes campos na entrada do registo são relevantes para validar as ações da Google:

  • cluster.cluster_urn: o identificador de recurso totalmente qualificado do cluster. Este identificador tem o formato //container.googleapis.com/projects/PROJECT_NUMBER/locations/LOCATION/clusters/CLUSTER_NAME, com as seguintes variáveis:

    • PROJECT_NUMBER: o número do projeto numérico do seu projeto de clusters.
    • LOCATION: a Google Cloud localização do seu cluster.
    • CLUSTER_NAME: o nome do cluster.

  • connection: detalhes sobre a tentativa de associação. Este campo tem as seguintes informações:

    • state: o estado da ligação. Para novas associações, o valor é NEW.
    • src_ip: o endereço IP da origem da ligação.
    • src_port: o número da porta da origem da ligação.
    • dest_ip: o endereço IP interno da VM do plano de controlo.
    • dest_port: o número da porta de destino.
    • direction: a direção da associação. O valor é sempre INGRESS.
    • protocol: o protocolo IP, como TCP.

Registos SSH do plano de controlo

O GKE adiciona registos SSH do plano de controlo para eventos relacionados com ligações SSH a instâncias do plano de controlo. O GKE regista os seguintes eventos:

  • Chave SSH aceite para um utilizador
  • O estado da sessão mudou de 0 para 1, o que indica que o utilizador iniciou sessão com êxito
  • Sessão SSH aberta
  • Sessão SSH fechada
  • O estado da sessão mudou de 1 para 0, o que indica que o utilizador terminou sessão
  • Falha na sessão SSH

Por exemplo, o seguinte registo SSH do plano de controlo destina-se a uma sessão SSH que está a ser aberta:

{
  insertId: "8llczemdulwbbwpa",
  jsonPayload: {
    instance: {
      vm_name: "gke-06cb920c609941c0a5ce-6840-40e9-vm",
      zone: "us-central1-c"
    },
    cluster: {
      cluster_id: "891e6d12889747748c1ac16ffcc6cb7c0a96450b36864eb680917c119fd801d0",
      cluster_urn: "//container.googleapis.com/projects/PROJECT_NUMBER/locations/us-central1/clusters/CLUSTER_NAME",
    },
    message: "pam_unix(sshd:session): session opened for user REDACTED by (uid=0)",
  },
  logName: "projects/PROJECT_ID/logs/container.googleapis.com%2Fkcp-ssh",
  receiveTimestamp: "2024-04-09T13:21:55.231436462Z"
  resource: {
    type: "gke_cluster",
    labels: {
      cluster_name: "CLUSTER_NAME",
      location: "us-central1",
      project_id: "PROJECT_ID"
    }
  },
  severity: "NOTICE",
  timestamp: "2024-04-09T13:21:50.742246Z"
}

Os seguintes campos na entrada do registo são relevantes para validar as ações da Google:

  • cluster.cluster_urn: o identificador de recurso totalmente qualificado do cluster. Este identificador tem o formato //container.googleapis.com/projects/PROJECT_NUMBER/locations/LOCATION/clusters/CLUSTER_NAME, com as seguintes variáveis:

    • PROJECT_NUMBER: o número do projeto numérico do seu projeto de cluster.
    • LOCATION: a Google Cloud localização do seu cluster.
    • CLUSTER_NAME: o nome do cluster.

  • message: detalhes sobre a ligação SSH.

Desative os registos de acesso do plano de controlo

  1. Para ver os tipos de registos específicos que o seu cluster usa, execute o seguinte comando:

    gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --flatten=loggingConfig \
    --format='csv[delimiter=",",no-heading](componentConfig.enableComponents)'

    O resultado é semelhante ao seguinte:

    SYSTEM_COMPONENTS,WORKLOADS,API_SERVER,SCHEDULER,CONTROLLER_MANAGER,KCP_SSHD,KCP_CONNECTION

  2. Para desativar os registos de acesso do plano de controlo de um cluster, execute o seguinte comando:

    gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --logging=SYSTEM,WORKLOAD,API_SERVER,SCHEDULER,CONTROLLER_MANAGER

Na flag --logging, especifique os componentes de registo da saída do comando anterior. Este comando de exemplo desativa os registos de acesso do plano de controlo, mas mantém outros registos de componentes do plano de controlo ativados.

Para desativar os componentes de registo através da API GKE, defina os valores correspondentes no objeto LoggingConfig do recurso ClusterUpdate no método projects.locations.clusters.update.

O que se segue?