Azure Policy DeployIfNotExists - Boot Diagnostics automático nas VMs

Azure Policy DeployIfNotExists: Boot Diagnostics Automático nas VMs

Deixe um comentário / Microsoft Azure / Por
Twittar
Compartilhar
Pin
Compartilhar
0 Compart.

Azure Policy DeployIfNotExists: Boot Diagnostics Automático nas VMs

Nos dois artigos anteriores desta série, ativamos o Boot Diagnostics em todas as VMs com Python e o usamos para resgatar uma VM que não inicializava. Mas ficou uma lacuna: o script corrige o passado, e nada impede que a próxima VM criada nasça sem o recurso. Governança de verdade não é rodar um script de vez em quando — é a plataforma se corrigir sozinha.

É exatamente isso que uma Azure Policy DeployIfNotExists faz: ela avalia cada VM criada ou alterada e, se o Boot Diagnostics não estiver habilitado, dispara automaticamente um deployment que o ativa — sem script, sem pipeline, sem intervenção humana. Neste tutorial você vai criar a política do zero, atribuí-la com uma Managed Identity, testá-la com uma VM nova e remediar as existentes com uma remediation task, tudo no mesmo laboratório da série (rg-bootdiag-lab-eus).

Sumário

Por que o script não basta

O script Python do primeiro artigo é ótimo para remediação pontual, mas tem uma natureza reativa: entre uma execução e outra, VMs novas ficam descobertas. A Azure Policy DeployIfNotExists inverte essa lógica — a avaliação acontece na plataforma, disparada pela própria criação ou alteração do recurso, além de uma varredura de conformidade automática a cada 24 horas. A comparação resume o ganho:

Abordagem Quando age VMs novas Visibilidade
Script Python (art. 1) Quando alguém executa Descobertas até a próxima execução Output do script
Azure Policy DeployIfNotExists Na criação/alteração + varredura diária Corrigidas automaticamente Dashboard de compliance nativo

Vale registrar que existe uma política built-in de auditoria (“Boot Diagnostics should be enabled on virtual machines”), mas o efeito dela é apenas audit — marca a VM como não conforme e para por aí. Para corrigir automaticamente, precisamos de uma definição customizada.

Como a Azure Policy DeployIfNotExists funciona

Uma Azure Policy DeployIfNotExists tem três engrenagens que precisam se encaixar:

  • Condição (if): quais recursos a política observa — no nosso caso, todo Microsoft.Compute/virtualMachines;
  • Condição de existência (existenceCondition): o que torna o recurso conforme — bootDiagnostics.enabled igual a true. Se for verdade, nada acontece;
  • Deployment: o template ARM que a plataforma executa quando a condição de existência falha — um patch incremental que liga o Boot Diagnostics gerenciado, idêntico em efeito ao begin_update do script Python.

Como o deployment roda em nome da política (e não do usuário), a atribuição precisa de uma Managed Identity com permissão de escrita nas VMs — configuraremos isso na seção de atribuição.

Pré-requisitos

  • Azure CLI autenticado (az login)
  • Permissão de Resource Policy Contributor (criar definições/atribuições) e User Access Administrator ou Owner no escopo (conceder a role à Managed Identity)
  • O laboratório da série: RG rg-bootdiag-lab-eus com as 5 VMs dos artigos anteriores

Criando a definição da política

Salve a regra abaixo como policy-rule.json. Ela é o coração da Azure Policy DeployIfNotExists: observa as VMs, considera conforme quem já tem o recurso ativo e, para as demais, executa um template incremental que altera apenas o diagnosticsProfile — disco, rede e tamanho ficam intocados:

{
  "if": {
    "field": "type",
    "equals": "Microsoft.Compute/virtualMachines"
  },
  "then": {
    "effect": "deployIfNotExists",
    "details": {
      "type": "Microsoft.Compute/virtualMachines",
      "name": "[field('name')]",
      "evaluationDelay": "AfterProvisioningSuccess",
      "existenceCondition": {
        "field": "Microsoft.Compute/virtualMachines/diagnosticsProfile.bootDiagnostics.enabled",
        "equals": "true"
      },
      "roleDefinitionIds": [
        "/providers/Microsoft.Authorization/roleDefinitions/9980e02c-c2be-4d73-94e8-173b1dc7cf3c"
      ],
      "deployment": {
        "properties": {
          "mode": "incremental",
          "template": {
            "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
            "contentVersion": "1.0.0.0",
            "parameters": {
              "vmName": { "type": "string" },
              "location": { "type": "string" }
            },
            "resources": [
              {
                "type": "Microsoft.Compute/virtualMachines",
                "apiVersion": "2024-03-01",
                "name": "[parameters('vmName')]",
                "location": "[parameters('location')]",
                "properties": {
                  "diagnosticsProfile": {
                    "bootDiagnostics": { "enabled": true }
                  }
                }
              }
            ]
          },
          "parameters": {
            "vmName": { "value": "[field('name')]" },
            "location": { "value": "[field('location')]" }
          }
        }
      }
    }
  }
}

Três detalhes merecem atenção. O roleDefinitionIds aponta para a role Virtual Machine Contributor — é ela que a Managed Identity da atribuição vai receber. O evaluationDelay: AfterProvisioningSuccess evita que a política tente corrigir uma VM que ainda está sendo provisionada. E o mode: incremental do template garante o comportamento de patch. Agora registre a definição:

$ az policy definition create \
    --name deploy-boot-diagnostics \
    --display-name "Habilitar Boot Diagnostics nas VMs (DeployIfNotExists)" \
    --description "Ativa o Boot Diagnostics gerenciado em VMs que estejam sem o recurso." \
    --rules policy-rule.json \
    --mode Indexed

Atribuir com Managed Identity

A atribuição liga a política a um escopo — aqui, o resource group do lab; em produção, tipicamente a subscription ou um management group. O parâmetro --mi-system-assigned cria a Managed Identity e o --role/--identity-scope já concede a permissão que o deployment precisa:

$ SUB=$(az account show --query id -o tsv)

$ az policy assignment create \
    --name habilitar-bootdiag \
    --policy deploy-boot-diagnostics \
    --scope "/subscriptions/$SUB/resourceGroups/rg-bootdiag-lab-eus" \
    --mi-system-assigned \
    --location eastus \
    --role "Virtual Machine Contributor" \
    --identity-scope "/subscriptions/$SUB/resourceGroups/rg-bootdiag-lab-eus"

Sem essa role, a política até detecta as VMs não conformes, mas todo deployment de correção falha com AuthorizationFailed — é o erro mais comum ao adotar Azure Policy DeployIfNotExists, e por isso a tabela de troubleshooting no fim do artigo começa por ele.

Testar: criar uma VM sem o recurso

Hora da prova real da Azure Policy DeployIfNotExists. A CLI, ao contrário do portal, não habilita Boot Diagnostics por padrão — perfeito para simular aquela VM criada “fora do processo”. Vamos criar a sexta máquina do lab:

$ az vm create -g rg-bootdiag-lab-eus -n vm-bootdiag-06 \
    --image Ubuntu2204 --size Standard_B1s \
    --admin-username azureuser --generate-ssh-keys \
    --public-ip-address "" --nsg ""

$ az vm show -g rg-bootdiag-lab-eus -n vm-bootdiag-06 \
    --query "diagnosticsProfile.bootDiagnostics.enabled" -o tsv
(vazio — recurso não configurado)

A avaliação dispara automaticamente após o provisionamento e o deployment de correção entra na fila — o ciclo completo costuma levar de 10 a 30 minutos. Você pode acompanhar pelo estado de conformidade e depois confirmar o resultado:

$ az policy state list -g rg-bootdiag-lab-eus \
    --filter "policyAssignmentName eq 'habilitar-bootdiag'" \
    --query "[?complianceState=='NonCompliant'].resourceId" -o tsv
/subscriptions/.../resourcegroups/rg-bootdiag-lab-eus/providers/microsoft.compute/virtualmachines/vm-bootdiag-06

# ~15 minutos depois, a política já corrigiu a VM:
$ az vm show -g rg-bootdiag-lab-eus -n vm-bootdiag-06 \
    --query "diagnosticsProfile.bootDiagnostics.enabled" -o tsv
true

Nenhum comando de correção foi executado por nós: a plataforma detectou, decidiu e corrigiu. A prova fica registrada no próprio resource group — cada correção da política aparece como um deployment com o prefixo PolicyDeployment_:

$ az deployment group list -g rg-bootdiag-lab-eus \
    --query "[?starts_with(name,'PolicyDeployment')].{Deployment:name, Estado:properties.provisioningState}" -o table

Deployment                              Estado
--------------------------------------  ---------
PolicyDeployment_17817486597642814811   Succeeded
PolicyDeployment_5848116706856540669    Succeeded

Bônus: a política também corrige drift

Repare que a listagem acima mostra dois deployments — e nós só criamos uma VM nova. O segundo veio de outro teste: desabilitamos o Boot Diagnostics da vm-bootdiag-05 (simulando alguém “arrumando” a VM na mão) e, minutos depois, a política reverteu a mudança sozinha. Isso acontece porque a avaliação do deployIfNotExists dispara em qualquer criação ou alteração do recurso: o próprio ato de desabilitar é um update, o update dispara a avaliação, a avaliação detecta a não conformidade e o deployment corrige. Ou seja, além de cobrir as VMs novas, a Azure Policy DeployIfNotExists elimina o drift de configuração — sem agente, sem cron, sem pipeline.

Remediation task para as VMs existentes

Se a política corrige criação, alteração e drift, o que sobra? Exatamente o caso mais comum na vida real: as VMs que já estavam fora do padrão antes da atribuição e nunca mais foram alteradas. Para elas, a varredura só marca NonCompliant — o deployIfNotExists não dispara sozinho, porque não houve nenhum evento de criação ou update. Corrigi-las exige uma remediation task explícita. No laboratório, a vm-bootdiag-04 estava sem o recurso desde antes da atribuição; após a varredura marcá-la como não conforme, criamos a remediação:

$ az policy remediation create \
    --name remediar-bootdiag \
    --policy-assignment habilitar-bootdiag \
    -g rg-bootdiag-lab-eus

$ az policy remediation show --name remediar-bootdiag -g rg-bootdiag-lab-eus \
    --query "{status:provisioningState, corrigidos:deploymentStatus.successfulDeployments}"
{
  "status": "Succeeded",
  "corrigidos": 1
}

E a verificação final — a mesma consulta usada no primeiro artigo da série, agora com seis VMs, todas conformes:

$ az vm list -g rg-bootdiag-lab-eus \
    --query "sort_by([].{VM:name, BootDiagnostics:diagnosticsProfile.bootDiagnostics.enabled}, &VM)" -o table

VM              BootDiagnostics
--------------  -----------------
vm-bootdiag-01  True
vm-bootdiag-02  True
vm-bootdiag-03  True
vm-bootdiag-04  True
vm-bootdiag-05  True
vm-bootdiag-06  True

Troubleshooting

Problema Causa Solução
Deployment da política falha com AuthorizationFailed Managed Identity sem a role de escrita Confirme o role assignment de Virtual Machine Contributor para a identity da atribuição no escopo
VM nova continua não conforme por muito tempo Ciclo de avaliação/correção ainda não fechou Aguarde até ~30 min ou force com az policy state trigger-scan -g rg-bootdiag-lab-eus
Política nunca marca nada como não conforme existenceCondition sempre verdadeira ou alias errado Valide o alias com az provider show -n Microsoft.Compute --expand resourceTypes/aliases
Conflict no deployment de correção Outra operação em andamento na VM A política tenta novamente no próximo ciclo; nenhuma ação necessária
Remediation task com failedDeployments VM desalocada em transição ou lock no RG Verifique locks e recrie a remediação após o estado estabilizar

Limpeza dos recursos

Este é o último artigo da série usando este laboratório, então a limpeza agora é completa — a atribuição, a definição e o resource group:

az policy assignment delete --name habilitar-bootdiag \
    --scope "/subscriptions/$SUB/resourceGroups/rg-bootdiag-lab-eus"
az policy definition delete --name deploy-boot-diagnostics
az group delete --name rg-bootdiag-lab-eus --yes --no-wait

Conclusão

A série fechou o ciclo completo de governança do Boot Diagnostics: o script Python corrigiu o passado, o troubleshooting mostrou o valor do recurso durante um incidente e a Azure Policy DeployIfNotExists garantiu o futuro — toda VM nova nasce conforme, e as existentes são corrigidas por remediation task, com dashboard de compliance nativo de brinde. O padrão que você montou aqui (condição + existenceCondition + template de patch + Managed Identity) é reutilizável para muito além do Boot Diagnostics: backup obrigatório, agente de monitoramento, tags de governança. Troque o alias e o template, e a mesma estrutura resolve o próximo requisito da sua operação.

Referências oficiais

Interessado em saber mais sobre artigos relacionados ao Microsoft Azure CLIQUE AQUI

🚀 Vamos nos conectar?

Não perca nenhuma oportunidade! Cadastre-se nas minhas redes e no canal do YouTube para receber conteúdos de TI, Cloud, Azure, Kubernetes e DevOps em primeira mão.

Dica: No Facebook, todos os artigos do blog são publicados automaticamente. Vale a pena curtir!

💬 Dúvidas ou Problemas?

Com o intuito de ajudar a comunidade, caso você tenha dúvidas ou encontre problemas na execução dos comandos deste artigo, deixe um comentário abaixo. Responderei o mais breve possível!

Muito obrigado pela visita e até o próximo post!

Jefferson Castilho Especialista em Cloud & DevOps.

Este guia técnico é exclusivo do Blog do Castilho. Explore mais conteúdos sobre Cloud e DevOps.

 

Twittar
Compartilhar
Pin
Compartilhar
0 Compart.

Posts relacionados

Deixe uma resposta

Rolar para cima

Descubra mais sobre Blog do Castilho - Tecnologia | FinOps | DevOps | Cloud

Assine agora mesmo para continuar lendo e ter acesso ao arquivo completo.

Continuar lendo