Version 3.0

Integrations - Ranger

ChartVersion3.0.1TypeapplicationAppVersion2.7.0

CompatibilityKubernetes1.32+OpenShift4.19+Rancher2.10.x+

Integration overview

The tdp-ranger chart can use an external PostgreSQL (tdp-postgresql) as its metadata and audit database — see Ranger Configuration.

The rangerIntegrations block automates one specific part of the integration flow: registering services and policies in Ranger Admin.

When rangerIntegrations.configJob.enabled=true, the chart runs a post-install or post-upgrade job that waits for Ranger Admin to respond, reads the enabled integrations, registers or updates the corresponding services in Ranger Admin, and creates the policies declared in defaultPolicies, when configured.

Without this job, that registration must be performed manually through the Ranger Admin UI or API.

Automation scope

This automation acts on the Ranger Admin side.

The integrated service configuration needed to query Ranger, when required, must be done according to that component's own documentation.

Enabling rangerIntegrations.<SERVICE_NAME>.enabled=true does not configure the component end to end.

Automation disabled by default

rangerIntegrations.configJob.enabled is false by default.

To automate registration in Ranger Admin, enable this parameter in your values file.

Configuration pattern

The same configuration model can appear in three scopes, depending on how the chart is used:

Scope	Use
`rangerIntegrations.*`	Consumed by resources rendered by `tdp-ranger`, including integration job and ConfigMap
`tdp-ranger.rangerIntegrations.*`	Forwarded to the Apache Ranger subchart
`global.rangerIntegrations.*`	Shared with subcharts that consume global values

Use the scope that matches the deployed package.

When Ranger Admin registration depends on the automatic job, ensure rangerIntegrations.configJob.enabled=true.

Prerequisites

Ranger Admin deployed and reachable through the internal Service.
Administrator password configured and available to the integrations job.
Target service deployed and reachable over the network.
Ranger service name defined in serviceName.
Credentials and endpoints compatible with the service type registered in Ranger Admin.
Integrated component configuration applied in that component's chart or documentation when it must query Ranger at runtime.
Policies declared in defaultPolicies reviewed before applying them in a shared environment.

Integrations job

The integrations job runs after release installation or upgrade.

It waits for Ranger Admin to respond, installs Python dependencies in the job container, and executes the script that registers services and policies in Ranger Admin.

Parameter	Description
`rangerIntegrations.configJob.enabled`	Enable the automatic job
`rangerIntegrations.configJob.image`	Image used by the setup container
`rangerIntegrations.configJob.imagePullPolicy`	Image pull policy
`rangerIntegrations.configJob.rangerReadyTimeout`	Maximum wait time for Ranger Admin
`rangerIntegrations.configJob.retryInterval`	Interval between attempts

Integration examples

The following sections show configuration examples accepted by rangerIntegrations.

They should not be read as a fixed conceptual list of everything Apache Ranger can protect.

Kafka

The Kafka configuration registers a Kafka service in Ranger Admin.

It requires bootstrap endpoints, ZooKeeper connection when required by the plugin, and the security protocol.

This configuration demonstrates registration in Ranger Admin and the creation of policies declared in defaultPolicies, when present.

It does not state that the Kafka chart automatically configures the Ranger plugin on the broker.

rangerIntegrations:
  configJob:
    enabled: true
  kafka:
    enabled: true
    serviceName: "tdp_kafka"
    serviceDisplayName: "TDP Kafka Cluster"
    connection:
      bootstrapServers: "<KAFKA_BOOTSTRAP_SERVICE>.<NAMESPACE>.svc.cluster.local:9092"
      zookeeperConnect: "<ZOOKEEPER_SERVICE>.<NAMESPACE>.svc.cluster.local:2181"
      securityProtocol: "PLAINTEXT"
    credentials:
      username: "<USERNAME>"
      password: "<PASSWORD>"
    defaultPolicies: []

Use defaultPolicies to create declared topic, cluster, transactional ID, and delegation token policies when this belongs to environment bootstrap.

Review groups and users before applying broad policies such as full access.

For a quick one-liner enable:

helm upgrade --install <RELEASE_NAME> 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>

Trino

The Trino configuration registers a service in Ranger Admin with JDBC URL and Trino driver.

It allows policies for catalogs, schemas, tables, and columns to be declared in Ranger Admin.

This registration does not replace the Ranger access control configuration in the Trino chart; Trino must also be configured to query Ranger at runtime.

rangerIntegrations:
  configJob:
    enabled: true
  trino:
    enabled: true
    serviceName: "tdp_trino"
    serviceDisplayName: "TDP Trino Cluster"
    connection:
      jdbcUrl: "jdbc:trino://<TRINO_SERVICE>.<NAMESPACE>.svc.cluster.local:8080"
      jdbcDriverClassName: "io.trino.jdbc.TrinoDriver"
    credentials:
      username: "<USERNAME>"
      password: "<PASSWORD>"
    defaultPolicies: []

Credentials should represent a technical user able to validate the registered service connection in Ranger.

Policies should reflect the data model of the environment and avoid broad * access without review.

Generic NiFi

The generic NiFi configuration registers a NiFi service in Ranger Admin.

It can be useful for simple scenarios, but it does not cover the full production flow where NiFi uses Ranger as the main authorizer.

This configuration demonstrates registration in Ranger Admin and the creation of policies declared in defaultPolicies, when present.

It does not state that the NiFi chart automatically configures the Ranger authorizer.

rangerIntegrations:
  configJob:
    enabled: true
  nifi:
    enabled: true
    serviceName: "tdp_nifi"
    serviceDisplayName: "TDP NiFi Cluster"
    connection:
      nifiUrl: "http://<NIFI_SERVICE>.<NAMESPACE>.svc.cluster.local:8080"
      internalUrl: "http://<NIFI_HEADLESS_SERVICE>.<NAMESPACE>.svc.cluster.local:8080"
      authenticationType: "none"
    credentials:
      username: "<USERNAME>"
      password: "<PASSWORD>"
    defaultPolicies: []

Use this mode only when it matches the security model of the deployed NiFi.

For NiFi with authorization centralized in Ranger, use the mTLS pattern below.

Dedicated overlay file

For NiFi integration with Ranger as the authorizer, use the dedicated overlay file provided with the chart. It already aligns the service definition with the Apache Ranger NiFi plugin documentation, pointing nifi.url to /nifi-api/resources and using a hostname present in the NiFi node certificate SANs.

Terminal input
helm upgrade --install <RELEASE_NAME> oci://registry.tecnisys.com.br/tdp/charts/tdp-ranger \
  -n <NAMESPACE> \
  -f values-nifi-ranger-authorizer.yaml

NiFi as authorizer through Ranger

When NiFi uses Ranger as the main authorizer, the service registration in Ranger Admin must be compatible with the mTLS flow between Ranger and NiFi.

In this scenario, Ranger accesses /nifi-api/resources, creates technical users, and creates the policies declared in defaultPolicies so the NiFi cluster can operate.

This flow also requires the corresponding configuration in the NiFi chart so NiFi queries Ranger as its authorizer.

Before installation, create the Secret with the stable JKS password:

kubectl -n <NAMESPACE> create secret generic ranger-nifi-client-tls-password --from-literal=password='<KEYSTORE_PASSWORD>' --dry-run=client -o yaml | kubectl apply -f -

For a first installation, you can also create the Secret with a direct command:

kubectl -n <NAMESPACE> create secret generic ranger-nifi-client-tls-password --from-literal=password='<KEYSTORE_PASSWORD>'

Do not rotate this password casually.

If it changes without reissuing the client certificate Secret, Ranger may fail to open keystore.jks and truststore.jks.

Key settings:

rangerIntegrations:
  configJob:
    enabled: true
  nifi:
    enabled: true
    serviceName: "tdp_nifi"
    tlsClientCertificate:
      autoGenerate:
        enabled: true
        secretName: "ranger-nifi-client-tls"
        passwordSecretName: "ranger-nifi-client-tls-password"
        passwordSecretKey: "password"
        issuerRef:
          name: "nifi-issuer"
          kind: "Issuer"
          group: "cert-manager.io"
        commonName: "ranger-nifi-client"
    connection:
      nifiUrl: "https://nifi-headless.<NAMESPACE>.svc.cluster.local:8443/nifi-api/resources"
      authenticationType: "SSL"
      sslUseDefaultContext: "false"
      ssl:
        keystore: "/opt/ranger/certs/keystore.jks"
        truststore: "/opt/ranger/certs/truststore.jks"
      additionalConfigs:
        policy.download.auth.users: "nifi"

The client certificate is created by cert-manager when tlsClientCertificate.autoGenerate.enabled=true.

The certificate Common Name must match the Ranger administrator identity configured in NiFi.

Declared policies

Each integration accepts defaultPolicies.

This block creates policies in Ranger Admin during bootstrap, when configured.

For NiFi as authorizer, the technical policies declared for bootstrap should allow:

CN=ranger-nifi-client on /resources.
CN=nifi-controller on /controller and /system.
NiFi node identities on /proxy.

These policies are technical and do not replace human access policies for flows.

Create real user and group policies after LDAP/AD and UserSync are validated.

Validation

Check whether the job was created and completed successfully:

kubectl -n <NAMESPACE> get jobs
kubectl -n <NAMESPACE> logs job/<RELEASE_NAME>-ranger-integrations

In Ranger Admin, validate service creation, connection status, policies declared in defaultPolicies when configured, and technical users when NiFi mTLS is enabled.

Troubleshooting

Symptom	Possible cause	Check
Job is not created	`rangerIntegrations.configJob.enabled=false`	Check the applied values file
Job fails waiting for Ranger	Ranger Admin unavailable or wrong admin password	Check pods, Service, and admin Secret
Service does not appear in Ranger	Specific integration disabled	Check `rangerIntegrations.<SERVICE_NAME>.enabled`
NiFi mTLS fails	Missing JKS password or certificate not issued	Check Secrets and cert-manager Certificate
Policies do not apply	Users/groups do not exist or DN is wrong	Validate UserSync and policy names

After fixing the cause, run a new helm upgrade to recreate the integration hook.

Integration overview​

Configuration pattern​

Prerequisites​

Integrations job​

Integration examples​

Kafka​

Trino​

Generic NiFi​

NiFi as authorizer through Ranger​

Declared policies​

Validation​

Troubleshooting​