Blog/Artigos · Cloud e Plataforma
OPA e Rego, Checkov, Sentinel e Kyverno, onde a política atua no pipeline, e a diferença entre guardrail que barra e alerta que só avisa.
O salmo fala de um decreto fixado sobre a criação que não se ultrapassa: um limite que vale porque a natureza o cumpre, não porque alguém fiscaliza a cada instante. Política de segurança devia ser assim, e quase nunca é. Na maioria das empresas ela vive num PDF que ninguém lê, contornado por pressa e por desconhecimento, fiscalizado tarde demais, na auditoria anual, quando o estrago já está no ar. Policy as Code muda a natureza do decreto: a regra vira código que barra a violação no instante em que ela tentaria nascer. O limite deixa de depender de vigilância e passa a valer por construção, como o decreto que não se ultrapassa.
Política escrita em documento tem três fraquezas fatais. Primeira: ninguém lê, e quem lê esquece. Segunda: ela é aplicada tarde, na revisão manual ou na auditoria, quando o recurso inseguro já está no ar há semanas. Terceira: ela depende de vigilância humana constante, que cansa e falha. O resultado é a política que existe no papel e não na realidade, o pior dos mundos, porque dá a sensação de controle sem o controle de fato. A auditoria encontra o bucket aberto que a política proibia, e a política não impediu nada.
Policy as Code escreve a regra em código executável e a coloca no caminho da mudança. A política deixa de ser um texto para consultar e vira uma verificação que roda automaticamente: o recurso sem criptografia não passa, a porta de rede aberta para o mundo é barrada, o container que roda como root é recusado. A regra é a mesma; o que muda é que ela executa em vez de aconselhar. E porque é código, ela é versionada, testada e revisada como qualquer outro código, o que resolve a pergunta que a política em PDF nunca respondia bem: quem mudou a regra, quando e por quê.
| Aspecto | Política em PDF | Policy as Code |
|---|---|---|
| Quando age | na auditoria, semanas depois | no instante da mudança, antes de subir |
| Como age | aconselha, depende de alguém ler | executa, barra a violação sozinha |
| Cobertura | amostra que o auditor conseguiu ver | toda mudança, sem exceção nem cansaço |
| Versionada | revisão de documento, se houver | código com histórico, teste e pull request |
| Efeito | sensação de controle sem controle | o limite vale por construção |
Policy as Code segue o princípio do shift-left: quanto mais cedo a regra atua, mais barato custa a violação. No commit, um hook local avisa antes mesmo do push. Na integração, o scanner roda sobre o código de infraestrutura e barra o pull request, e é aqui que ferramentas como o Checkov brilham, lendo o Terraform e apontando o recurso inseguro antes de ele existir. No plan, o Atlantis pode exigir que a política aprove o diff antes do apply. E na admissão do cluster, um controlador recusa o manifesto que viola a regra no momento em que ele tentaria entrar.
Essas camadas não competem, se somam. A verificação no commit dá feedback rápido a quem escreve; a do pipeline é o gate que não se contorna com pressa; a da admissão é a última linha, que pega até o que tentou entrar por fora do pipeline. Um programa maduro tem a mesma política expressa nas várias camadas, para que a regra valha independentemente do caminho pelo qual a mudança chega. É defesa em profundidade aplicada à conformidade: mesmo que uma camada falhe ou seja pulada, a seguinte segura, e o decreto se cumpre em qualquer rota.
As camadas não competem, se somam: se uma falha ou é pulada, a seguinte segura. O decreto se cumpre em qualquer rota pela qual a mudança chegue.
O ecossistema tem uma peça central e várias especialistas. O OPA, o Open Policy Agent, projeto graduado da CNCF, é o motor de política de propósito geral: sua linguagem, o Rego, expressa regra sobre qualquer JSON, o que o torna capaz de avaliar desde manifesto Kubernetes até configuração de nuvem e resposta de API. Em torno dele e ao lado dele vivem as especialistas: o Checkov, da Bridgecrew, focado em varrer IaC; o Sentinel, da HashiCorp, integrado ao Terraform; o Conftest, que roda Rego sobre arquivos de configuração; e o Kyverno e o Gatekeeper, para admissão em Kubernetes.
A escolha depende de onde a regra precisa morar. Para admissão em cluster, Kyverno agrada por escrever política em YAML, sem aprender Rego, enquanto o Gatekeeper usa OPA por baixo. Para IaC, Checkov entrega centenas de regras prontas e cobre o caso comum sem escrever nada. Para regra própria e complexa que atravessa domínios, OPA e Rego dão o poder geral, ao custo de uma linguagem a aprender. O erro é dogmático: adotar uma só ferramenta para tudo e forçá-la onde não encaixa. O maduro combina, com a mesma intenção de política expressa na ferramenta certa de cada camada.
| Ferramenta | Onde atua | Como se escreve | Força |
|---|---|---|---|
| OPA / Rego | propósito geral, qualquer JSON | Rego | poder de expressar regra que atravessa domínios |
| Checkov | varredura de IaC | regras prontas, extensível | centenas de regras sem escrever nada |
| Sentinel | Terraform (HashiCorp) | linguagem própria | integrado ao plan do Terraform Cloud |
| Kyverno | admissão em Kubernetes | YAML, sem Rego | política de cluster sem linguagem nova |
| Gatekeeper | admissão em Kubernetes | OPA/Rego por baixo | o poder do OPA no controle de admissão |
Nem toda política deve barrar. Existem dois modos, e confundir os dois quebra o programa. O modo preventivo barra: a violação não passa, e isso é certo para o inegociável, o dado sensível exposto, a porta aberta para o mundo, a credencial no código. O modo detectivo alerta: deixa passar e registra, o que é certo para o que é recomendação, não lei, ou para o que ainda está sendo adotado e barrar de imediato pararia o time. A arte é saber qual regra merece qual modo, e essa é uma decisão de risco, não de tecnologia.
O erro dos dois lados é comum. Barrar tudo, inclusive o que é só recomendação, gera o efeito Gandalf, o não passarás em toda mudança, e o time aprende a burlar ou a odiar a segurança. Alertar tudo, inclusive o inegociável, gera a fadiga de alerta, e o aviso que importa afoga no ruído dos que não importam. O equilíbrio maduro é a metáfora do guardrail: como a mureta na estrada, ele te impede de cair no precipício, mas não dirige o carro por você. Barra o desastre, avisa o resto, e deixa o time andar. Governança que só sabe dizer não é governança que o time aprende a contornar.
Policy as Code amadurece do nada ao decreto que se cumpre em qualquer rota. No começo é a política no PDF, aplicada na auditoria. No meio é o scanner no pipeline barrando o IaC inseguro. No topo é a mesma política expressa em várias camadas, com modo preventivo e detectivo bem escolhidos, exceções rastreadas e a IA gerando e explicando regra. Cada degrau move a política para mais perto do instante da mudança, até ela valer por construção.
Policy as Code não flutua sozinho: ele senta sobre o IaC, que dá o alvo a verificar, e sobre o GitOps, que dá o momento de verificar, e serve à governança, que dá a intenção. É a ponte entre a política que a governança escreve, vista no artigo sobre GRC, e a realidade da nuvem: sem ela, a política é aspiração; com ela, é fato. Escrever o decreto em código é o que faz a regra deixar o papel e passar a valer no mundo, cumprindo o salmo, um limite que se cumpre porque está construído para se cumprir, não porque alguém vigia.
Policy as Code transforma a política do PDF que ninguém cumpre no decreto que não se ultrapassa, escrito em código que barra a violação no instante da mudança. Atua em camadas, do commit à admissão, com defesa em profundidade; usa OPA, Checkov, Sentinel ou Kyverno conforme a camada; e distingue o guardrail que barra o desastre do alerta que só avisa, para o time seguir andando. A IA gera a regra, escreve o teste e explica o bloqueio. Mas decidir qual violação é inegociável, e qual é só recomendação, continua sendo decisão de risco de quem responde pela segurança do ambiente.
Gerente de Operações, Tecnologia e Infraestrutura (SRE) numa central de registros. Trabalho com tecnologia desde 2009 e com cibersegurança em tempo integral desde 2015, em infraestrutura crítica, fintech e banking. Escrevo sobre o que eu opero: confiabilidade, segurança, governança e IA que passa por gate antes de chegar em produção.
Cloud e Plataformaכְּתָב
Infra criada no clique não se reproduz e ninguém sabe explicar. IaC escreve a infraestrutura como código versionado e revisável, e o que está escrito se materializa igual toda vez. O perigo mora no state, e a maturidade em tratar servidor como gado, não como bicho de estimação.
Cloud e Plataformaשׁוּב
GitOps faz do Git a única fonte de verdade do que roda, e um controlador puxa a realidade de volta ao que está escrito, sem parar. Deploy vira commit, rollback vira reverter, e o drift se corrige sozinho. O repositório declara, o laço reconcilia.
