O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Migrar do Controlador de Políticas

Autopilot Standard

Neste documento, explicamos como migrar suas políticas de admissão do Policy Controller para reduzir o risco de lacunas na aplicação de políticas. O Controlador de Políticas foi descontinuado em 12 de novembro de 2026 e o suporte vai terminar em 31 de dezembro de 2027. Na versão 1.39 e posteriores, os clusters do Google Kubernetes Engine (GKE) não são compatíveis com o Controlador de Políticas.

É possível migrar as políticas de admissão que você aplica usando o Controlador de Políticas para as ValidatingAdmissionPolicies do Kubernetes ou para o Open Policy Agent (OPA) Gatekeeper autogerenciado. A migração não afeta as cargas de trabalho que já estão em execução. O Controlador de Políticas avalia as solicitações para criar ou atualizar recursos. Portanto, removê-lo não reinicia nem altera as cargas de trabalho em execução.

Este documento é destinado a operadores e especialistas em segurança que gerenciam o Controlador de Políticas em uma frota. Para saber mais sobre os papéis comuns e as tarefas de exemplo mencionados no conteúdo doGoogle Cloud , consulte Tarefas e papéis de usuário comuns do GKE.

Upgrades bloqueados para a versão 1.39 do GKE

O GKE bloqueia upgrades para a versão 1.39 e posteriores em clusters que têm o Controlador de Políticas instalado. Antes de fazer upgrade de um cluster para a versão 1.39, migre suas políticas e remova o Controlador de Políticas desse cluster. Não remova o Policy Controller apenas para desbloquear o upgrade antes de migrar as políticas, porque isso deixa o cluster sem aplicação de políticas.

Escolher uma substituição

Avalie cada política de admissão no Controlador de Políticas e escolha uma opção de substituição para essa política na tabela a seguir. Não é preciso escolher uma substituição para um cluster inteiro. É possível combinar opções no mesmo cluster com base no que cada política exige:

Comparação das opções de substituição do Controlador de Políticas
Opção	Quando usar	Operação e suporte
ValidatingAdmissionPolicy (recomendado)	Políticas que verificam um único recurso quando ele é criado ou atualizado. A maioria dos modelos na biblioteca de modelos do Controlador de Políticas funciona dessa maneira.	As ValidatingAdmissionPolicies são integradas ao Kubernetes e estão disponíveis na versão 1.30 e posteriores do GKE sem custo financeiro adicional. O Cloud Customer Care é compatível com ValidatingAdmissionPolicies como parte do GKE.
Admissão de segurança de pods (recomendado para pacotes de segurança de pods)	Controles de segurança predefinidos de pods do pacote `pss-baseline-v2022`, `pss-restricted-v2022` ou `psp-v2022`. Para mais informações, consulte Usar a admissão de segurança de pods para pacotes de segurança de pods.	A admissão de segurança de pods é integrada ao Kubernetes e ativada por padrão no GKE sem custo financeiro adicional. O Atendimento ao cliente oferece suporte à Admissão de Segurança de Pods como parte do GKE.
OPA Gatekeeper autogerenciado	Políticas que as ValidatingAdmissionPolicies não podem expressar, como políticas referenciais que leem outros recursos no cluster, políticas que você quer manter no Rego e auditorias de recursos atuais. Também é possível adicionar regras da Common Expression Language (CEL) aos ConstraintTemplates do Gatekeeper para que ele gere ValidatingAdmissionPolicies para a aplicação do servidor de API, e o controlador de auditoria verifique os recursos atuais.	Você instala, faz upgrade e opera o Gatekeeper. O Atendimento ao cliente não oferece suporte ao Gatekeeper de código aberto. A comunidade do Gatekeeper oferece suporte pelo GitHub.

Inventariar e classificar suas políticas

Por padrão, a biblioteca de modelos do Controlador de Políticas instala todos os modelos, e os pacotes de políticas instalam as restrições com a ação de fiscalização dryrun. Como resultado, os modelos e as restrições em um cluster não correspondem necessariamente às políticas que você aplica. Para descobrir o que você aplica, siga estas etapas:

Identifique os clusters na frota que executam o Controlador de Políticas:
```
gcloud container fleet policycontroller describe \
    --project=PROJECT_ID
```
Substitua PROJECT_ID pelo ID do projeto host da frota.

Observação: é possível ter clusters fora de uma frota que executa o Controlador de Políticas, como clusters em que você instalou o Controlador de Políticas usando o operador ConfigManagement ou clusters que você cancelou o registro de uma frota sem desinstalar o Controlador de Políticas. Esses clusters não aparecem na saída do comando anterior. Para verificar se um cluster executa o Controlador de Políticas, consulte Ver a versão do Controlador de Políticas. Para remover o Controlador de Políticas desses clusters, consulte Remover o Controlador de Políticas de clusters fora de uma frota.
Em cada cluster identificado, liste as restrições:
```
kubectl get constraints \
    -o custom-columns='KIND:.kind,NAME:.metadata.name,'\
'ACTION:.spec.enforcementAction,VIOLATIONS:.status.totalViolations,'\
'BUNDLE:.metadata.labels.policycontroller\.gke\.io/bundleName'
```
A saída mostra a ação de fiscalização de cada restrição, a contagem de violações da auditoria mais recente e qualquer pacote que a tenha instalado. Uma restrição que não tem valor na coluna ACTION usa a ação de aplicação padrão deny.

Faça backup dos ConstraintTemplates e das restrições em arquivos separados:

kubectl get constrainttemplates -o yaml \
    > policy-controller-templates-backup.yaml
kubectl get constraints -o yaml \
    > policy-controller-constraints-backup.yaml

Opcional: realize as seguintes operações de backup adicionais:
- Se você ativou as regras referenciais no Controlador de Políticas, faça backup da configuração de sincronização:
```
kubectl get config.config.gatekeeper.sh -n gatekeeper-system -o yaml \
    > policy-controller-config-backup.yaml
```
- Se você ativou a mutação no Controlador de Políticas, faça backup dos mutadores:
```
kubectl get assign,assignmetadata,assignimage,modifyset -o yaml \
    > policy-controller-mutators-backup.yaml
```

Mantenha esses arquivos de backup em um local seguro. A remoção do Controlador de Políticas exclui todos os ConstraintTemplates, restrições, configurações de sincronização e mutadores no cluster, incluindo os que você criou. Você precisa dos backups para traduzir ou recriar suas políticas.

Depois de fazer backup das políticas, determine o caminho de migração para cada restrição verificando o tipo de restrição na tabela a seguir:

Caminhos de migração por tipo de restrição
Tipo de restrição	Caminho de migração
Restrição de recurso único	Se uma restrição avaliar campos apenas no recurso de entrada sem ler `data.inventory` ou pertencer a um pacote de segurança de pod, use uma ValidatingAdmissionPolicy.
Restrição `dryrun` não aplicada	Se uma restrição usar a ação de aplicação `dryrun` e você não planejar aplicá-la, exclua a restrição.
Restrição do pacote de segurança de pods	Se uma restrição vier do pacote `pss-baseline-v2022`, `pss-restricted-v2022` ou `psp-v2022`, use a admissão de segurança do pod. Use ValidatingAdmissionPolicies para todos os controles que a admissão de segurança de pods não abrange.
Restrição referencial	Se uma restrição usar um modelo referencial que lê outros recursos no cluster, use o Gatekeeper autogerenciado. Para encontrar modelos referenciais, pesquise a referência `data.inventory` no arquivo de backup.
Restrição do Cloud Service Mesh, do Istio ou do Google Cloud	Analise a restrição individualmente para verificar se um recurso integrado do GKE substitui a política ou se o ConstraintTemplate no arquivo de backup lê `data.inventory`. A maioria desses modelos verifica apenas o recurso de entrada e funciona em ValidatingAdmissionPolicies, exceto os modelos referenciais `AsmAuthzPolicyDefaultDeny` e `AsmPeerAuthnMeshStrictMtls`, que exigem o Gatekeeper autogerenciado. Para substituições integradas, ative a autorização binária em vez de usar o ConstraintTemplate `K8sRequireBinAuthZ` e configure a imagem de nó dos pools de nós em vez de usar o ConstraintTemplate `K8sRequireCosNodeImage`.

Migrar para ValidatingAdmissionPolicy

Uma ValidatingAdmissionPolicy contém a lógica da política, como um ConstraintTemplate. Uma ValidatingAdmissionPolicyBinding aplica a política, como uma restrição. Uma ValidatingAdmissionPolicy usa expressões CEL em vez de Rego, e o servidor de API avalia as expressões diretamente, sem um webhook.

Exemplo: repositórios de imagens permitidos

A restrição do Controlador de Políticas a seguir exige que os pods usem imagens de um repositório do Artifact Registry. Ele exclui o namespace kube-system:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sAllowedRepos
metadata:
  name: allowed-repos
spec:
  enforcementAction: deny
  match:
    kinds:
    - apiGroups: [""]
      kinds: ["Pod"]
    excludedNamespaces: ["kube-system"]
  parameters:
    repos:
    - "us-docker.pkg.dev/example-project/example-repo/"

O ValidatingAdmissionPolicy e o ValidatingAdmissionPolicyBinding a seguir aplicam a mesma regra. O ValidatingAdmissionPolicyBinding usa as ações Warn e Audit para que você possa comparar os resultados antes de aplicar a ValidatingAdmissionPolicy:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: allowed-repos
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
    - apiGroups: [""]
      apiVersions: ["v1"]
      operations: ["CREATE", "UPDATE"]
      resources: ["pods", "pods/ephemeralcontainers"]
  variables:
  - name: repos
    expression: "['us-docker.pkg.dev/example-project/example-repo/']"
  - name: images
    expression: >-
      object.spec.containers.map(c, c.image) +
      (has(object.spec.initContainers) ?
        object.spec.initContainers.map(c, c.image) : []) +
      (has(object.spec.ephemeralContainers) ?
        object.spec.ephemeralContainers.map(c, c.image) : [])
  validations:
  - expression: >-
      variables.images.all(image,
        variables.repos.exists(repo, image.startsWith(repo)))
    messageExpression: >-
      'container images must come from one of these repositories: ' +
      variables.repos.join(', ')
    reason: Forbidden
---
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: allowed-repos
spec:
  policyName: allowed-repos
  validationActions: ["Warn", "Audit"]
  matchResources:
    namespaceSelector:
      matchExpressions:
      - key: kubernetes.io/metadata.name
        operator: NotIn
        values: ["kube-system", "gatekeeper-system"]

Neste exemplo, a variável repos contém o valor do campo parameters da restrição. A expressão de validação retorna um valor true para pods que obedecem à ValidatingAdmissionPolicy, que é o oposto de uma regra de violação do Rego. Para reutilizar uma ValidatingAdmissionPolicy em várias ValidatingAdmissionPolicyBindings que fornecem valores diferentes, use um recurso de parâmetro em vez de uma variável. Para mais informações sobre recursos de parâmetros, consulte Recursos de parâmetros na documentação do Kubernetes.

A tabela a seguir mostra como os campos de restrição são mapeados para os campos ValidatingAdmissionPolicy e ValidatingAdmissionPolicyBinding:

Mapeamento de campos de restrição do Controlador de Políticas para campos ValidatingAdmissionPolicy e ValidatingAdmissionPolicyBinding
Campo de restrição	Campo ValidatingAdmissionPolicy ou ValidatingAdmissionPolicyBinding
`spec.enforcementAction`	O campo `validationActions` em ValidatingAdmissionPolicyBinding, que mapeia as ações `deny`, `warn` e `dryrun` para os valores `["Deny"]`, `["Warn"]` e `["Audit"]`.
`spec.parameters`	O campo `variables` na ValidatingAdmissionPolicy ou um recurso de parâmetro que o ValidatingAdmissionPolicyBinding referencia no campo `paramRef`.
`spec.match.kinds`	O campo `matchConstraints.resourceRules` na ValidatingAdmissionPolicy, que usa grupos de API e nomes de recursos, como o recurso `pods`, em vez de tipos.
`spec.match.namespaces` e `spec.match.excludedNamespaces`	O campo `matchResources.namespaceSelector` na ValidatingAdmissionPolicyBinding, usando o operador `In` ou `NotIn` no rótulo `kubernetes.io/metadata.name`.
`spec.match.labelSelector`	O campo `matchResources.objectSelector` no ValidatingAdmissionPolicyBinding
`spec.match.namespaceSelector`	O campo `matchResources.namespaceSelector` no ValidatingAdmissionPolicyBinding
`spec.match.scope`	O campo `scope` de cada regra de recurso

Para mais informações sobre como escrever expressões, consulte CEL no Kubernetes na documentação do Kubernetes.

Testar políticas com o Controlador de Políticas

Para substituir uma restrição sem uma lacuna na aplicação, execute a ValidatingAdmissionPolicy ao lado da restrição antes de aplicar a ValidatingAdmissionPolicy:

Aplique o ValidatingAdmissionPolicy e um ValidatingAdmissionPolicyBinding que tenha a configuração validationActions: ["Warn", "Audit"]. Deixe a restrição do Controlador de Políticas em vigor.
Compare os resultados usando a consulta do registro de auditoria em Substituir relatórios de violação. Se o ValidatingAdmissionPolicy sinalizar solicitações que o Controlador de Políticas permite, ou o inverso, corrija o ValidatingAdmissionPolicy. Para ValidatingAdmissionPolicies que correspondem a pods, não confie em avisos. Os controladores criam os pods para implantações e outras cargas de trabalho, de modo que o controlador recebe o aviso.
Depois que os resultados corresponderem, mude o ValidatingAdmissionPolicyBinding para usar a configuração validationActions: ["Deny"].
Exclua a restrição do Controlador de Políticas.

Planejar as diferenças de comportamento

As ValidatingAdmissionPolicies se comportam de maneira diferente do Policy Controller das seguintes maneiras, o que pode bloquear solicitações ou deixar lacunas na aplicação:

Política de falha: o webhook do Controlador de Políticas falha ao abrir, o que significa que o servidor de API aceita uma solicitação se o Controlador de Políticas não responder. Uma ValidatingAdmissionPolicy que tem a configuração failurePolicy: Fail nega uma solicitação se uma expressão retornar um erro ou exceder o limite de custo da CEL. A ValidatingAdmissionPolicy também nega uma solicitação se um recurso de parâmetro referenciado não existe e o valor do campo paramRef.parameterNotFoundAction na ValidatingAdmissionPolicyBinding é Deny. Se o valor for Allow, o servidor de API vai ignorar um recurso de parâmetro ausente, independentemente da configuração de failurePolicy. Teste cada ValidatingAdmissionPolicy e escolha valores para os dois campos.
Campos ausentes: o Rego trata um campo ausente como não violação, mas o CEL retorna um erro. Antes de ler um campo opcional, use a macro has() para verificar se o campo existe.
Isenções: uma ValidatingAdmissionPolicy não isenta namespaces por padrão nem usa o rótulo admission.gatekeeper.sh/ignore. Em clusters do GKE Standard, um ValidatingAdmissionPolicyBinding se aplica a todos os namespaces no cluster, incluindo namespaces do sistema, como o namespace kube-system, a menos que você os exclua no campo matchResources.namespaceSelector no ValidatingAdmissionPolicyBinding ou nos campos matchConstraints.namespaceSelector ou matchConditions no ValidatingAdmissionPolicy. Em clusters do Autopilot, o GKE exclui automaticamente os namespaces gerenciados e rejeita as ValidatingAdmissionPolicies que correspondem aos recursos nodes, persistentVolumes, certificatesigningrequests ou tokenreviews. Para mais informações, consulte Medidas de segurança do Autopilot do GKE.
Sub-recursos: o Controlador de Políticas verifica as atualizações de pods que adicionam contêineres temporários. Para manter essa cobertura, inclua o sub-recurso pods/ephemeralcontainers nas regras de recursos, como no exemplo.
Nenhuma auditoria de recursos atuais: uma ValidatingAdmissionPolicy avalia apenas as solicitações recebidas do servidor de API. Ele não informa recursos atuais que violam uma ValidatingAdmissionPolicy.
Uma mensagem para cada solicitação: uma ValidatingAdmissionPolicy informa a primeira validação que falha, não todas as violações.

Usar a admissão de segurança de pods para pacotes de segurança de pods

Se você usa os pacotes pss-baseline-v2022 ou pss-restricted-v2022, substitua o pacote pela Admissão de Segurança de Pod em vez de traduzir cada restrição. A Admissão de segurança de pods usa o controlador de admissão PodSecurity integrado do Kubernetes para aplicar regras predefinidas dos Padrões de segurança de pods do Kubernetes com base em rótulos de namespace. O pacote pss-baseline-v2022 corresponde ao nível baseline, e o pacote pss-restricted-v2022 corresponde ao nível restricted.

A admissão de segurança de pods não abrange todos os controles no pacote psp-v2022, como listas de permissões para caminhos de host, usuários, recursos e sysctls. Use ValidatingAdmissionPolicies para esses controles. A Admissão de segurança de pods também não pode isentar imagens específicas, como restrições do Controlador de Políticas que usam o parâmetro exemptImages. O GKE não é compatível com a configuração de isenções de admissão de segurança de pods. Se você precisar de exceções, use ValidatingAdmissionPolicies para as políticas afetadas.

Para mais informações sobre como configurar a Admissão de Segurança de Pods, consulte Aplicar políticas de segurança predefinidas no nível do pod usando o PodSecurity.

Migrar para o OPA Gatekeeper autogerenciado

Escolha o Gatekeeper para as políticas que as ValidatingAdmissionPolicies não podem expressar. O Controlador de Políticas é baseado no Gatekeeper, então os ConstraintTemplates e as restrições usam as mesmas APIs no Gatekeeper. Todos os modelos na biblioteca de modelos do Controlador de Políticas funcionam no Gatekeeper sem alterações na lógica. No entanto, o Gatekeeper usa um mecanismo Rego mais recente e uma validação mais rigorosa que pode rejeitar um ConstraintTemplate personalizado.

Ao usar o Gatekeeper autogerenciado, você se torna responsável pelas tarefas que o Google Cloud realiza para o Controlador de Políticas, como instalar, fazer upgrade, escalonar e monitorar o Gatekeeper em cada cluster. O Atendimento ao cliente não oferece suporte ao Gatekeeper de código aberto. Para receber ajuda, use o Issue Tracker do Gatekeeper no GitHub.

O Gatekeeper não inclui a biblioteca de modelos do Controlador de Políticas nem os pacotes de políticas. Os arquivos de backup contêm os ConstraintTemplates e as restrições dos clusters. Para modelos que se originaram na biblioteca de código aberto do Gatekeeper, use os modelos na biblioteca de políticas do Gatekeeper. Os nomes dos modelos permanecem os mesmos, mas os parâmetros e as mensagens podem ser diferentes entre as versões.

Para mover políticas para o Gatekeeper, siga estas etapas:

Opcional: se você não puder aceitar uma lacuna na aplicação enquanto substitui o Policy Controller, migre primeiro as políticas mais importantes para ValidatingAdmissionPolicies. Verifique se esses ValidatingAdmissionPolicyBindings excluem o namespace gatekeeper-system para que não bloqueiem os jobs de instalação do Gatekeeper. Depois de remover o Controlador de Políticas, o cluster vai parar de aplicar as políticas do Gatekeeper até que você aplique as restrições correspondentes. As ValidatingAdmissionPolicies continuam sendo aplicadas porque não dependem do Controlador de Políticas ou do Gatekeeper.
Se você usa ConstraintTemplates personalizados, teste cada manifesto de modelo personalizado usando a ferramenta de linha de comando gator da versão do Gatekeeper que você planeja instalar:
```
gator test --filename=TEMPLATE_FILE
```
Substitua TEMPLATE_FILE pelo caminho para o arquivo de manifesto ConstraintTemplate. Antes de remover o Controlador de Políticas, corrija qualquer ConstraintTemplate personalizado que o Gatekeeper rejeite.
Se você implantar restrições de um repositório Git usando uma ferramenta GitOps, prepare os ConstraintTemplates que as restrições usam e adicione-os ao repositório ao instalar o Gatekeeper. Caso contrário, as restrições não serão aplicadas depois que você remover o Controlador de Políticas, porque os ConstraintTemplates não vão mais existir.
Remova o Controlador de Políticas seguindo as etapas em Remover o Controlador de Políticas. Não instale o Gatekeeper em um cluster que ainda executa o Controlador de Políticas. Ambos usam o namespace gatekeeper-system, as mesmas CustomResourceDefinitions e os mesmos nomes de webhook.
Instale o Gatekeeper usando o Helm e as configurações escolhidas na tabela da próxima seção, Configurações do Gatekeeper que diferem do Controlador de Políticas. Para mais informações sobre como instalar o Gatekeeper, consulte Instalação na documentação do Gatekeeper.

Nos clusters do Autopilot, a instalação padrão do gráfico do Helm falha porque o GKE rejeita regras de caracteres curinga em webhooks de mutação. Defina o valor do Helm disableMutation: true ou defina o valor do Helm mutatingWebhookCustomRules para listar apenas os recursos específicos que os mutadores segmentam. Não inclua os recursos nodes, persistentvolumes, certificatesigningrequests ou tokenreviews.
Nos arquivos de backup, remova os seguintes campos, rótulos e anotações de cada recurso que você planeja reaplicar:
- O campo status.
- Os campos resourceVersion, uid, creationTimestamp, generation, managedFields e ownerReferences na seção metadata.
- A anotação kubectl.kubernetes.io/last-applied-configuration.
- O rótulo app.kubernetes.io/managed-by: anthospolicycontroller.googleapis.com. Se o Policy Controller for ativado novamente no cluster, por exemplo, por uma configuração padrão no nível da frota, ele vai gerenciar os recursos que têm esse rótulo e poderá modificá-los ou excluí-los.
- Rótulos e anotações com chaves que têm o prefixo policycontroller..
Aplique os ConstraintTemplates que suas restrições usam e verifique se o Gatekeeper criou uma CustomResourceDefinition para cada modelo:
```
kubectl get constrainttemplates \
    -o custom-columns='NAME:.metadata.name,CREATED:.status.created'
```
Quando todos os modelos mostrarem um valor true na coluna CREATED, aplique as restrições.

Configurações do Gatekeeper que diferem do Controlador de Políticas

Antes de instalar o Gatekeeper, revise as configurações na tabela a seguir, em que os padrões do gráfico do Helm do Gatekeeper são diferentes do Controlador de Políticas:

Comparação dos padrões do Controlador de Políticas e do gráfico do Helm do Gatekeeper
Configuração	Padrão do Policy Controller	Padrão do gráfico Helm do Gatekeeper	Recomendação
Mutação	Desativado, a menos que você o tenha ativado	Ativado	Se você não usar a mutação, defina o valor do Helm `disableMutation: true`. Em clusters do Autopilot, defina o valor do Helm `disableMutation: true` ou configure o valor do Helm `mutatingWebhookCustomRules` sem caracteres curinga ou recursos restritos. Se você não especificar um desses valores, o GKE vai rejeitar a instalação.
Namespaces isentos	O namespace `gatekeeper-system` e os namespaces na lista `exemptableNamespaces`	O namespace em que o Gatekeeper está instalado.	Adicione os namespaces isentos ao valor do Helm `controllerManager.exemptNamespaces`. O Gatekeeper rejeita alterações em namespaces que têm o rótulo `admission.gatekeeper.sh/ignore`, a menos que esses namespaces sejam isentos.
Dados referenciais	Sincronizados automaticamente para pacotes referenciais	Não sincronizado	Crie um Config ou SyncSet do Gatekeeper que liste os tipos lidos pelos modelos referenciais. Até que esses tipos sejam sincronizados com o objeto `data.inventory`, as verificações de conflito vão permitir solicitações de violação, e as verificações de existência, como o ConstraintTemplate `K8sRequireNamespaceNetworkPolicies`, vão negar todas as solicitações atendidas, mesmo quando o recurso necessário existir.
Geração de ValidatingAdmissionPolicy	Indisponível	Ativado para modelos que contêm código CEL	Os modelos do Controlador de Políticas contêm apenas Rego, então o Gatekeeper gera ValidatingAdmissionPolicies somente se você adicionar CEL aos seus ConstraintTemplates. Para manter a aplicação no webhook, defina os valores do Helm `defaultCreateVAPForTemplates: false` e `defaultCreateVAPBindingForConstraints: false`. Para mais informações, consulte Integração com a política de admissão de validação do Kubernetes na documentação do Gatekeeper.
Réplicas e recursos	Uma réplica para cada componente, com um limite de memória de 1.024 MiB	Três réplicas de webhook, com limites de recursos diferentes	Configure a contagem de réplicas e os limites de recursos com base no uso atual.
Imagens	Extraído de um registro gerenciado pelo Google	Extraídas do Docker Hub (as imagens `openpolicyagent/gatekeeper`, `openpolicyagent/gatekeeper-crds` e `curlimages/curl`)	Para clusters particulares ou que aplicam a autorização binária, espelhe as três imagens no Artifact Registry e substitua os valores de imagem no gráfico. Se você não espelhar a imagem `curlimages/curl`, desative o job de sondagem do webhook.

Por padrão, o Gatekeeper expõe apenas métricas do Prometheus, e os nomes das métricas são diferentes dos nomes que o Controlador de Políticas envia ao Cloud Monitoring. Atualize todos os painéis e alertas que usam métricas do Policy Controller.

Migrar políticas de mutação

Se você ativou a mutação no Controlador de Políticas, liste os mutadores:

kubectl get assign,assignmetadata,assignimage,modifyset

Para cada mutador, escolha uma destas opções:

MutatingAdmissionPolicy: é possível usar uma MutatingAdmissionPolicy no GKE versão 1.36 e mais recentes. Como uma ValidatingAdmissionPolicy, uma MutatingAdmissionPolicy usa expressões CEL e é executada no servidor de API sem um webhook. O Kubernetes executa todas as MutatingAdmissionPolicies antes das ValidatingAdmissionPolicies. Portanto, teste-as juntas para garantir que uma mutação não faça com que uma ValidatingAdmissionPolicy rejeite um manifesto válido. Em clusters do Autopilot, o GKE exclui namespaces gerenciados de MutatingAdmissionPolicies. Para mais informações sobre políticas de mutação, consulte Política de admissão de mutação na documentação do Kubernetes.
Gatekeeper autogerenciado: em clusters padrão, os mutadores funcionam sem mudanças porque o Gatekeeper ativa a mutação por padrão. Em clusters do Autopilot, é preciso definir o valor do Helm mutatingWebhookCustomRules no gráfico do Gatekeeper para listar os recursos específicos que os mutadores segmentam em vez de regras de caracteres curinga. Para mais informações, consulte Medidas de segurança do Autopilot do GKE. Depois de instalar o Gatekeeper, remova os metadados do Controlador de Políticas do arquivo de backup do mutador e reaplique os mutadores, como você faz para as restrições.

Atualizar verificações de políticas em pipelines de build

Seu pipeline de build pode verificar manifestos em relação às restrições do Controlador de Políticas antes da implantação. Por exemplo, o pipeline pode usar a função gatekeeper em kpt ou a ferramenta de linha de comando gator. Para mais informações, consulte Validar aplicativos em relação às políticas da empresa em um pipeline de CI.

Se o pipeline verificar manifestos, atualize-o para a substituição:

Se você usa o Gatekeeper, pode manter seu pipeline. Atualize os caminhos de arquivo ou diretório no comando gator ou kpt para fazer referência ao repositório ou diretório que contém os manifestos de restrição e ConstraintTemplate do Gatekeeper limpos.
Se você usar ValidatingAdmissionPolicies, essas ferramentas não vão avaliar suas políticas. Em vez disso, execute uma simulação do lado do servidor em um cluster de teste que tenha ValidatingAdmissionPolicies e ValidatingAdmissionPolicyBindings que usem a ação Deny:
```
kubectl apply --dry-run=server -f MANIFEST_DIRECTORY
```
Substitua MANIFEST_DIRECTORY pelo diretório que contém os manifestos. O comando falhará se uma ValidatingAdmissionPolicy rejeitar um manifesto.

Substituir denúncia de violação

Uma ValidatingAdmissionPolicy não inclui um painel e não audita recursos que já existem no cluster. Em vez disso, use os seguintes métodos:

Avisos: se um ValidatingAdmissionPolicyBinding usar a ação Warn, então o servidor de API retorna um aviso ao cliente que enviou a solicitação, como a ferramenta de linha de comando kubectl. Para pods criados por um controlador, como os pods em uma implantação, o controlador recebe o aviso.
Registros de auditoria: se um ValidatingAdmissionPolicyBinding usar a ação Audit, o servidor de API vai anotar a entrada de registro de auditoria para cada validação com falha. O GKE grava solicitações de criação, atualização e exclusão nos registros de auditoria de atividade do administrador no Cloud Logging. Para encontrar validações com falha, execute a seguinte consulta na Análise de Registros:
```
resource.type="k8s_cluster"
logName:"cloudaudit.googleapis.com%2Factivity"
labels."validation.policy.admission.k8s.io/validation_failure":*
```

Se você usar restrições que tenham a ação de aplicação da política dryrun como um relatório de compliance em recursos atuais, as ValidatingAdmissionPolicies não poderão substituir esse relatório. Mantenha essas políticas no Gatekeeper autogerenciado, cujo controlador de auditoria verifica os recursos atuais de acordo com uma programação.

Remover o Controlador de Políticas

Antes de remover o Controlador de Políticas de um cluster, conclua as seguintes tarefas:

Confirme se as políticas migradas para ValidatingAdmissionPolicies ou Pod Security Admission estão sendo aplicadas e se você tem um backup dos ConstraintTemplates, das restrições e dos mutadores. A remoção do Controlador de Políticas exclui as CustomResourceDefinitions, o que exclui todos os ConstraintTemplates, restrições e mutadores no cluster, incluindo os que você criou.
Se você implantar restrições de um repositório Git usando uma ferramenta GitOps, como o Config Sync ou o Argo CD, remova as restrições substituídas do repositório. Confirme se as restrições foram removidas dos clusters.
Opcional: para confirmar que nada depende do webhook do Controlador de Políticas, suspenda o Controlador de Políticas primeiro. A suspensão remove apenas as configurações do webhook, que podem ser restauradas.

Para remover o Controlador de Políticas, siga estas etapas:

Desinstale o Controlador de Políticas dos clusters:
```
gcloud container fleet policycontroller disable \
    --memberships=MEMBERSHIP_NAME \
    --project=PROJECT_ID
```
Substitua:
- MEMBERSHIP_NAME: o nome do membro do cluster registrado do qual você quer desinstalar o Controlador de Políticas. Para desinstalar o Policy Controller de vários clusters, especifique uma lista de nomes de assinaturas separada por vírgulas ou substitua a flag --memberships=MEMBERSHIP_NAME pela flag --all-memberships.
- PROJECT_ID: o ID do projeto host da frota.
Confirme se o Controlador de Políticas foi desinstalado dos clusters:
```
gcloud container fleet policycontroller describe \
    --memberships=MEMBERSHIP_NAME \
    --project=PROJECT_ID \
    --format="yaml(membershipStates)"
```
Aguarde até que o valor do campo policycontroller.state de nível superior para cada assinatura seja NOT_INSTALLED, não DECOMMISSIONING. As entradas individuais de componentStates alcançam o estado NOT_INSTALLED antes que a limpeza de CustomResourceDefinition seja concluída.

Se você planeja instalar o Gatekeeper autogerenciado, confirme se o namespace gatekeeper-system não existe mais:
```
kubectl get namespace gatekeeper-system
```
Aguarde até que a saída informe que o namespace gatekeeper-system não foi encontrado.
Opcional: para evitar que os clusters registrados posteriormente recebam o Controlador de Políticas, remova a configuração padrão no nível da frota:
```
gcloud container fleet policycontroller enable \
    --no-fleet-default-member-config \
    --project=PROJECT_ID
```
Esse comando remove apenas a configuração padrão. Ele não instala o Controlador de Políticas em nenhum cluster.

Remover o Controlador de Políticas de clusters fora de uma frota

O comando gcloud container fleet policycontroller disable remove o Controlador de Políticas apenas dos clusters gerenciados pela frota. Um cluster pode executar o Policy Controller sem o gerenciamento de frota nos seguintes casos:

Você instalou o Controlador de Políticas usando o ConfigManagement Operator.
Você cancelou o registro do cluster na frota ou executou o comando gcloud container fleet policycontroller detach antes que o Controlador de Políticas terminasse a desinstalação.

Para remover o Controlador de Políticas desses clusters, coloque o cluster sob o gerenciamento de frota e desinstale o Controlador de Políticas:

Faça backup dos ConstraintTemplates, das restrições, da configuração de sincronização e dos mutadores, conforme descrito em Inventariar e classificar suas políticas. Ao limpar os metadados de backups de uma instalação do ConfigManagement Operator, remova também os rótulos configmanagement.gke.io/* e k8s-app: kubernetes-config-management, além do campo ownerReferences e dos metadados policycontroller.*.
Se você instalou o Controlador de Políticas usando o ConfigManagement Operator, remova o campo policyController do recurso personalizado ConfigManagement no cluster. Aguarde a conclusão da reconciliação. A reconciliação pode levar cerca de dois minutos. Em seguida, verifique se o namespace gatekeeper-system ainda existe:
```
kubectl get namespace gatekeeper-system
```
Na versão 1.17 e anteriores do ConfigManagement Operator, a remoção do campo policyController desinstala o Policy Controller automaticamente. Se o namespace gatekeeper-system não for encontrado, pule as etapas restantes nesta seção. No ConfigManagement Operator versão 1.18 e mais recentes, o namespace gatekeeper-system permanece no cluster. Siga para a próxima etapa.
Se o cluster não estiver registrado em uma frota, registre-o. Para mais informações, consulte Registrar um cluster no Google Cloud na sua frota.

Verifique se a mutação está ativada no cluster:

kubectl get mutatingwebhookconfiguration \
    gatekeeper-mutating-webhook-configuration

Ative o Controlador de Políticas na assinatura do cluster para que a frota assuma o gerenciamento da instalação atual. Se o comando anterior retornou o recurso gatekeeper-mutating-webhook-configuration, inclua a flag --mutation para que a frota adote e depois remova os recursos de mutação com escopo de cluster:
```
gcloud container fleet policycontroller enable \
    --memberships=MEMBERSHIP_NAME \
    --project=PROJECT_ID
```
Substitua:
- MEMBERSHIP_NAME: o nome da assinatura do cluster registrado.
- PROJECT_ID: o ID do projeto host da frota.

Aguarde até que o valor do campo policycontroller.state da assinatura seja ACTIVE:

gcloud container fleet policycontroller describe \
    --memberships=MEMBERSHIP_NAME \
    --project=PROJECT_ID \
    --format="yaml(membershipStates)"

Desinstale o Controlador de Políticas seguindo as etapas em Remover o Controlador de Políticas. Se você não estiver instalando o Gatekeeper autogerenciado, exclua as CustomResourceDefinitions de restrição restantes depois que o namespace gatekeeper-system for removido:
```
kubectl get crd -o name \
    | grep '\.constraints\.gatekeeper\.sh$' \
    | xargs -r kubectl delete
```
Opcional: se você registrou o cluster apenas para concluir este procedimento, cancele o registro dele depois que o comando describe mostrar o estado NOT_INSTALLED da assinatura. Para clusters registrados usando a flag --enable-fleet, execute o comando gcloud container clusters update com a flag --clear-fleet-project em vez do comando gcloud container fleet memberships unregister. Para mais informações, consulte Como cancelar o registro de um cluster.

A seguir

Leia sobre a política de admissão de validação na documentação do Kubernetes.
Saiba como aplicar políticas de segurança predefinidas no nível do pod usando o PodSecurity.
Leia a documentação do Gatekeeper.