Configuração do Ranger
O que é o Apache Ranger?
O Apache Ranger é um framework de segurança centralizado para plataformas de dados.
Em vez de cada serviço gerenciar suas próprias regras de acesso, o Ranger fornece um ponto único onde você define quem pode fazer o quê em qual recurso — e todos os serviços integrados consultam essas políticas em tempo real.
No TDP Kubernetes, o Ranger protege três serviços:
| Serviço | O que o Ranger controla |
|---|---|
| Apache Kafka | Quais usuários podem produzir ou consumir em quais tópicos |
| Apache NiFi | Acesso a componentes e flows do NiFi |
| Trino | Acesso a catálogos, schemas e tabelas em queries SQL |
Consulte Apache Ranger — Conceitos para uma visão completa da ferramenta, seu modelo de plugins e funcionamento.
Como o Ranger funciona na prática
O modelo do Ranger é baseado em plugins: cada serviço integrado instala um plugin que intercepta as requisições de acesso e as valida contra as políticas definidas no Ranger Admin. Esse processo é transparente para o usuário final — ele simplesmente recebe uma permissão concedida ou negada.
O Ranger também registra todas as decisões de acesso em logs de auditoria, armazenados no Apache Solr (incluído como subchart do tdp-ranger).
Isso permite rastrear quem acessou o quê e quando — essencial para conformidade e investigação de incidentes.
O processo de integração
O chart tdp-ranger usa um configJob — um Kubernetes Job que aguarda o Ranger ficar disponível e então executa o registro dos plugins e das políticas padrão.
Esse job é controlado por rangerIntegrations.configJob.enabled e roda automaticamente após a instalação.
Visão geral
| Propriedade | Valor |
|---|---|
| Chart | tdp-ranger |
| Versão do Ranger | 2.7.0 |
| Versão do Chart | 3.0.0 |
| Registry (OCI) | oci://registry.tecnisys.com.br/tdp/charts/tdp-ranger |
Instalação (OCI)
helm install <release> oci://registry.tecnisys.com.br/tdp/charts/tdp-ranger -n <namespace> --create-namespace
Parâmetros principais
| Parâmetro | Descrição | Valor por omissão |
|---|---|---|
tdp-ranger.enabled | Habilitar o deploy do Ranger | true |
tdp-ranger.clusterLabel | Label de cluster | tdp |
tdp-ranger.ranger.adminUser | Usuário admin Ranger | admin |
tdp-ranger.ranger.adminPassword | Senha admin Ranger | não definido |
tdp-ranger.ranger.dbUser | Usuário do banco | ranger |
tdp-ranger.ranger.dbPassword | Senha do banco | "" |
tdp-ranger.ranger.existingSecret | Secret existente para credenciais do DB | <release>-ranger-database |
tdp-ranger.ranger.existingSecretPasswordKey | Chave da senha no Secret | password |
tdp-ranger.ranger.database.host | Host do banco | <postgresql-service>.<namespace>.svc.cluster.local |
tdp-ranger.ranger.database.port | Porta do banco | 5432 |
TDPConfigurations.externalDatabase.enabled | Habilitar Job de bootstrap do DB externo (db-create-job) | false |
TDPConfigurations.externalDatabase.recreate | Recriar DB em install/upgrade | true |
TDPConfigurations.externalDatabase.externalSecret.releaseName | Nome do release PostgreSQL | tdp-postgresql |
TDPConfigurations.externalDatabase.externalSecret.area | Sufixo da área (montagem do nome do Secret) | project |
rangerIntegrations.configJob.enabled | Habilitar job de integrações | true |
rangerIntegrations.configJob.image | Imagem do job | python:3.11-slim |
rangerIntegrations.configJob.rangerReadyTimeout | Timeout de prontidão (s) | 600 |
rangerIntegrations.configJob.retryInterval | Intervalo de retry (s) | 10 |
rangerIntegrations.kafka.enabled | Integração Kafka | false |
rangerIntegrations.nifi.enabled | Integração NiFi | false |
rangerIntegrations.trino.enabled | Integração Trino | false |
tdp-ranger.solr.persistence.enabled | Persistência Solr | true |
tdp-ranger.solr.persistence.size | Tamanho do PVC Solr | 1Gi |
tdp-ranger.solr.persistence.storageClassName | StorageClass Solr | "" |
Lista completa: helm show values na versão instalada.
base de dados externo
Um Job (db-create-job) cria banco/usuário Ranger e grava credenciais em um Secret. O Job só é criado quando:
tdp-ranger.postgres.enabled=false, eTDPConfigurations.externalDatabase.enabled=true
A senha admin do PostgreSQL usada pelo Job vem de um Secret existente cujo nome é <releaseName>-<area> e cuja chave esperada é postgres-password.
Desabilitar explicitamente o Job:
helm upgrade --install <release> oci://registry.tecnisys.com.br/tdp/charts/tdp-ranger \
-n <namespace> \
--set TDPConfigurations.externalDatabase.enabled=false
Integrações (Kafka, NiFi, Trino)
Configuração em rangerIntegrations. O mesmo esquema pode aparecer em rangerIntegrations.*, tdp-ranger.rangerIntegrations.* e global.rangerIntegrations.* (subcharts / global).
Cada integração suporta, entre outros: serviceName, serviceDisplayName, connection.*, credentials.*, defaultPolicies (lista de objetos de política).
Exemplo habilitando Kafka:
helm upgrade --install <release> oci://registry.tecnisys.com.br/tdp/charts/tdp-ranger \
-n <namespace> \
--set rangerIntegrations.kafka.enabled=true \
--set rangerIntegrations.kafka.connection.bootstrapServers=<kafka-bootstrap-servers> \
--set rangerIntegrations.kafka.connection.zookeeperConnect=<zookeeper-connect>
Mais exemplos em YAML: Integrações — Ranger.
Acesso
Depende do subchart upstream; serviços costumam ser listados com o instance do release:
kubectl -n <namespace> get svc -l app.kubernetes.io/instance=<release>
Resolução de Problemas
kubectl -n <namespace> get pods
kubectl -n <namespace> get jobs
kubectl -n <namespace> get events --sort-by=.lastTimestamp
kubectl -n <namespace> logs job/<job-name>
Desinstalação
helm uninstall <release> -n <namespace>