Version 3.0

Security - Trino

ChartVersion3.0.1TypeapplicationAppVersion478

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

Overview

The tdp-trino chart concentrates security in three main areas.
The first one is LDAP authentication, which changes Trino access from unauthenticated HTTP to HTTPS with PASSWORD authentication.
The second one is the trinoCerts block, used to organize keystores, certificates, and TLS material through a Secret, PVC, and copy Job.
The third one is access control with Apache Ranger, configured through tdp-trino.accessControl and additional XML files on the coordinator.

The practical idea is simple: LDAP authenticates who connects, HTTPS protects transport, and Ranger decides what each user can access.
When LDAP or Ranger is enabled, treat certificates, passwords, and shared secrets as required deployment dependencies.

Operation Modes

The chart is designed to switch between a simple development mode and an authenticated mode.
This difference is mainly controlled by ldap.enabled and the HTTPS/authentication values under tdp-trino.server.config.

Mode	`ldap.enabled`	Port	Authentication	Certificates
HTTP without LDAP	`false`	`8080`	No login required	Does not mount certificates by default
HTTPS with LDAP	`true`	`8443`	`PASSWORD` with LDAP	Mounts keystore and configures shared secret

With ldap.enabled: false, the chart uses HTTP on port 8080 and does not require authentication.
This mode is useful for controlled testing, but it should not be exposed outside restricted environments.

With ldap.enabled: true, access moves to HTTPS on port 8443.
In this mode, Trino needs a keystore, keystore password, internal-communication.shared-secret, and a password-authenticator.properties file pointing to LDAP.

Prerequisites

LDAP server reachable from the Trino namespace when LDAP is used.
Valid JKS keystore for HTTPS and the matching password.
Kubernetes Secret with certificate files before deployment.
StorageClass available if trinoCerts.pvc.enabled: true.
Ranger deployed and reachable when access-control.name=ranger is used.
Coordinator connectivity to LDAP, Ranger, and protected data sources.

Trino TLS Certificates (`trinoCerts`)

The trinoCerts block prepares certificate material used by Trino when the environment requires HTTPS, LDAP, or integrations such as Ranger.
It does not generate certificates automatically; it organizes how existing files are made available to the pods.

The Secret stores sensitive files, such as JKS keystores.
The PVC provides a persistent volume to reuse these files across Helm steps.
The copyJob runs as a pre-install and pre-upgrade hook to copy files from the Secret to the PVC before installation or upgrade.

Parameter	Purpose	Default
`trinoCerts.pvc.enabled`	Creates a PVC for certificates	`false`
`trinoCerts.pvc.name`	Certificate PVC name	`trino-certs-pvc`
`trinoCerts.pvc.size`	PVC size	`1Gi`
`trinoCerts.secret.enabled`	Mounts certificate Secret in the Job	`false`
`trinoCerts.secret.name`	Certificate Secret name	`tdp-trino-certs-secret`
`trinoCerts.copyJob.enabled`	Runs the Job that prepares the PVC	`false`

Secret model for LDAP with a keystore:

kubectl -n <NAMESPACE> create secret generic tdp-trino-certs-secret \
  --from-file=keystore.jks=<LOCAL_PATH>/keystore.jks

Secret example for a PVC and Ranger flow:

kubectl -n <NAMESPACE> create secret generic tdp-trino-certs-secret \
  --from-file=trino_cert.jks=<LOCAL_PATH>/trino_cert.jks

Example of preparing the PVC with copyJob:

trinoCerts:
  pvc:
    enabled: true
    size: "1Gi"
  secret:
    enabled: true
    name: "tdp-trino-certs-secret"
  copyJob:
    enabled: true

LDAP Enabled

LDAP is used by Trino as the password authenticator.
In the chart, enabling LDAP also implies enabling HTTPS, because user credentials should not travel over plain HTTP.

The password-authenticator.properties file defines how Trino queries the LDAP directory.
The userBindPattern is the DN template used for bind; ${USER} is replaced by the user supplied by the Trino client.

Configuration model:

ldap:
  enabled: true
  server:
    url: "ldap://<LDAP_HOST>:389"
    insecure: true
  auth:
    userBindPattern: "uid=${USER},cn=users,cn=accounts,dc=<LDAP_DOMAIN>,dc=com,dc=br"

tdp-trino:
  server:
    config:
      https:
        enabled: true
        port: 8443
        keystore:
          path: "/etc/trino/certs/keystore.jks"
      authenticationType: "PASSWORD"
  additionalConfigProperties:
    - "internal-communication.shared-secret=<SHARED_SECRET>"
    - "http-server.https.keystore.key=<KEYSTORE_PASSWORD>"
  coordinator:
    additionalVolumes:
      - name: trino-certs
        secret:
          secretName: tdp-trino-certs-secret
    additionalVolumeMounts:
      - name: trino-certs
        mountPath: /etc/trino/certs
        readOnly: true
    additionalConfigFiles:
      password-authenticator.properties: |
        password-authenticator.name=ldap
        ldap.url=ldap://<LDAP_HOST>:389
        ldap.allow-insecure=true
        ldap.user-bind-pattern=uid=${USER},cn=users,cn=accounts,dc=<LDAP_DOMAIN>,dc=com,dc=br
        ldap.cache-ttl=1h
        ldap.timeout.connect=1m
        ldap.timeout.read=1m

Replace the placeholders before installing.
<LDAP_HOST> is the LDAP address as seen from inside the cluster.
<LDAP_DOMAIN> represents the directory DN components.
<SHARED_SECRET> must be a strong value for Trino internal communication.
<KEYSTORE_PASSWORD> must match the password of the keystore used by HTTPS.

To disable LDAP and return to HTTP mode, remove the LDAP-specific configuration and keep ldap.enabled: false.
After the upgrade, validate that the pods restarted and that the client uses port 8080.

To enable LDAP, create the certificate Secret first, apply the LDAP/HTTPS values, and use port 8443 on the client.
After the upgrade, check the generated ConfigMap, the coordinator mounts, and authentication logs.

Ranger

Apache Ranger adds centralized access control to Trino via an authorization plugin.

The integration uses tdp-trino.accessControl to enable the Ranger plugin.
Extra files in tdp-trino.coordinator.additionalConfigFiles provide the policy, audit, and SSL configuration that the plugin reads at startup.

Use the example below as a structure model.
It shows where the main pieces go without bringing full XML into the page.

trinoCerts:
  pvc:
    enabled: true
    size: "1Gi"
  secret:
    enabled: true
    name: "tdp-trino-certs-secret"
  copyJob:
    enabled: true

tdp-trino:
  server:
    config:
      https:
        enabled: true
        port: 8443
        keystore:
          path: "/etc/trino/ssl/trino_cert.jks"
          key: "<KEYSTORE_PASSWORD>"
      authenticationType: "PASSWORD"

  accessControl:
    type: properties
    properties: |
      access-control.name=ranger
      ranger.service.name=dev_trino
      ranger.plugin.config.resource=/etc/trino/ranger-trino-security.xml,/etc/trino/ranger-trino-audit.xml,/etc/trino/ranger-policymgr-ssl.xml

  coordinator:
    additionalVolumes:
      - name: trino-certs
        persistentVolumeClaim:
          claimName: trino-certs-pvc
    additionalVolumeMounts:
      - name: trino-certs
        mountPath: /etc/trino/ssl
    additionalConfigFiles:
      ranger-trino-security.xml: |
        <?xml version="1.0" encoding="UTF-8"?>
        <configuration>
          <property>
            <name>ranger.plugin.trino.policy.rest.url</name>
            <value>http://ranger-<NAMESPACE>.svc.cluster.local:6180</value>
          </property>
          <property>
            <name>ranger.plugin.trino.super.users</name>
            <value>admin</value>
          </property>
        </configuration>
      ranger-trino-audit.xml: |
        <configuration>
          <!-- Plugin audit configuration -->
        </configuration>
      ranger-policymgr-ssl.xml: |
        <configuration>
          <!-- Truststore/keystore for Ranger communication -->
        </configuration>

The ranger.service.name value must match the service registered in the Ranger UI.
If the names do not match, the plugin may start, but policies will not apply to the expected service.

Use superusers carefully.
An account listed as a superuser receives broad privileges through the plugin, so keep the list short and auditable.

When using external audit or mutual SSL, fill the XML files with the destinations, truststores, and credentials required by the environment.
Keep passwords and sensitive files out of the repository.

Connecting with the Trino Client

Model for HTTP without LDAP:

HTTP without LDAP

kubectl -n <NAMESPACE> port-forward svc/<RELEASE_NAME> 8080:8080 &
trino --server http://localhost:8080

Model for HTTPS with LDAP:

HTTPS with LDAP
kubectl -n <NAMESPACE> port-forward svc/<RELEASE_NAME> 8443:8443 &
trino --server https://localhost:8443 \
      --user <LDAP_USER> \
      --password \
      --insecure

Example:

HTTP without LDAP

kubectl port-forward -n tdp-project svc/tdp-trino 8080:8080 &
trino --server http://localhost:8080

HTTPS with LDAP
kubectl port-forward -n tdp-project svc/tdp-trino 8443:8443 &
trino --server https://localhost:8443 \
      --user your-ldap-username \
      --password \
      --insecure

In production, prefer validating the certificate chain instead of using --insecure.
Use --insecure only for controlled debugging or lab certificates.

Key Parameters

Parameter	Role	Default	When to change
`ldap.enabled`	Enables or disables LDAP mode	`false`	Environments with corporate authentication
`tdp-trino.server.config.https.enabled`	Enables HTTPS in Trino	`false`	LDAP, Ranger, or secure exposure
`tdp-trino.server.config.https.port`	Trino HTTPS port	`8443`	When the environment standardizes another port
`tdp-trino.server.config.https.keystore.path`	Keystore path inside the pod	empty	Whenever HTTPS is used
`tdp-trino.server.config.authenticationType`	Trino authentication type	empty	Use `PASSWORD` for LDAP or password files
`tdp-trino.additionalConfigProperties`	Extra Trino properties	`[]`	Shared secret, internal HTTPS, and advanced tuning
`tdp-trino.coordinator.additionalVolumes`	Extra coordinator volumes	`[]`	Mount Secret or PVC with certificates
`tdp-trino.coordinator.additionalConfigFiles`	Extra files on the coordinator	`{}`	LDAP, password file, and Ranger XMLs
`tdp-trino.accessControl`	Authorization configuration	`{}`	Apache Ranger or another supported control
`trinoCerts.*`	Certificate preparation	disabled	HTTPS, LDAP, Ranger, or mutual SSL

Troubleshooting

Situation	What to check
Pod does not start with LDAP	Keystore path, keystore password, Secret, mounts, and `authenticationType`
LDAP login fails	LDAP URL, `userBindPattern`, connectivity, certificate, and bind user permissions
Client cannot connect	Correct port: 8080 for HTTP, 8443 for HTTPS
Certificate error	File name in the Secret, mountPath, and path configured in Trino
Ranger does not apply policies	`ranger.service.name`, Ranger URL, coordinator XMLs, and authenticated user
PVC is not created	`trinoCerts.pvc.enabled`, StorageClass, and namespace events

When switching from LDAP to HTTP, remove LDAP/HTTPS-specific blocks to avoid residual configuration.
Then validate that the Service and client returned to port 8080.

When switching from HTTP to LDAP, create the Secret before helm upgrade.
Then validate the ConfigMap, mounted volumes, and access through port 8443.

Best Practices

Use LDAPS on port 636 in production whenever the directory supports it.
Do not version keystores, passwords, real hashes, or shared secrets.
Rotate keystore passwords and shared secrets periodically.
Restrict LDAP bind user permissions.
Keep the Ranger superuser list minimal.
Monitor Trino authentication logs and Ranger audit.
Keep ldap.enabled: false only in controlled development or test environments.

Overview​

Operation Modes​

Prerequisites​

Trino TLS Certificates (trinoCerts)​

LDAP Enabled​

Ranger​

Connecting with the Trino Client​

Key Parameters​

Troubleshooting​

Best Practices​