Usando Rego como uma linguagem genérica de políticas

As políticas têm um papel fundamental em todas as organizações, mas podem significar coisas bem diferentes dependendo do contexto. Para os nossos fins, uma política é um conjunto de princípios ou ideias que uma organização usa para tomar decisões.

Neste post, vamos falar sobre o Open Policy Agent (OPA) e sua linguagem de regras, Rego, mostrando como usá-los para escrever uma política simples para um microsserviço de folha de pagamento.

O que é uma política?

Em sistemas de software, políticas são regras que controlam como um sistema funciona. Computadores e pessoas costumam usar políticas para responder a perguntas como:

• O usuário A tem permissão para modificar a configuração do serviço X?

• Em qual domínio devemos instalar a aplicação X?

• Quais operações estão na região geográfica errada?

A forma como definimos e aplicamos uma política depende de vários fatores, como a tecnologia à qual ela se aplica e o grau de clareza da própria política. Em alguns casos, as políticas são conhecimentos não documentados. Assim, se quisermos modificar um sistema ou entender como ele deveria funcionar, precisamos consultar outra pessoa. Depois de algum tempo, documentamos as respostas, mas esses documentos acabam ficando desatualizados.

Outra abordagem é codificar as políticas diretamente nos sistemas de software. Infelizmente, as políticas mudam com o tempo. Além de atualizações quase constantes e da necessidade de reaprender, modificar políticas codificadas exige uma leitura ampla e minuciosa do código para entender o que precisa ser alterado. A codificação direta torna as políticas menos acessíveis e mais trabalhosas de mudar.

Conheça o Open Policy Agent

As abordagens tradicionais de gerenciamento de políticas oferecem poucas garantias de aplicação e têm alto custo de manutenção. Uma solução moderna para esse problema é o Open Policy Agent (OPA, pronunciado “Ô-pa”).

O OPA é um mecanismo de políticas de código aberto e uso geral, empregado para definir políticas em vários sistemas, incluindo microsserviços, gateways de API, pipelines de CI/CD e Kubernetes. Ele permite escrever políticas como código e usá-las como parte do processo de tomada de decisão.

Com o OPA, definimos regras que controlam o comportamento de um sistema. Essas regras respondem a perguntas como:

• O usuário A pode fazer uma solicitação GET a este serviço?

• Quais registros o usuário B tem permissão para visualizar?

• Em qual servidor devemos implantar a aplicação X?

Quando solicitamos uma decisão sobre uma política, o OPA analisa as regras e os dados fornecidos para gerar uma resposta, que é aplicada pelo serviço que solicitou a decisão. Em outras palavras, o OPA é responsável por tomar a decisão sobre a política, enquanto os serviços integrados ao OPA são responsáveis por implementá-la. O diagrama abaixo mostra o fluxo de trabalho geral do OPA:

Para entender todo o fluxo de trabalho do OPA, vamos ver como ele processa solicitações em um caso simples de autorização de API, no qual definimos regras para permitir ou negar o acesso a determinados serviços de API. Quando um serviço recebe uma solicitação de API, ele envia uma consulta ao OPA. Em seguida, o OPA compara a consulta com as políticas e os dados existentes e retorna uma decisão de “permitir” ou “negar”. Por fim, o serviço aplica a decisão do OPA, aprovando ou rejeitando a solicitação de API.

A linguagem de políticas do OPA: Rego

Escrevemos políticas do OPA em uma linguagem declarativa de alto nível chamada Rego (pronunciada “RÊ-go”). A Rego permite criar decisões de políticas escaláveis com facilidade para diferentes tipos de serviços. Usamos a Rego para avaliar os dados fornecidos como entrada e tomar as decisões de acordo com eles. Vale lembrar que Rego não é uma linguagem de programação para criar software: é uma linguagem declarativa para escrever regras, semelhante a uma linguagem de consulta como SQL.

Rego é uma linguagem de políticas de uso geral, ou seja, funciona com vários sistemas. Ela só processa dados JSON; podemos escrever uma política para qualquer serviço, desde que os dados necessários estejam no formato JSON. Isso nos permite usar Rego para criar políticas que abrangem diferentes sistemas.

Escreva sua primeira política do OPA

Agora, vamos escrever uma política simples com Rego e testá-la no Rego Playground, uma plataforma interativa online. A política que vamos criar determina quais usuários podem acessar informações salariais em um microsserviço de folha de pagamento.

Para começar, apague todo o código existente no painel principal do Rego playground e substitua-o pelo seguinte:

1package play 
2default allow = false
3# Users can only view their salary info
4allow = true { 
5    input.method = "GET" 
6    input.path = ["getSalary", user_id] 
7    input.user = user_id 
8}

Agora, vamos analisar o trecho de código acima para entender o que está acontecendo:

• A primeira linha da nossa política é o nome do pacote. Toda política Rego tem um nome de pacote que define seu escopo.

• A linha seguinte indica que, por padrão, o valor de allow é false.

• O sinal de cerquilha (#) indica o início de um comentário e fornece informações explicativas simples sobre o código escrito.

• allow = true significa que allow seria true se todas as expressões entre colchetes fossem true.

• Por fim, podemos interpretar as expressões entre colchetes assim: as solicitações serão permitidas se o método de entrada for GET, o caminho for /getSalary/user_id e o usuário for o user_id. Observe que a variável input representa os dados JSON que fornecemos à Rego.

O Rego Playground permite avaliar o código e confirmar se a política funciona como esperado. Então, no painel de entrada, podemos simular uma solicitação adicionando o seguinte código:

1{ 
2    "method": "GET", 
3    "path": ["getSalary","John"], 
4    "user": "John" 
5}

Agora, vamos ver como o OPA responderia à solicitação acima clicando no botão Avaliar. O painel de saída deve exibir algo parecido com isto:

1{
2    "allow": true 
3}

Veja uma captura do Playground após concluir todas as etapas:

Vamos testar a política novamente, alterando o valor de user na solicitação para Jane, o que significa que um usuário está tentando visualizar as informações salariais de outra pessoa. Ao clicar em Avaliar, vemos o resultado esperado:

1{
2    "allow": false
3}

Em seguida, vamos atualizar a política para que os funcionários do departamento financeiro possam visualizar as informações salariais de todos os usuários. Para isso, adicionamos o seguinte código à política que definimos anteriormente:

1#finance department workers can view every user's salary info
2allow = true { 
3    input.method = "GET" 
4    input.path = ["getSalary", user_id] 
5    finance[input.user] 
6} 
7finance = {"Ruth","Josh","Vivian"}

No novo código da política, definimos um objeto finance e adicionamos os nomes de todos os funcionários que trabalham no departamento financeiro.

Vamos testar a política usando o mesmo nome para user e user_id (por exemplo, Joe). A política deve retornar true. Agora, altere user para John (um funcionário do departamento financeiro) e execute a política. Mais uma vez, ela deve retornar true. Por fim, altere user para qualquer nome que não esteja listado no objeto finance (por exemplo, Jane). Dessa vez, a política deve retornar false.

Juntando tudo

Depois de combinar todos os trechos de código, temos nossa nova política:

1package play 
2default allow = false
3# Users should have access to view their salary 
4allow = true { 
5    input.method = "GET" 
6    input.path = ["getSalary", user_id] 
7    input.user = user_id 
8}
9allow = true { 
10    input.method = "GET" 
11    input.path = ["getSalary", user_id] 
12    finance[input.user] 
13} 
14finance = {"John","Mary","Peter","Vivian"}

O futuro da personalização de políticas

Agora que você sabe criar políticas com OPA e Rego, precisa mantê-las e analisá-las para garantir que continuem livres de vulnerabilidades. Com Snyk Infrastructure as Code (Snyk IaC), que usa o OPA para analisar políticas, você pode incluir políticas novas e existentes nas suas análises com alguns comandos simples. Confira a documentação do Snyk IaC e também nosso artigo Como desenvolver regras personalizadas de IaC com a Snyk para saber mais.

Comece criando sua conta gratuita da Snyk e encontre e corrija configurações incorretas de IaC com verificações de segurança integradas, controles de políticas e recomendações de correção pensadas para desenvolvedores, diretamente no seu fluxo de trabalho.