Security - Ranger

ChartVersion3.0.1TypeapplicationAppVersion2.7.0

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

Overview

The tdp-ranger chart concentrates security in four areas: administrative credentials, database credentials, LDAP/AD authentication, and user/group synchronization. These areas directly affect who can access Ranger Admin, how policies are stored, and which identities are available for permission assignment.

Use Secrets for sensitive values and keep only placeholders in versioned files. Example passwords must be replaced before any environment with real data.

Authentication modes

Mode	Typical use	Note
Local admin user	Initial installation and emergency administration	Change the example default password
LDAP/AD	Login with a corporate directory	Requires bind DN, bind password, and search filters
UserSync	Synchronization of users and groups into Ranger	Recommended together with LDAP/AD
LDAPS	LDAP connection protected by TLS	Requires a compatible certificate/truststore

The local admin user is useful for bootstrap and recovery. In shared environments, prefer corporate authentication and role assignment by groups.

Administrative credentials

Configure tdp-ranger.ranger.adminUser and tdp-ranger.ranger.adminPassword before installation. The Ranger Admin password must contain at least 8 characters, with uppercase and lowercase letters, a number, and a special character.

Avoid recording the real password in versioned files. When the environment uses an external secret management tool, keep the values file with placeholders only and inject the value during the deploy process.

Database credentials

Ranger uses PostgreSQL to store policies, users, and configurations. When the database is external, the chart runs a bootstrap job (db-create-job) that creates the Ranger database and user.

The job is created only when both conditions are met:

• tdp-ranger.postgres.enabled=false — bundled database disabled
• TDP-Settings.externalDatabase.enabled=true — external PostgreSQL enabled

The job reads the PostgreSQL administrator credentials from a Secret whose name matches the releaseName of the tdp-postgresql release (default: tdp-postgresql) and whose expected key is postgres-password. This Secret is automatically generated by the tdp-postgresql chart.

The Ranger database credential Secret is expected in tdp-ranger.ranger.existingSecret, with the password in the key defined by tdp-ranger.ranger.existingSecretPasswordKey.

To explicitly disable the job:

Terminal input

helm upgrade --install <RELEASE_NAME> \
  oci://registry.tecnisys.com.br/tdp/charts/tdp-ranger \
  -n <NAMESPACE> \
  --set TDP-Settings.externalDatabase.enabled=false

LDAP/AD

Enable LDAP/AD when Ranger Admin must authenticate users from a corporate directory. The configuration must provide the server URL, bind DN, bind password, base DN, search filters, and the attributes used for users and groups.

The recommended workflow is to keep tdp-ranger.ldap.enabled=false in the base configuration, create the required Secrets, and apply the LDAP/AD configuration only during the install or upgrade of the environment that will use a corporate directory. This avoids enabling external authentication without bind DN, bind password, filters, and certificates already defined.

Example applying a dedicated values file for LDAP/AD:

helm upgrade --install <RELEASE_NAME> oci://registry.tecnisys.com.br/tdp/charts/tdp-ranger -f <BASE_VALUES_FILE> -f <LDAP_VALUES_FILE> -n <NAMESPACE>

Create the bind password Secret in the same namespace as Ranger:

kubectl create secret generic tdp-ranger-ldap-secret --from-literal=bind-password='<LDAP_BIND_PASSWORD>' -n <NAMESPACE>

Configuration example:

tdp-ranger:
  ldap:
    enabled: true
    connection:
      url: "ldap://<LDAP_HOST>:389"
      allowInsecure: true
    bind:
      dn: "cn=<LDAP_BIND_USER>,dc=<LDAP_DOMAIN>,dc=com"
      passwordSecret:
        name: "tdp-ranger-ldap-secret"
        key: "bind-password"
    baseDn: "dc=<LDAP_DOMAIN>,dc=com"
    user:
      searchBase: "ou=users,dc=<LDAP_DOMAIN>,dc=com"
      searchFilter: "(&(objectClass=person)(uid={0}))"
      nameAttribute: "uid"
      emailAttribute: "mail"
    group:
      searchBase: "ou=groups,dc=<LDAP_DOMAIN>,dc=com"
      searchFilter: "(objectClass=groupOfNames)"
      memberAttribute: "member"

For Active Directory, adjust filters and attributes to the schema used by the domain, such as sAMAccountName when applicable. For OpenLDAP or FreeIPA, validate uid, cn, memberOf, and the object classes used in the directory.

LDAPS and truststore

Use LDAPS when the directory requires a connection protected by TLS. In this mode, Ranger must trust the certificate presented by the LDAP server.

Create the Secret with the expected certificate or truststore:

kubectl create secret generic tdp-ranger-ldap-certs --from-file=truststore.pem=<LOCAL_PATH> -n <NAMESPACE>

To enable LDAPS, replace the connection block with the ldaps:// URL (port 636) using allowInsecure: false and add the tls section referencing the tdp-ranger-ldap-certs Secret:

tdp-ranger:
  ldap:
    connection:
      url: "ldaps://<LDAP_HOST>:636"
      allowInsecure: false
    tls:
      enabled: true
      truststore:
        secretName: "tdp-ranger-ldap-certs"
        secretKey: "truststore.pem"
        path: "/etc/ranger/ldap-certs"

If the certificate chain is incomplete, LDAP login can fail even with the correct username and password. Validate the CA, certificate SAN, and DNS resolution for the LDAP host.

UserSync

UserSync synchronizes directory users and groups into Ranger Admin. This allows policies to use corporate identities without manually creating users.

When LDAP/AD is enabled, configure tdp-ranger.usersync.enabled=true and adjust the sync source, interval, filters, and resources. UserSync uses an initContainer to wait for Ranger Admin to become available before starting synchronization. In the dedicated LDAP/AD flow, UserSync uses the registry.tecnisys.com.br/tdp/images/ranger-usersync:2.7.0 image and loads install.properties from a ConfigMap, applying secrets at runtime. Customize resources via tdp-ranger.usersync.resources and fine-tune LDAP knobs via tdp-ranger.usersync.ldap.

Example:

tdp-ranger:
  usersync:
    enabled: true
    syncSource: "ldap"
    syncInterval: 60

Role assignment

Use tdp-ranger.usersync.roleAssignment.rules to assign Ranger roles to synchronized users or groups. This avoids depending exclusively on the local admin user for administration.

tdp-ranger:
  usersync:
    roleAssignment:
      enabled: true
      rules:
        - role: "ROLE_SYS_ADMIN"
          users: []
          groups:
            - "cn=ranger_admins,ou=groups,dc=<LDAP_DOMAIN>,dc=com"
        - role: "ROLE_ADMIN_AUDITOR"
          users: []
          groups:
            - "cn=ranger_auditors,ou=groups,dc=<LDAP_DOMAIN>,dc=com"

Supported roles include ROLE_SYS_ADMIN, ROLE_KEY_ADMIN, ROLE_ADMIN_AUDITOR, ROLE_KEY_ADMIN_AUDITOR, and ROLE_USER. Use directory groups to reduce manual changes in Ranger Admin.

Main parameters

Parameter	Description
tdp-ranger.ranger.adminUser	Local Ranger administrator user
tdp-ranger.ranger.adminPassword	Local administrator password
tdp-ranger.ranger.dbPassword	Ranger database user password
tdp-ranger.ranger.existingSecret	Secret with Ranger database credentials
tdp-ranger.ldap.enabled	Enable LDAP/AD authentication
tdp-ranger.ldap.connection.url	LDAP or LDAPS server URL
tdp-ranger.ldap.connection.allowInsecure	Allow LDAP without TLS
tdp-ranger.ldap.bind.passwordSecret	Secret with bind password
tdp-ranger.ldap.user.searchFilter	User search filter
tdp-ranger.ldap.group.searchFilter	Group search filter
tdp-ranger.ldap.tls.enabled	Enable TLS/LDAPS
tdp-ranger.usersync.enabled	Enable user and group synchronization
tdp-ranger.usersync.roleAssignment.enabled	Enable automatic role assignment

Troubleshooting

Symptom	Possible cause	Check
Local login fails	Wrong admin password or stale Secret	Check the Secret and pod events
LDAP login fails	Wrong bind DN, password, or filter	Test the DN, filter, and bind Secret
LDAPS fails	Untrusted certificate or host does not match the certificate	Check the CA, SAN, and truststore.pem
Users do not appear	UserSync disabled or restrictive filters	Check the UserSync logs
Roles are not assigned	Group DN does not match the directory	Compare the real group DN with the rule

Useful commands:

kubectl -n <NAMESPACE> get pods
kubectl -n <NAMESPACE> get secrets
kubectl -n <NAMESPACE> logs deploy/<RELEASE_NAME>-ranger

Best practices

• Replace all example passwords before environments with real data.
• Use Secrets or an external tool for sensitive values.
• Prefer LDAPS for corporate directories.
• Use LDAP/AD groups to manage roles and policies.
• Keep the local admin user only for controlled bootstrap and recovery.
• Validate UserSync before creating policies that depend on groups.