Onde o Azure Policy termina e o Open Policy Agent (OPA) começa

Governança em cloud costuma falhar quando tentamos resolver problemas de camadas diferentes com uma única ferramenta. O resultado é previsível: policies difíceis de manter, exceções demais, fricção com times de produto e uma falsa sensação de segurança.

Capa do artigo: Onde o Azure Policy termina e o Open Policy Agent começa.

Figura 1 — Onde cada ferramenta atua: Azure Policy, OPA e Sentinel por camadas.

A pergunta “onde o Azure Policy termina e o Open Policy Agent (OPA) começa?” é excelente — e normalmente vem acompanhada de dúvidas práticas como:

“OPA consegue aplicar políticas no ambiente nativo da cloud, como se fosse Azure Policy?”
“Consigo importar os JSONs do Azure Policy para o OPA?”
“Eu já tenho Sentinel (HCP Terraform/Terraform Enterprise). Devo usar OPA mesmo assim?”
“OPA substitui o Terraform (ou a esteira de IaC), incluindo o state do Terraform?”

Este artigo responde essas dúvidas com um modelo mental simples, pragmático e que escala.

Conceitos-chave (para quem está começando)

Azure Policy

Azure Policy é o mecanismo nativo do Azure para enforcement e compliance em escala no control plane (ARM): você define regras e o Azure avalia recursos em criação/atualização e em inventário, com escopo corporativo (Management Groups, subscriptions, resource groups) e visibilidade central de conformidade.

Open Policy Agent (OPA)

OPA é um motor genérico de policy-as-code: ele recebe “entradas” (geralmente JSON), avalia políticas escritas em Rego, e retorna decisões (permitir/negar/explicar). Ele não “é a cloud”; ele precisa de um ponto de enforcement (CI/CD, Kubernetes admission controller, gateway, serviço, etc.) para que a decisão vire bloqueio/validação.

Sentinel (HashiCorp)

Sentinel é o framework de policy-as-code nativo do ecossistema HashiCorp (ex.: HCP Terraform), usado para validar e aplicar políticas durante o workflow de runs/plan/apply. Em HCP Terraform você pode usar Sentinel ou OPA para enforcement de políticas (conforme o seu padrão).

Terraform (IaC)

Terraform é uma ferramenta de Infrastructure as Code (IaC) usada para provisionar e alterar infraestrutura declarando recursos em arquivos (HCL). Ele calcula o que precisa mudar (plan) e executa essas mudanças (apply) em provedores como Azure, AWS e GCP.

Esteira IaC (CI/CD para infraestrutura)

A esteira IaC é o fluxo automatizado que aplica governança e controle ao ciclo do IaC, normalmente envolvendo:

Pull Request (revisão e aprovação)
Validações automáticas (lint, segurança, policy checks)
Geração de terraform plan (pré-visualização das mudanças)
Aprovação (manual ou automática, conforme criticidade)
Execução do terraform apply (implantação)
O objetivo é garantir que infraestrutura seja criada com qualidade, rastreabilidade e compliance, reduzindo bypass e retrabalho.

Terraform Plan

O plan é a “prévia” das mudanças que o Terraform pretende fazer: o que será criado, alterado ou removido. Em fluxos de governança, é comum usar o plan em formato JSON como entrada para validações (por exemplo, OPA), porque ele descreve as mudanças de forma estruturada.

Terraform State (estado)

O state é o registro que o Terraform mantém para saber o que existe de fato na infraestrutura e como isso se relaciona com o código IaC.
Ele é essencial para o Terraform calcular diffs corretamente, evitar recriações indevidas e coordenar atualizações.

Na prática:

O state não é “do OPA” nem “do Azure Policy”.
Ele fica em um backend de state (ex.: Terraform Cloud/HCP Terraform, Azure Storage, etc.).
Em ambientes corporativos, o state deve ser remoto, com controle de acesso, versionamento e travas (locking) quando aplicável.

Shift-left

Shift-left significa validar regras antes do deploy, idealmente ainda no PR/pipeline (ou no workflow do Terraform) para reduzir retrabalho, risco e tempo de feedback.

Control plane vs runtime (resumo útil)

Control plane (Azure/ARM): onde o Azure Policy atua com enforcement nativo.
Runtime (Kubernetes/APIs): onde OPA/Gatekeeper e decisões em gateways/microserviços se tornam relevantes.

O problema real: camadas diferentes, mecanismos diferentes

Para decidir corretamente, separe três camadas:

Controle de plataforma (control plane): Regras aplicadas “no Azure”, no momento de criação/atualização de recursos (ARM), com escopo corporativo e compliance.
Entrega (shift-left no CI/CD): Regras aplicadas antes de criar recursos: PRs, pipelines, terraform plan, Helm, manifests, etc.
Runtime (execução): Regras aplicadas “durante” a execução: admission control em Kubernetes, autorização em APIs, gateways, serviços, etc.

Azure Policy domina a camada 1.
OPA domina a camada 2 e 3.

Infográfico: Controle de Plataforma, Entrega (Shift-left) e Runtime com ferramentas associadas.

Figura 2 — Camadas de governança: primeira linha (shift-left) e última linha (Azure Policy).

O que o Azure Policy faz muito bem (e por que ele é insubstituível no Azure)

Azure Policy é excelente quando você precisa:

Impor guardrails nativos no Azure (ARM): regiões, SKUs, tipos de recurso, criptografia, tags, configurações mínimas.
Ter compliance corporativo centralizado: iniciativas, escopos e exceções (exemptions), com visão agregada.
Usar efeitos (“effects”) para definir o comportamento, como audit e deny.

Também existe o cenário de remediação para certos casos com deployIfNotExists, que executa uma implantação quando a condição é atendida (normalmente exigindo identidade gerenciada para Remediação (deployIfNotExists).

Onde o Azure Policy “termina” (limites naturais)

Azure Policy tende a ser a escolha errada quando o requisito:

Precisa acontecer antes do deploy (falhar PR/pipeline sem criar recurso).
Precisa ser portável multi-cloud com o mesmo motor/linguagem/processo.
Depende de entradas fora do modelo do Azure (ex.: regras específicas de PR, reuso de controles entre stacks, correlações que fazem mais sentido no CI/CD).

O que o OPA faz muito bem (e por que ele “começa” fora do Azure)

OPA é forte quando você quer:

Shift-left real: validar terraform plan em JSON, manifests Kubernetes e outros artefatos antes do deploy.
Portabilidade: aplicar o mesmo padrão de governança em múltiplas plataformas e pontos de decisão.
Testabilidade: tratar políticas como software (testes, versionamento e evolução controlada).

Dúvidas comuns

“OPA consegue aplicar políticas no ambiente nativo da cloud, como se fosse Azure Policy?”

Não no mesmo sentido. OPA não se integra ao ARM como um “efeito nativo” do Azure (como deny, modify ou deployIfNotExists). Ele é um motor de decisão, e precisa de um enforcer no caminho (pipeline, plataforma de Terraform, admission controller no Kubernetes, gateway, etc.).

Na prática:

Se alguém cria recursos direto no Portal, o OPA não bloqueia sozinho.
Para bloqueio nativo no Azure (inclusive Portal), o caminho típico é Azure Policy.
Para bloquear antes do Azure, o caminho típico é OPA no CI/CD ou no workflow de Terraform (quando disponível).

Modelo recomendado: OPA como “primeira linha” (shift-left) e Azure Policy como “última linha” (baseline corporativo e proteção contra bypass).

“Consigo importar os JSONs do Azure Policy para o OPA?”

Não de forma direta. Azure Policy e OPA têm modelos e linguagens diferentes:

Azure Policy: JSON específico do engine do Azure, com escopos e efeitos.
OPA: Rego + entradas arbitrárias (por exemplo, JSON do terraform plan).

O caminho correto é portar a intenção, não o artefato:

você mantém a regra “baseline” no Azure Policy (enforcement nativo);
e implementa a regra equivalente no OPA para shift-left (validando plan, manifests, etc.).

“Eu já tenho Sentinel (HCP Terraform). Devo usar OPA mesmo assim?”

Depende do seu objetivo:

Se seu enforcement é majoritariamente Terraform dentro do HCP Terraform, Sentinel pode ser suficiente (especialmente se já está padronizado e operante).
Se você quer unificar políticas além do Terraform (Kubernetes, APIs, gateways, multi-cloud) e reduzir lock-in, OPA tende a ser o investimento mais versátil.

Ponto importante: no HCP Terraform você pode definir policies usando Sentinel ou OPA (frameworks suportados) e gerir policy sets conforme o seu modelo.

Além disso, a HashiCorp tem posicionamento público sobre suporte nativo a OPA na plataforma.

“OPA substitui o Terraform (ou a esteira de IaC), incluindo o state do Terraform?”

Não. OPA não substitui Terraform, nem “guarda o state” do Terraform. OPA é um motor de decisão (policy engine). Terraform continua sendo o motor de provisionamento e o state continua sendo responsabilidade do Terraform backend (ex.: Azure Storage, Terraform Cloud/HCP Terraform, etc.).

Explicação prática (para evitar confusão)

Terraform: calcula o plano, aplica mudanças e mantém o estado (state) do que foi provisionado.
OPA: avalia regras e responde “permitido/negado” com base em entradas (por exemplo, o JSON do terraform plan).
Policy as Code com Terraform: normalmente significa “Terraform como IaC + um mecanismo de policy enforcement no pipeline/plataforma” (ex.: Sentinel ou OPA) — ou seja, OPA entra como guardrail, não como substituto do IaC.

Onde o OPA entra no fluxo (exemplo)

Você gera terraform plan (idealmente em JSON).
OPA valida o plano: “este recurso viola padrões?” (tags, regiões, exposição pública, SKUs, etc.).
Se violar, o pipeline falha e o apply nem acontece.

Isso entrega shift-left (feedback rápido) sem mexer em state, backends ou no papel do Terraform.

Regra de bolso

State: sempre do Terraform (e seu backend).
Guardrails: OPA/Sentinel (ou ambos, conforme o ecossistema).
Baseline no Azure: Azure Policy (para cobrir bypass e manter conformidade).

Matriz de decisão: Azure Policy vs OPA vs Sentinel

Tabela visual comparando cenários e a escolha típica entre Azure Policy, OPA e Sentinel.

Figura 3 — Matriz de decisão: qual ferramenta faz mais sentido por cenário.

Padrão recomendado: “Shift-left” + “Last line of defense”

Um desenho estável em ambientes corporativos:

PR/CI (Shift-left)

OPA (ou Sentinel no HCP Terraform) bloqueando violações antes do deploy.

Azure (Baseline/Enforcement/Compliance)

Azure Policy impedindo bypass via Portal/atalhos e garantindo conformidade central.

Runtime (quando aplicável)

OPA/Gatekeeper em Kubernetes e/ou decisões em gateways/microserviços.

Fluxo: Dev/PR → CI/CD com OPA ou Sentinel → Deploy IaC → Azure com Azure Policy → Runtime com OPA/Gatekeeper.

Figura 4 — Fluxo recomendado: validação cedo (OPA/Sentinel), baseline no Azure (Azure Policy) e runtime quando aplicável.

Como evitar duplicidade e inconsistência (o erro mais comum)

O erro mais comum ao introduzir OPA/Sentinel é duplicar regras sem um “contrato” de intenção.

Recomendação prática:

Crie um catálogo único de guardrails (por pilar: segurança, custo, confiabilidade, operações).

Para cada guardrail, defina:

Intenção (o que protege e por quê),
Implementação shift-left (OPA/Sentinel),
Implementação baseline (Azure Policy),
Exceções (com dono, prazo e justificativa).

Conclusão

Azure Policy termina quando o problema é governança nativa do Azure (ARM), com efeitos e compliance corporativo.

OPA começa quando você precisa de shift-left, portabilidade e enforcement em diferentes pontos (CI/CD, K8s, APIs).

Sentinel é uma alternativa forte quando o centro do seu mundo é HCP Terraform, e pode coexistir com OPA conforme o escopo da governança.

Repositório da PoC

Este repositório contém uma PoC prática de Policy as Code com Open Policy Agent (OPA) aplicada ao contexto de governança em cloud, com foco em shift-left: a ideia é validar regras de governança antes do deploy, durante o ciclo de desenvolvimento (PR/pipeline), reduzindo retrabalho e evitando que configurações fora do padrão cheguem ao ambiente.

Objetivos principais da PoC

Demonstrar como estruturar um repositório de políticas em Rego de forma organizada (por domínio/categoria).
Implementar testes automatizados (opa test) para garantir qualidade e evitar regressões.
Integrar a validação em CI (GitHub Actions) para que mudanças em políticas ou artefatos sejam verificadas automaticamente.
Servir como base para evoluir um modelo de governança “em camadas”: OPA no shift-left e Azure Policy como baseline/enforcement no Azure.

Figura 5 — Estrutura do repositório e organização das políticas/testes.

O que você encontra no repositório

Estrutura de diretórios para políticas (policies) e exemplos/testes associados.
Pipeline de CI com etapas de formatação/validação (ex.: opa fmt) e execução de testes (opa test).
Um ponto de partida para expandir políticas por temas comuns de governança (ex.: tagging, segurança, padrões de recursos), conectando a discussão do artigo com um exemplo executável.