Verificar a integridade da VM do plano de controle do GKE

É possível verificar a integridade da imagem de máquina virtual (VM) do Compute Engine que o Google Kubernetes Engine (GKE) usa para VMs do plano de controle. Esta página fornece instruções para uma equipe de segurança que monitora os registros do plano de controle para verificar o seguinte:

  • A VM do plano de controle foi inicializada com firmware autêntico e outro software de inicialização que foi verificado criptograficamente pela inicialização segura e pelo monitoramento de integridade.
  • A VM do plano de controle foi inicializada a partir de uma imagem de SO autêntica do GKE.

Também é possível realizar essa verificação para as imagens do SO e a integridade de inicialização dos nós.

Esta página descreve uma parte de um conjunto de recursos opcionais do plano de controle no GKE que permite realizar tarefas como verificar a postura de segurança do plano de controle ou configurar a criptografia e a assinatura de credenciais no plano de controle usando chaves gerenciadas. Para mais detalhes, consulte Sobre a autoridade do plano de controle do GKE.

Por padrão, Google Cloud aplica várias medidas de segurança ao plano de controle gerenciado. Esta página descreve recursos opcionais que oferecem mais visibilidade ou controle sobre o plano de controle do GKE.

Sobre a verificação de integridade da VM

Por padrão, todas as instâncias do plano de controle do GKE são VMs protegidas, que são VMs reforçadas que usam recursos de segurança, como inicialização segura e medida, um módulo de plataforma confiável virtual (vTPM) e firmware UEFI. Todos os nós do GKE também ativam o monitoramento de integridade, que valida a sequência de inicialização de cada VM protegida em relação a uma sequência de inicialização "boa" de referência. Essa validação retorna resultados de aprovação ou reprovação para cada fase da sequência de inicialização e adiciona esses resultados ao Cloud Logging. O monitoramento de integridade é ativado por padrão em todos os clusters do GKE e valida as seguintes fases:

  • Sequência de inicialização antecipada: desde quando o firmware UEFI é iniciado até o momento em que o carregador de inicialização assume o controle. Adicionado aos registros da VM como earlyBootReportEvent.
  • Sequência de inicialização atrasada: desde quando o carregador de inicialização assume o controle até o momento em que o kernel do sistema operacional assume o controle. Adicionado aos registros da VM como lateBootReportEvent.

O GKE também adiciona registros de criação de VM do plano de controle ao Logging. Esses registros contêm metadados que identificam a máquina e incluem detalhes sobre a imagem da VM e a sequência de inicialização. Google Cloud publica um atestado de resumo de verificação (VSA, na sigla em inglês) para cada imagem de VM do plano de controle do GKE no repositório gke-vsa no GitHub. O VSA usa o framework in-toto para atestados. É possível validar os registros de VM do plano de controle dos clusters em relação aos VSAs correspondentes para verificar se os nós do plano de controle foram inicializados conforme o esperado.

A realização dessas validações pode ajudar você a alcançar as seguintes metas:

  • Garanta que o software no plano de controle esteja protegido pela inicialização segura e pelo monitoramento de integridade, corresponda ao código-fonte pretendido e seja exatamente o mesmo que a imagem usada por outros Google Cloud clientes.
  • Melhore sua confiança em como o GKE protege o plano de controle.

Preços

Esse recurso é oferecido sem custo extra no GKE.

Antes de começar

Antes de começar, verifique se você realizou as tarefas a seguir:

  • Ativar a API Google Kubernetes Engine.
    • Ativar a API Google Kubernetes Engine
  • Se você quiser usar a Google Cloud CLI para essa tarefa, instale e, em seguida, inicialize a CLI gcloud. Se você instalou a CLI gcloud anteriormente, instale a versão mais recente executando o comando gcloud components update. Talvez as versões anteriores da CLI gcloud não sejam compatíveis com a execução dos comandos neste documento.

  • Ativar a API Cloud Logging.

    Funções necessárias para ativar APIs

    Para ativar as APIs, é necessário ter a permissão serviceusage.services.enable. Se você criou o projeto, provavelmente já tem essa permissão pelo papel Proprietário (roles/owner). Caso contrário, é possível receber essa permissão pelo papel Administrador de uso do serviço (roles/serviceusage.serviceUsageAdmin). Saiba como conceder papéis.

    Ativar a API

  • Verifique se você já tem um cluster do GKE no modo Autopilot ou Standard executando a versão 1.29 ou mais recente.

Funções exigidas

Para receber as permissões necessárias para verificar a integridade da VM do plano de controle, peça ao administrador para conceder a você os seguintes papéis do IAM no projeto:

Para mais informações sobre a concessão de papéis, consulte Gerenciar o acesso a projetos, pastas e organizações.

Também é possível conseguir as permissões necessárias com papéis personalizados ou outros papéis predefinidos.

Verificar se há fases de sequência de inicialização com falha

O monitoramento de integridade adiciona um registro ao Logging se uma VM do plano de controle falhar ou concluir uma fase da sequência de inicialização. Para conferir eventos de inicialização com falha, execute os seguintes comandos:

  1. No Google Cloud console do, acesse a página Análise de registros:

    Acessar a Análise de registros

  2. No campo Consulta, insira a seguinte consulta:

    jsonPayload.@type="type.googleapis.com/cloud_integrity.IntegrityEvent"
jsonPayload.earlyBootReportEvent.policyEvaluationPassed="false" OR jsonPayload.lateBootReportEvent.policyEvaluationPassed="false"
jsonPayload.metadata.isKubernetesControlPlaneVM="true"

    Também é possível verificar eventos de inicialização bem-sucedidos substituindo false por true nesta consulta.

  3. Clique em Executar consulta. Se você não encontrar resultados, as VMs do plano de controle passaram em todas as verificações de monitoramento de integridade. Se você encontrar uma saída, siga para a próxima etapa para identificar o cluster correspondente.

  4. No registro de integridade de inicialização com falha, copie o valor no campo resource.labels.instance_id.

  5. No campo Consulta, insira a seguinte consulta:

    protoPayload.@type="type.googleapis.com/google.cloud.audit.AuditLog"
protoPayload.metadata.isKubernetesControlPlaneVM="true"
resource.labels.instance_id="INSTANCE_ID"
protoPayload.methodName="v1.compute.instances.insert"

    Substitua INSTANCE_ID pelo valor do campo instance_id da etapa anterior.

  6. Clique em Executar consulta. O valor no campo protoPayload.metadata.parentResource.parentResourceId é o ID do cluster do GKE.

  7. Encontre o nome do cluster do GKE:

    gcloud asset query \
    --organization=ORGANIZATION_ID \
    --statement="SELECT name FROM container_googleapis_com_Cluster WHERE resource.data.id='CLUSTER_ID';"

    Substitua:

    • ORGANIZATION_ID: o ID numérico da sua Google Cloud organização.
    • CLUSTER_ID: o valor do campo protoPayload.metadata.parentResource.parentResourceId da etapa anterior.

    O resultado será assim:

    # lines omitted for clarity
//container.googleapis.com/projects/PROJECT_ID/locations/LOCATION/clusters/CLUSTER_NAME

    Essa saída tem os seguintes campos:

    • PROJECT_ID: o ID do Google Cloud projeto.
    • LOCATION: o local do cluster.
    • CLUSTER_NAME: o nome do cluster.

Encontrar e inspecionar os registros de VM do plano de controle

Os registros de criação de VM do Compute Engine que correspondem aos clusters do GKE são armazenados no _Default bucket de registros. Para encontrar os registros de criação das VMs do plano de controle do cluster e recuperar esses metadados, faça o seguinte:

  1. No Google Cloud console do, acesse a página Análise de registros:

    Acessar a Análise de registros

  2. No campo Consulta, insira a seguinte consulta:

    resource.type="gce_instance"
protoPayload.methodName="v1.compute.instances.insert"
protoPayload.metadata.isKubernetesControlPlaneVM="true"

  3. Clique em Executar consulta. Se você não encontrar resultados, verifique se atende a todos os requisitos na seção Antes de começar.

  4. Nos resultados da consulta, verifique o campo metadata. O resultado será assim:

    # fields omitted for clarity
"metadata": {
  "usedResources": {
    "attachedDisks": [
      {
        "sourceImageId": "9046093115864736653",
        "sourceImage": "https://www.googleapis.com/compute/v1/projects/1234567890/global/images/gke-1302-gke1627000-cos-113-18244-85-49-c-pre",
        "isBootDisk": true
      }
# fields omitted for clarity

    O campo metadata inclui as seguintes informações:

    • usedResources: a lista de recursos usados para criar a VM.
    • attachedDisks: o disco de inicialização da VM.
    • sourceImageId: o ID exclusivo da imagem da VM.
    • sourceImage: o URL da imagem da VM de origem. A sintaxe do valor nesse campo é https://www.googleapis.com/compute/v1/projects/PROJECT_NUMBER/global/images/IMAGE_NAME, em que PROJECT_NUMBER é o número do projeto de propriedade do Google Cloudque hospeda as VMs do plano de controle e IMAGE_NAME é o nome da imagem usada para inicializar a VM.
    • isBootDisk: um identificador booleano para indicar se esse disco foi usado como disco de inicialização da VM.

Encontrar e verificar o VSA para imagens de VM do plano de controle

Nesta seção, você vai encontrar o VSA que corresponde à imagem de VM do plano de controle no repositório gke-vsa no GitHub. Em seguida, use uma ferramenta chamada slsa-verifier fornecida pelo framework Níveis da cadeia de suprimentos para artefatos de software (SLSA) para verificar o VSA. Você precisa dos seguintes dados do registro de criação de VM do plano de controle:

  • O ID da imagem da VM
  • O número do projeto de propriedade do Google Cloudque hospeda as VMs
  • O nome da imagem do SO que foi usada para inicializar a VM

O arquivo que corresponde à VM do plano de controle tem o seguinte formato de nome de arquivo:

IMAGE_NAME:IMAGE_ID.intoto.jsonl

Substitua:

  • IMAGE_NAME: o nome da imagem da VM, que é a string após /images/ no campo attachedDisks.sourceImage no registro de auditoria da VM da seção anterior. Por exemplo, gke-1302-gke1627000-cos-113-18244-85-49-c-pre.
  • IMAGE_ID: o ID da imagem da VM, que é o valor do campo attachedDisks.sourceImageId no registro de auditoria da VM da seção anterior. Por exemplo, 9046093115864736653.

Para encontrar e verificar o VSA quando você souber o nome do arquivo VSA, siga estas etapas:

  1. Abra o gke-vsa repositório do GitHub.
  2. No diretório "gke-master-images", encontre o arquivo que corresponde à imagem da VM. Por exemplo, https://github.com/GoogleCloudPlatform/gke-vsa/blob/main/gke-master-images:78064567238/IMAGE_NAME:IMAGE_ID.intoto.jsonl
  3. Faça o download do arquivo VSA.
  4. Instale a ferramenta slsa-verifier tool.

  5. Salve a chave pública para verificar o VSA em um arquivo chamado vsa_signing_public_key:

    -----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEeGa6ZCZn0q6WpaUwJrSk+PPYEsca
3Xkk3UrxvbQtoZzTmq0zIYq+4QQl0YBedSyy+XcwAMaUWTouTrB05WhYtg==
-----END PUBLIC KEY-----

  6. Verifique o VSA:

    slsa-verifier verify-vsa \
    --attestation-path=PATH_TO_VSA_FILE \
    --resource-uri=gce_image://gke-master-images:IMAGE_NAME \
    --subject-digest=gce_image_id:IMAGE_ID\
    --verifier-id=https://bcid.corp.google.com/verifier/bcid_package_enforcer/v0.1 \
    --verified-level=BCID_L1 \
    --verified-level=SLSA_BUILD_LEVEL_2 \
    --public-key-path=PATH_TO_PUBLIC_KEY_FILE \
    --public-key-id=keystore://76574:prod:vsa_signing_public_key

    Substitua:

    • PATH_TO_VSA_FILE: o caminho para o arquivo VSA que você fez o download.
    • IMAGE_NAME: o nome da imagem da VM, como gke-1302-gke1627000-cos-113-18244-85-49-c-pre.
    • IMAGE_ID: o ID da imagem da VM, como 9046093115864736653.

    Se o VSA passar nas verificações, a saída será a seguinte:

    Verifying VSA: PASSED
PASSED: SLSA verification passed

A seguir