você escreve uma política em rego, roda o opa test contra ela, vê todos os casos ficarem verdes e, por um segundo, sente que está pronto. essa sensação é exatamente onde isso fica interessante.
newton permite que desenvolvedores escrevam políticas de autorização em rego, a mesma linguagem de políticas que muitas equipes de conformidade corporativa já usam fora do mundo cripto — o que, honestamente, é uma escolha sensata aqui. essas políticas são avaliadas por um mecanismo em rust, um fork do projeto regorus da microsoft, estendido com builtins próprios da newton para checagens de cripto, identidade, privacidade e tempo. até a cli própria da newton inclui uma flag não estrita especificamente para que o comando local do regorus possa se comportar de forma compatível com o opa — um reconhecimento silencioso de que o comportamento padrão não é. e o guia de testes da própria newton diz que, como primeiro passo, você deve testar sua rego com opa test, a implementação de referência real, antes que qualquer coisa específica da newton toque a política.
regorus, pelo que os próprios mantenedores dizem, é em grande parte compatível com o opa, mas não totalmente. ele passa a suíte real de conformidade do opa para a maioria dos builtins, mas não todos, e a documentação própria do newton lista categorias inteiras como ainda não suportadas na build dele: hashing criptográfico e funções hmac padrão, codificação e verificação de jwt, http.send, net.*, json.patch, graphql, builtins do provedor aws, introspecção de metadados do próprio rego. o newton te direciona às próprias extensões. nenhuma das coisas que faltam é algum caso extremo obscuro. crypto.hmac.equal, por exemplo, é o jeito “clássico” e seguro contra timing para comparar dois macs em rego, documentado de forma bem clara no próprio site do opa.
vale dizer de forma bem direta: parte dessa lacuna é deliberada, não atraso. o regorus exclui builtins criptográficos por design, feito para setups de computação confidencial que querem controle rígido sobre o que entra na base de computação confiável. essa é uma racionalidade de segurança real, não preguiça. isso só não muda o que acontece com quem recorre àquela função sem saber em qual categoria acabou caindo.
então, imagine a sequência. um autor de políticas precisa confirmar que uma carga útil (payload) de um oráculo não foi adulterada, recorre a crypto.hmac.equal porque é para isso que qualquer referência do rego apontaria, escreve uma policy_test.rego em paralelo, executa o opa test, vê passar, porque o opa test é literalmente a implementação de referência verificando a si mesma contra a semântica própria. nada daquela etapa toca o mecanismo do newton. a política parece concluída. só depois que é implantada e avaliada pela própria build regorus do newton é que essa mesma chamada falha em resolver, porque o builtin específico nunca chegou ao fork. e aqui vai a parte que eu continuo voltando: quanto mais “no livro” estiver seu rego, mais exposto você fica, já que é precisamente a lista padrão e bem documentada de builtins que o newton ainda não incorporou — não os builtins específicos do newton, que obviamente funcionam. quem diria que buscar a função mais padrão seria a jogada mais arriscada.
o que eu acho é que isso é, na prática, um problema de supply chain disfarçado de problema de testes. o opa é a especificação original e a verdade no chão, escrita em go. o regorus é uma reimplementação em rust dessa especificação, verificada contra a própria suíte de conformidade do opa, mas incompleta — como ele mesmo admite —, construída e mantida pela microsoft. o newton então faz um fork do regorus de novo em cima disso e adiciona seus próprios builtins. e, honestamente, a lacuna provavelmente acompanha mais a lógica do roadmap do newton do que qualquer descuido: entregar builtins de identidade e privacidade que nenhum outro runtime do rego tem é um trabalho diferenciado que vale financiar, enquanto buscar paridade total em builtins genéricos que ainda não são prioridade é o tipo pouco glamouroso que fica esperando. cada salto nessa cadeia pode, silenciosamente, derrubar um pedacinho da garantia que a camada acima forneceu, e o desenvolvedor que escreve um único arquivo rego só tem visibilidade direta do primeiro elo: o que tem o playground público e o cli familiar.
para ser justo, a lacuna não está escondida. ela é catalogada, função por função, no guia de sintaxe do rego do próprio newton, com um nome alternativo para quase toda categoria ausente. mas um catálogo em uma página de referência e um aviso dentro da ferramenta que você já tem aberta são duas coisas diferentes. o fluxo de trabalho recomendado completo do newton vai além do opa test sozinho, indo até uma chamada newt_simulatePolicy que executa a política inteira contra condições reais de rede do newton antes que qualquer implantação aconteça — e essa etapa capturaria exatamente este problema. então a versão honesta não é que a informação não exista. é que o passo mais rápido e reflexivo no processo é precisamente o que não consegue enxergar a camada onde a falha real mora.
dê crédito onde é devido, porém. conseguir uma reimplementação em rust do rego passar pela própria suíte de conformidade do opa, em meio a meia dúzia de bindings de linguagem, sem trazer junto um runtime do go, é uma peça genuinamente rara de engenharia com continuidade — não um projeto apressado paralelo. e o newton não enterrou a lacuna em algum lugar conveniente de passar despercebido: ele escreveu o que estava faltando e o que usar no lugar, categoria por categoria. reutilizar uma linguagem de políticas existente e bem compreendida em vez de inventar algo proprietário também é, honestamente, a escolha mais generosa para desenvolvedores, mesmo com a lacuna de conformidade embutida nela.
talvez empilhar uma camada de extensão feita para um propósito específico em cima de uma reimplementação já parcial da especificação de outra pessoa seja apenas uma forma razoável de entregar um recurso específico rápido. ou talvez seja exatamente o movimento que transforma silenciosamente um teste no opa antes de você implantar, de um passo de segurança para um passo incompleto, sem a pessoa que escreve a política perceber jamais qual camada realmente falhou.