Skip to main content
Version Next

Ranger Configuration

What is Apache Ranger?

Apache Ranger is a centralized security framework for data platforms.

Instead of each service managing its own access rules, Ranger provides a single point where you define who can do what on which resource — and all integrated services consult those policies in real time.

In TDP Kubernetes, Ranger secures three services:

ServiceWhat Ranger controls
Apache KafkaWhich users can produce or consume on which topics
Apache NiFiAccess to NiFi components and flows
TrinoAccess to catalogs, schemas, and tables in SQL queries
Learn more

See Apache Ranger — Concepts for a complete overview of the tool, its plugin model and how it works.

How Ranger works in practice

The Ranger model is based on plugins: each integrated service installs a plugin that intercepts access requests and validates them against the policies defined in Ranger Admin. This process is transparent to the end user — they simply receive an access granted or denied response.

Ranger also records all access decisions in audit logs, stored in Apache Solr (included as a subchart of tdp-ranger).

This allows you to track who accessed what and when — essential for compliance and incident investigation.

The integration process

The tdp-ranger chart uses a configJob — a Kubernetes Job that waits for Ranger to become available and then registers the plugins and default policies.

This job is controlled by rangerIntegrations.configJob.enabled and runs automatically after installation.

Overview

PropertyValue
Charttdp-ranger
Ranger Version2.7.0
Chart Version3.0.0
Registry (OCI)oci://registry.tecnisys.com.br/tdp/charts/tdp-ranger

Installation (OCI)

Terminal input
helm install <release> oci://registry.tecnisys.com.br/tdp/charts/tdp-ranger -n <namespace> --create-namespace

Main parameters

ParameterDescriptionDefault value
tdp-ranger.enabledEnable the Ranger deploytrue
tdp-ranger.clusterLabelCluster labeltdp
tdp-ranger.ranger.adminUserRanger admin useradmin
tdp-ranger.ranger.adminPasswordRanger admin passwordnot set
tdp-ranger.ranger.dbUserDatabase userranger
tdp-ranger.ranger.dbPasswordDatabase password""
tdp-ranger.ranger.existingSecretExisting Secret for DB credentials<release>-ranger-database
tdp-ranger.ranger.existingSecretPasswordKeyPassword key in the Secretpassword
tdp-ranger.ranger.database.hostDatabase host<postgresql-service>.<namespace>.svc.cluster.local
tdp-ranger.ranger.database.portDatabase port5432
TDPConfigurations.externalDatabase.enabledEnable external DB bootstrap Job (db-create-job)false
TDPConfigurations.externalDatabase.recreateRecreate DB on install/upgradetrue
TDPConfigurations.externalDatabase.externalSecret.releaseNamePostgreSQL release nametdp-postgresql
TDPConfigurations.externalDatabase.externalSecret.areaArea suffix (Secret name construction)project
rangerIntegrations.configJob.enabledEnable integrations jobtrue
rangerIntegrations.configJob.imageJob imagepython:3.11-slim
rangerIntegrations.configJob.rangerReadyTimeoutReadiness timeout (s)600
rangerIntegrations.configJob.retryIntervalRetry interval (s)10
rangerIntegrations.kafka.enabledKafka integrationfalse
rangerIntegrations.nifi.enabledNiFi integrationfalse
rangerIntegrations.trino.enabledTrino integrationfalse
tdp-ranger.solr.persistence.enabledSolr persistencetrue
tdp-ranger.solr.persistence.sizeSolr PVC size1Gi
tdp-ranger.solr.persistence.storageClassNameSolr StorageClass""

Full list: helm show values on the installed version.

External database

A Job (db-create-job) creates the Ranger database/user and writes credentials to a Secret. The Job is only created when:

  • tdp-ranger.postgres.enabled=false, and
  • TDPConfigurations.externalDatabase.enabled=true

The PostgreSQL admin password used by the Job comes from an existing Secret whose name is <releaseName>-<area> and whose expected key is postgres-password.

To explicitly disable the Job:

Terminal input
helm upgrade --install <release> oci://registry.tecnisys.com.br/tdp/charts/tdp-ranger \
-n <namespace> \
--set TDPConfigurations.externalDatabase.enabled=false

Integrations (Kafka, NiFi, Trino)

Configuration under rangerIntegrations. The same schema may appear under rangerIntegrations.*, tdp-ranger.rangerIntegrations.*, and global.rangerIntegrations.* (subcharts / global).

Each integration supports, among others: serviceName, serviceDisplayName, connection.*, credentials.*, defaultPolicies (list of policy objects).

Example enabling Kafka:

Terminal input
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>

More YAML examples at: Integrations — Ranger.

Access

Depends on the upstream subchart; services are typically listed using the release instance:

Terminal input
kubectl -n <namespace> get svc -l app.kubernetes.io/instance=<release>

Troubleshooting

Terminal input
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>

Uninstallation

Terminal input
helm uninstall <release> -n <namespace>