Resolver problemas com cargas de trabalho e listas de permissões privilegiadas do Autopilot

As cargas de trabalho privilegiadas nos clusters do Google Kubernetes Engine (GKE) Autopilot precisam ser configuradas corretamente para evitar problemas. Configurações incorretas podem causar falhas de sincronização com listas de permissão ou rejeição da carga de trabalho. Esses problemas podem impedir que agentes ou serviços essenciais sejam executados com as permissões necessárias.

Use este documento para resolver problemas com a implantação de cargas de trabalho privilegiadas no Autopilot. Encontre orientações sobre como resolver erros de sincronização da lista de permissões e diagnosticar por que uma carga de trabalho privilegiada pode ser rejeitada.

Essas informações são importantes para administradores e operadores da plataforma e equipes de segurança que implantam cargas de trabalho com permissões elevadas em clusters do Autopilot. Para mais informações sobre as funções comuns e as tarefas de exemplo que mencionamos no conteúdo do Google Cloud , consulte Funções e tarefas comuns do usuário do GKE.

Problemas de sincronização da lista de permissão

Quando você implanta um AllowlistSynchronizer, o GKE tenta instalar e sincronizar os arquivos de lista de permissões especificados. Se essa sincronização falhar, o campo status do AllowlistSynchronizer vai informar o erro.

Confira o status do objeto AllowlistSynchronizer:

kubectl get allowlistsynchronizer ALLOWLIST_SYNCHRONIZER_NAME -o yaml

Substitua ALLOWLIST_SYNCHRONIZER_NAME pelo nome do AllowlistSynchronizer.

O resultado será o seguinte:

...
status:
  conditions:
  - type: Ready
    status: "False"
    reason: "SyncError"
    message: "some allowlists failed to sync: example-allowlist-1.yaml"
    lastTransitionTime: "2024-10-12T10:00:00Z"
    observedGeneration: 2
  managedAllowlistStatus:
    - filePath: "gs://path/to/allowlist1.yaml"
      generation: 1
      phase: Installed
      lastSuccessfulSync: "2024-10-10T10:00:00Z"
    - filePath: "gs://path/to/allowlist2.yaml"
      phase: Failed
      lastError: "Initial install failed: invalid contents"
      lastSuccessfulSync: "2024-10-08T10:00:00Z"

Os campos conditions.message e managedAllowlistStatus.lastError fornecem informações detalhadas sobre o erro. Use essas informações para resolver o problema.

Vários AllowlistSynchronizers

Em clusters do GKE em versões anteriores à 1.33.4-gke.1035000, a instalação do WorkloadAllowlists pode falhar se mais de um AllowlistSynchronizer estiver presente.

Para resolver o problema, use apenas um AllowlistSynchronizer que contenha vários allowlistPaths.

Como alternativa, faça upgrade do cluster para uma versão mais recente.

Classificação de contêineres de carga de trabalho

Em clusters do GKE em versões anteriores a 1.34.0-gke.0000000, se uma ou mais imagens de contêiner de carga de trabalho corresponderem a uma imagem de contêiner especificada em uma lista de permissões de carga de trabalho no cluster, os contêineres de carga de trabalho poderão ser criados e classificados em ordem alfabética inversa.

Para resolver esse problema, tente as seguintes opções:

  • Faça upgrade do cluster para a versão 1.34.0-gke.0000000 ou mais recente.
  • Renomeie os contêineres da sua carga de trabalho para que eles sejam classificados na ordem correta.

Problemas de implantação de carga de trabalho privilegiada

Depois de instalar uma lista de permissões, implante a carga de trabalho privilegiada correspondente no cluster. Em alguns casos, o GKE pode rejeitar a carga de trabalho.

Tente as seguintes opções de resolução:

  • Verifique se a versão do GKE do cluster atende ao requisito de versão da carga de trabalho.
  • Verifique se a carga de trabalho que você está implantando é aquela a que o arquivo de lista de permissões se aplica.

Para saber por que uma carga de trabalho privilegiada foi rejeitada, solicite informações detalhadas do GKE sobre violações da lista de permissões:

  1. Confira uma lista das allowlists instaladas no cluster:

    kubectl get workloadallowlist

    Encontre o nome da lista de permissões que deve ser aplicada à carga de trabalho privilegiada.

  2. Abra o manifesto YAML da carga de trabalho privilegiada em um editor de texto. Se você não conseguir acessar os manifestos YAML, por exemplo, se o processo de implantação da carga de trabalho usar outras ferramentas, entre em contato com o provedor da carga de trabalho para abrir um problema. Ignore as demais etapas.

  3. Adicione o seguinte rótulo à seção spec.metadata.labels da especificação do pod de carga de trabalho privilegiada:

    labels:
  cloud.google.com/matching-allowlist: ALLOWLIST_NAME

    Substitua ALLOWLIST_NAME pelo nome da lista de permissões que você recebeu na etapa anterior. Use o nome da saída do comando kubectl get workloadallowlist, não o caminho para o arquivo de permissão.

  4. Salve o manifesto e aplique a carga de trabalho ao cluster:

    kubectl apply -f WORKLOAD_MANIFEST_FILE

    Substitua WORKLOAD_MANIFEST_FILE pelo caminho para o arquivo de manifesto.

    A saída fornece informações detalhadas sobre quais campos na carga de trabalho não corresponderam à lista de permissões especificada, como no exemplo a seguir:

    Error from server (GKE Warden constraints violations): error when creating "STDIN": admission webhook "warden-validating.common-webhooks.networking.gke.io" denied the request:

===========================================================================
Workload Mismatches Found for Allowlist (example-allowlist-1):
===========================================================================
HostNetwork Mismatch: Workload=true, Allowlist=false
HostPID Mismatch: Workload=true, Allowlist=false
Volume[0]: data
         - data not found in allowlist. Verify volume with matching name exists in allowlist.
Container[0]:
- Envs Mismatch:
        - env[0]: 'ENV_VAR1' has no matching string or regex pattern in allowlist.
        - env[1]: 'ENV_VAR2' has no matching string or regex pattern in allowlist.
- Image Mismatch: Workload=k8s.gcr.io/diff/image, Allowlist=k8s.gcr.io/pause2. Verify that image string or regex match.
- SecurityContext:
        - Capabilities.Add Mismatch: the following added capabilities are not permitted by the allowlist: [SYS_ADMIN SYS_PTRACE]
- VolumeMount[0]: data
        - data not found in allowlist. Verify volumeMount with matching name exists in allowlist.

    Neste exemplo, ocorrem as seguintes violações:

    • A carga de trabalho especifica hostNetwork: true, mas a lista de permissões não especifica hostNetwork: true.
    • A carga de trabalho especifica hostPID: true, mas a lista de permissões não especifica hostPID: true.
    • A carga de trabalho especifica um volume chamado data, mas a lista de permissões não especifica um volume chamado data.
    • O contêiner especifica variáveis de ambiente chamadas ENV_VAR1 e ENV_VAR2, mas a lista de permissões não especifica essas variáveis de ambiente.
    • O contêiner especifica a imagem k8s.gcr.io/diff/image, mas a lista de permissões especifica k8s.gcr.io/pause2.
    • O contêiner adiciona os recursos SYS_ADMIN e SYS_PTRACE, mas a lista de permissões não permite isso.
    • O contêiner especifica uma montagem de volume chamada data, mas a lista de permissões não especifica uma montagem de volume chamada data.

Se você estiver implantando uma carga de trabalho de propriedade de um provedor terceirizado, abra um problema com esse provedor para resolver as violações. Forneça a saída da etapa anterior no problema.

Versão incompatível do GKE

O GKE pode rejeitar uma carga de trabalho se a lista de permissões especificar uma versão mínima do GKE mais recente que a versão do GKE do cluster.

  1. Verifique se a lista de permissões especifica uma versão mínima do GKE:

    kubectl describe workloadallowlist ALLOWLIST_NAME | grep "minGKEVersion"

    Substitua ALLOWLIST_NAME pelo nome da lista de permissões.

    Se a saída estiver vazia, a lista de permissões não especificará uma versão mínima do GKE. Pule esta seção. Se a saída for um valor, a lista de permissões vai especificar uma versão mínima do GKE.

  2. Verifique a versão do GKE do cluster:

    gcloud container clusters describe CLUSTER_NAME \
    --location=CLUSTER_LOCATION \
    --format="value(currentMasterVersion)"

    Substitua:

    • CLUSTER_NAME: o nome do cluster.
    • CLUSTER_LOCATION: o local Google Cloud do cluster.

    O resultado será o seguinte:

    1.32.3-gke.1006000

  3. Se a versão do GKE do cluster for anterior à versão mínima do GKE da lista de permissões, faça upgrade do cluster para a versão mínima do GKE da lista de permissões ou posterior. Para mais informações, consulte Fazer upgrade do cluster.

Quando o upgrade for concluído, tente implantar a carga de trabalho no cluster.

Incompatibilidades de strings

Campos específicos na especificação "WorkloadAllowlist" precisam ser correspondências exatas de string dos campos correspondentes na especificação da carga de trabalho.

  1. Abra a página de referência da CustomResourceDefinition (CRD) WorkloadAllowlist.
  2. Para cada campo na especificação "WorkloadAllowlist", verifique se o CRD exige uma correspondência exata de string.

  3. Para cada campo que exige uma correspondência exata de string, verifique se o valor na especificação "WorkloadAllowlist" corresponde ao valor correspondente na especificação da carga de trabalho.

    Por exemplo, todos os comandos executados por um contêiner precisam corresponder exatamente a um comando na lista de permissões. Qualquer desvio do comando exato resulta em uma rejeição.

Se houver uma incompatibilidade, atualize a especificação WorkloadAllowlist para corresponder à especificação da carga de trabalho.

Incompatibilidades de expressão regular

Campos específicos na especificação WorkloadAllowlist são compatíveis com a correspondência de expressões regulares.

  1. Na especificação WorkloadAllowlist, encontre os campos que especificam expressões regulares.

  2. Verifique se a sintaxe da expressão regular está correta. O CRD WorkloadAllowlist aceita a sintaxe de expressão regular RE2 do Google. Valide se as expressões têm as seguintes propriedades:

    • A expressão regular começa com o caractere ^ e termina com o caractere $. Por exemplo, ^example-auth\.google\.com\/go_[a-z0-9]+\/google\/path$.
    • Cada caractere especial tem escape com o caractere de escape \. Procure caracteres \ extras ou ausentes.
    • Os caminhos de imagem na lista de permissões não incluem tags nem resumos. Por exemplo, use k8s.gcr.io/pause em vez de k8s.gcr.io/pause:3.1 ou k8s.gcr.io/pause@sha256:1234567890.

Depois de corrigir os problemas de expressão regular, tente implantar a carga de trabalho no cluster.

Fazer escape de caracteres em comandos e argumentos

O GKE não pode corresponder comandos e argumentos se você não usar o escape dos caracteres especiais. Os requisitos para caracteres de escape dependem de como você aplica a lista de permissões. Por exemplo, aplicar uma lista de permissões como um arquivo YAML ou JSON tem requisitos de escape diferentes de criar uma especificação de lista de permissões usando uma ferramenta de linha de comando. Esta seção descreve os requisitos de escape para arquivos YAML.

Faça o escape de todos os caracteres especiais nos campos commands e args da especificação WorkloadAllowlist, mesmo que você não use uma expressão regular. Para escapar caracteres especiais, use o caractere \, como nos exemplos a seguir:

  • Comando: kubectl describe \$\{POD_NAME\}
  • Argument: hostname \$NODE_NAME; dcgm-exporter --remote-hostengine-info \$\(NODE_IP\) --collectors /etc/dcgm-exporter/counters.csv

Interferência de webhook com cargas de trabalho em uma lista de permissões

Em alguns casos, mesmo que uma carga de trabalho esteja configurada corretamente para corresponder a uma lista de permissões, ela ainda pode ser rejeitada pelo GKE. Essa situação pode ocorrer se outro controlador de admissão (webhook) no cluster modificar os pods criados pelo controlador de carga de trabalho depois que eles forem permitidos pela lista de permissões. Essas modificações podem fazer com que a especificação do pod não corresponda mais à lista de permissões, resultando em rejeição pelo webhook de admissão do GKE Warden.

Esse problema é comum com agentes de segurança e monitoramento de terceiros que inserem contêineres sidecar ou variáveis de ambiente em pods.

O sintoma mais comum é que o controlador de carga de trabalho (como um DaemonSet ou uma implantação) é criado, mas não cria nenhum pod. Ao inspecionar os eventos do controlador, você vai encontrar mensagens indicando que os pods foram negados pelo webhook de admissão.

  1. Siga as etapas na seção Problemas de implantação de carga de trabalho privilegiada para adicionar o rótulo cloud.google.com/matching-allowlist à sua carga de trabalho.
  2. Copie o spec.template do manifesto YAML da sua carga de trabalho.
  3. Crie um manifesto de pod e cole a especificação copiada no campo spec.

  4. Defina os campos apiVersion, kind e metadata.name no manifesto do pod:

    apiVersion: v1
kind: Pod
metadata:
  name: POD_NAME
  labels:
    cloud.google.com/matching-allowlist: ALLOWLIST_NAME
spec:
  # Paste the content of spec.template here

    Substitua:

    • POD_NAME: o nome do pod de teste.
    • ALLOWLIST_NAME: o nome da lista de permissões.

  5. Aplique o manifesto do pod:

    kubectl apply -f YOUR_POD_MANIFEST_FILE

    Substitua YOUR_POD_MANIFEST_FILE pelo caminho para o arquivo de manifesto do pod.

  6. Inspecione a saída da etapa anterior. Se você encontrar campos inesperados na seção "Incompatibilidades de carga de trabalho", como variáveis de ambiente extras (por exemplo, DD_AGENT_HOST), contêineres ou volumes, isso indica que outro webhook está modificando seus pods.

Para resolver esse problema, configure o webhook conflitante para excluir a modificação dos pods da carga de trabalho na lista de permissões. Isso geralmente é feito adicionando um rótulo ou uma anotação à carga de trabalho ou ao namespace dela para sinalizar ao webhook que ela precisa ser excluída da mutação. Por exemplo, com o Datadog, adicione o rótulo admission.datadoghq.com/enabled: "false" ao namespace da sua carga de trabalho.

Consulte a documentação do software de terceiros específico que você está usando para saber como excluir cargas de trabalho do controlador de admissão.

Ao impedir que o outro webhook modifique os pods, você ajuda a garantir que eles continuem correspondendo à lista de permissões e sejam implantados com sucesso no cluster do Autopilot.

Bugs e solicitações de recursos para cargas de trabalho privilegiadas e listas de permissões

Se você executar uma carga de trabalho privilegiada fornecida por um parceiro do GKE ou um provedor terceirizado, esse provedor será responsável por criar, desenvolver e manter as cargas de trabalho privilegiadas e as listas de permissões. Se você encontrar um bug ou tiver um pedido de recurso para uma carga de trabalho privilegiada ou uma lista de permissões de parceiro ou terceirizada, entre em contato com o provedor.

A seguir

  • Se você não encontrar uma solução para seu problema na documentação, consulte Receber suporte para mais ajuda, incluindo conselhos sobre os seguintes tópicos: