Projetar os fluxos de trabalho do Azure Policy como código

  • Artigo

À media que você avança no percurso com Governança de Nuvem, convém mudar de gerenciar manualmente cada atribuição de política no portal do Azure ou por meio de vários SDKs para algo mais gerenciável e repetível em escala empresarial. Duas das abordagens predominantes para gerenciar sistemas em escala na nuvem são:

  • Infraestrutura como código: a prática de tratar o conteúdo que define seus ambientes, tudo, desde modelos do Azure Resource Manager (modelo do ARM) até definições do Azure Policy e o Azure Blueprints, como código-fonte.
  • DevOps: a união de pessoas, processos e produtos para permitir a entrega contínua de valor aos nossos usuários finais.

Azure Policy como Código é a combinação dessas ideias. Essencialmente, mantenha suas definições de política no controle do código-fonte e sempre que uma alteração for feita, teste e valide essa alteração. No entanto, isso não deve ser a extensão do envolvimento das políticas com a Infraestrutura como Código ou DevOps.

A etapa de validação também deve ser um componente de outros fluxos de trabalho de integração contínua ou implantação contínua (CI/CD), como a implantação de um ambiente de aplicativo ou infraestrutura virtual. Ao fazer da validação do Azure Policy um componente inicial do processo de compilação e implantação, as equipes de aplicativos e operações descobrem se suas alterações estão se comportando como esperado muito antes que seja tarde demais e se estão tentando implantar na produção.

Definições e informações básicas

Antes de entrar nos detalhes do fluxo de trabalho do Azure Policy como Código, é importante entender alguns conceitos fundamentais, como criar definições de política e definições de iniciativa e como aproveitar isenções em atribuições dessas definições:

Os nomes dos arquivos correspondem a certas porções de definições de iniciativas e outros recursos de política:

Formato de arquivo Conteúdos do arquivo
policy-v#.json Toda a definição de política dessa versão
policyset-v#.json Toda a definição de iniciativa dessa versão
policy-v#.parameters.json A porção properties.parameters da definição de política
policyset-v#.parameters.json A porção properties.parameters da definição de iniciativa
policy-v#.rules.json A porção properties.policyRule da definição de política
policyset-v#.definitions.json A porção properties.policyDefinitions da definição de iniciativa
exemptionName.json A isenção de política direcionada a um determinado recurso ou escopo

Visão geral do fluxo de trabalho

O fluxo de trabalho geral recomendado do Azure Policy como Código é semelhante a este diagrama:

Diagrama mostrando as caixas do fluxo de trabalho do Azure Policy como Código de Criar até Testar e Implantar.

Controle do código-fonte

As definições de política e iniciativa de existentes podem ser exportadas de maneiras diferentes, como por meio do PowerShell, da CLI ou consultas do ARG (Azure Resource Graph). O ambiente de gerenciamento de controle do código-fonte escolhido para armazenar estas definições pode ser uma das muitas opções, incluindo um GitHub ou Azure DevOps.

Criar e atualizar definições de política

As definições de política são criadas usando JSON e armazenadas no controle do código-fonte. Cada política tem seu próprio conjunto de arquivos, como parâmetros, regras e parâmetros de ambiente, que devem ser armazenados na mesma pasta. A estrutura a seguir é uma forma recomendada de manter suas definições de política no controle do código-fonte.

.
|
|- policies/  ________________________ # Root folder for policy resources
|  |- policy1/  ______________________ # Subfolder for a policy
|     |- versions_____________________ # Subfolder for versions of definition
|       |- policy-v#.json _________________ # Policy definition
|       |- policy-v#.parameters.json ______ # Policy definition of parameters
|       |- policy-v#.rules.json ___________ # Policy rule
|     |- assign.<name1>.json _________ # Assignment 1 for this policy definition
|     |- assign.<name2>.json _________ # Assignment 2 for this policy definition
|     |- exemptions.<name1>/__________ # Subfolder for exemptions on assignment 1
        | - exemptionName.json________ # Exemption for this particular assignment
      |- exemptions.<name2>/__________ # Subfolder for exemptions on assignment 2
        | - exemptionName.json________ # Exemption for this particular assignment
|
|  |- policy2/  ______________________ # Subfolder for a policy
|     |- versions_____________________ # Subfolder for versions of definition
|       |- policy-v#.json _________________ # Policy definition
|       |- policy-v#.parameters.json ______ # Policy definition of parameters
|       |- policy-v#.rules.json ___________ # Policy rule
|     |- assign.<name1>.json _________ # Assignment 1 for this policy definition
|     |- exemptions.<name1>/__________ # Subfolder for exemptions on assignment 1
        | - exemptionName.json________ # Exemption for this particular assignment
|

Quando uma nova política ou nova versão é adicionada ou uma já existente é atualizada, o fluxo de trabalho deve atualizar automaticamente a definição de política no Azure. O teste da definição de política nova ou atualizada vem em uma etapa posterior.

Criar e atualizar definições de iniciativa

As definições de iniciativa também são criadas utilizando arquivos JSON que devem ser armazenados na mesma pasta que as definições de política. A definição de iniciativa requer que a definição de política já exista, portanto, ela não pode ser criada nem atualizada até que a fonte de dados da política tenha sido atualizada no controle do código-fonte e depois atualizada no Azure. A seguinte estrutura é uma forma recomendada de manter suas definições de iniciativa no controle do código-fonte:

.
|
|- initiatives/ ______________________ # Root folder for initiatives
|  |- init1/ _________________________ # Subfolder for an initiative
|     |- versions ____________________ # Subfolder for versions of initiative
|       |- policyset.json ______________ # Initiative definition
|       |- policyset.definitions.json __ # Initiative list of policies
|       |- policyset.parameters.json ___ # Initiative definition of parameters
|     |- assign.<name1>.json _________ # Assignment 1 for this policy initiative
|     |- assign.<name2>.json _________ # Assignment 2 for this policy initiative
|     |- exemptions.<name1>/__________ # Subfolder for exemptions on assignment 1
        | - exemptionName.json________ # Exemption for this particular assignment
      |- exemptions.<name2>/__________ # Subfolder for exemptions on assignment 2
        | - exemptionName.json________ # Exemption for this particular assignment
|
|  |- init2/ _________________________ # Subfolder for an initiative
|     |- versions ____________________ # Subfolder for versions of initiative
|       |- policyset.json ______________ # Initiative definition
|       |- policyset.definitions.json __ # Initiative list of policies
|       |- policyset.parameters.json ___ # Initiative definition of parameters
|     |- assign.<name1>.json _________ # Assignment 1 for this policy initiative
|     |- exemptions.<name1>/__________ # Subfolder for exemptions on assignment 1
        | - exemptionName.json________ # Exemption for this particular assignment
|

Como nas definições de política, o fluxo de trabalho deve atualizar automaticamente a definição de iniciativa no Azure quando uma iniciativa existente é adicionada ou atualizada. O teste da definição de iniciativa nova ou atualizada vem em uma etapa posterior.

Observação

É recomendável usar um mecanismo de implantação centralizado, como os fluxos de trabalho do GitHub ou o Azure Pipelines, para implantar políticas. Isso ajuda a garantir que apenas os recursos de política revisados sejam implantados no ambiente e que um mecanismo de implantação central seja usado. As permissões de Gravação para recursos de política podem ser restritas à identidade usada na implantação.

Testar e validar a definição atualizada

Depois que a automação tiver obtido suas definições de política ou de iniciativa recém-criadas ou atualizadas e feito a atualização para o objeto no Azure, é hora de testar as alterações. A política ou as iniciativas da qual faz parte deve ser atribuída a recursos no ambiente mais distante da produção. Normalmente, esse ambiente é Desenvolvimento.

Observação

Nesta etapa, estamos realizando testes de integração da definição de política em seu ambiente do Azure. Isso é separado da verificação da funcionalidade da definição de política que deve ocorrer durante o processo de criação de definição.

A atribuição deve usar enforcementMode de disabled para que a criação de recursos e as atualizações não sejam bloqueadas, mas que os recursos existentes ainda sejam auditados quanto à conformidade com a definição de política atualizada. Mesmo com enforcementMode, é recomendável que o escopo de atribuição seja um grupo de recursos ou uma assinatura que seja especificamente para validar políticas.

Observação

Embora o modo de imposição seja útil, não é uma substituição para um teste completo de uma definição de política sob várias condições. A definição de política deve ser testada com chamadas à API REST PUT e PATCH, recursos compatíveis e não compatíveis e casos de borda como uma propriedade ausente do recurso.

Depois que a atribuição for implantada, use o SDK do Azure Policy, a tarefa de Avaliação de Conformidade e Segurança do Azure Pipelines, ou consultas no Azure Resource Graph (ARG) (veja modelos) para obter dados de conformidade para a nova atribuição. O ambiente usado para testar as políticas e atribuições deve ter recursos com diferentes estados de conformidade. Como um bom teste de unidade para o código, você quer testar se os recursos são avaliados como esperado sem falsos positivos ou falsos negativos. Se você testar e validar apenas o que espera, poderá haver um impacto inesperado e não identificado da política. Para obter mais informações, confira Avaliar o impacto de uma nova definição de Azure Policy.

Habilitar tarefas de correção

Se a validação da atribuição atender às expectativas, a próxima etapa será validar a correção. As políticas que usam deployIfNotExists ou modify podem ter uma tarefa de correção associada a gatilhos para corrigir recursos de um estado sem conformidade e colocá-los em conformidade.

A primeira etapa para corrigir recursos é conceder à atribuição da política a atribuição de função definida na definição de política. Essa atribuição de função dá à identidade gerenciada da política direitos suficientes para fazer as alterações necessárias a fim de tornar o recurso compatível.

Depois que a atribuição de política tiver direitos apropriados, use o SDK do Policy para disparar uma tarefa de correção em um conjunto de recursos conhecidos como sem conformidade. Três testes devem ser concluídos em relação a essas tarefas remediadas antes de continuar:

  • Validar que a tarefa de correção foi concluída com êxito
  • Executar a avaliação de política para ver que os resultados de conformidade de política foram atualizados conforme o esperado
  • Executar um teste de unidade de ambiente em relação aos recursos diretamente para validar que suas propriedades foram alteradas

Testar os resultados da avaliação da política atualizada e o ambiente fornecem diretamente a confirmação de que as tarefas de correção mudaram o que era esperado e que a definição da política observou a alteração de conformidade conforme o esperado.

Atualizar para atribuições impostas

Após a conclusão de todos os portões de validação, atualize a atribuição para usar enforcementMode de enabled. É recomendável fazer essa alteração inicialmente no mesmo ambiente longe da produção. Valide se os efeitos desejados são aplicados durante a criação de recursos e a atualização de recursos. Depois que o ambiente é validado como funcionando conforme o esperado, a alteração deve ser delimitada para incluir o próximo ambiente e assim por diante, até que a política seja implantada nos recursos de produção.

Processar avaliações integradas

O fluxo de trabalho geral do Azure Policy como Código serve para desenvolver e implantar políticas e iniciativas em um ambiente em escala. No entanto, a avaliação da política deve fazer parte do processo de implantação para qualquer fluxo de trabalho que implanta ou cria recursos no Azure, como a implantação de aplicativos ou a execução de modelos ARM para criar a infraestrutura.

Nesses casos, depois que a implantação do aplicativo ou da infraestrutura for realizada em um grupo de recursos ou em uma assinatura de teste, a avaliação da política deverá ser feita para esse escopo verificando a validação de todas as políticas e iniciativas existentes. Embora elas possam ser configuradas como enforcementMode disabled nesse ambiente, é útil saber antecipadamente se uma implantação de aplicativo ou de infraestrutura está violando as definições de política no início. Essa avaliação de política deve, portanto, ser uma etapa nesses fluxos de trabalho e falha nas implantações que criam recursos sem conformidade.

Revisão

Este artigo aborda o fluxo de trabalho geral do Azure Policy como Código e também onde a avaliação da política deve fazer parte de outros fluxos de trabalho de implantação. Esse fluxo de trabalho pode ser usado em qualquer ambiente que dê suporte a etapas e automação com script com base em gatilhos.

Próximas etapas