Criar fluxos de trabalho do Azure Policy como Código

  • Artigo

À medida que você progride em sua jornada com a Governança de Nuvem, convém mudar do gerenciamento manual de cada atribuição de política no portal do Azure ou por meio dos 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, desde modelos do Azure Resource Manager (modelos ARM) até definições de Política do Azure e 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.

A Política do Azure 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, essa 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 tornar a validação da Política do Azure 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 de ser tarde demais e estão tentando implantar na produção.

Definições e informações fundamentais

Antes de entrar nos detalhes do fluxo de trabalho da Política do Azure 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 ficheiros correspondem a determinadas partes das definições de política ou iniciativa e a outros recursos de política:

File format Conteúdo do ficheiro
policy-v#.json Toda a definição de política para essa versão
policyset-v#.json Toda a definição da iniciativa para essa versão
policy-v#.parameters.json A properties.parameters parte da definição da política
policyset-v#.parameters.json A properties.parameters parte da definição da iniciativa
policy-v#.rules.json A properties.policyRule parte da definição da política
policyset-v#.definitions.json A properties.policyDefinitions parte da definição da 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 da Política do Azure como Código é semelhante a este diagrama:

Diagrama mostrando a Política do Azure como caixas de fluxo de trabalho de Código de Criar para Testar e Implantar.

Controlo de origem

As definições de política e iniciativa existentes podem ser exportadas de diferentes maneiras, como por meio de consultas PowerShell, CLI ou Azure Resource Graph (ARG). O ambiente de gerenciamento de controle do código-fonte escolhido para armazenar essas 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 maneira 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 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 usando 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 ou atualizada até que a fonte da política tenha sido atualizada no controle do código-fonte e, em seguida, atualizada no Azure. A estrutura a seguir é uma maneira recomendada de manter as definições de sua 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
|

Tal como acontece com as 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.

Nota

É recomendável usar um mecanismo de implantação centralizado, como fluxos de trabalho do GitHub ou Pipelines do Azure, para implantar políticas. Isso ajuda a garantir que apenas os recursos de política revisados sejam implantados em seu ambiente e que um mecanismo de implantação gradual e 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 tomado suas definições de política ou iniciativa recém-criadas ou atualizadas e feito a atualização para o objeto no Azure, é hora de testar as alterações que foram feitas. A política ou a(s) iniciativa(s) de que faz parte devem então ser atribuídas a recursos no ambiente mais distante da produção. Este ambiente é tipicamente Dev.

Nota

Nesta etapa, estamos conduzindo 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 da definição.

A atribuição deve usar enforcementMode de disabled para que a criação e as atualizações de recursos 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 da atribuição seja um grupo de recursos ou uma assinatura especificamente para validar políticas.

Nota

Embora o modo de imposição seja útil, ele não substitui o teste completo de uma definição de política sob várias condições. A definição de política deve ser testada com PUT chamadas de PATCH API REST, 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 de Política do Azure, a tarefa Avaliação de Segurança e Conformidade do Azure Pipelines ou consultas do Azure Resource Graph (ARG) (consulte exemplos) 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 código, você deseja testar se os recursos são avaliados conforme o esperado, sem falsos positivos ou falsos negativos. Se você testar e validar apenas para o que espera, pode haver um impacto inesperado e não identificado da política. Para obter mais informações, consulte Avaliar o impacto de uma nova definição de Política do Azure.

Habilitar tarefas de correção

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

A primeira etapa para remediar recursos é conceder à atribuição de 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 atribuição de política direitos suficientes para fazer as alterações necessárias para tornar o recurso compatível.

Quando a atribuição de política tiver direitos apropriados, use o SDK de política para disparar uma tarefa de correção em relação a um conjunto de recursos que são conhecidos por não estarem em conformidade. Três testes devem ser concluídos em relação a essas tarefas remediadas antes de prosseguir:

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

O teste dos resultados atualizados da avaliação da política e do ambiente fornece diretamente a confirmação de que as tarefas de correção alteraram o que era esperado e que a definição da política viu a conformidade mudar conforme o esperado.

Atualização para atribuições impostas

Depois que todos os portões de validação forem concluídos, atualize a atribuição para usar enforcementMode of enabled. Recomenda-se fazer essa mudança inicialmente no mesmo ambiente, longe da produção. Valide se os efeitos desejados são aplicados durante a criação e atualização de recursos. Depois que esse ambiente for validado como funcionando conforme o esperado, a alteração deverá ter o escopo para incluir o próximo ambiente, e assim por diante, até que a política seja implantada nos recursos de produção.

Avaliações integradas de processos

O fluxo de trabalho geral da Política do Azure como Código destina-se ao desenvolvimento e implementação de políticas e iniciativas num ambiente em escala. No entanto, a avaliação de políticas deve fazer parte do processo de implantação de qualquer fluxo de trabalho que implante ou crie recursos no Azure, como implantar aplicativos ou executar modelos ARM para criar infraestrutura.

Nesses casos, depois que a implantação do aplicativo ou da infraestrutura for feita em uma assinatura de teste ou grupo de recursos, a avaliação de políticas deve ser feita para essa validação de verificação de escopo de todas as políticas e iniciativas existentes. Embora eles possam ser configurados como enforcementMode desabilitado em tal ambiente, é útil saber antecipadamente se uma implantação de aplicativo ou infraestrutura viola as definições de política antecipadamente. Essa avaliação de política deve, portanto, ser uma etapa nesses fluxos de trabalho e falhar implantações que criam recursos não compatíveis.

Rever

Este artigo aborda o fluxo de trabalho geral da Política do Azure 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 ofereça suporte a etapas com script e automação com base em gatilhos.

Próximos passos