Azure Policy e como ela se integra aos Serviços Kubernetes do Azure

Concluído

O Azure Policy é um serviço do Azure que ajuda você a gerenciar seu estado de conformidade em diferentes serviços do Azure. A Política do Azure para Kubernetes permite que você use as mesmas políticas do Azure em seus clusters Kubernetes, permitindo que você gerencie o estado de conformidade dos recursos do Kubernetes, como pods, implantações e serviços, como se fossem um recurso do Azure.

Apresentando a Política do Azure

A Política do Azure permite-lhe gerir o estado de conformidade dos seus serviços do Azure. Ele funciona comparando o estado de seus recursos do Azure com as regras de negócios que você define. As regras comuns são a limitação de determinadas regiões, o requisito de tags de recursos ou a limitação de quais serviços do Azure podem ser usados.

A maneira como você define essas regras de negócios na política do Azure é usando definições de política. Há muitas políticas internas que abrangem uma variedade de cenários comuns. Se uma das políticas internas não atender às suas necessidades, você também poderá definir uma política personalizada usando uma linguagem baseada em JSON. Também é possível agrupar várias definições de política em uma iniciativa.

Em uma definição de política, você define uma condição de conformidade de recursos e o efeito que deve ser tomado se essa condição for atendida. Uma condição compara as propriedades de um recurso com um valor necessário. Um exemplo de uma condição pode ser comparar a localização de um recurso versus uma lista predefinida de locais permitidos. O efeito de uma política pode ser auditar a condição, negar a criação do recurso ou modificar o recurso criado. No exemplo do local de um recurso, você pode negar a criação de recursos que não estão na lista de locais permitidos. Para obter uma explicação mais detalhada das definições de política, consulte a estrutura de definição da Política do Azure.

A Política do Azure funciona atribuindo uma definição de política ou uma iniciativa a um escopo específico. Um escopo pode ser um grupo de gerenciamento, uma assinatura ou um grupo de recursos. As atribuições de política são herdadas automaticamente para todos os escopos abaixo da atribuição, a menos que você faça uma exclusão. Várias definições de política podem ser aplicadas a um determinado escopo. O resultado líquido das definições de política em camadas é considerado cumulativo mais restritivo: se várias políticas se aplicarem a um determinado recurso, esse recurso só estará em conformidade se todas as definições de política que se aplicam a ele forem compatíveis.

As atribuições de política são avaliadas durante a criação ou atualização dos recursos do Azure. Eles também são avaliados se a definição ou escopo é alterado, e periodicamente para monitoramento contínuo. Na prática, a política entra em vigor imediatamente quando você cria novos recursos. Todos os recursos históricos também são verificados, para que você obtenha uma visão contínua sobre a conformidade de todos os seus recursos.

Integração da Política do Azure com o AKS

Há duas maneiras pelas quais a Política do Azure se integra ao Serviço Kubernetes do Azure (AKS).

  • Políticas que impõem a conformidade no plano de controle do Azure para AKS.
  • Políticas que impõem a conformidade na carga de trabalho em execução no cluster.

O primeiro conjunto de políticas é focado mais nos recursos do Azure que representam o design do cluster, enquanto o segundo conjunto de políticas é focado em cargas de trabalho em execução no cluster.

Um exemplo de Política focada no plano de controle do Azure para AKS é a política para impor o uso de clusters privados. A política avalia se um cluster AKS está ou não usando a funcionalidade de cluster privado. Esta política é uma configuração na API do Azure que controla o design do próprio cluster.

Um exemplo do conjunto de políticas focadas na carga de trabalho em execução no cluster é a política para impor o uso de imagens permitidas. A política avalia se uma definição de pod no Kubernetes usa uma imagem correspondente a uma determinada expressão regular. Esta política é uma configuração dentro do próprio cluster e não interage com a API do Azure.

O primeiro conjunto de políticas funciona em relação à própria API do Azure. O segundo conjunto de políticas interage com a API do Kubernetes. Para aplicar e impor essas políticas de segurança internas, você precisa configurar o complemento Política do Azure para o AKS em seu cluster AKS.

Compreender como funciona a Política do Azure para AKS sob as capas

Para impor políticas sobre a API do Kubernetes, a Política do Azure para Kubernetes usa muitas ferramentas: webhooks de admissão, Open Policy Agent (OPA), Gatekeeper e, finalmente, um pod de Política do Azure.

O Azure Policy usa webhooks de admissão no Kubernetes. Webhooks de admissão são uma funcionalidade interna da API do Kubernetes. Eles permitem que a API do Kubernetes chame um webhook externo para validar se uma solicitação para criar, excluir, modificar ou se conectar a um recurso deve ser permitida ou negada (ValidatingAdmissionWebhook); ou se a solicitação deve ser alterada (MutatingAdmissionWebhook).

O Open Policy Agent (OPA) é um mecanismo de política de código aberto. O OPA fornece uma linguagem de alto nível para definir políticas. Você pode usar OPA para impor políticas em seus próprios microsserviços, em pipelines de CI/CD e no Kubernetes. A política do Azure para Kubernetes traduz as políticas do Azure para a linguagem OPA a ser implantada em seu cluster Kubernetes.

OPA Gatekeeper é uma implementação específica do Kubernetes do OPA que se integra com a API do Kubernetes. Ele se integra com os webhooks de admissão introduzidos anteriormente. Em vez de ter que implantar seus próprios manipuladores de webhook, você pode usar o gatekeeper OPA para atender às respostas do webhook de admissão. A Política do Azure para Kubernetes implanta o OPA Gatekeeper em seu cluster Kubernetes para obter essa funcionalidade.

1.

Como atribuir uma política do Azure a todas as subscrições da sua organização?

2.

Como você pode usar o Azure para garantir que todos os pods criados em seu cluster Kubernetes tenham solicitações e limites configurados e negar pods sem que essas configurações sejam criadas?

3.

Você atribui a política 'Os contêineres de cluster do Kubernetes só devem usar imagens permitidas' ao grupo de recursos do cluster do Kubernetes. O que acontece aos pods existentes que não utilizam imagens permitidas?