Resolver problemas na implantação de cargas de trabalho 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 fazer com que a carga de trabalho seja rejeitada. 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

Ao implantar 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.

Acesse o status do objeto AllowlistSynchronizer:

kubectl get allowlistsynchronizer ALLOWLIST_SYNCHRONIZER_NAME -o yaml

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ões.

  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 fornecida por um provedor terceirizado, abra um problema com esse provedor para resolver as violações. Forneça a saída da etapa anterior no problema.

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.

Sintoma

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.

Diagnóstico

  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.

Resolução

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

Os parceiros são responsáveis 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, entre em contato com o parceiro correspondente.

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: