Kong Gateway é um gateway de API de código aberto que garante que apenas as solicitações certas entram, gerenciando assim segurança, limitação de taxa, loggin e muito mais. OPA (Open Policy Agent) é uma engine de política de código aberto que assume controle das suas decisões de segurança e acesso. Pense nisto como a mente que desacopla o cumprimento de políticas do seu aplicativo, para que seus serviços não precisem se preocupar com a aplicação de regras. Em vez disso, a OPA faz o cálculo com a sua linguagem Rego, avaliando políticas em APIs, microserviços, ou até em Kubernetes. É flexível, seguro e faz a atualização de políticas com muita facilidade. A OPA funciona avaliando três coisas chave: entrada (dados em tempo real, como solicitações), dados (informações externas, como papéis de usuário) e política (a lógica em Rego que decide se deve “permitir” ou “negar”). Juntos, esses componentes permitem que a OPA mantenha o seu jogo de segurança forte enquanto mantém as coisas simples e consistentes.
O que estamos procurando alcançar ou resolver?
Muitas vezes, os dados em OPA são como um velho amigo confiável – estático ou lentamente mudando. Eles são usados juntamente com os dados de entrada que sempre estão mudando para tomar decisões inteligentes. Mas, imaginem um sistema com uma extensa rede de microserviços, montes de usuários e uma base de dados massiva como o PostgreSQL. Este sistema processa uma alta taxa de transações a cada segundo e precisa manter sua velocidade e throughput sem fazer um arroto.
O controle de acesso em granularidade tão fina é complicado, mas com OPA, você pode desencargar o trabalho pesado dos seus microserviços e manipulará-lo no nível do gateway. Ao unir-se ao Gateway de API Kong e OPA, você obtém tanto throughput de primeira linha quanto controle de acesso preciso.
Como você mantém dados de usuário precisos sem abrandar as coisas? Continuamente atingindo aquela base de dados PostgreSQL para buscar milhões de registros é caro e lento. Alcançar precisão e velocidade normalmente exige compromissos entre os dois. Vamos tentar atingir um equilíbrio prático desenvolvendo um plugin personalizado (no nível do gateway) que frequentemente carrega e localmente cache dados para que OPA use na avaliação de suas políticas.
Demo
Para a demonstração, eu configurei dados de exemplo em PostgreSQL, contendo informações de usuário, como nome, email e papel. Quando um usuário tenta acessar um serviço através de uma URL específica, o OPA avalia se a requisição é permitida. A política Rego verifica a URL da requisição (recurso), método e o papel do usuário, e retorna verdadeiro ou falso baseado nas regras. Se verdadeiro, a requisição é permitida; se falso, o acesso é negado. Até aqui, é uma configuração simples. Vamos mergulhar no plugin personalizado. Para uma melhor compreensão de sua implementação, por favor, refira-se ao diagrama abaixo.
Quando uma requisição chega pelo proxy Kong, o plugin personalizado do Kong é ativado. O plugin busca os dados necessários e passa-os para o OPA juntamente com a entrada/consulta. Esta busca de dados tem duas partes: uma seria procurar no Redis para encontrar os valores necessários e, se encontrado, passá-los para o OPA; caso contrário, faria uma consulta adicional ao Postgres e buscaria os dados, cacheando-os em Redis antes de passá-los para o OPA. Podemos voltar a isso quando executarmos os comandos na próxima seção e observarmos os logs. O OPA toma uma decisão (baseada na política, entrada e dados) e, se permitida, o Kong prosseguirá para enviar essa requisição para a API. Usando essa abordagem, o número de consultas ao Postgres é reduzido significativamente, enquanto os dados disponíveis para o OPA são razoavelmente precisos e preservam a baixa latência.
Para começar a construir um plugin personalizado, precisamos de um handler.lua onde a lógica central do plugin é implementada e um schema.lua que, conforme o nome indica, define o esquema de configuração do plugin. Se você está começando a aprender a escrever plugins personalizados para o Kong, consulte este link para mais informações. A documentação também explica como empacotar e instalar o plugin. Vamos prosseguir e entender a lógica the este plugin.
O primeiro passo do demo seria instalar o OPA, o Kong, o Postgres e o Redis no seu ambiente local ou em qualquer nuvem. Clone em este repositório.
Revise o arquivo docker-compose.yaml que tem as configurações definidas para deployar todos os quatro serviços acima. Observe as variáveis de ambiente do Kong para ver como o plugin personalizado é carregado.
Execute os comandos abaixo para deployar os serviços:
docker-compose build
docker-compose up
Uma vez que verifique que os contêineres estão rodando, o Kong manager e o OPA estão disponíveis em respectivos endpoints https://localhost:8002 e https://localhost:8181, conforme mostrado abaixo:
Crie um serviço de teste, uma rota e adicione o nosso plugin personalizado do Kong a esta rota usando o comando abaixo:
curl -X POST http://localhost:8001/config -F config=@config.yaml
A política OPA, definida no arquivo authopa.rego, é publicada e atualizada para o serviço OPA usando o comando abaixo:
curl -X PUT http://localhost:8181/v1/policies/mypolicyId -H "Content-Type: application/json" --data-binary @authopa.rego
Esta política de exemplo concede acesso às solicitações do usuário somente se o usuário estiver acessando o caminho /demo com um método GET e tiver o papel de "Moderator". Regras adicionais podem ser adicionadas conforme necessário para adaptar o controle de acesso com base em diferentes critérios.
opa_policy = [
{
"path": "/demo",
"method": "GET",
"allowed_roles": ["Moderator"]
}
]
Agora a configuração está pronta, mas antes de testar, precisamos de alguns dados de teste para adicionar no Postgres. Adicionei alguns dados de amostra (nome, e-mail e função) para alguns funcionários, conforme mostrado abaixo (por favor, consulte o PostgresReadme).
Aqui está um exemplo de solicitação falhada e bem-sucedida:
Agora, para testar a funcionalidade principal deste plugin personalizado, vamos fazer duas solicitações consecutivas e verificar os logs para ver como está acontecendo a recuperação de dados.
Aqui estão os logs:
2024/09/13 14:05:05 [error] 2535#0: *10309 [kong] redis.lua:19 [authopa] No data found in Redis for key: [email protected], client: 192.168.96.1, server: kong, request: "GET /demo HTTP/1.1", host: "localhost:8000", request_id: "ebbb8b5b57ff4601ff194907e35a3002"
2024/09/13 14:05:05 [info] 2535#0: *10309 [kong] handler.lua:25 [authopa] Fetching roles from PostgreSQL for email: [email protected], client: 192.168.96.1, server: kong, request: "GET /demo HTTP/1.1", host: "localhost:8000", request_id: "ebbb8b5b57ff4601ff194907e35a3002"
2024/09/13 14:05:05 [info] 2535#0: *10309 [kong] postgres.lua:43 [authopa] Fetched roles: Moderator, client: 192.168.96.1, server: kong, request: "GET /demo HTTP/1.1", host: "localhost:8000", request_id: "ebbb8b5b57ff4601ff194907e35a3002"
2024/09/13 14:05:05 [info] 2535#0: *10309 [kong] handler.lua:29 [authopa] Caching user roles in Redis, client: 192.168.96.1, server: kong, request: "GET /demo HTTP/1.1", host: "localhost:8000", request_id: "ebbb8b5b57ff4601ff194907e35a3002"
2024/09/13 14:05:05 [info] 2535#0: *10309 [kong] redis.lua:46 [authopa] Data successfully cached in Redis, client: 192.168.96.1, server: kong, request: "GET /demo HTTP/1.1", host: "localhost:8000", request_id: "ebbb8b5b57ff4601ff194907e35a3002"
2024/09/13 14:05:05 [info] 2535#0: *10309 [kong] opa.lua:37 [authopa] Is Allowed by OPA: true, client: 192.168.96.1, server: kong, request: "GET /demo HTTP/1.1", host: "localhost:8000", request_id: "ebbb8b5b57ff4601ff194907e35a3002"
2024/09/13 14:05:05 [info] 2535#0: *10309 client 192.168.96.1 closed keepalive connection
------------------------------------------------------------------------------------------------------------------------
2024/09/13 14:05:07 [info] 2535#0: *10320 [kong] redis.lua:23 [authopa] Redis result: {"roles":["Moderator"],"email":"[email protected]"}, client: 192.168.96.1, server: kong, request: "GET /demo HTTP/1.1", host: "localhost:8000", request_id: "75bf7a4dbe686d0f95e14621b89aba12"
2024/09/13 14:05:07 [info] 2535#0: *10320 [kong] opa.lua:37 [authopa] Is Allowed by OPA: true, client: 192.168.96.1, server: kong, request: "GET /demo HTTP/1.1", host: "localhost:8000", request_id: "75bf7a4dbe686d0f95e14621b89aba12"
Os logs mostram que, para a primeira solicitação, quando não há dados no Redis, os dados estão sendo buscados do Postgres e armazenados em cache no Redis antes de serem enviados ao OPA para avaliação. Na solicitação subsequente, como os dados estão disponíveis no Redis, a resposta seria muito mais rápida.
Conclusão
Em conclusão, combinando o Kong Gateway com o OPA e implementando o plugin personalizado com cache do Redis, equilibramos eficientemente a precisão e a velocidade para o controle de acesso em ambientes de alto tráfego. O plugin minimiza o número de consultas caras ao Postgres ao cachear as roles de usuário em Redis após a consulta inicial. Em pedidos subsequentes, os dados são recuperados do Redis, reduzindo significativamente a latência enquanto mantém informações de usuário precisas e atualizadas para avaliações de políticas do OPA. Esta abordagem garante que o controle de acesso granular é tratado eficientemente no nível de gateway sem sacrificar desempenho ou segurança, tornando-se uma solução ideal para escalar microsserviços enquanto impõe políticas de acesso precisas.
Source:
https://dzone.com/articles/enhanced-api-security-fine-grained-access-control