Implantação segura de atribuições do Azure Policy

Artigo
07/16/2024

À medida que seu ambiente se expande, a demanda por um pipeline de CD (implantação contínua) controlada com controle de exposição progressiva também se expande. Portanto, a Microsoft recomenda que as equipes de DevOps sigam a estrutura SDP (práticas de implantação seguras). A implantação segura de definições e atribuições do Azure Policy ajuda a limitar o impacto de comportamentos não intencionais de recursos de política.

A abordagem de alto nível para implementação da SDP com o Azure Policy é distribuir gradualmente atribuições de política por anéis para detectar alterações de política que afetam o ambiente nos estágios iniciais, antes que afetem a infraestrutura de nuvem crítica.

Os anéis de implantação podem ser organizados de diversas maneiras. Neste tutorial de instruções, os anéis são divididos por diferentes regiões do Azure. O Anel 0 representa locais de tráfego baixo e não críticos, enquanto o Anel 5 indica os locais de tráfego mais alto e críticos.

Etapas para a implantação segura das atribuições do Azure Policy com efeitos de negação ou acréscimo

Use o fluxograma a seguir como referência enquanto trabalhamos em como aplicar a estrutura SDP a atribuições do Azure Policy que usam os efeitos de política deny ou append.

Observação

Para saber mais sobre os efeitos da política do Azure, confira Entender como os efeitos funcionam.

Fluxograma com etapas de um a oito mostrando práticas de implantação seguras de uma nova definição do Azure Policy.

Números da etapa do fluxograma:

Depois de selecionar sua definição de política, atribua a política no escopo de nível mais alto, incluindo todos os anéis de implantação. Aplique seletores de recursos para restringir a aplicabilidade ao anel menos crítico usando a propriedade "kind": "resource location". Configure o tipo de efeito audit usando substituições de atribuição. Seletor de amostras com eastUSlocalização e efeito comoaudit:
```
"resourceSelectors": [{ 
  "name": "SDPRegions", 
  "selectors": [{
      "kind": "resourceLocation",
      "in": [ "eastUS" ] 
  }]
}], 
"overrides":[{ 
  "kind": "policyEffect", 
  "value": "Audit" 
}] 
```
Depois que a atribuição for implantada e a verificação de conformidade inicial for concluída, valide se o resultado da conformidade é o esperado.

Você também deve configurar testes automatizados que executam verificações de conformidade. Uma verificação de conformidade deve abranger a seguinte lógica:
- Coletar resultados de conformidade
- Se os resultados de conformidade forem os esperados, o pipeline deverá continuar
- Se os resultados de conformidade não forem os esperados, o pipeline deverá falhar e você deverá iniciar a depuração
Por exemplo, você pode configurar a verificação de conformidade usando outras ferramentas em seu pipeline específico de CI/CD (integração contínua/implantação contínua).

Em cada estágio de distribuição, as verificações de integridade do aplicativo devem confirmar a estabilidade do serviço e o impacto da política. Se os resultados não forem os esperados devido à configuração do aplicativo, refatore o aplicativo conforme apropriado.
Repita expandindo os valores de propriedade do seletor de recursos para incluir os próximos anéis. localizações e validação dos resultados de conformidade esperados e da integridade do aplicativo. Seletor de exemplo com um valor de local adicionado:
```
"resourceSelectors": [{ 
  "name": "SDPRegions", 
  "selectors": [{
      "kind": "resourceLocation",
      "in": [ "eastUS", "westUS"] 
  }]
}]
```
Depois de atribuir com êxito a política a todos os anéis usando o modo audit, o pipeline deve disparar uma tarefa que altera o efeito de política para deny e redefinir os seletores de recursos para o local associado ao Anel 0. Seletor de exemplo com uma região e um efeito definidos para negar:
```
"resourceSelectors": [{ 
  "name": "SDPRegions", 
  "selectors": [{
      "kind": "resourceLocation",
      "in": [ "eastUS" ] 
  }]
}], 
"overrides":[{ 
  "kind": "policyEffect", 
  "value": "Deny" 
}] 
```
Depois que o efeito for alterado, os testes automatizados devem verificar se a imposição está ocorrendo conforme o esperado.
Repita incluindo mais anéis na configuração do seletor de recursos.
Repita esse processo para todos os anéis de produção.

Etapas para a implantação segura de atribuições do Azure Policy com efeitos modify ou deployIfNotExists

As etapas para políticas que usam os efeitos modify ou deployIfNotExists são semelhantes às etapas explicadas anteriormente com a ação adicional de usar o modo de imposição e disparar uma tarefa de correção. Examine o fluxograma a seguir com as etapas modificadas 5 a 9:

Fluxograma mostrando as etapas 5 a 9 no fluxo de trabalho de práticas de implantação seguras do Azure Policy.

Números da etapa do fluxograma:

Depois de selecionar sua definição de política, atribua a política no escopo de nível mais alto, incluindo todos os anéis de implantação. Aplique seletores de recursos para restringir a aplicabilidade ao anel menos crítico usando a propriedade "kind": "resource location". Configure o modo de imposição da atribuição para DoNotEnforce. Seletor de exemplo com local eastUS e enforcementMode como DoNotEnforce:
```
"resourceSelectors": [{ 
  "name": "SDPRegions", 
  "selectors": [{
      "kind": "resourceLocation",
      "in": [ "eastUS" ] 
  }]
}], 
"enforcementMode": "DoNotEnforce"
```
Depois que a atribuição for implantada e a verificação de conformidade inicial for concluída, valide se o resultado da conformidade é o esperado.

Você também deve configurar testes automatizados que executam verificações de conformidade. Uma verificação de conformidade deve abranger a seguinte lógica:
- Coletar resultados de conformidade
- Se os resultados de conformidade forem os esperados, o pipeline deverá continuar
- Se os resultados de conformidade não forem os esperados, o pipeline deverá falhar e você deverá iniciar a depuração
Você pode configurar a verificação de conformidade usando outras ferramentas em seu pipeline de CI/CD (integração contínua/implantação contínua).

Em cada estágio de distribuição, as verificações de integridade do aplicativo devem confirmar a estabilidade do serviço e o impacto da política. Se os resultados não forem os esperados devido à configuração do aplicativo, refatore o aplicativo conforme apropriado.

Você também pode disparar tarefas de correção para corrigir recursos não compatíveis existentes. Verifique se as tarefas de correção estão colocando recursos em conformidade conforme o esperado.
Repita expandindo os valores das propriedades do seletor de recursos para incluir a localização dos próximos anéis e validando os resultados de conformidade esperados e a integridade do aplicativo. Seletor de exemplo com um valor de local adicionado:
```
"resourceSelectors": [{ 
  "name": "SDPRegions", 
  "selectors": [{
      "kind": "resourceLocation",
      "in": [ "eastUS", "westUS"] 
  }]
}]
```
Depois de atribuir a política a todos os anéis com êxito usando o modo DoNotEnforce, o pipeline deve disparar uma tarefa que altera a política enforcementMode para habilitação padrão e redefinir os seletores de recursos para o local associado ao anel 0. Seletor de exemplo com uma região e um efeito definidos para negar:
```
"resourceSelectors": [{ 
  "name": "SDPRegions", 
  "selectors": [{
      "kind": "resourceLocation",
      "in": [ "eastUS" ] 
  }]
}], 
"enforcementMode": "Default",
```
Depois que o efeito for alterado, os testes automatizados devem verificar se a imposição está ocorrendo conforme o esperado.
Repita incluindo mais anéis na configuração do seletor de recursos.
Repita esse processo para todos os anéis de produção.

Etapas para atualizar com segurança a versão da definição padrão dentro de uma atribuição do Azure Policy

Na atribuição já existente, aplique substituições para atualizar a versão da definição para o anel menos crítico. Estamos usando uma combinação de substituições para alterar a definitionVersion e seletores dentro da condição de substituições, com o objetivo de limitar a aplicação da política pela propriedade "kind": "resource location". Todos os recursos que não estiverem nos locais especificados continuarão a ser avaliados com base na versão indicada pela propriedade definitionVersion principal na atribuição. O exemplo substitui a atualização da versão da definição para 2.0.* e aplica essa mudança apenas aos recursos em EastUs.
```
"overrides":[{ 
  "kind": "definitionVersion", 
  "value": "2.0.*",
  "selectors": [{
    "kind": "resourceLocation",
    "in": [ "eastus"]
  }]
}] 
```
Após a atualização da atribuição e a conclusão da verificação inicial de conformidade, valide se o resultado da conformidade é o esperado.

Você também deve configurar testes automatizados que executam verificações de conformidade. Uma verificação de conformidade deve abranger a seguinte lógica:
- Coletar resultados de conformidade
- Se os resultados de conformidade forem os esperados, o pipeline deverá continuar
- Se os resultados de conformidade não forem os esperados, o pipeline deverá falhar e você deverá iniciar a depuração
Por exemplo, você pode configurar a verificação de conformidade usando outras ferramentas em seu pipeline específico de CI/CD (integração contínua/implantação contínua).

Em cada estágio de distribuição, as verificações de integridade do aplicativo devem confirmar a estabilidade do serviço e o impacto da política. Se os resultados não forem os esperados devido à configuração do aplicativo, refatore o aplicativo conforme apropriado.
Repita expandindo os valores de propriedade do seletor de recursos para incluir os próximos anéis. localizações e validação dos resultados de conformidade esperados e da integridade do aplicativo. Exemplo com um valor de local adicionado:
```
 "overrides":[{ 
  "kind": "definitionVersion", 
  "value": "2.0",
  "selectors": [{
    "kind": "resourceLocation",
    "in": [ "eastus", "westus"]
  }]
}] 
```
Depois de incluir com sucesso todos os locais necessários nos _seletores, você pode remover a substituição e atualizar a propriedade definitionVersion na atribuição:

"properties": {
        "displayName": "Enforce resource naming rules",
        "description": "Force resource names to begin with DeptA and end with -LC",
        "definitionVersion": "2.0.*",
}

Próximas etapas

Saiba como criar políticas de forma programática.
Examine a Azure Policy como fluxos de trabalho de código.
Estude as orientações da Microsoft sobre as práticas de implantação segura.
Revise Corrigir recursos que não estão em conformidade com o Azure Policy.

Compartilhar via

Implantação segura de atribuições do Azure Policy

Etapas para a implantação segura das atribuições do Azure Policy com efeitos de negação ou acréscimo

Etapas para a implantação segura de atribuições do Azure Policy com efeitos modify ou deployIfNotExists

Etapas para atualizar com segurança a versão da definição padrão dentro de uma atribuição do Azure Policy

Próximas etapas

Comentários

Recursos adicionais