Compreender a Política do Azure para clusters do Kubernetes

A Política do Azure estende o Gatekeeper v3, um webhook de controlador de admissão para o Open Policy Agent (OPA), para aplicar, de forma centralizada e consistente, imposições e salvaguardas em grande escala nos seus componentes de cluster. Os componentes de cluster incluem pods, contêineres e namespaces.

O Azure Policy permite-lhe gerir e reportar o estado de conformidade dos componentes de cluster do Kubernetes a partir de um local. Ao usar o Complemento ou Extensão da Política do Azure, o controle dos componentes do cluster é aprimorado com os recursos da Política do Azure, como a capacidade de usar seletores e substituições para implantação e reversão seguras de políticas.

O Azure Policy para Kubernetes suporta os seguintes ambientes de cluster:

• Serviço Kubernetes do Azure (AKS), através do Add-on da Política do Azure para AKS
• Azure Arc ativado para Kubernetes, através da Extensão da Política do Azure para Arc<|vq_13607|>

Descrição geral

Ao instalar o suplemento ou extensão do Azure Policy nos seus clusters Kubernetes, o Azure Policy executa as seguintes funções:

• Verifica com o serviço de política do Azure se há atribuições de política para o cluster.
• Implanta definições de política no cluster como modelo de restrição e recursos personalizados de restrição ou como um recurso de modelo de mutação (dependendo do conteúdo da definição de política).
• Relata detalhes de auditoria e conformidade ao serviço de política do Azure.

Para ativar e usar a política do Azure com o seu cluster Kubernetes, execute as seguintes ações:

1. Configure o seu cluster Kubernetes e instale o add-on Serviço Kubernetes do Azure (AKS) ou a Extensão da Política da Azure para clusters Kubernetes com Arc ativado (dependendo do seu tipo de cluster).

   Nota

   Para problemas comuns na instalação, consulte Resolução de problemas - Complemento do Azure Policy.

2. Criar ou usar uma definição de política do Azure de exemplo para Kubernetes

3. Atribuir uma definição ao cluster Kubernetes

4. Aguarde a validação

5. Registo e resolução de problemas

6. Reveja as limitações e recomendações na nossa secção FAQ

Instalar o Complemento de Política do Azure para AKS

O Complemento de Política do Azure para AKS está integrado na versão 1.27 do Kubernetes com suporte de longo prazo (LTS).

Pré-requisitos

1. Registe os provedores de recursos e previsualize as funcionalidades.

   • Portal do Azure:

     Registe os provedores de recursos Microsoft.PolicyInsights. Para conhecer as etapas, consulte Provedores e tipos de recursos.

   • CLI do Azure:

     # Log in first with az login if you're not using Cloud Shell
     
     # Provider register: Register the Azure Policy provider
     az provider register --namespace Microsoft.PolicyInsights
     

2. Você precisa da CLI do Azure versão 2.12.0 ou posterior instalada e configurada. Para localizar a versão, execute o az --version comando. Se você precisar instalar ou atualizar, consulte Como instalar a CLI do Azure.

3. O cluster AKS deve ser uma versão do Kubernetes suportada no Serviço Kubernetes do Azure (AKS). Use o seguinte script para validar sua versão do cluster AKS:

   # Log in first with az login if you're not using Cloud Shell
   
   # Look for the value in kubernetesVersion
   az aks list
   

4. Abra as portas para a extensão do Azure Policy. A extensão de Política do Azure usa esses domínios e portas para buscar definições e atribuições de política e relatar a conformidade do cluster de volta à Política do Azure.

   Domínio	Porto
   data.policy.core.windows.net	443
   store.policy.core.windows.net	443
   login.windows.net	443
   dc.services.visualstudio.com	443

Depois que os pré-requisitos forem concluídos, instale o Complemento de Política do Azure no cluster AKS que você deseja gerenciar.

• portal do Azure

  1. Inicie o serviço AKS no portal do Azure selecionando Todos os serviços e, em seguida, procurando e selecionando serviços Kubernetes.

  2. Selecione um dos seus clusters AKS.

  3. Selecione Políticas no lado esquerdo da página do serviço Kubernetes.

  4. Na página principal, selecione o botão Ativar complemento.

• CLI do Azure

  # Log in first with az login if you're not using Cloud Shell
  
  az aks enable-addons --addons azure-policy --name MyAKSCluster --resource-group MyResourceGroup
  

Para validar se a instalação do complemento foi bem-sucedida e se os pods azure-policy e gatekeeper estão em execução, execute o seguinte comando:

# azure-policy pod is installed in kube-system namespace
kubectl get pods -n kube-system

# gatekeeper pod is installed in gatekeeper-system namespace
kubectl get pods -n gatekeeper-system

Por fim, verifique se o complemento mais recente está instalado executando este comando da CLI do Azure, substituindo <rg> pelo nome do grupo de recursos e <cluster-name> pelo nome do cluster AKS: az aks show --query addonProfiles.azurepolicy -g <rg> -n <cluster-name>. O resultado deve ser semelhante à seguinte saída para os clusters que utilizam principais de serviço:

{
  "config": null,
  "enabled": true,
  "identity": null
}

A seguinte saída para os clusters utilizando identidade gerida é:

 {
   "config": null,
   "enabled": true,
   "identity": {
     "clientId": "########-####-####-####-############",
     "objectId": "########-####-####-####-############",
     "resourceId": "<resource-id>"
   }
 }

Instalar a Extensão de Política do Azure para Kubernetes habilitado pelo Azure Arc

A Política do Azure para Kubernetes torna possível gerenciar e relatar o estado de conformidade de seus clusters Kubernetes de um só lugar. Com a Extensão da Política do Azure para clusters Kubernetes com suporte ao Arc, pode-se governar os componentes do cluster Kubernetes com suporte ao Arc, como pods e contentores.

Este artigo descreve como criar, mostrar o status da extensão e excluir a Política do Azure para a extensão Kubernetes.

Para obter uma visão geral da plataforma de extensões, consulte Extensões de cluster do Azure Arc.

Pré-requisitos

Se você já implantou a Política do Azure para Kubernetes em um cluster do Azure Arc usando Helm diretamente sem extensões, siga as instruções para excluir o gráfico Helm. Depois que a exclusão for feita, você pode prosseguir.

1. Verifique se o cluster do Kubernetes é uma distribuição suportada.

   Nota

   A extensão Azure Policy for Arc é suportada nas seguintes distribuições do Kubernetes.

2. Verifique se você atendeu a todos os pré-requisitos comuns para extensões do Kubernetes listados aqui, incluindo conectar seu cluster ao Azure Arc.

   Nota

   A extensão de Política do Azure tem suporte para clusters Kubernetes habilitados pelo Arc nessas regiões.

3. Abra as portas para a extensão do Azure Policy. A extensão de Política do Azure usa esses domínios e portas para buscar definições e atribuições de política e relatar a conformidade do cluster de volta à Política do Azure.

   Domínio	Porto
   data.policy.core.windows.net	443
   store.policy.core.windows.net	443
   login.windows.net	443
   dc.services.visualstudio.com	443

4. Antes de instalar a extensão da Política do Azure ou habilitar qualquer um dos recursos de serviço, sua assinatura deve habilitar os Microsoft.PolicyInsights provedores de recursos.

   Nota

   Para habilitar o provedor de recursos, siga as etapas em Provedores e tipos de recursos ou execute o comando Azure CLI ou Azure PowerShell.

   • CLI do Azure

     # Log in first with az login if you're not using Cloud Shell
     # Provider register: Register the Azure Policy provider
     az provider register --namespace 'Microsoft.PolicyInsights'
     

   • Azure PowerShell

     # Log in first with Connect-AzAccount if you're not using Cloud Shell
     
     # Provider register: Register the Azure Policy provider
     Register-AzResourceProvider -ProviderNamespace 'Microsoft.PolicyInsights'
     

Criar extensão de Política do Azure

Para criar uma instância de extensão, para seu cluster habilitado para Arc, execute o seguinte comando substituindo <> por seus valores:

az k8s-extension create --cluster-type connectedClusters --cluster-name <CLUSTER_NAME> --resource-group <RESOURCE_GROUP> --extension-type Microsoft.PolicyInsights --name <EXTENSION_INSTANCE_NAME>

Exemplo:

az k8s-extension create --cluster-type connectedClusters --cluster-name my-test-cluster --resource-group my-test-rg --extension-type Microsoft.PolicyInsights --name azurepolicy

Saída de Exemplo:

{
  "aksAssignedIdentity": null,
  "autoUpgradeMinorVersion": true,
  "configurationProtectedSettings": {},
  "configurationSettings": {},
  "customLocationSettings": null,
  "errorInfo": null,
  "extensionType": "microsoft.policyinsights",
  "id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/my-test-rg/providers/Microsoft.Kubernetes/connectedClusters/my-test-cluster/providers/Microsoft.KubernetesConfiguration/extensions/azurepolicy",
 "identity": {
    "principalId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    "tenantId": null,
    "type": "SystemAssigned"
  },
  "___location": null,
  "name": "azurepolicy",
  "packageUri": null,
  "provisioningState": "Succeeded",
  "releaseTrain": "Stable",
  "resourceGroup": "my-test-rg",
  "scope": {
    "cluster": {
      "releaseNamespace": "kube-system"
    },
    "namespace": null
  },
  "statuses": [],
  "systemData": {
    "createdAt": "2021-10-27T01:20:06.834236+00:00",
    "createdBy": null,
    "createdByType": null,
    "lastModifiedAt": "2021-10-27T01:20:06.834236+00:00",
    "lastModifiedBy": null,
    "lastModifiedByType": null
  },
  "type": "Microsoft.KubernetesConfiguration/extensions",
  "version": "1.1.0"
}

Mostrar extensão da Política do Azure

Para verificar se a criação da instância de extensão foi bem-sucedida e inspecionar os metadados da extensão, execute o seguinte comando substituindo <> pelos seus valores:

az k8s-extension show --cluster-type connectedClusters --cluster-name <CLUSTER_NAME> --resource-group <RESOURCE_GROUP> --name <EXTENSION_INSTANCE_NAME>

Exemplo:

az k8s-extension show --cluster-type connectedClusters --cluster-name my-test-cluster --resource-group my-test-rg --name azurepolicy

Para validar se a instalação da extensão foi bem-sucedida e se os pods azure-policy e gatekeeper estão em execução, execute o seguinte comando:

# azure-policy pod is installed in kube-system namespace
kubectl get pods -n kube-system

# gatekeeper pod is installed in gatekeeper-system namespace
kubectl get pods -n gatekeeper-system

Eliminar a extensão de Política do Azure

Para excluir a instância de extensão, execute o seguinte comando substituindo <> por seus valores:

az k8s-extension delete --cluster-type connectedClusters --cluster-name <CLUSTER_NAME> --resource-group <RESOURCE_GROUP> --name <EXTENSION_INSTANCE_NAME>

Criar uma definição de política

A estrutura da linguagem da Política do Azure para gerenciar o Kubernetes segue a das definições de política existentes. Há arquivos de definição de exemplo disponíveis para atribuir na biblioteca de políticas integradas do Azure Policy que podem ser usados para controlar os componentes do seu cluster.

A Política do Azure para Kubernetes também suporta a criação de definições personalizadas ao nível do componente para clusters do Azure Kubernetes Service e clusters do Kubernetes ativados pelo Azure Arc. Os exemplos de modelo de restrição e modelo de mutação estão disponíveis na biblioteca da comunidade do Gatekeeper. A extensão do Visual Studio Code do Azure Policy pode ser usada para ajudar a traduzir um modelo de restrição ou modelo de mutação existente para uma definição de política personalizada do Azure Policy.

Com um modo Provedor de Recursos de Microsoft.Kubernetes.Data, os efeitos auditoria, negação, desativação e mutação são usados para gerenciar os seus clusters Kubernetes.

Auditoria e negação devem fornecer details propriedades específicas para trabalhar com o OPA Constraint Framework e o Gatekeeper v3.

Como parte das propriedades details.templateInfo ou details.constraintInfo na definição de política, a Azure Policy passa o URI ou o valor dessas Base64Encoded(CRD) para o complemento. Rego é a linguagem que OPA e Gatekeeper suportam para validar uma solicitação para o cluster Kubernetes. Ao dar suporte a um padrão existente para gerenciamento de Kubernetes, a Política do Azure torna possível reutilizar regras existentes e emparelhá-las com a Política do Azure para uma experiência unificada de relatórios de conformidade na nuvem. Para obter mais informações, consulte O que é Rego?.

Atribuir uma definição de política

Para atribuir uma definição de política ao seu cluster Kubernetes, deve ter as operações adequadas de atribuição de política associadas ao controlo de acesso baseado em funções do Azure (Azure RBAC). As funções integradas do Azure Contribuidor de Política de Recursos e Proprietário têm essas operações. Para saber mais, consulte Permissões do RBAC do Azure na Política do Azure.

Encontre as definições de política internas para gerenciar seu cluster usando o portal do Azure com as etapas a seguir. Se estiver usando uma definição de política personalizada, pesquise-a pelo nome ou pela categoria com a qual você a criou.

1. Inicie o serviço de Política do Azure no portal do Azure. Selecione Todos os serviços no painel esquerdo e, em seguida, procure e selecione Política.

2. No painel esquerdo da página Política do Azure, selecione Definições.

3. Na lista suspensa da categoria, utilize Selecionar tudo para limpar o filtro e depois selecione Kubernetes.

4. Selecione a definição de política e, em seguida, selecione o botão Atribuir .

5. Defina o Escopo como o grupo de gerenciamento, assinatura ou grupo de recursos do cluster Kubernetes onde se aplica a atribuição de política.

   Nota

   Ao atribuir a definição de Política do Azure para Kubernetes, o Escopo deve incluir o recurso de cluster.

6. Dê à atribuição de política um Nome e Descriçãoque você possa usar para identificá-la facilmente.

7. Defina a aplicação da política para um dos seguintes valores:

   • Habilitado - Aplique a política no cluster. Os pedidos de admissão do Kubernetes com violações são recusados.

   • Desativado - Não imponha a política no cluster. Os pedidos de admissão no Kubernetes com violações não são recusados. Os resultados da avaliação da conformidade ainda estão disponíveis. Quando você implementa novas definições de política em clusters em execução, a opção Desabilitado é útil para testar a definição de política, pois as solicitações de admissão com violações não são negadas.

8. Selecione Seguinte.

9. Definir valores de parâmetros

   • Para excluir namespaces do Kubernetes da avaliação de políticas, especifique a lista de namespaces no parâmetro Exclusões de namespace. A recomendação é excluir: kube-system, gatekeeper-system e azure-arc.

10. Selecione Revisar + criar.

Como alternativa, use o Quickstart - Atribuir uma política - Portal para localizar e atribuir uma política do Kubernetes. Procure uma definição de política do Kubernetes em vez de auditar vms.

Avaliação de Política

O suplemento consulta o serviço do Azure Policy para verificar alterações nas atribuições de políticas de 15 em 15 minutos. Durante este ciclo de atualização, a extensão verifica as alterações. Estas alterações acionam criações, atualizações ou eliminações dos modelos de restrição e restrições.

Em um cluster Kubernetes, se um namespace tiver o rótulo apropriado ao cluster, as solicitações de admissão com violações não serão negadas. Os resultados da avaliação da conformidade ainda estão disponíveis.

• Cluster do Azure Arc habilitado para Kubernetes: admission.policy.azure.com/ignore

A cada 15 minutos, a extensão realiza uma análise completa do cluster. Depois de reunir os detalhes da análise completa e quaisquer avaliações em tempo real do Gatekeeper relativamente a tentativas de alterações ao cluster, o add-on reporta os resultados de volta para o Azure Policy para inclusão nos detalhes de conformidade como qualquer atribuição do Azure Policy. Apenas os resultados das atribuições de políticas ativas são devolvidos durante o ciclo de auditoria. Os resultados da auditoria também podem ser vistos como violações listadas no campo de estado da restrição falhada. Para obter detalhes sobre recursos não compatíveis , consulte Detalhes do componente para modos de provedor de recursos.

Algumas outras considerações:

• Se a assinatura do cluster estiver registrada no Microsoft Defender for Cloud, as políticas do Microsoft Defender for Cloud Kubernetes serão aplicadas automaticamente no cluster.

• Quando uma política de negação é aplicada no cluster com recursos existentes do Kubernetes, qualquer recurso preexistente que não esteja em conformidade com a nova política continua a ser executado. Quando o recurso não compatível é reagendado em um nó diferente, o Gatekeeper bloqueia a criação do recurso.

• Quando um cluster tem uma política de negação que valida recursos, o usuário não recebe uma mensagem de rejeição ao criar uma implantação. Por exemplo, considere uma implementação no Kubernetes que contenha replicasets e os pods. Quando um utilizador executa kubectl describe deployment $MY_DEPLOYMENT, isto não retorna uma mensagem de rejeição como parte dos eventos. No entanto, kubectl describe replicasets.apps $MY_DEPLOYMENT retorna os eventos associados à rejeição.

input_containers[c] {
   c := input.review.object.spec.initContainers[_]
}

Conflitos de modelo de restrição

Se os modelos de restrição tiverem o mesmo nome de metadados de recurso, mas a definição de política fizer referência à fonte em locais diferentes, as definições de política serão consideradas conflitantes. Exemplo: Duas definições de política fazem referência ao mesmo template.yaml arquivo armazenado em locais de origem diferentes, como o repositório de modelos de Política do Azure (store.policy.core.windows.net) e o GitHub.

Quando as definições de política e seus modelos de restrição são atribuídos, mas ainda não estão instalados no cluster e estão em conflito, eles são relatados como um conflito e não são instalados no cluster até que o conflito seja resolvido. Da mesma forma, todas as definições de política existentes e seus modelos de restrição que já estão no cluster que entram em conflito com as definições de diretiva recém-atribuídas continuam a funcionar normalmente. Se uma atribuição existente for atualizada e houver uma falha na sincronização do modelo de restrição, o cluster também será marcado como um conflito. Para todas as mensagens de conflito, consulte Razões de conformidade do modo AKS Resource Provider

Registo

Como controlador/contentor do Kubernetes, tanto os pods azure-policy quanto os de gatekeeper mantêm logs no cluster Kubernetes. Em geral, os logs azure-policy podem ser usados para solucionar problemas com a ingestão de políticas no cluster e relatórios de conformidade. Os logs do pod do gatekeeper-controller-manager podem ser usados para solucionar problemas de falhas de execução. Os logs do pod gatekeeper de auditoria podem ser usados para solucionar problemas nas auditorias de recursos existentes. Os registos podem ser expostos na página Informações do cluster do Kubernetes. Para obter mais informações, veja Monitorizar o desempenho do cluster do Kubernetes com o Azure Monitor para contentores.

Para exibir os registos de complementos, use kubectl:

# Get the azure-policy pod name installed in kube-system namespace
kubectl logs <azure-policy pod name> -n kube-system

# Get the gatekeeper pod name installed in gatekeeper-system namespace
kubectl logs <gatekeeper pod name> -n gatekeeper-system

Se estiver a tentar solucionar problemas de um ComplianceReasonCode específico que aparece nos seus resultados de conformidade, pode procurar esse código nos registos do pod azure-policy para ver o erro completo que o acompanha.

Para obter mais informações, veja Depurar o Gatekeeper na documentação do Gatekeeper.

Ver artefatos do Gatekeeper

Depois que o complemento baixa as atribuições de política e instala os modelos de restrição e as restrições no cluster, ele faz anotações com as informações da Política do Azure, como a ID de atribuição de política e a ID de definição de política. Para configurar seu cliente para exibir os artefatos relacionados ao complemento, use as seguintes etapas:

1. Configure o kubeconfig para o cluster.

   Para um cluster do Serviço Kubernetes no Azure, utilize a seguinte interface de linha de comandos (CLI) do Azure:

   # Set context to the subscription
   az account set --subscription <YOUR-SUBSCRIPTION>
   
   # Save credentials for kubeconfig into .kube in your home folder
   az aks get-credentials --resource-group <RESOURCE-GROUP> --name <CLUSTER-NAME>
   

2. Teste a conexão do cluster.

   Execute o comando kubectl cluster-info. Uma execução bem-sucedida faz com que cada serviço responda com uma URL de onde está sendo executado.

Exibir os modelos de restrição de extensões

Para exibir modelos de restrição baixados pelo complemento, execute kubectl get constrainttemplates. Os modelos de restrição que começam com k8sazure são os instalados pelo complemento.

Veja os modelos de mutação de complementos

Para exibir modelos de mutação baixados pelo complemento, execute kubectl get assign, kubectl get assignmetadatae kubectl get modifyset.

Obter mapeamentos de Política do Azure

Para identificar o mapeamento entre um modelo de restrição baixado para o cluster e a definição de política, use kubectl get constrainttemplates <TEMPLATE> -o yaml. Os resultados são semelhantes aos seguintes resultados:

apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
    annotations:
    azure-policy-definition-id: /subscriptions/<SUBID>/providers/Microsoft.Authorization/policyDefinitions/<GUID>
    constraint-template-installed-by: azure-policy-addon
    constraint-template: <URL-OF-YAML>
    creationTimestamp: "2021-09-01T13:20:55Z"
    generation: 1
    managedFields:
    - apiVersion: templates.gatekeeper.sh/v1beta1
    fieldsType: FieldsV1
...

<SUBID> é o ID da assinatura e <GUID> é o ID da definição de política mapeada. <URL-OF-YAML> é o local de origem do modelo de restrição que o complemento baixou para instalar no cluster.

Exibir restrições relacionadas a um modelo de restrição

Depois de obter os nomes dos modelos de restrição de complemento obtidos por download, pode usar o nome para ver as restrições relacionadas. Use kubectl get <constraintTemplateName> para obter a lista. As restrições instaladas pelo complemento começam com azurepolicy-.

Ver detalhes da restrição

A restrição contém detalhes sobre violações, bem como mapeamentos para a definição e atribuição da política. Para ver os detalhes, use kubectl get <CONSTRAINT-TEMPLATE> <CONSTRAINT> -o yaml. Os resultados são semelhantes aos seguintes resultados:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sAzureContainerAllowedImages
metadata:
  annotations:
    azure-policy-assignment-id: /subscriptions/<SUB-ID>/resourceGroups/<RG-NAME>/providers/Microsoft.Authorization/policyAssignments/<ASSIGNMENT-GUID>
    azure-policy-definition-id: /providers/Microsoft.Authorization/policyDefinitions/<DEFINITION-GUID>
    azure-policy-definition-reference-id: ""
    azure-policy-setdefinition-id: ""
    constraint-installed-by: azure-policy-addon
    constraint-url: <URL-OF-YAML>
  creationTimestamp: "2021-09-01T13:20:55Z"
spec:
  enforcementAction: deny
  match:
    excludedNamespaces:
    - kube-system
    - gatekeeper-system
    - azure-arc
  parameters:
    imageRegex: ^.+azurecr.io/.+$
status:
  auditTimestamp: "2021-09-01T13:48:16Z"
  totalViolations: 32
  violations:
  - enforcementAction: deny
    kind: Pod
    message: Container image nginx for container hello-world has not been allowed.
    name: hello-world-78f7bfd5b8-lmc5b
    namespace: default
  - enforcementAction: deny
    kind: Pod
    message: Container image nginx for container hello-world has not been allowed.
    name: hellow-world-89f8bfd6b9-zkggg

Solução de problemas do complemento

Para obter mais informações sobre como solucionar problemas do Complemento para Kubernetes, consulte a seção de Kubernetes do artigo sobre a resolução de problemas da Política do Azure.

Para problemas relacionados a extensão da Política do Azure para Arc, vá para:

• Solução de problemas de Kubernetes habilitado com Azure Arc

Para problemas relacionados à Política do Azure, vá para:

• Inspecionar os logs da Política do Azure
• Solução de problemas gerais para a Política do Azure no Kubernetes

Azure Policy Add-on para AKS Changelog

O Complemento do Azure Policy para AKS tem um número de versão que indica a versão da imagem do complemento. Como o suporte a funcionalidades foi recentemente introduzido no complemento, o número da versão é incrementado.

Esta seção ajuda você a identificar qual versão do Complemento está instalada em seu cluster e também compartilhar uma tabela histórica da versão do Complemento de Política do Azure instalada por cluster AKS.

Identificar qual versão do complemento está instalada no cluster

O Complemento de Política do Azure usa o esquema padrão de Versão Semântica para cada versão. Para identificar a versão do Complemento de Política do Azure que está sendo usada, você pode executar o seguinte comando: kubectl get pod azure-policy-<unique-pod-identifier> -n kube-system -o json | jq '.spec.containers[0].image'

Para identificar a versão do Gatekeeper que seu Complemento de Política do Azure está usando, você pode executar o seguinte comando: kubectl get pod gatekeeper-controller-<unique-pod-identifier> -n gatekeeper-system -o json | jq '.spec.containers[0].image'

Finalmente, para identificar a versão do cluster AKS que está a usar, siga as orientações associadas ao AKS.

Versões adicionais disponíveis por cada versão do cluster AKS

1.13.1

Patch CVE-2025-47907.

• Lançado em agosto de 2025
• Kubernetes 1,27+
• Porteiro 3.20.0-1

1.13.0

Limite de Dados da UE agora suportado pela Política do Azure para Kubernetes no AKS. Para saber mais sobre os limites de dados da UE, visite: Visão geral dos limites de dados da UE.

Patch CVE-2025-22874.

Melhorias de segurança.

• Lançado em julho de 2025
• Kubernetes 1,27+
• Gatekeeper 3.20.0

Porteiro 3.20.0-1

Lançamento do Gatekeeper: https://github.com/open-policy-agent/gatekeeper/releases/tag/v3.20.0 Alterações: https://github.com/open-policy-agent/gatekeeper/compare/v3.19.1...v3.20.0

1.12.3

Aplicar patch para CVEs CVE-2025-22874 e GHSA-vrw8-fxc6-2r93.

• Lançado em julho de 2025
• Kubernetes 1,27+
• Gatekeeper 3.19.1

1.12.2

Melhorias de segurança.

• Lançado em junho de 2025
• Kubernetes 1,27+
• Gatekeeper 3.19.1

1.11.1

Melhorias de segurança.

• Lançado em maio de 2025
• Kubernetes 1,27+
• Gatekeeper 3.19.1

Porteiro 3.19.1-1

Lançamento do Gatekeeper: https://github.com/open-policy-agent/gatekeeper/releases/tag/v3.19.1 Alterações: https://github.com/open-policy-agent/gatekeeper/compare/v3.18.2...v3.19.1 Patch CVE-2025-22872.

1.10.1

Atualize as imagens policy-kubernetes-addon-prod e policy-kubernetes-webhook para corrigir CVE-2025-30204 e CVE-2025-22870.

• Lançado em abril de 2025
• Kubernetes 1,27+
• Gatekeeper 3.18.2

1.10.0

Melhorias de segurança.

A CEL está habilitada por padrão, você pode continuar usando o Rego. É introduzido um novo CRD configpodstatuses.status.gatekeeper.sh (Referência: https://github.com/open-policy-agent/gatekeeper/issues/2918)

• Lançado em fevereiro de 2025
• Kubernetes 1,27+
• Gatekeeper 3.18.2

Porteiro 3.18.2-1

Lançamento do Gatekeeper: https://github.com/open-policy-agent/gatekeeper/releases/tag/v3.18.2 Alterações: https://github.com/open-policy-agent/gatekeeper/compare/v3.17.1...v3.18.2

1.9.1

Melhorias de segurança.

Patch CVE-2024-45337 e CVE-2024-45338.

• Lançado em janeiro de 2025
• Kubernetes 1,27+
• Gatekeeper 3.17.1

Porteiro 3.17.1-5

Patch CVE-2024-45337 e CVE-2024-45338.

1.8.0

Uma política agora pode ser usada para avaliar operações CONNECT, por exemplo, para negar execs. Observe que não existe conformidade brownfield disponível para operações CONNECT não conformes, portanto, uma política com efeito de auditoria direcionada a CONNECTs não terá efeito.

Melhorias de segurança.

• Lançado em novembro de 2024
• Kubernetes 1,27+
• Gatekeeper 3.17.1

1.7.1

Apresentando o CEL e o VAP. Common Expression Language (CEL) é uma linguagem de expressão nativa do Kubernetes que pode ser usada para declarar regras de validação de uma política. O recurso Validating Admission Policy (VAP) fornece avaliação de política em árvore, reduz a latência da solicitação de admissão e melhora a confiabilidade e a disponibilidade. As ações de validação suportadas incluem Negar, Avisar e Auditar. A criação de políticas personalizadas para CEL/VAP é permitida e os utilizadores existentes não precisarão de converter o seu Rego para CEL, uma vez que ambos serão suportados e utilizados para aplicar políticas. Para usar CEL e VAP, os utilizadores precisam inscrever-se no feature flag AKS-AzurePolicyK8sNativeValidation no namespace Microsoft.ContainerService. Para obter mais informações, consulte a documentação do Gatekeeper.

Melhorias de segurança.

• Lançado em setembro de 2024
• Kubernetes 1.27+ (a geração VAP só é suportada em 1.30+)
• Gatekeeper 3.17.1

1.7.0

Apresentamos a funcionalidade de expansão, uma abordagem de "shift left" que lhe permite saber antecipadamente se os seus recursos de carga de trabalho (Deployments, ReplicaSets, Jobs, etc.) irão produzir pods válidos. A expansão não deve mudar o comportamento das suas políticas; em vez disso, ela apenas desloca a avaliação do Gatekeeper das políticas de escopo do pod para ocorrer no momento de admissão da carga de trabalho em vez do momento de admissão do pod. No entanto, para realizar essa avaliação, ele deve gerar e avaliar um pod hipotético baseado na especificação do pod definida na carga de trabalho, que pode ter metadados incompletos. Por exemplo, o pod 'what-if' não conterá as referências de proprietário adequadas. Devido a esse pequeno risco de mudança de comportamento da política, estamos introduzindo a expansão como desabilitada por padrão. Para habilitar a expansão para uma determinada definição de política, defina .policyRule.then.details.source como All. As funcionalidades embutidas serão atualizadas em breve para permitir a parametrização deste campo. Se testar a sua definição de política e achar que o pod hipotético gerado para fins de avaliação está incompleto, pode também usar uma mutação com a origem Generated para alterar os pods hipotéticos. Para obter mais informações sobre essa opção, consulte a documentação do Gatekeeper.

Atualmente, a expansão só está disponível em clusters AKS, não em clusters Arc.

Melhorias de segurança.

• Lançado em julho de 2024
• Kubernetes 1,27+
• Gatekeeper 3.16.3

1.6.1

Melhorias de segurança.

• Lançado em maio de 2024
• Gatekeeper 3.14.2

1.5.0

Melhorias de segurança.

• Lançado em maio de 2024
• Kubernetes 1,27+
• Gatekeeper 3.16.3

1.4.0

Permite mutação e dados externos por padrão. O webhook mutável adicional e o aumento do tempo limite do webhook de validação podem adicionar latência às chamadas em situações de pior caso. Também introduz suporte para visualizar a definição de políticas e a versão de definição de conjunto nos resultados de conformidade.

• Lançado em maio de 2024
• Kubernetes 1,25+
• Gatekeeper 3.14.0

1.3.0

Introduz o estado de erro para políticas em erro, permitindo que elas sejam distinguidas de políticas em estados não compatíveis. Adiciona suporte para modelos de restrição v1 e uso do parâmetro excludedNamespaces em políticas de mutação. Adiciona uma verificação de estado de erro em modelos de restrição pós-instalação.

• Lançado em fevereiro de 2024
• Kubernetes 1,25+
• Gatekeeper 3.14.0

1.2.1

• Lançado em outubro de 2023
• Kubernetes 1,25+
• Gatekeeper 3.13.3

1.1.0

• Lançado em julho de 2023
• Kubernetes 1,27+
• Gatekeeper 3.11.1

1.0.1

• Lançado em junho de 2023
• Kubernetes 1,24+
• Gatekeeper 3.11.1

1.0.0

A Política do Azure para Kubernetes agora suporta mutação para corrigir clusters AKS em larga escala!

Remover o complemento

Remova o complemento do AKS

Para remover o Complemento de Política do Azure do seu cluster AKS, use o portal do Azure ou a CLI do Azure:

• portal do Azure

  1. Inicie o serviço AKS no portal do Azure selecionando Todos os serviços e, em seguida, procurando e selecionando serviços Kubernetes.

  2. Selecione seu cluster AKS onde você deseja desabilitar o Complemento de Política do Azure.

  3. Selecione Políticas no lado esquerdo da página do serviço Kubernetes.

  4. Na página principal, selecione o botão Desativar complemento.

• CLI do Azure

  # Log in first with az login if you're not using Cloud Shell
  
  az aks disable-addons --addons azure-policy --name MyAKSCluster --resource-group MyResourceGroup
  

Remover o complemento do Kubernetes utilizado com o Azure Arc

Para remover o Complemento de Política do Azure e o Gatekeeper do cluster Kubernetes habilitado pelo Azure Arc, execute o seguinte comando Helm:

helm uninstall azure-policy-addon

Remova o complemento do AKS Engine

Para remover o Complemento de Política do Azure e o Gatekeeper do cluster do AKS Engine, use o método alinhado com a forma como o complemento foi instalado:

• Se for instalado ao definir a propriedade addons na definição de cluster para o AKS Engine:

  Redefina a definição do cluster no AKS Engine depois de alterar a propriedade addons de azure-policy para false:

  "addons": [
    {
      "name": "azure-policy",
      "enabled": false
    }
  ]
  

  Para obter mais informações, consulte AKS Engine - Disable Azure Policy Add-on.

• Se instalado com Helm Charts, execute o seguinte comando Helm:

  helm uninstall azure-policy-addon
  

Limitações

• Para obter definições gerais da Política do Azure e limites de atribuição, consulte os limites documentados da Política do Azure
• O Complemento de Política do Azure para Kubernetes só pode ser implantado em pools de nós Linux.
• Número máximo de pods suportados pelo Complemento de Política do Azure por cluster: 10.000
• Número máximo de registros não compatíveis por política por cluster: 500
• Número máximo de registos não conformes por subscrição: 1 milhão
• Os motivos para a não conformidade não estão disponíveis para o modo Microsoft.Kubernetes.Data Resource Provider. Utilize Detalhes do componente.
• Não há suporte para isenções no nível de componente para os modos de Provedor de Recursos. O suporte a parâmetros está disponível nas definições de Política do Azure para excluir e incluir namespaces específicos.
• Atualmente, o uso da metadata.gatekeeper.sh/requires-sync-data anotação em um template de restrição para configurar a replicação de dados do cluster para o cache OPA só é permitido para políticas integradas. A razão é porque ele pode aumentar drasticamente o uso de recursos dos pods do Gatekeeper se não for usado com cuidado.

Configurando a configuração do Gatekeeper

Não há suporte para alterar a configuração do Gatekeeper, pois ele contém configurações de segurança críticas. As edições na configuração são reconciliadas.

Usando data.inventory em modelos de restrição

Atualmente, várias políticas integradas fazem uso da replicação de dados, o que permite aos utilizadores sincronizar recursos existentes no cluster com a cache OPA e referenciá-los durante a avaliação de uma AdmissionReview solicitação. As políticas de replicação de dados podem ser diferenciadas pela presença de data.inventory no Rego e pela presença da anotação metadata.gatekeeper.sh/requires-sync-data, que informa ao complemento de Política do Azure quais recursos precisam ser armazenados em cache para que a avaliação da política funcione corretamente. Esse processo difere do Gatekeeper autônomo, onde essa anotação é descritiva, não prescritiva.

A replicação de dados está atualmente bloqueada para uso em definições de políticas personalizadas, porque a replicação de recursos com altas contagens de instâncias pode aumentar drasticamente o uso de recursos dos pods do Gatekeeper se não for usada com cuidado. Você verá um ConstraintTemplateInstallFailed erro ao tentar criar uma definição de política personalizada contendo um modelo de restrição com essa anotação.

Remover a anotação pode parecer atenuar o erro que você vê, mas o complemento de política não sincronizará nenhum recurso necessário para esse modelo de restrição no cache. Assim, as suas políticas serão avaliadas em relação a um espaço vazio data.inventory (supondo que nenhuma funcionalidade interna esteja atribuída que replique os recursos necessários). Tal conduzirá a resultados de conformidade enganadores. Como observado anteriormente, editar manualmente a configuração para armazenar em cache os recursos necessários também não é permitido.

As limitações a seguir se aplicam somente ao Complemento de Política do Azure para AKS:

• A política de segurança do AKS Pod e o Complemento de Política do Azure para AKS não podem ser habilitados. Para obter mais informações, consulte Limitação de segurança do pod AKS.
• Namespaces excluídos automaticamente pelo Azure Policy Add-on para avaliação: kube-system e gatekeeper-system.

Perguntas mais frequentes

O que o Azure Policy Add-on / Azure Policy Extension implanta no meu cluster após a instalação?

O Complemento de Políticas do Azure requer três componentes do Gatekeeper para funcionar: um pod de auditoria e duas réplicas de pod webhook. Um pod de Azure Policy e um pod de webhook de Azure Policy também estão instalados.

Quanto consumo de recursos posso esperar que o Complemento/Extensão de Política do Azure utilize em cada cluster?

Os componentes da Política do Azure para Kubernetes que são executados no seu cluster consomem mais recursos à medida que a contagem de recursos do Kubernetes e as atribuições de política aumentam no cluster, o que requer operações de auditoria e aplicação.

Seguem-se estimativas para o ajudar a planear:

• Para menos de 500 pods em um único cluster com um máximo de 20 restrições: duas vCPUs e 350 MB de memória por componente.
• Para mais de 500 pods em um único cluster com um máximo de 40 restrições: três vCPUs e 600 MB de memória por componente.

As definições da Política do Azure para Kubernetes podem ser aplicadas em pods do Windows?

Os pods Windows não suportam contextos de segurança. Assim, algumas das definições da Política do Azure, como não permitir privilégios de raiz, não podem ser escaladas em pods do Windows e só se aplicam a pods do Linux.

Que tipo de dados de diagnóstico são coletados pelo Complemento de Política do Azure?

O Complemento de Política do Azure para Kubernetes recolhe dados de diagnóstico limitados do cluster. Estes dados de diagnóstico são dados técnicos vitais relacionados com o software e o desempenho. Os dados são utilizados das seguintes formas:

• Mantenha o Aditivo de Política do Azure em dia.
• Mantenha o Azure Policy Add-on seguro, confiável e com desempenho.
• Melhorar o Complemento de Política do Azure - por meio da análise agregada do uso do complemento.

As informações recolhidas pelo add-on não são dados pessoais. Os seguintes detalhes são coletados atualmente:

• Versão do agente do complemento Azure Policy
• Tipo de cluster
• Região do cluster
• Grupo de recursos de cluster
• ID do recurso de cluster
• ID da subscrição do cluster
• SO de cluster (exemplo: Linux)
• Cluster city (exemplo: Seattle)
• Estado ou província do cluster (Exemplo: Washington)
• País ou região do cluster (Exemplo: Estados Unidos)
• Exceções/erros encontrados pelo Complemento de Política do Azure durante a instalação do agente na avaliação da política
• Número de definições de política do Gatekeeper não instaladas pelo Complemento de Política do Azure

Quais são as práticas recomendadas gerais a ter em mente ao instalar o Complemento de Política do Azure?

• Use o conjunto de nós do sistema que possui CriticalAddonsOnly taint para agendar pods do Gatekeeper. Para obter mais informações, consulte Usando pools de nós do sistema.
• Proteja o tráfego de saída de rede dos seus clusters AKS. Para mais informações, consulte Controlar o tráfego de saída nos nós do cluster.
• Se o cluster tiver aad-pod-identity ativado, os NMI pods (Node Managed Identity) modificarão os nós iptables para intercetar chamadas para o endpoint de Metadados da Instância do Azure. Esta configuração significa que qualquer requisição feita ao endpoint de metadados é intercetada pelo NMI, mesmo que o pod não use aad-pod-identity.
• AzurePodIdentityException O CRD pode ser configurado para indicar ao aad-pod-identity que quaisquer pedidos para o ponto final de metadados oriundos de um pod que corresponda aos rótulos definidos no CRD devem ser encaminhados através de um proxy, sem qualquer processamento no NMI. Os pods do sistema com o rótulo kubernetes.azure.com/managedby: aks no namespace kube-system devem ser excluídos por meio da configuração do CRD aad-pod-identity. Para obter mais informações, consulte Desativar aad-pod-identity para um pod ou aplicativo específico. Para configurar uma exceção, instale o mic-exception YAML.

Próximos passos

• Analise exemplos em Exemplos de Políticas do Azure.
• Veja a Estrutura de definição da Política.
• Revise Compreender os efeitos da política.
• Entenda como criar políticas de forma programática.
• Saiba como obter dados de conformidade.
• Saiba como corrigir recursos não compatíveis.
• Analise o que é um grupo de gerenciamento com Organize seus recursos com grupos de gerenciamento do Azure.