Partilhar via

Compreender o Azure Policy para clusters do Kubernetes

  • Artigo

A Política do Azure estende o Gatekeeper v3, um webhook de controlador de admissão para o Open Policy Agent (OPA), para aplicar imposições e proteções em escala em seus componentes de cluster de maneira centralizada e consistente. 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:

Importante

O modelo Azure Policy Add-on Helm e o complemento para AKS Engine foram preteridos. Siga as instruções para remover os complementos.

Descrição geral

Ao instalar o suplemento ou extensão da política do Azure nos seus clusters Kubernetes, a política do Azure 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 suplemento Serviço Kubernetes do Azure (AKS) ou a extensão da política do Azure para clusters Kubernetes com Arc ativado (dependendo do seu tipo de cluster).

    Nota

    Para problemas comuns com a instalação, consulte Solucionar problemas - Complemento de política do Azure.

  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 faz parte do Kubernetes versão 1.27 com suporte de longo prazo (LTS).

Pré-requisitos

  1. Registre os provedores de recursos e visualize os recursos.

    • Portal do Azure:

      Registre os provedores de Microsoft.PolicyInsights recursos. 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.

    Domain Porta
    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 clusters que usam entidades de serviço:

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

E a seguinte saída para clusters usando identidade gerenciada:

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

Instalar o Azure Policy Extension para o Kubernetes habilitado para 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 habilitados para Arc, você pode controlar seus componentes de cluster Kubernetes habilitados para Arc, como pods e contêineres.

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 para 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.

    Domain Porta
    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

Nota

Observe o seguinte para a criação da extensão de Política do Azure:

  • A atualização automática é habilitada por padrão, o que atualizará a versão secundária da extensão da Política do Azure se novas alterações forem implantadas.
  • Todas as variáveis de proxy passadas como parâmetros serão connectedk8s propagadas para a extensão da Política do Azure para dar suporte ao proxy de saída.

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

Excluir extensão da 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 atribuição na biblioteca de políticas interna da Política do Azure que podem ser usados para controlar seus componentes de cluster.

A Política do Azure para Kubernetes também dá suporte à criação de definições personalizadas no nível do componente para clusters do Serviço Kubernetes do Azure e clusters do Kubernetes habilitados para 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 de Código do Visual Studio da Política do Azure 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 da Política do Azure.

Com um modo Provedor de Recursos do Microsoft.Kubernetes.Data, os efeitos auditar, negar, desabilitar e mutar são usados para gerenciar seus clusters Kubernetes.

Auditar e negar 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 Política do Azure passa o URI ou Base64Encoded o valor dessas CustomResourceDefinitions(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, você deve receber as operações apropriadas de atribuição de política de controle de acesso baseado em função do Azure (Azure RBAC). As funções internas do Azure, Colaborador e Proprietário da Política de Recursos 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 caixa de listagem suspensa Categoria, use Selecionar tudo para limpar o filtro e, em seguida, 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 a atribuição de política se aplica.

    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ção que você possa usar para identificá-la facilmente.

  7. Defina a imposiçã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 negados.

    • Desabilitado - Não imponha a política no cluster. Os pedidos de admissão do Kubernetes com violações não são negados. 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 em Exclusões de namespace de parâmetro. A recomendação é excluir: kube-system, gatekeeper-system e azure-arc.

  10. Selecione Rever + criar.

Como alternativa, use o início rápido 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 das vms de auditoria de exemplo.

Importante

As definições de política internas estão disponíveis para clusters Kubernetes na categoria Kubernetes. Para obter uma lista de definições de política internas, consulte Exemplos do Kubernetes.

Avaliação do Policy

O suplemento dá entrada com o serviço Azure Policy para verificar alterações nas atribuições de políticas a cada 15 minutos. Durante este ciclo de atualização, o suplemento 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 Kubernetes habilitado para Azure Arc: admission.policy.azure.com/ignore

Nota

Embora um administrador de cluster possa ter permissão para criar e atualizar modelos de restrição e recursos de restrições instalados pelo Complemento de Política do Azure, esses cenários não são suportados, pois as atualizações manuais são substituídas. O Gatekeeper continua a avaliar as políticas que existiam antes de instalar o complemento e atribuir definições de política do Azure.

A cada 15 minutos, o suplemento solicita uma análise completa do cluster. Depois de recolher os detalhes da análise completa e quaisquer avaliações em tempo real do Gatekeeper relativamente a tentativas de alterações ao cluster, o suplemento reporta os resultados de volta ao 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.

Nota

Cada relatório de conformidade na Política do Azure para seus clusters Kubernetes inclui todas as violações nos últimos 45 minutos. O carimbo de data/hora indica quando ocorreu uma violação.

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 implantação do Kubernetes que contenha replicasets e pods. Quando um usuário executa kubectl describe deployment $MY_DEPLOYMENTo , ele 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.

Nota

Os contêineres de inicialização podem ser incluídos durante a avaliação da política. Para ver se os contêineres init estão incluídos, revise o CRD para obter a seguinte declaração ou uma declaração semelhante:

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 um controlador/contêiner do Kubernetes, os pods azure-policy e gatekeeper mantêm logs no cluster do 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 de pod gatekeeper-controller-manager podem ser usados para solucionar problemas de negações de tempo de execução. Os logs do pod de auditoria gatekeeper podem ser usados para solucionar problemas de 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 logs 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 você estiver tentando solucionar problemas de um ComplianceReasonCode específico que está aparecendo em seus resultados de conformidade, poderá pesquisar esses códigos nos logs 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. kubeconfig Configuração para o cluster.

    Para um cluster do Serviço Kubernetes do Azure, use a seguinte 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 complemento

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.

Ver os modelos de mutação de suplementos

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.

Depois de baixar os nomes dos modelos de restrição do complemento, você 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 tem detalhes sobre violações e 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 Kubernetes do artigo de solução de problemas da Política do Azure.

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

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

Azure Policy Add-on para AKS Changelog

O Complemento da Política do Azure para AKS tem um número de versão que indica a versão de imagem do complemento. Como o suporte a recursos é recentemente introduzido no complemento, o número da versão é aumentado.

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 de Controle de Versão Semântico padrão 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 você está usando, siga as orientações do AKS vinculadas.

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

1.9.1

Melhorias de segurança.

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

1.8.0

A política agora pode ser usada para avaliar operações CONNECT, por exemplo, para negar execs. Observe que não há conformidade brownfield disponível para operações CONNECT não compatíveis, portanto, uma política com efeito de auditoria direcionada a CONNECTs é uma opção não.

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 usuários precisam se inscrever no sinalizador AKS-AzurePolicyK8sNativeValidation de recurso no Microsoft.ContainerService namespace. 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

Apresentando a expansão, um recurso de deslocamento para a esquerda que permite saber antecipadamente se seus recursos de carga de trabalho (Implantações, ReplicaSets, Jobs, etc.) produzirão pods admissíveis. A expansão não deve mudar o comportamento de suas políticas; em vez disso, ele 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 tempo 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 hipotético 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. Built-ins serão atualizados em breve para permitir a parametrização deste campo. Se você testar sua definição de política e achar que o pod hipotético que está sendo gerado para fins de avaliação está incompleto, você também pode usar uma mutação com a fonte Generated para mutar 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 mutante adicional e o limite de tempo limite de validação do webhook aumentado podem adicionar latência às chamadas na pior das hipóteses. Também introduz suporte para visualização de definição de política e definição de versão de definição 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 status 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 remediar clusters AKS em 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 habilitado para Azure Arc

Nota

O modelo de Helm do Complemento de Política do Azure agora foi preterido. Em vez disso, você deve optar pela Extensão de Política do Azure para o Kubernetes habilitado para Azure Arc.

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

helm uninstall azure-policy-addon

Remova o complemento do AKS Engine

Nota

O produto AKS Engine foi preterido para clientes de nuvem pública do Azure. Considere usar o Serviço Kubernetes do Azure (AKS) para Kubernetes gerenciados ou o Provedor de API de Cluster Azure para Kubernetes autogerenciados. Não há novos recursos planejados; este projeto só será atualizado para CVEs & similares, com o Kubernetes 1.24 como a versão final para receber atualizações.

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 instalado definindo a propriedade addons na definição de cluster para AKS Engine:

    Reimplante a definição de cluster no AKS Engine depois de alterar a propriedade addons para 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 do 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
  • Não há suporte para instalações do Gatekeeper fora do Complemento de Política do Azure. Desinstale todos os componentes instalados por uma instalação anterior do Gatekeeper antes de habilitar o Complemento de Política do Azure.
  • Os motivos para a não conformidade não estão disponíveis para o modo Microsoft.Kubernetes.Data Resource Provider. Use 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 modelo de restrição para configurar a replicação de dados do cluster para o cache OPA só é permitido para políticas internas. 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 internas usam a replicação de dados, que permite aos usuários sincronizar recursos existentes no cluster com o cache OPA e fazer referência a eles durante a avaliação de uma AdmissionReview solicitação. As políticas de replicação de dados podem ser diferenciadas pela presença de no Rego e pela metadata.gatekeeper.sh/requires-sync-data presença da anotação, que informa ao complemento de Política do Azure quais recursos precisam ser armazenados em cache para que a avaliação da data.inventory 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, suas políticas serão avaliadas em relação a um vazio data.inventory (supondo que nenhum interno seja atribuído 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 Complemento de Política do Azure 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ítica do Azure requer três componentes do Gatekeeper para serem executados: um pod de auditoria e duas réplicas de pod webhook. Um pod de Política do Azure e um pod de webhook do Azure Policy também estão instalados.

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

Os componentes da Política do Azure para Kubernetes executados em seu cluster consomem mais recursos à medida que a contagem de recursos do Kubernetes e atribuições de política aumenta no cluster, o que requer operações de auditoria e imposiçã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 do 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 coleta dados de diagnóstico de cluster limitados. 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 Complemento de Política do Azure atualizado.
  • 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 Azure Policy Add-on
  • 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 pool de nós do sistema com 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 dos seus clusters AKS. Para obter mais informações, consulte Controlar o tráfego de saída para nós de cluster.
  • Se o cluster tiver aad-pod-identity habilitado, os pods NMI (Node Managed Identity) modificarão os nós iptables para intercetar chamadas para o ponto de extremidade de Metadados da Instância do Azure. Essa configuração significa que qualquer solicitação feita ao ponto de extremidade de metadados é intercetada pelo NMI, mesmo que o pod não use aad-pod-identity.
  • AzurePodIdentityException O CRD pode ser configurado para informar aad-pod-identity que quaisquer solicitações para o ponto de extremidade de metadados originadas de um pod que corresponda aos rótulos definidos no CRD devem ser intermediadas por proxy sem qualquer processamento no NMI. Os pods do sistema com kubernetes.azure.com/managedby: aks rótulo no namespace kube-system devem ser excluídos configurando aad-pod-identity o AzurePodIdentityException CRD. 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