Noções básicas sobre clusters do Azure Policy para Kubernetes

  • Artigo

O Azure Policy estende o Gatekeeper V3, um webhook do controlador de admissão para o OPA (Open Policy Agent), para aplicar imposições e garantias em escala nos componentes do cluster de maneira centralizada e consistente. Os componentes do cluster incluem pods, contêineres e namespaces.

O Azure Policy possibilita gerenciar e relatar o estado de conformidade dos componentes do cluster do Kubernetes de um único lugar. Ao usar o Complemento ou a Extensão do Azure Policy, a governança dos componentes do cluster é melhorada com recursos do Azure Policy, como a capacidade de usar seletores e substituições para implantação e reversão de políticas seguras.

O Azure Policy para Kubernetes dá suporte aos seguintes ambientes de cluster:

Importante

O modelo de Helm de Complemento do Azure Policy e o complemento para o AKS Engine foram descontinuados. Siga as instruções para remover os complementos.

Visão geral

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

  • Verificar atribuições de política ao cluster com o serviço Azure Policy.
  • Implanta definições de política no cluster como modelo de restrição e restrição de recursos personalizados ou como um recurso de modelo de mutação (dependendo do conteúdo da definição de política).
  • Relatar os detalhes de auditoria e de conformidade de volta ao serviço Azure Policy.

Para habilitar e usar o Azure Policy com o cluster do Kubernetes, execute as seguintes ações:

  1. Configure o cluster do Kubernetes e instale o complemento do AKS (Serviço de Kubernetes do Azure) ou a Extensão do Azure Policy para os clusters do Kubernetes habilitado para o Arc (dependendo do seu tipo de cluster).

    Observação

    Para ver problemas comuns com instalação, confira Solução de problemas – Azure Policy Add-on.

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

  3. Atribuir uma definição ao cluster do Kubernetes

  4. Aguardar a validação

  5. Registro em log e solução de problemas

  6. Examinar limitações e recomendações em nossa seção de perguntas frequentes

Instalar complemento do Azure Policy para AKS

O Complemento do Azure Policy para AKS faz parte do Kubernetes versão 1.27 com LTS (suporte a longo prazo).

Pré-requisitos

  1. Registre os provedores de recursos e as versões prévias do recurso.

    • Portal do Azure:

      Registre os provedores de recursos Microsoft.PolicyInsights. Para obter as etapas, confira Provedores e tipos de recurso.

    • 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 ter a versão 2.12.0 ou posterior da CLI do Azure instalada e configurada. Para localizar a versão, execute o comando az --version. Se precisar instalar ou atualizar a CLI, confira Como instalar a CLI do Azure.

  3. O cluster do AKS deve ser uma versão do Kubernetes com suporte no AKS (Serviço de Kubernetes do Azure). Use o seguinte script para validar a versão do cluster do 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 portas para a extensão do Azure Policy. A extensão do Azure Policy usa esses domínios e essas portas para buscar definições de política e atribuições e para reportar a conformidade do cluster para o Azure Policy.

    Domínio 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 do Azure Policy no cluster do AKS que você deseja gerenciar.

  • Portal do Azure

    1. Inicie o serviço AKS no portal do Azure selecionando Todos os serviços. Em seguida, pesquise e selecione Serviços de Kubernetes.

    2. Selecione um dos clusters do AKS.

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

    4. Na página principal, selecione o botão Habilitar 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 que a instalação do complemento foi bem-sucedida e que 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 com a execução deste comando da CLI do Azure, substituindo <rg> pelo nome do grupo de recursos e <cluster-name> pelo nome do cluster do AKS: az aks show --query addonProfiles.azurepolicy -g <rg> -n <cluster-name>. O resultado para os clusters que usam entidades de serviço deve se parecer com a saída abaixo:

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

E com a saída abaixo para os clusters que usam identidade gerenciada:

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

Instalar a extensão do Azure Policy para Kubernetes habilitado para Azure Arc

O Azure Policy para Kubernetes possibilita gerenciar e relatar o estado de conformidade de seus clusters do Kubernetes de um único lugar. Com a Extensão do Azure Policy para os clusters do Kubernetes habilitados para o Arc, é possível controlar os componentes de cluster do Kubernetes habilitados para o Arc, como pods e contêineres.

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

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

Pré-requisitos

Se você já tiver implantado o Azure Policy para Kubernetes em um cluster do Azure Arc usando o Helm diretamente sem extensões, siga as instruções para excluir o gráfico do Helm. Depois que a exclusão for concluída, você poderá continuar.

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

    Observação

    Há suporte para a extensão do Azure Policy para Arc nas distribuições do Kubernetes a seguir.

  2. É preciso que você tenha atendido a todos os pré-requisitos comuns para extensões Kubernetes listadas aqui, incluindo conectar o cluster ao Azure Arc.

    Observação

    Há suporte para a extensão do Azure Policy para clusters do Kubernetes habilitados para Arc nestas regiões.

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

    Domínio 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 do Azure Policy ou habilitar qualquer um dos recursos de serviço, sua assinatura precisa habilitar os provedores de recursos Microsoft.PolicyInsights.

    Observação

    Para habilitar o provedor de recursos, siga as etapas em Provedores e tipos de recursos ou execute o comando da CLI do Azure ou do 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 do Azure Policy

Observação

Observe o seguinte para a criação da extensão do Azure Policy:

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

Para criar uma instância de extensão, para o cluster habilitado para Arc, execute o seguinte comando substituindo <> pelos 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

Exemplo de saída:

{
  "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 do Azure Policy

Para verificar se a criação da instância de extensão foi bem-sucedida e inspecionar metadados de extensão, execute o seguinte comando substituindo <> por 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 que a instalação do complemento foi bem-sucedida e que 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 do Azure Policy

Para excluir a instância de extensão, execute o seguinte comando substituindo <> pelos 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 da política

A estrutura de linguagem do Azure Policy para gerenciar o Kubernetes segue as definições de política existentes. Há arquivos de definição de amostra disponíveis para atribuir na biblioteca de políticas interna do Azure Policy que podem ser usados para controlar os componentes do cluster.

O Azure Policy para Kubernetes também dá suporte à criação de definição personalizada no nível do componente para os clusters do Serviço de Kubernetes do Azure e clusters do Kubernetes habilitado para o Azure Arc. Exemplos de modelo de restrição e de mutação estão disponíveis na biblioteca da comunidade do Gatekeeper. A Extensão de VS 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 o modo de Provedor de Recursos de Microsoft.Kubernetes.Data, os efeitos de auditar, recusar, desabilitado e mutação são usados para gerenciar os clusters do Kubernetes.

Auditar e negar devem fornecer propriedades details de detalhes 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, o Azure Policy passa o URI ou o valor Base64Encoded desse CustomResourceDefinitions (CRD) para o complemento. Rego é a linguagem que o OPA e o Gatekeeper suportam para validar uma solicitação ao cluster do Kubernetes. Dando suporte a um padrão existente para o gerenciamento do Kubernetes, o Azure Policy torna possível reutilizar as regras existentes e as emparelhar com o Azure Policy para uma experiência unificada de relatórios de conformidade de nuvem. Para obter mais informações, consulte O que é Rego?.

Atribuir uma definição de política

Para atribuir uma definição de políticas ao cluster Kubernetes, você precisa receber as operações de atribuição de políticas do Azure RBAC (Controle de Acesso Baseado em Função) apropriadas. As funções internas do Azure Colaborador de Política de Recursos e Proprietário contêm essas operações. Para saber mais, confira Permissões do Azure RBAC no Azure Policy.

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

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

  2. No painel esquerdo da página do Azure Policy, 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, o botão Atribuir.

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

    Observação

    Ao atribuir o Azure Policy à definição de Kubernetes, o Escopo precisará incluir o recurso de cluster.

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

  7. Defina a Imposição de política como um dos valores a seguir:

    • Habilitado: impõe a política no cluster. As solicitações de admissão de Kubernetes com violações são negadas.

    • Desabilitado: não impõe a política no cluster. As solicitações de admissão de Kubernetes com violações não são negadas. Os resultados da avaliação de conformidade ainda estão disponíveis. Quando você distribui novas definições de política aos 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 Avançar.

  9. Definir valores de parâmetro

    • Para excluir namespaces de Kubernetes da avaliação da política, especifique a lista de namespaces no parâmetro Exclusões de namespace. É recomendável excluir: kube-system, gatekeeper-system e azure-arc.

  10. Selecione Examinar + 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 de Kubernetes em vez da amostra audit vms.

Importante

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

Avaliação da política

O complemento se comunica com o serviço Azure Policy para ver se há alterações nas atribuições de política a cada 15 minutos. Durante esse ciclo de atualização, o complemento verifica se há alterações. Essas alterações disparam criações, atualizações ou exclusões dos modelos de restrição e das restrições.

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

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

Observação

Embora um administrador do cluster possa ter permissão para criar e atualizar modelos de restrição e restrições de recursos instalados pelo complemento do Azure Policy, esses não são cenários com suporte, pois as atualizações manuais são substituídas. O Gatekeeper continua avaliando as políticas que existiam antes da instalação do complemento e da atribuição das definições de política do Azure Policy.

A cada 15 minutos, o complemento chama um exame completo do cluster. Depois de coletar detalhes do exame completo e de quaisquer avaliações em tempo real pelo Gatekeeper de tentativas de alterações no cluster, o complemento relata os resultados de volta ao Azure Policy para inclusão nos detalhes de conformidade como qualquer atribuição do Azure Policy. Apenas os resultados de atribuições de política ativas são retornados durante o ciclo de auditoria. Os resultados da auditoria também podem ser vistos como violações listadas no campo de status da restrição com falha. Para obter detalhes sobre recursos Não compatíveis, confira Detalhes do componente para modos Provedor de Recursos.

Observação

Cada relatório de conformidade no Azure Policy de seus clusters do 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 com Microsoft Defender para Nuvem, as políticas do Microsoft Defender para Nuvem do Kubernetes serão aplicadas no cluster automaticamente.

  • Quando uma política de negação é aplicada ao cluster com recursos de Kubernetes existentes, qualquer recurso pré-existente que não esteja em conformidade com a nova política continuará sendo executado. Quando o recurso sem conformidade é 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 os recursos, não é exibida uma mensagem de rejeição para o usuário durante a criação de uma implantação. Por exemplo, considere uma implantação do Kubernetes que contém replicasets e pods. Quando um usuário executa kubectl describe deployment $MY_DEPLOYMENT, 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.

Observação

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

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 à origem em locais diferentes, as definições de política serão consideradas em conflito. Exemplo: duas definições de política fazem referência ao mesmo arquivo armazenado template.yaml em locais de origem diferentes, como o armazenamento de modelos do Azure Policy (store.policy.core.windows.net) e o GitHub.

Quando as definições de política e seus modelos de restrição estão atribuídas, mas ainda não estão instaladas no cluster e estão em conflito, elas são relatadas como um conflito e não são instaladas 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 e entram em conflito com as definições de política atribuídas recentemente continuam a funcionar normalmente. Se uma atribuição existente for atualizada e houver uma falha ao sincronizar o modelo de restrição, o cluster também será marcado como um conflito. Para todas as mensagens de conflito, consulte motivos de conformidade do modo do provedor de recursos do AKS

Log

Como um controlador/contêiner do Kubernetes, os pods azure-policy e gatekeeper mantêm os logs no cluster Kubernetes. Em geral, os logs de azure-policy podem ser usados para solucionar problemas com a ingestão de políticas no cluster e nos relatórios de conformidade. Os logs de pod de gatekeeper-controller-manager podem ser usados para solucionar problemas de negações de runtime. Os logs de pod de gatekeeper-audit podem ser usados para solucionar problemas de auditorias de recursos existentes. Os logs podem ser expostos na página Insights do cluster do Kubernetes. Para obter mais informações, confira Monitorar o desempenho do cluster do Kubernetes com o Azure Monitor para contêineres.

Para exibir os logs do complemento, 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 tentando solucionar problemas de um ComplianceReasonCode específico que está aparecendo nos seus resultados de conformidade, você poderá pesquisar os logs de pod da azure-policy para esse código para ver o erro completo que o acompanha.

Para obter mais informações, confira Depuração do Gatekeeper na documentação do Gatekeeper.

Exibir artefatos do Gatekeeper

Após o complemento baixar as atribuições de política, instalar os modelos de restrição e as restrições no cluster, ele anota os dois com informações do Azure Policy 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 etapas a seguir:

  1. Configure kubeconfig para o cluster.

    Para um cluster do Serviço de Kubernetes do Azure, use a CLI do Azure a seguir:

    # 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 tem cada serviço respondendo com uma URL de onde ele está em execução.

Exibir os modelos de restrição de complemento

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

Exibir os modelos de mutação do complemento

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

Obter mapeamentos do Azure Policy

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 serão parecidos com a seguinte saída:

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

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

Assim que tiver os nomes dos modelos de restrição baixados pelo 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-.

Exibir detalhes da restrição

A restrição tem detalhes sobre violações e mapeamentos para a definição e atribuição de política. Para conferir os detalhes, use kubectl get <CONSTRAINT-TEMPLATE> <CONSTRAINT> -o yaml. Os resultados serão parecidos com a seguinte saída:

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 Add-on para Kubernetes, confira a seção sobre Kubernetes do artigo de solução de problemas do Azure Policy.

Para obter a extensão do Azure Policy para problemas relacionados à extensão do Arc, acesse:

Para problemas relacionados ao Azure Policy, acesse:

Complemento do Azure Policy para o Log de Mudanças do AKS

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 recursos foi introduzido recentemente no Complemento, o número de 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 do Azure Policy, instalada por cluster do AKS.

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

O Complemento do Azure Policy usa o esquema de Controle de versão semântico padrão para cada versão. Para identificar a versão do Complemento do Azure Policy que está sendo usada, execute 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 o Complemento do Azure Policy está usando, execute o seguinte comando: kubectl get pod gatekeeper-controller-<unique-pod-identifier> -n gatekeeper-system -o json | jq '.spec.containers[0].image'

Por fim, para identificar a versão do cluster do AKS que você está usando, siga as diretrizes vinculadas do AKS.

Versões de complemento disponíveis para cada versão do cluster do AKS

1.7.1

Apresentando CEL e VAP. A CEL (Common Expression Language) é uma linguagem de expressão nativa do Kubernetes que pode ser usada para declarar regras de validação de uma política. O recurso de VAP (validação de política de admissão) fornece avaliação de política na árvore, reduz a latência da solicitação de admissão e aprimora a confiabilidade e a disponibilidade. As ações de validação com suporte incluem Negar, Avisar e Auditar. A criação de políticas personalizadas para CEL/VAP é permitida e os usuários existentes não precisarão converter o Rego deles em CEL, pois ambos terão suporte e serão usados para impor políticas. Para usar o CEL e o VAP, os usuários precisam se registrar no sinalizador de recursos AKS-AzurePolicyK8sNativeValidation no namespace Microsoft.ContainerService. Para obter mais informações, confira a documentação do Gatekeeper.

Aprimoramentos de segurança.

  • Lançado em setembro de 2024
  • Kubernetes 1.27+ (a geração VAP é compatível apenas com a versão 1.30+)
  • Gatekeeper 3.17.1

1.7.0

Apresentamos a expansão, um recurso de mudança para a esquerda que permite saber antecipadamente se os recursos da sua carga de trabalho (implantações, ReplicaSets, trabalhos etc.) produzirão pods admissíveis. A expansão não deve alterar o comportamento das suas políticas; em vez disso, ele apenas muda a avaliação do Gatekeeper das políticas com escopo de pod para ocorrer no momento de admissão da carga de trabalho, em vez de no momento de admissão do pod. No entanto, para realizar esta 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 no comportamento da política, estamos introduzindo a expansão como desabilitado por padrão. Para habilitar a expansão para uma determinada definição de política, defina .policyRule.then.details.source como All. Os built-ins serão atualizados em breve para permitir a parametrização deste campo. Se você testar sua definição de política e descobrir que o pod de simulação que está sendo gerado para fins de avaliação está incompleto, você também poderá usar uma mutação com source Generated para alterar os pods de simulação. Para mais informações sobre essa opção, consulte a documentação do Gatekeeper.

Aprimoramentos de segurança.

  • Lançado em julho de 2024
  • Kubernetes 1.27+
  • Porteiro 3.16.3

1.6.1

Aprimoramentos de segurança.

  • Lançado em maio de 2024
  • Porteiro 3.14.2

1.5.0

Aprimoramentos de segurança.

  • Lançado em maio de 2024
  • Kubernetes 1.27+
  • Porteiro 3.16.3

1.4.0

Habilita a mutação e os dados externos por padrão. O webhook de mutação adicional e o limite de tempo limite de validação do Webhook aumentado, podem adicionar latência às chamadas no pior caso. Também apresenta suporte para exibir a definição de política e definir a versão de definição nos resultados de conformidade.

  • Lançamento em maio de 2024
  • Kubernetes 1.25+
  • Gatekeeper 3.14.0

1.3.0

Introduz o estado de erro para políticas com erro, permitindo que elas sejam distinguidas das 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 após a 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

O Azure Policy para Kubernetes agora dá suporte à mutação para corrigir clusters do AKS em escala!

Remover o complemento

Remover o complemento do AKS

Para remover o complemento do Azure Policy que está no cluster do 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. Em seguida, pesquise e selecione Serviços de Kubernetes.

    2. Selecione o cluster do AKS no qual você deseja desabilitar o complemento do Azure Policy.

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

    4. Na página principal, selecione o botão Desabilitar 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

Observação

O complemento do modelo Helm do Azure Policy foi preterido. Opte pela extensão do Azure Policy para Kubernetes habilitado para Azure Arc em vez disso.

Para remover o complemento do Azure Policy e o Gatekeeper do seu cluster do Kubernetes habilitado para Azure Arc, execute o seguinte comando Helm:

helm uninstall azure-policy-addon

Remover o complemento do Mecanismo do AKS

Observação

O produto do Mecanismo do AKS agora está preterido para clientes de nuvem pública do Azure. Considere usar o AKS (Serviço de Kubernetes do Azure) para Kubernetes gerenciados ou o Provedor de API de Cluster do Azure para Kubernetes autogerenciados. Não há novos recursos planejados; este projeto será atualizado apenas para CVEs e semelhantes, sendo o Kubernetes 1.24 a versão final para receber atualizações.

Para remover o complemento do Azure Policy e o Gatekeeper do seu cluster do Mecanismo AKS, use o método que se alinha com o modo como o complemento foi instalado:

  • Se instalado através da definição da propriedade addons na definição de cluster para o Mecanismo AKS:

    Reimplante a definição de cluster no Mecanismo AKS depois de alterar a propriedade addons de azure-policy para falso:

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

    Para obter mais informações, confira Mecanismo AKS – Desabilitar o complemento do Azure Policy.

  • Se instalado com Pacotes do Helm, execute o seguinte comando Helm:

    helm uninstall azure-policy-addon

Limitações

  • Para obter definições gerais do Azure Policy e limites de atribuição, examine os limites documentados do Azure Policy
  • O complemento do Azure Policy para Kubernetes pode ser implantado somente em pools de nós do Linux.
  • Número máximo de pods com suporte no complemento do Azure Policy 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 registros Não compatíveis por assinatura: 1 milhão.
  • Não há suporte para instalações do Gatekeeper fora do Azure Policy Add-on. Desinstale todos os componentes instalados por uma instalação anterior do Gatekeeper antes de habilitar o Azure Policy Add-on.
  • Os motivos para não conformidade não estão disponíveis para o modo de Provedor de Recursosdo Microsoft.Kubernetes.Data. Use Detalhes do componente.
  • Não há suporte para isenções no nível do componente para modos Provedor de recursos. O suporte a parâmetros está disponível nas definições do Azure Policy para excluir e incluir namespaces específicos.
  • O uso da anotação metadata.gatekeeper.sh/requires-sync-data em um modelo de restrição para configurar a replicação de dados do cluster no cache OPA atualmente só é permitido para políticas internas. Isso ocorre porque ele pode aumentar drasticamente o uso de recursos dos pods do Gatekeeper se não for usado com cuidado.

Configurando o Gatekeeper

Não há suporte para a alteração da configuração do Gatekeeper, pois ela 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 fazem uso da replicação de dados, o que permite aos usuários sincronizar recursos existentes no cluster com o cache OPA e referenciá-los durante a avaliação de uma solicitação AdmissionReview. 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, que informa ao complemento do Azure Policy quais recursos precisam ser armazenados em cache para que a avaliação de política metadata.gatekeeper.sh/requires-sync-data funcione corretamente. Isto difere do Gatekeeper autônomo, em que essa anotação é descritiva, não prescritiva.

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

A remoção da anotação pode parecer atenuar o erro que você vê, mas o complemento de política não sincronizará os recursos necessários para esse modelo de restrição no cache. Portanto, suas políticas serão avaliadas em relação a um data.inventory vazio (supondo que nenhum interno seja atribuído que replique os recursos necessários). Isso levará a resultados de conformidade enganosos. Conforme observado anteriormente, a edição manual da configuração para armazenar em cache os recursos necessários também não é permitida.

As seguintes limitações se aplicam somente ao Azure Policy Add-on para AKS:

Perguntas frequentes

O que o Complemento do Azure Policy/Extensão do Azure Policy implanta em meu cluster após a instalação?

O complemento do Azure Policy requer três componentes de Gatekeeper para ser executado: um pod de auditoria e duas réplicas de pod do webhook. Um pod do Azure Policy e um pod de webhook do Azure Policy também são instalados.

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

Os componentes do Azure Policy 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.

Confira a seguir as estimativas para ajudá-lo a planejar:

  • 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 do Azure Policy para Kubernetes podem ser aplicadas em pods do Windows?

Os pods do Windows não dão suporte a contextos de segurança. Portanto, algumas das definições do Azure Policy, como a desabilitação de privilégios raiz, não podem ser escalonadas em pods do Windows e se aplicam apenas a pods do Linux.

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

O complemento do Azure Policy para o Kubernetes coleta dados de diagnóstico de cluster limitados. Esses dados de diagnóstico são dados técnicos vitais relacionados ao software e ao desempenho. Os dados são usados das seguintes maneiras:

  • Manter o complemento do Azure Policy atualizado.
  • Manter o complemento do Azure Policy seguro, confiável e com bom desempenho.
  • Aprimorar o complemento do Azure Policy por meio da análise agregada do uso do complemento.

As informações coletadas pelo complemento não são dados pessoais. Os detalhes a seguir são coletados no momento:

  • Versão do agente do complemento do Azure Policy
  • Tipo de cluster
  • Região do cluster
  • Grupo de recursos de cluster
  • ID do recurso de cluster
  • ID da assinatura de cluster
  • Sistema operacional do cluster (exemplo: Linux)
  • Cidade do cluster (exemplo: Seattle)
  • Estado ou província do cluster (exemplo: Washington)
  • País ou região do cluster (exemplo: Estados Unidos)
  • Exceções/erros encontrados por complemento do Azure Policy 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 do Azure Policy

Quais são as melhores práticas gerais para ter em mente ao instalar o Complemento do Azure Policy?

  • Use o pool de nós do sistema com o CriticalAddonsOnly afetado para agendar pods do Gatekeeper. Para obter mais informações, confira Usando pools de nós do sistema.
  • Proteja o tráfego de saída dos clusters AKS. Para obter mais informações, confira Controlar o tráfego de saída para nós de cluster.
  • Se o cluster tiver aad-pod-identity habilitado, os pods de NMI (Identidade Gerenciada do Nó) modificarão os iptables dos nós para interceptar as chamadas para o ponto de extremidade Metadados de Instância do Azure. Essa configuração significa que qualquer solicitação feita ao ponto de extremidade Metadados será interceptada pela NMI, mesmo que o pod não use aad-pod-identity.
  • O CRD AzurePodIdentityException pode ser configurado para informar a aad-pod-identity que qualquer solicitação ao ponto de extremidade Metadados originada em um pod correspondente aos rótulos definidos no CRD deve usar um proxy sem processamento na NMI. Os pods do sistema com o rótulo kubernetes.azure.com/managedby: aks no namespace do sistema kube devem ser excluídos em aad-pod-identity configurando o CRD AzurePodIdentityException. Para obter mais informações, confira Desabilitar aad-pod-identity para um pod ou aplicativo específico. Para configurar uma exceção, instale o YAML mic-exception.

Próximas etapas