Fortificando APIs no Linux: Integração Profunda de Kong Gateway e Keycloak para Segurança DevOps
A segurança de APIs é uma fundação crítica em qualquer arquitetura de microsserviços moderna. Com o crescimento exponencial de APIs expondo funcionalidades de negócios, a gestão de autenticação, autorização e controle de acesso tornou-se uma preocupação central. A integração do Kong Gateway como um proxy reverso e gerenciador de APIs, juntamente com o Keycloak como uma solução de gerenciamento de Identidade e Acesso (IAM) de código aberto, oferece uma combinação poderosa para estabelecer uma camada de segurança robusta e escalável em ambientes linux. Esta abordagem, alinhada aos princípios DevOps, visa automação, repetibilidade e segurança inerente à infraestrutura.
Visão Arquitetural da Proteção de APIs
A configuração de segurança para APIs com Kong e Keycloak tipicamente envolve uma arquitetura onde o Kong atua como o ponto de entrada principal para todas as APIs. Ele intercepta as requisições, as valida, e então as encaminha para os serviços de backend (APIs) apropriados. O Keycloak, por sua vez, é o provedor de identidade (IdP), responsável por autenticar usuários e clientes, emitir tokens de acesso (OAuth 2.0/OpenID Connect) e gerenciar permissões. A integração se dá através do plugin OpenID Connect (OIDC) do Kong, que delega a autenticação e validação de tokens ao Keycloak. Essa delegação permite que os serviços de backend foquem na lógica de negócio, enquanto a segurança é centralizada no Kong.
Pré-requisitos do Ambiente Linux
Para prosseguir com a implementação, é essencial ter um ambiente Linux configurado com as ferramentas fundamentais. Recomenda-se uma distribuição baseada em Debian ou RHEL, com os seguintes componentes instalados:
- Docker e Docker Compose: Para orquestração dos serviços Kong, Keycloak e PostgreSQL.
curl: Ferramenta de linha de comando para interagir com APIs.jq: Processador JSON de linha de comando, útil para analisar respostas de APIs.- Git: Para clonar repositórios de configuração, se aplicável.
A instalação do Docker e Docker Compose pode ser realizada conforme a documentação oficial, adaptando-se à sua distribuição Linux. Por exemplo, para Ubuntu:
sudo apt update
sudo apt install -y apt-transport-https ca-certificates curl gnupg lsb-release
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu
$(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io
sudo curl -L "https://github.com/docker/compose/releases/download/v2.16.0/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose
Orquestração de Componentes com Docker Compose
Vamos configurar o Kong Gateway (com PostgreSQL como banco de dados) e o Keycloak utilizando um arquivo docker-compose.yml. Esta abordagem garante a reprodutibilidade do ambiente e simplifica a gestão dos serviços.
Configuração do Keycloak
O Keycloak será executado em um contêiner Docker. É crucial expor as portas necessárias e configurar variáveis de ambiente para a administração inicial.
version: '3.8'
services:
keycloak:
image: quay.io/keycloak/keycloak:21.1.2 # Ou versão mais recente
command: start-dev --import-realm
environment:
KEYCLOAK_ADMIN: admin
KEYCLOAK_ADMIN_PASSWORD: admin
KC_DB: postgres
KC_DB_URL_HOST: keycloak-db
KC_DB_USERNAME: keycloak
KC_DB_PASSWORD: password
KC_HTTP_PORT: 8080
ports:
- "8080:8080"
volumes:
- ./keycloak-realm:/opt/keycloak/data/import
depends_on:
- keycloak-db
networks:
- kong-keycloak-net
keycloak-db:
image: postgres:13
environment:
POSTGRES_DB: keycloak
POSTGRES_USER: keycloak
POSTGRES_PASSWORD: password
volumes:
- keycloak_db_data:/var/lib/postgresql/data
networks:
- kong-keycloak-net
kong-database:
image: postgres:13
environment:
POSTGRES_DB: kong
POSTGRES_USER: kong
POSTGRES_PASSWORD: kong
volumes:
- kong_db_data:/var/lib/postgresql/data
networks:
- kong-keycloak-net
kong-migrations:
image: kong:3.3.0-alpine
command: kong migrations bootstrap
environment:
KONG_DATABASE: postgres
KONG_PG_HOST: kong-database
KONG_PG_PASSWORD: kong
KONG_PG_USER: kong
depends_on:
- kong-database
networks:
- kong-keycloak-net
restart: on-failure
kong:
image: kong:3.3.0-alpine
environment:
KONG_DATABASE: postgres
KONG_PG_HOST: kong-database
KONG_PG_USER: kong
KONG_PG_PASSWORD: kong
KONG_PROXY_ACCESS_LOG: /dev/stdout
KONG_ADMIN_ACCESS_LOG: /dev/stdout
KONG_PROXY_ERROR_LOG: /dev/stderr
KONG_ADMIN_ERROR_LOG: /dev/stderr
KONG_ADMIN_LISTEN: 0.0.0.0:8001, 0.0.0.0:8444 ssl
KONG_PROXY_LISTEN: 0.0.0.0:8000, 0.0.0.0:8443 ssl
KONG_PG_PORT: 5432
ports:
- "8000:8000" # Porta HTTP do proxy
- "8443:8443" # Porta HTTPS do proxy
- "8001:8001" # Porta HTTP da Admin API
- "8444:8444" # Porta HTTPS da Admin API
depends_on:
- kong-migrations
networks:
- kong-keycloak-net
volumes:
keycloak_db_data:
kong_db_data:
networks:
kong-keycloak-net:
driver: bridge
Crie o diretório keycloak-realm e um arquivo realm.json dentro dele para importar automaticamente um realm inicial no Keycloak. Este arquivo pode conter um realm, um cliente e um usuário de teste.
Exemplo de keycloak-realm/realm.json:
{
"realm": "minha-api-realm",
"enabled": true,
"clients": [
{
"clientId": "minha-api-client",
"secret": "minha-api-secret",
"enabled": true,
"clientAuthenticatorType": "client-secret",
"redirectUris": [
"http://localhost:8000/callback",
"http://localhost:8000/*",
"http://kong:8000/callback",
"http://kong:8000/*"
],
"webOrigins": [],
"publicClient": false,
"protocol": "openid-connect",
"fullScopeAllowed": true,
}
],
"users": [
{
"username": "apiuser",
"enabled": true,
"credentials": [
{
"type": "password",
"value": "password",
"temporary": false
}
]
}
]
}
Após criar o arquivo docker-compose.yml e o diretório keycloak-realm com o realm.json, inicie os serviços:
docker-compose up -d
Verifique o status dos contêineres:
docker-compose ps
Você deverá conseguir acessar o console de administração do Keycloak em http://localhost:8080/admin com as credenciais admin/admin. O realm minha-api-realm, o cliente minha-api-client e o usuário apiuser devem estar pré-configurados.
Configuração do Kong Gateway para OIDC
Com os serviços essenciais em execução, o próximo passo é configurar o Kong para integrar-se ao Keycloak usando o plugin OIDC. Isso envolve criar um Serviço, uma Rota e, finalmente, habilitar e configurar o plugin OIDC para essa Rota ou Serviço. Para este exemplo, usaremos a Admin API do Kong para configurar, embora em um ambiente de produção a abordagem declarativa (DEC) via kong.yml e deck seria preferível.
Definindo um Serviço e uma Rota de Exemplo
Vamos supor que temos um serviço de backend simples que desejamos proteger. Para fins de teste, podemos usar httpbin.org ou um serviço local.
# Criar um serviço no Kong para o backend de exemplo
curl -X POST http://localhost:8001/services
--data "name=httpbin-service"
--data "url=https://httpbin.org/anything"
# Criar uma rota para o serviço
curl -X POST http://localhost:8001/services/httpbin-service/routes
--data "paths[]=/api/v1/anything"
--data "strip_path=true"
Habilitando e Configurando o Plugin OIDC
Agora, ative o plugin OIDC na rota ou serviço que você deseja proteger. Para maior granularidade, é comum aplicar o plugin na Rota. Os parâmetros de configuração virão do seu cliente Keycloak e do próprio Keycloak IdP.
# Configurar o plugin OIDC na rota '/api/v1/anything'
# Note: keycloak é o nome do serviço docker-compose, que resolve para o IP interno do contêiner Keycloak.
# O host precisa ser acessível do Kong. Se for um ambiente fora do docker-compose, use o IP/hostname do Keycloak.
curl -X POST http://localhost:8001/routes/api-v1-anything/plugins
--data "name=openid-connect"
--data "config.client_id=minha-api-client"
--data "config.client_secret=minha-api-secret"
--data "config.issuer=http://keycloak:8080/realms/minha-api-realm"
--data "config.auth_methods=client_credentials,authorization_code"
--data "config.credential_location=header"
--data "config.redirect_uri=http://kong:8000/callback"
--data "config.bearer_only=false"
--data "config.token_introspection_endpoint=http://keycloak:8080/realms/minha-api-realm/protocol/openid-connect/token/introspect"
--data "config.introspection_key_claim=sub"
--data "config.introspection_value_claim=preferred_username"
Parâmetros chave:
config.client_id: ID do cliente Keycloak.config.client_secret: Segredo do cliente Keycloak.config.issuer: URL do emissor (Keycloak Realm URL).config.redirect_uri: URL para onde o Keycloak redirecionará após a autenticação. Deve ser uma URL que o Kong pode interceptar (http://kong:8000/callbacké o hostname do serviço Kong dentro da rede Docker Compose).config.auth_methods: Define os fluxos OIDC permitidos.
Testando a Integração de Autenticação
Com o plugin OIDC ativado, tentar acessar a rota protegida sem autenticação resultará em um redirecionamento para o Keycloak para login (se bearer_only for false para o fluxo de código de autorização), ou em uma falha de autenticação se bearer_only for true para o fluxo de client credentials.
Fluxo Client Credentials
Este fluxo é ideal para comunicação serviço a serviço, onde um cliente (não um usuário final) precisa de acesso a uma API. O cliente usa seu client_id e client_secret para obter um token de acesso diretamente do Keycloak.
# 1. Obter um token de acesso do Keycloak usando Client Credentials
TOKEN_RESPONSE=$(curl -X POST "http://localhost:8080/realms/minha-api-realm/protocol/openid-connect/token"
-H "Content-Type: application/x-www-form-urlencoded"
-d "grant_type=client_credentials"
-d "client_id=minha-api-client"
-d "client_secret=minha-api-secret")
ACCESS_TOKEN=$(echo $TOKEN_RESPONSE | jq -r '.access_token')
echo "Token de Acesso: $ACCESS_TOKEN"
# 2. Acessar a API protegida via Kong com o token
curl -X GET http://localhost:8000/api/v1/anything
-H "Authorization: Bearer $ACCESS_TOKEN"
A resposta esperada deve ser do serviço httpbin.org/anything, indicando que o Kong validou o token e encaminhou a requisição.
Fluxo Authorization Code (para usuários)
Para fluxos que envolvem um usuário final e um navegador, o fluxo de código de autorização é mais comum. O Kong iniciaria o redirecionamento para o Keycloak, o usuário faria login, e o Keycloak redirecionaria de volta para o Kong com um código, que o Kong trocaria por um token.
Para testar isso, você pode tentar acessar http://localhost:8000/api/v1/anything diretamente em um navegador. Você será redirecionado para a página de login do Keycloak. Após login (com apiuser/password), será redirecionado de volta ao Kong, que então mostrará a resposta da API.
Granularidade de Acesso com ACLs do Kong
Além da autenticação básica, o Kong permite implementar controle de acesso baseado em lista (ACL) utilizando informações dos tokens de acesso. O plugin OIDC do Kong pode extrair dados (claims) do token e mapeá-los para consumidores ou grupos de consumidores no Kong. Isso permite que você crie políticas de autorização mais refinadas.
Mapeando Claims para Consumidores
O plugin OIDC pode ser configurado para criar ou associar consumidores do Kong dinamicamente com base em claims do token. Por exemplo, você pode mapear o preferred_username do Keycloak para o username de um consumidor do Kong.
# Exemplo de configuração de um consumidor para o usuário 'apiuser'
# Idealmente, isto seria feito programaticamente ou via kong.yml/deck
curl -X POST http://localhost:8001/consumers
--data "username=apiuser"
# Associar o usuário 'apiuser' a um grupo de ACL
curl -X POST http://localhost:8001/consumers/apiuser/acls
--data "group=api_readers"
# Habilitar o plugin ACL na rota (ou serviço)
curl -X POST http://localhost:8001/routes/api-v1-anything/plugins
--data "name=acl"
--data "config.whitelist=api_readers"
Com esta configuração, somente tokens de usuários que pertencem ao grupo api_readers (ou seja, o consumidor apiuser) terão acesso à rota /api/v1/anything. A integração do plugin OIDC com o plugin ACL é poderosa para autorização baseada em atributos (ABAC).
Automação e Manutenção com Kong Declarative Configuration (DEC)
Para ambientes de produção, gerenciar configurações do Kong via Admin API de forma manual é inviável e propenso a erros. A abordagem recomendada é utilizar a configuração declarativa do Kong, com um arquivo YAML ou JSON que descreve o estado desejado da sua infraestrutura de API. Ferramentas como Kong deck (declarative config) permitem sincronizar esse arquivo com o estado do Kong Gateway.
Exemplo de kong.yml:
_format_version: "3.0"
services:
- name: httpbin-service
url: https://httpbin.org/anything
routes:
- name: api-v1-anything
paths: [
"/api/v1/anything"
]
strip_path: true
plugins:
- name: openid-connect
config:
client_id: minha-api-client
client_secret: minha-api-secret
issuer: http://keycloak:8080/realms/minha-api-realm
auth_methods:
- client_credentials
- authorization_code
credential_location: header
redirect_uri: http://kong:8000/callback
bearer_only: false
token_introspection_endpoint: http://keycloak:8080/realms/minha-api-realm/protocol/openid-connect/token/introspect
introspection_key_claim: sub
introspection_value_claim: preferred_username
- name: acl
config:
whitelist:
- api_readers
consumers:
- username: apiuser
acls:
- group: api_readers
Para aplicar essa configuração, primeiro copie o kong.yml para o contêiner do Kong ou um volume persistente. Então execute:
docker-compose exec kong kong deck sync -s kong.yml
Este comando sincronizará o estado do kong.yml com a configuração ativa do Kong. Esta metodologia é fundamental para integrar a gestão do Kong em pipelines de CI/CD, garantindo que as mudanças de configuração sejam versionadas, revisadas e aplicadas de forma automatizada.
Considerações de Resiliência e Segurança em Produção
Para um ambiente de produção, diversos fatores adicionais merecem atenção:
- HTTPS/TLS: Todas as comunicações (Kong <-> Cliente, Kong <-> Keycloak, Keycloak <-> Cliente) devem ser protegidas por TLS. Configure certificados no Kong e Keycloak.
- Segredos: Credenciais de banco de dados, segredos de clientes Keycloak e outros segredos não devem ser hardcoded. Utilize ferramentas de gerenciamento de segredos como HashiCorp Vault, Kubernetes Secrets (se em K8s), ou variáveis de ambiente seguras.
- Alta Disponibilidade: Execute múltiplos nós do Kong e Keycloak, distribuídos em diferentes zonas de disponibilidade, para garantir resiliência contra falhas. Bancos de dados devem ser configurados com replicação e failover automático.
- Monitoramento e Logs: Integre o Kong e Keycloak com sistemas de monitoramento (Prometheus, Grafana) e agregação de logs (ELK Stack, Grafana Loki) para visibilidade operacional e de segurança.
- Auditoria: Configure o Keycloak para registrar eventos de auditoria detalhados, permitindo rastrear tentativas de login, alterações de permissão e outras ações críticas.
- Atualizações e Patches: Mantenha Kong, Keycloak e o sistema operacional subjacente atualizados com os últimos patches de segurança.
- Rede Segregada: Isole os componentes em redes privadas, expondo apenas o Kong Gateway para o tráfego externo.
Expandindo a Autorização com OPA/Rego
Para cenários de autorização mais complexos, onde as decisões não são binárias (permitir/negar) mas dependem de múltiplos atributos da requisição, do usuário e do recurso, a integração com o Open Policy Agent (OPA) é uma excelente evolução. O Kong pode ser configurado para enviar informações da requisição para um serviço OPA, que avaliaria as políticas de Rego e retornaria uma decisão de autorização. Esta abordagem desacopla a lógica de autorização da sua API Gateway e dos seus microsserviços, promovendo maior flexibilidade e reusabilidade de políticas.
A implementação de segurança de APIs com Kong Gateway e Keycloak no Linux estabelece uma base sólida para qualquer arquitetura de microsserviços. Adotando práticas DevOps e infraestrutura como código, é possível construir um sistema seguro, escalável e de fácil manutenção, capaz de proteger recursos valiosos contra acessos não autorizados e ataques maliciosos.
Sou um profissional na área de Tecnologia da informação, especializado em monitoramento de ambientes, Sysadmin e na cultura DevOps. Possuo certificações de Segurança, AWS e Zabbix.
