Open Policy Agent para MSPs: admissão, autorização de API e portões de CI

O Open Policy Agent (OPA) é conhecido sobretudo como o motor por trás do controlo de admissão no Kubernetes, mas o projeto principal não tem nada de específico do Kubernetes. Este guia é para MSPs e equipas de plataforma que querem usar o OPA como motor de políticas de uso geral — para autorização de API, verificações de CI e admissão no Kubernetes — sem confundir o papel de cada ferramenta, além do que mudou numa correção recente do parser para quem já usa a sintaxe Rego mais recente do OPA.

Onde o OPA se aplica além do Kubernetes

O projeto principal — open-policy-agent/opa no GitHub, com cerca de 12,3 mil estrelas e 1,7 mil forks — é um motor de políticas que avalia um pedido face a uma política escrita em vez de lógica de aplicação codificada de forma fixa. MSPs e equipas de produto usam-no onde quer que esse tipo de decisão seja necessário, não apenas na fronteira de um cluster Kubernetes.

A mesma linguagem de políticas Rego que executa funciona igualmente bem numa gateway de API ou dentro de um sidecar de serviço, avaliando se um pedido está autorizado antes de chegar ao código da aplicação. Os mesmos pacotes de políticas podem ser reutilizados em pipelines de CI para detetar violações, como uma dependência proibida, um recurso mal configurado ou uma região não aprovada, antes de uma alteração ser implementada em vez de depois.

OPA, Gatekeeper e Conftest são três coisas diferentes

O controlo de admissão no Kubernetes através do Gatekeeper é uma integração construída sobre o OPA, não o OPA em si, e o Conftest é uma ferramenta de linha de comandos separada para testar ficheiros de configuração estruturados face a políticas Rego. Juntar os três numa única narrativa de OPA em material voltado para clientes exagera o que cada ferramenta faz por si só: cada uma tem o seu próprio modelo de implementação e os seus próprios modos de falha.

Gatekeeper: aplicar políticas à entrada do Kubernetes

O OPA Gatekeeper, mantido sob a organização Open Policy Agent no GitHub com cerca de 4,3 mil estrelas, é um controlador de admissão do Kubernetes. Intercepta pedidos de API através de um webhook de admissão de validação e verifica-os face a políticas Rego no momento em que uma carga de trabalho é submetida, em vez de depois de já estar em execução. Para um MSP que gere vários clusters de clientes, uma regra pode ser escrita uma vez e aplicada de forma consistente: exigir que as imagens de contentor venham de um registo aprovado ou tenham uma atestação de assinatura verificada, recusar contentores que peçam modo privilegiado ou montagens hostPath sem restrições, ou restringir que tipos de carga de trabalho um determinado namespace pode aceitar.

O Gatekeeper é uma integração específica do Kubernetes, não um substituto do motor principal, que os MSPs também usam para autorização de API e verificações de CI fora do Kubernetes; os dois são complementares, com o Gatekeeper a gerir o caminho de admissão enquanto o motor principal toma decisões de política noutras partes da stack. Também não substitui o RBAC, a política de rede ou a higiene de segredos: acrescenta uma camada sobre eles, não em seu lugar.

Setembro de 2026: um bug do parser corrigido no OPA 1.20.2

O OPA 1.20.2, lançado no início de setembro de 2026, corrige um bug do parser introduzido duas versões antes, na 1.20.0, que tinha adicionado as novas palavras-chave Rego and e or para combinar condições dentro de um único corpo de regra. Quando uma política importava essas palavras-chave, diretamente ou via import future.keywords, o parser do OPA lia primeiro uma instrução que começava com uma chaveta como corpo de um operando e depois voltava a lê-la como um termo, como uma comprehension, se não seguisse nem and nem or.

Uma regressão fazia com que os erros registados durante essa primeira leitura abandonada ficassem em cache e fossem indevidamente reportados na segunda leitura, a bem-sucedida, levando o parser a rejeitar políticas que, na verdade, eram válidas. As políticas que não importam and/or nunca foram afetadas, e trata-se de uma correção pontual, não de um aviso de segurança; o projeto complementar opa-envoy-plugin lançou uma versão v1.20.2-envoy correspondente ao mesmo tempo, pelo que as equipas que usam esse plugin devem confirmar se receberam a mesma atualização de versão.

Os MSPs que queiram uma verificação externa destes controlos no âmbito de um programa de conformidade com o NIS2, o DORA ou o RGPD podem contar com apoio dedicado: os serviços de cibersegurança da Altovar cobrem testes de penetração, avaliação de vulnerabilidades, resposta a incidentes e trabalho de conformidade para esses mesmos referenciais.

Pontos de partida práticos

• Autorização de API: avalie políticas Rego ao nível da gateway ou do sidecar para pedidos que precisem de regras por tenant ou por função além da autenticação incorporada de uma framework.
• Portões de política em CI: execute as mesmas regras Rego contra infraestrutura como código ou manifestos numa etapa do pipeline, falhando o build em caso de violações em vez de depender de revisão manual.
• Admissão no Kubernetes: inicie as políticas do Gatekeeper em modo dry-run ou warn, documente exceções para cargas de trabalho existentes e limite as restrições a namespaces específicos antes de as alargar.
• Bibliotecas de políticas partilhadas: escreva as regras uma vez e aplique-as à admissão, à autorização de API e à CI, em vez de reimplementar a mesma lógica três vezes.

O que fazer

1. Mapeie onde vivem hoje as decisões de política na sua stack — admissão, gateway, CI — e assinale as que ainda estão codificadas de forma fixa em vez de baseadas em políticas.
2. Se usa o Gatekeeper, implemente as novas restrições em modo dry-run ou warn e documente exceções antes de mudar para enforce.
3. Mantenha as três ferramentas separadas na sua própria documentação: o motor OPA, o Gatekeeper para admissão e o Conftest para CI e testes de configuração.
4. Se as suas políticas Rego importam as palavras-chave and/or, confirme que está na versão 1.20.2 ou posterior antes de tratar uma rejeição como um erro de escrita.
5. Verifique se ferramentas dependentes, como o plugin Envoy ou sidecars, receberam a mesma atualização de versão do OPA.
6. Combine políticas de admissão e autorização com RBAC, política de rede e higiene de segredos, em vez de as tratar como um substituto completo.

Fontes: GitHub — open-policy-agent/opa, GitHub — open-policy-agent/opa releases, GitHub — open-policy-agent/gatekeeper.