Security

This page covers [Authentication] and [Authorization].

Authentication

Trino supports several authentication types.

Different authentication types can be used simultaneously.

Password

The Trino operator currently supports the following PASSWORD authenticators.

File

The file based authentication can be defined as follows. First create a secret with your users:

apiVersion: v1
kind: Secret
metadata:
  name: trino-users
type: kubernetes.io/opaque
stringData:
  admin: admin
  alice: alice
  bob: bob

This contains username and password pairs as shown in the previous snippet. The username and password combinations are provided in the stringData field.

The Secret is referenced in an AuthenticationClass.

apiVersion: authentication.stackable.tech/v1alpha1
kind: AuthenticationClass
metadata:
  name: simple-trino-users
spec:
  provider:
    static:
      userCredentialsSecret:
        name: trino-users

Then reference the AuthenticationClass in your TrinoCluster definition:

apiVersion: trino.stackable.tech/v1alpha1
kind: TrinoCluster
metadata:
  name: simple-trino
spec:
  clusterConfig:
    authentication:
      - authenticationClass: simple-trino-users
      - authenticationClass: ...

Multiple authentication classes with different user secrets can be provided.

The operator never reads secrets directly, but mounts them directly into the Pod. Volume mount names can not exceed 63 characters due to Kubernetes restrictions.

For uniqueness, the volume mount name is internally build up of the name of the AuthenticationClass. This means the AuthenticationClass name must not exceed 63 characters.

Due to Kubernetes restrictions, the name of the AuthenticationClass must not exceed 63 characters.

Changes to the referenced user Secret (e.g. adding or removing a user) are updated in Trino without restarts but after a small delay. This heavily depends on Kubernetes and may take a couple of minutes.

Adding or removing an AuthenticationClass will however result in a Pod restart.

LDAP

The Trino operator supports LDAP authentication as well and authentication in Stackable is done using AuthenticationClasses:

apiVersion: authentication.stackable.tech/v1alpha1
kind: AuthenticationClass
metadata:
  name: my-ldap
spec:
  provider:
    ldap:
      hostname: openldap.default.svc.cluster.local
      searchBase: ou=users,dc=example,dc=org
...
You can follow the Authentication with OpenLDAP tutorial to learn how to create an AuthenticationClass for an LDAP server.

With an AuthenticationClass ready, PASSWORD authentication using LDAP is done by referencing the LDAP AuthenticationClass:

apiVersion: trino.stackable.tech/v1alpha1
kind: TrinoCluster
metadata:
  name: trino-with-ldap
spec:
  clusterConfig:
    authentication:
      - authenticationClass: my-ldap

In the Trino CLI and web interface, LDAP users can now be used to log in.

Authorization

In order to authorize Trino via OPA, a ConfigMap containing a rego rule package for Trino has to be applied and referenced in the TrinoCluster resource. The following example is an all-access Rego rule for testing with the user admin. Do not use it in production!

Due to changes in the Trino OPA authorizer, rego rules differ between version 414 and 428. The OPA authorizer will become part of the Trino package once this pull request is merged. The stackable Trino version 428 already uses that new OPA authorizer and utilizes the batch mode (documented in the readme file here) to avoid multiple queries to OPA. This is under active development and is not stable yet!

Rego for Trino version 414

---
apiVersion: v1
kind: ConfigMap
metadata:
  name: opa-bundle-trino
  labels:
    opa.stackable.tech/bundle: "true"
data:
  trino.rego: |
    package trino

    import future.keywords.in

    default allow = false

    allow {
      is_admin
    }

    is_admin() {
      input.context.identity.user == "admin"
    }

Rego for Trino version 428

---
apiVersion: v1
kind: ConfigMap
metadata:
  name: opa-bundle-trino
  labels:
    opa.stackable.tech/bundle: "true"
data:
  trino.rego: |
    package trino

    import future.keywords.in

    default allow = false

    # Allow non-batched access
    allow {
      is_admin
    }
    # Allow batched access
    extended[i] {
      some i
      input.action.filterResources[i]
      is_admin
    }
    # Corner case: filtering columns is done with a single table item, and many columns inside
    extended[i] {
      some i
      input.action.operation == "FilterColumns"
      count(input.action.filterResources) == 1
      input.action.filterResources[0].table.columns[i]
      is_admin
    }

    is_admin() {
      input.context.identity.user == "admin"
    }

Reference the package in the Trino cluster:

...
spec:
  clusterConfig:
    authorization:
      opa:
        configMapName: opa  (1)
        package: trino      (2)
...
1 The name of the OpaCluster
2 The name of the package defined in the rego rule ConfigMap

Define a secure cluster

For secure connections the following steps must be taken:

  1. Enable authentication

  2. Enable TLS between the clients and coordinator

  3. Enable internal TLS for communication between coordinators and workers

Via authentication

If authentication is enabled, TLS for the coordinator as well as a shared secret for internal communications (this is base64 and not encrypted) must be configured.

Securing the Trino cluster will disable all HTTP ports and disable the web interface on the HTTP port as well. In the definition below the authentication is directed to use the trino-users secret and TLS communication will use a certificate signed by the Secret Operator (indicated by autoTls).

---
apiVersion: trino.stackable.tech/v1alpha1
kind: TrinoCatalog
metadata:
  name: hive
  labels:
    trino: simple-trino
spec:
  connector:
    hive:
      metastore:
        configMap: simple-hive-derby
---
apiVersion: trino.stackable.tech/v1alpha1
kind: TrinoCluster
metadata:
  name: simple-trino
spec:
  image:
    productVersion: "428"
  clusterConfig:
    tls:
      serverSecretClass: trino-tls (1)
    authentication:
      - authenticationClass: trino-users (3)
    catalogLabelSelector:
      matchLabels:
        trino: simple-trino (5)
  coordinators:
    roleGroups:
      default:
        replicas: 1
  workers:
    roleGroups:
      default:
        replicas: 1
---
apiVersion: secrets.stackable.tech/v1alpha1
kind: SecretClass
metadata:
  name: trino-tls (1)
spec:
  backend:
    autoTls: (6)
      ca:
        secret:
          name: secret-provisioner-trino-tls-ca (2)
          namespace: default
        autoGenerate: true
---
apiVersion: authentication.stackable.tech/v1alpha1
kind: AuthenticationClass
metadata:
  name: trino-users (3)
spec:
  provider:
    static:
      userCredentialsSecret:
        name: trino-users (4)
---
apiVersion: v1
kind: Secret
metadata:
  name: trino-users (4)
type: kubernetes.io/opaque
stringData:
  admin: admin
---
apiVersion: hive.stackable.tech/v1alpha1
kind: HiveCluster
metadata:
  name: simple-hive-derby
spec:
  image:
    productVersion: 3.1.3
  clusterConfig:
    database:
      connString: jdbc:derby:;databaseName=/tmp/metastore_db;create=true
      user: APP
      password: mine
      dbType: derby
  metastore:
    roleGroups:
      default:
        replicas: 1
1 The name of (and reference to) the SecretClass
2 The name of (and reference to) the Secret
3 The AuthenticationClass for file based user control
4 The Secret containing user and password combinations in plaintext
5 TrinoCatalog reference
6 TLS mechanism

The CLI now requires that a path to the keystore and a password be provided:

./trino.jar --debug --server https://172.18.0.3:31748
--user=admin --keystore-path=<path-to-keystore.p12> --keystore-password=<password>

Via TLS only

This will disable the HTTP port and UI access and encrypt client-server communications.

---
apiVersion: trino.stackable.tech/v1alpha1
kind: TrinoCatalog
metadata:
  name: hive
  labels:
    trino: simple-trino
spec:
  connector:
    hive:
      metastore:
        configMap: simple-hive-derby
---
apiVersion: trino.stackable.tech/v1alpha1
kind: TrinoCluster
metadata:
  name: simple-trino
spec:
  image:
    productVersion: "428"
  clusterConfig:
    tls:
      serverSecretClass: trino-tls (1)
    catalogLabelSelector:
      matchLabels:
        trino: simple-trino (2)
  coordinators:
    roleGroups:
      default:
        replicas: 1
  workers:
    roleGroups:
      default:
        replicas: 1
---
apiVersion: secrets.stackable.tech/v1alpha1
kind: SecretClass
metadata:
  name: trino-tls (1)
spec:
  backend:
    autoTls: (3)
      ca:
        secret:
          name: secret-provisioner-trino-tls-ca
          namespace: default
        autoGenerate: true
---
apiVersion: hive.stackable.tech/v1alpha1
kind: HiveCluster
metadata:
  name: simple-hive-derby
spec:
  image:
    productVersion: 3.1.3
  clusterConfig:
    database:
      connString: jdbc:derby:;databaseName=/tmp/metastore_db;create=true
      user: APP
      password: mine
      dbType: derby
  metastore:
    roleGroups:
      default:
        replicas: 1
1 The name of (and reference to) the SecretClass
2 TrinoCatalog reference
3 TLS mechanism

CLI callout:

./trino.jar --debug --server https://172.18.0.3:31748 --keystore-path=<path-to-keystore.p12> --keystore-password=<password>

Via internal TLS

Internal TLS is for encrypted and authenticated communications between coordinators and workers. Since this applies to all the data send and processed between the processes, this may reduce the performance significantly.

---
apiVersion: trino.stackable.tech/v1alpha1
kind: TrinoCatalog
metadata:
  name: hive
  labels:
    trino: simple-trino
spec:
  connector:
    hive:
      metastore:
        configMap: simple-hive-derby
---
apiVersion: trino.stackable.tech/v1alpha1
kind: TrinoCluster
metadata:
  name: simple-trino
spec:
  image:
    productVersion: "428"
  clusterConfig:
    tls:
      internalSecretClass: trino-internal-tls (1)
    authentication:
      - authenticationClass: trino-users (3)
    catalogLabelSelector:
      matchLabels:
        trino: simple-trino
  coordinators:
    roleGroups:
      default:
        replicas: 1
  workers:
    roleGroups:
      default:
        replicas: 1
---
apiVersion: secrets.stackable.tech/v1alpha1
kind: SecretClass
metadata:
  name: trino-internal-tls (1)
spec:
  backend:
    autoTls: (5)
      ca:
        secret:
          name: secret-provisioner-trino-internal-tls-ca (2)
          namespace: default
        autoGenerate: true
---
apiVersion: authentication.stackable.tech/v1alpha1
kind: AuthenticationClass
metadata:
  name: trino-users (3)
spec:
  provider:
    static:
      userCredentialsSecret:
        name: trino-users (4)
---
apiVersion: v1
kind: Secret
metadata:
  name: trino-users (4)
type: kubernetes.io/opaque
stringData:
  admin: admin
---
apiVersion: hive.stackable.tech/v1alpha1
kind: HiveCluster
metadata:
  name: simple-hive-derby
spec:
  image:
    productVersion: 3.1.3
  clusterConfig:
    database:
      connString: jdbc:derby:;databaseName=/tmp/metastore_db;create=true
      user: APP
      password: mine
      dbType: derby
  metastore:
    roleGroups:
      default:
        replicas: 1
1 The name of (and reference to) the SecretClass
2 The name of (and reference to) the Secret
3 The AuthenticationClass for file based user control
4 The Secret containing user and password combinations in plaintext
5 TLS mechanism

Since Trino has internal and external communications running over a single port, this will enable the HTTPS port but not expose it. Cluster access is only possible via HTTP.

./trino.jar --debug --server http://172.18.0.3:31748 --user=admin