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

Concluído

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

Introdução ao Azure Policy

O Azure Policy permite que você gerencie o estado de conformidade de seus serviços do Azure. Ele atua comparando o estado dos recursos do Azure com as regras de negócio que você define. Regras comuns são a limitação de determinadas regiões, o requisito para marcas de recurso ou a limitação de quais serviços do Azure podem ser usados.

Você define essas regras de negócio no Azure Policy 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. Outra opção é 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 do recurso e o efeito que deve haver 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 o local de um recurso a 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 do Azure Policy.

O Azure Policy 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 de 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 aplicadas a ele estiverem em conformidade.

As atribuições de política são avaliadas durante a criação ou atualização de recursos do Azure. Eles também serão avaliados se a definição ou o escopo for 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 serão verificados, portanto, você obterá uma exibição contínua da conformidade de todos os seus recursos.

Integração do Azure Policy ao AKS

Há duas maneiras de integrar o Azure Policy ao AKS (Serviço de Kubernetes do Azure).

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

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

Um exemplo de Policy 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 do AKS está usando ou não a funcionalidade de cluster privado. Essa política é uma configuração na API do Azure que controla o design do próprio cluster.

Um exemplo do conjunto de políticas voltadas para a 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 que corresponde a uma determinada expressão regular. Essa 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 na 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 do Azure Policy para o AKS no cluster do AKS.

Entenda o mecanismo de funcionamento do Azure Policy para AKS

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

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 OPA (Open Policy Agent) é um mecanismo de política de software livre. O OPA fornece uma linguagem de alto nível no qual definir políticas. Você pode usar o OPA para impor políticas em seus microsserviços, em pipelines de CI/CD e no Kubernetes. O Azure Policy para Kubernetes converte as políticas do Azure na linguagem OPA para implantação no cluster do Kubernetes.

O Gatekeeper do OPA é uma implementação específica do Kubernetes do OPA que se integra à API do Kubernetes. Ele se integra aos webhooks de admissão introduzidos anteriormente. Em vez de implantar manipuladores de webhook próprios, você pode usar o Gatekeeper do OPA para atender as respostas de webhook de admissão. O Azure Policy para Kubernetes implanta o Gatekeeper do OPA em seu cluster do Kubernetes para obter essa funcionalidade.

1.

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

2.

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

3.

Atribua a política "Contêineres de cluster do Kubernetes só devem usar imagens permitidas" ao grupo de recursos do cluster do Kubernetes. O que acontece com pods que não usam imagens permitidas?