Skip to content

Latest commit

 

History

History
224 lines (154 loc) · 9.56 KB

security.adoc

File metadata and controls

224 lines (154 loc) · 9.56 KB
Raw

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:

link:example$usage-guide/trino-file-auth-snippet.yaml[role=include]

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.

link:example$usage-guide/trino-file-auth-snippet.yaml[role=include]

Then reference the AuthenticationClass in your TrinoCluster definition:

link:example$usage-guide/trino-file-auth-snippet.yaml[role=include]

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.

Important
 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:

link:example$usage-guide/trino-ldap-auth-snippet.yaml[role=include]
Note
 You can follow the tutorials:authentication_with_openldap.adoc 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:

link:example$usage-guide/trino-ldap-auth-snippet.yaml[role=include]

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

OAUTH2

For using OAuth 2.0 authentication, TLS must be enabled and a Secret with the client credentials must be created:

link:example$usage-guide/trino-oidc-auth-snippet.yaml[role=include]

In the AuthenticationClass, an OpenID Connect (OIDC) provider can be specified:

link:example$usage-guide/trino-oidc-auth-snippet.yaml[role=include]
Note
 There is no generic support for OAuth 2, only OpenID Connect providers are supported.

The AuthenticationClass and the Secret with the client credentials must be referenced in the authentication section of the Trino cluster:

link:example$usage-guide/trino-oidc-auth-snippet.yaml[role=include]

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! The rego rules below are written using Rego V1 to be compatible with the OPA v1.0.0 release.

Note
 For a production setup you will use something much more granular. We provide a detailed set of rego rules in our integration tests. Details can be found below in the fine-granular rego rule section. 
link:example$usage-guide/opa-bundle-trino-cm.yaml[role=include]

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

Fine-granular rego rules

The operator repository contains a more production-ready set of rego-rules in this integration test. The test uses the following:

  • a set of rules provided by the Stackable Data Platform, together with associated test files that can be used directly with OPA (i.e. outside the integration test context)

    • these files can be tested by using the built-in policy test functionality and running opa test <path-to-trino-rule-folder> -b

  • a sample set of trino policies that represents what is to be provided by the user.

The rules implement system-level access control files (catalog-level access control is currently not provided). As illustrated by the integration test, both internal and customer-provided policies are deployed as ConfigMaps and there is thus no requirement for an extra configuration file in JSON to be created.

Please note these additional points:

  • Roles are not checked, only users and groups.

  • Principal rules are deprecated and not implemented.

  • The allow property of the catalog rules accepts only the new values all, read-only, and none, but not the legacy values true and false.

  • The Rego rules attempt to implement the Java implementation as close as possible although this is not always reflected clearly in the documentation (for instance the documentation states that "If neither impersonation nor principal rules are defined, impersonation is not allowed", although in practice users are always allowed to impersonate themselves).

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).

link:example$usage-guide/trino-secure-tls.yaml[role=include]

  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.

link:example$usage-guide/trino-secure-tls-only.yaml[role=include]

  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.

link:example$usage-guide/trino-secure-internal-tls.yaml[role=include]

  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