Password and LDAP Authentication

Password authentication is an authentication method you probably use every day. By providing a username and password to the system, you are proving who you say you are by providing something you know. Trino supports this basic form of authentication by using its password authenticator. The password authenticator receives the username and password credentials from the client, validates them, and creates a principal. The password authenticator is designed to support custom password authenticators deployed as a plug-in in Trino.

Currently, password authentication supported by Trino uses the LDAP authenticator, and therefore an LDAP service.

LDAP stands for Lightweight Directory Access Protocol, an industry-standard application protocol for accessing and managing information in a directory server. The data model in the directory server is a hierarchical data structure that stores identity information. We won’t elaborate on too many more details about what LDAP is or how it works. If you are interested in learning more, there is plenty of information available in books or on the web.

When using the LDAP authenticator, a user passes a username and password to the Trino coordinator. This can be done from the CLI, JDBC driver, or any other client that supports passing the username and password. The coordinator then validates these credentials with an external LDAP service and creates the principal from the username. You can see a visualization of this flow in Figure 10-2. To enable LDAP authentication with Trino, you need to add to the config.properties file on the Trino coordinator:

http-server.authentication.type=PASSWORD

By setting the authentication type to PASSWORD, we are telling the Trino coordinator to use the password authenticator to authenticate.

In addition, you need to configure the LDAP service with the additional file password-authenticator.properties in the etc directory:

password-authenticator.name=ldap
ldap.url=ldaps://ldap-server:636
ldap.user-bind-pattern=${USER}@example.com

Figure 10-2. LDAP authentication to Trino using an external LDAP service

The password-authenticator.name specifies to use the LDAP plug-in for the password authenticator. The following lines configure the LDAP server URL and the pattern to locate the user record. The preceding bind pattern is an example usage with Active Directory. Other LDAP servers or configurations define a user ID (UID):

ldap.user-bind-pattern=uid=${USER},OU=people,DC=example,DC=com

In LDAP, several operation types interact with the LDAP directory, such as add, delete, modify, search, and bind. Bind is the operation used to authenticate clients to the directory server and is what Trino uses for supporting LDAP authentication. In order to bind, you need to supply identification and proof of identity such as a password. LDAP allows for different types of authentication, but user identity, also known as the distinguished name, and password is the main supported method by Trino for LDAP authentication.

A secondary method, which was recently added, is to authenticate and authorize with a LDAP service user. Check the Trino documentation for configuration tips.

Once the LDAP configuration is in place, you can test it with the Trino CLI:

trino --user matt --password

Specifying --password causes the CLI to prompt you to enter the password. When you configure the LDAP password authenticator, you have set the user bind pattern.

When the username and password are passed to the Trino coordinator from the client, the CLI in our example, Trino replaces this username in the bind pattern and sends this as a security principal, and the password as the security credentials, as part of the bind request for LDAP. In our example, the principal used to match the distinguished name in the directory structure is uid=matt,OU=people,DC=example,DC=com. Each entry in the LDAP directory may consist of multiple attributes. One such attribute is userPassword, which the bind operation uses to match the password sent.

Trino can further restrict access based on group memberships. You learn more about the importance of groups in the following authorization sections. By using groups, you can assign privileges to a group, so the users in that group inherit all the privileges of that group rather than having to manage privileges individually. Say, for example, you want to allow only people in the engineering group to authenticate with Trino. In our example, we want users matt and maria to be able to authenticate to Trino, but not user jane.

To further restrict users based on group membership, Trino allows you to specify additional properties in the password-authenticator.properties file.

ldap.user-base-dn=OU=people,DC=example,DC=com

ldap.group-auth-pattern=(&(objectClass=inetOrgPerson)(uid=${USER})(memberof=
CN=developers,OU=groups,DC=example,DC=com))

In our example, the preceding filter restricts users from the base distinguished name and allows only users who belong to the developers group in LDAP. If user jane tries to authenticate, the bind operation succeeds since jane is a valid user, but the user is filtered out of the results because she does not belong to the developers group.

System Access Control

System access control enforces authorization at the global Trino level and allows you to configure access for catalogs and rules for the principals used.

Lower-level rights and restrictions within a catalog have to be configured with connector access control; see “Connector Access Control”.

As you learned in the authentication section, security principals are the entity used to authenticate to Trino. The principal may be an individual user or a service account. Trino also separates the principal for authentication from the user who is running queries. For example, multiple users may share a principal for authenticating, but run queries as themselves. By default, Trino allows any principal who can authenticate to run queries as anyone else:

$ trino --krb5-principal [email protected] --user bob

This is generally not what you would want to run in a real environment, since it potentially elevates the access granted to one user, bob, beyond his authorization. Changing this default behavior requires additional configuration. Trino supports a set of built-in system access control configurations.

By default, Trino allows any authenticated user to do anything. This is the least secure and not recommended when deploying in a production environment. While it is the default, you can set it explicitly by creating access-control.properties within the etc directory.

access-control.name=allow-all

Read-only authorization is slightly more secure in that it allows only any operation that is reading data or metadata. This includes SELECT queries, but not CREATE, INSERT, or DELETE queries:

access-control.name=read-only

To configure system access control beyond simple allow-all or read-only, you can use a file-based approach. This allows you to specify access control rules for catalog access by users and what users a principal can identify as. These rules are specified in a file that you maintain.

When using file-based system access control, all access to catalogs is denied unless there is a matching rule for a user that explicitly gives them permission. You can enable this in the access-control.properties file in the etc configuration directory:

access-control.name=file
security.config-file=etc/rules.json

The security.config-file property specifies the location of the file containing the rules. It must be a JSON file using the format detailed in the following code. Best practice is to keep it in the same directory as all other configuration files:

{
  "catalogs": [
    {
      "user": "admin",
      "catalog": "system",
      "allow": true
    },
    {
      "catalog": "hive",
      "allow": true
    },
    {
      "user": "alice",
      "catalog": "postgresql",
      "allow": true
    }
    {
      "catalog": "system",
      "allow": false
    }
  ]
}

Rules are examined in order, and the first rule that matches is used. In this example, the admin user is allowed access to the system catalog, whereas all other users are denied because of the last rule. We mentioned earlier that all catalog access is denied by default unless there is a matching rule. The exception is that all users have access to the system catalog by default.

The example file also grants access to the hive catalog for all users, but only the user alice is granted access to the postgresql catalog.

As we mentioned earlier, authenticated principal can run queries as any user by default. This is generally not desirable, as it allows users to potentially access data as someone else. If the connector has implemented a connector access control, it means that a user can authenticate with a principal and pretend to be another user to access data they should not have access to. Therefore, it is important to enforce an appropriate matching between the principal and the user running the queries.

Let’s say we want to set the username to that of the LDAP principal:

{
  "catalogs": [
    {
      "allow": "all"
    }
  ],
  "principals": [
    {
      "principal": "(.*)",
      "principal_to_user": "$1",
      "allow": "all"
    }
  ]
}

This can be further extended to enforce the user to use exactly their Kerberos principal name. In addition, we can match the username to a group principal that may be shared:

  "principals": [
    {
      "principal": "([^/]+)/?.*@example.com",
      "principal_to_user": "$1",
      "allow": "all"
    },
    {
      "principal": "[email protected]",
      "user": "alice|bob",
      "allow": "all"
    }
  ]

Therefore, if you want a different behavior, you must override the rule; in this case, the users bob and alice can use the principal [email protected] as well as their own principals, [email protected] and [email protected].

Encrypting Trino Client-to-Coordinator Communication

It’s important to secure the traffic between the client and Trino for two reasons. First, if you are using LDAP authentication, the password is in clear text. And with Kerberos authentication, the SPNEGO token can be intercepted as well. Additionally, any data returned from queries is in plain text.

Understanding the lower-level details of the TLS handshake for encryption algorithms is not crucial to understanding how Trino encrypts network traffic. But it is important to understand more about certificates, since you need to create and configure certificates for use by Trino. Figure 10-5 depicts communications between a client web browser and web server secured over HTTPS. This is exactly how HTTPS communication is used between the Trino coordinator and a Trino client such as the Trino Web UI, the Trino CLI, or the JDBC driver, displayed in Figure 10-6.

Figure 10-6. Secured communication over HTTP between Trino clients and the Trino coordinator

A TLS certificate relies on public-key (asymmetric) cryptography using key pairs:

• A public key, which is available to anyone

• A private key, which is kept private by the owner

Anyone can use the public key to encrypt messages that can be decrypted only by those who have the private key. Therefore, any message encrypted with the public key should be secret, as long as only the owner of the key pair does not share or have its private key stolen. A TLS certificate contains information such as the domain the certificate was issued for, the person or company it was issued to, the public key, and several other items. This information is then hashed and encrypted using a private key. The process of signing the certificate creates the signature to include in the certificate.

These certificates are often signed by a trusted certificate authority such as DigiCert or GlobalSign. These authorities verify that the person requesting a certificate to be issued is who they say they are and that they own the domain as stated in the certificate. The certificate is signed by the authority’s private key, for which their public keys are made widely available and typically installed by default on most operating systems and web browsers.

The process of signing the certificate is important during the TLS handshake to verify authenticity. The client uses the public key of the pair to decrypt the signature and compare to the content in the certificate to make sure it was not tampered with.

Now that you understand the basics of TLS, let’s look at how we can encrypt data between the Trino clients and coordinator. To enable HTTPS on the Trino coordinator, you need to set additional properties in the config.properties file (see Table 10-2).

Take, for example, the following lines to add to your config.properties:

http-server.https.enabled=true
http-server.https.port=8443
http-server.https.keystore.path=/etc/trino/trino_keystore.jks
http-server.https.keystore.key=slickpassword

Remember to restart the Trino coordinator after you update the properties file.

Creating Java Keystores and Java Truststores

The Java keytool, a command-line tool for creating and managing keystores and truststores, is available as part of any Java Development Kit (JDK) installation. Let’s go over a simple example for creating a Java keystore and truststore. For simplicity, we use self-signed certificates.

Let’s first create the keystore to be used by the Trino coordinator. The following keytool command creates a public/private key pair and wraps the public key in a certificate that is self-signed:

$ keytool -genkeypair 
    -alias trino_server 
    -dname CN=*.example.com 
    -validity 10000 -keyalg RSA -keysize 2048 
    -keystore keystore.jks 
    -keypass password
    -storepass password

The generated keystore.jks file needs to be used on the server and specified in the http-server.https.keystore.path property. Similar usage applies for the storepass password in the http-server.https.keystore.key property.

In this example, you are using a wildcard certificate. We specify the common name (CN) to be *.example.com. This certificate can be shared by all the nodes on the Trino cluster, assuming they use the same domain; this certificate works with coordinator.example.com, worker1.example.com, worker2.example.com, and so on. The disadvantage to this approach is that any node under the example.com domain can use the certificate.

You can limit the subdomains by using a subject alternative name (SubjectAltName), where you list the subdomains. This allows you to create a single certificate to be shared by a limited, specific list of hosts. An alternative approach is to create a certificate for each node, requiring you to explicitly define the full domain for each. This adds an administrative burden and makes it challenging when scaling a Trino cluster, as the new nodes require certificates bound to the full domain.

When connecting a client to the coordinator, the coordinator sends its certificate to the client to verify its authenticity. A truststore is used to verify the authenticity by containing the coordinator certificate if self-signed, or a certificate chain if signed by a CA. Later, we discuss how to use a certificate chain of a CA. Because the keystore also contains the certificate, you could simply copy the keystore to the client machine and use that as the truststore. However, that is not secure, as the keystore also contains the private key that we want to keep secret. To create a custom truststore, you need to export the certificate from the keystore and import it into a truststore.

First, on the coordinator where your keystore was created, you export the certificate:

$ keytool --exportcert 
    -alias trino_server 
    -file trino_server.cer 
    -keystore keystore.jks 
    -storepass password

This command creates a trino_server.cer certificate file. As a next step, you use that file to create the truststore:

$ keytool --importcert 
    -alias trino_server 
    -file trino_server.cer 
    -keystore truststore.jks 
    -storepass password

Since the certificate is self-signed, this keytool command prompts you to confirm that you want to trust this certificate. Simply type yes and the truststore.jks is created. Now you can safely distribute this truststore to any machine from which you use a client to connect the coordinator.

Now that we have the coordinator enabled with HTTPS using a keystore and we’ve created a truststore for the clients, we can securely connect to Trino such that the communication between the client and coordinator is encrypted. Here is an example using the Trino CLI:

$ trino --server https://trino-coordinator.example.com:8443 
      --truststore-path ~/truststore.jks 
      --truststore-password password

Encrypting Communication Within the Trino Cluster

Next let’s look at how to secure the communication between the workers, and the workers and the coordinator, all within the Trino cluster, by using HTTP over TLS again as shown in Figure 10-7.

While the client-to-coordinator communication may be over an untrusted network, the Trino cluster is generally deployed on a more secure network, making secured intercluster communication more optional. However, if you’re concerned about a malicious attacker being able to get onto the network of the cluster, communication can be encrypted.

As with securing client-to-coordinator communication, cluster internal communication also relies on the same keystore. This keystore you created on the coordinator must be distributed to all worker nodes.

Figure 10-7. Secured communication over HTTPS between nodes in the Trino cluster

The same method of performing the TLS handshake to establish trust between the client and server, and create an encrypted channel, works for the intercluster communication. Communication in the cluster is bidirectional, meaning a node may act as a client sending the HTTPS request to another node, or a node can act as a server when it receives the request and presents the certificate to the client for verification. Because each node can act as both client and server for different connections, it needs a keystore that contains both the private key and the public key wrapped in the certificate.

All nodes need to enable HTTPS in config.properties, including for internal communication:

http-server.https.enabled=true
http-server.https.port=8443

internal-communication.https.required=true
discovery.uri=https://coordinator.example.com:8443

internal-communication.https.keystore.path=/etc/trino/trino_keystore.jks
internal-communication.https.keystore.key=slickpassword

Remember to restart the workers after you update the properties file. Now you have entirely secured the internal and external communication and secured it against eavesdroppers on the network trying to intercept data from Trino.

Prerequisites

Kerberos needs to be configured on the Trino coordinator, which needs to be able to connect to the Kerberos key distribution center (KDC). The KDC is responsible for authenticating principals and issues session keys that can be used with Kerberos-enabled services. KDCs typically use TCP/IP port 88.

Using MIT Kerberos, you need to have a [realms] section in the /etc/krb5.conf configuration file.

Kerberos Client Authentication

To enable Kerberos authentication with Trino, you need to add details to the config.properties file on the Trino coordinator. You need to change the authentication type, configure the location of the keytab file, and specify the user name of the Kerberos service account to use:

http-server.authentication.type=KERBEROS
http.server.authentication.krb5.service-name=trino
http.server.authentication.krb5.keytab=/etc/trino/trino.keytab

No changes to the worker configuration are required. The worker nodes continue to connect to the coordinator over unauthenticated HTTP.

To connect to this kerberized Trino cluster, a user needs to set up their keytab file, their principal, and their krb5.conf configuration file on the client and then use the relevant parameters for the Trino CLI or the properties for a JDBC connection. You can find all the details including a small wrapper script in the Trino documentation.

Cluster Internal Kerberos

If you want to secure the cluster internal communication, the Kerberos authentication must be enabled on workers, and internal communication needs to be changed to use SSL/TLS; see “Encrypting Communication Within the Trino Cluster”. This requires specifying valid Kerberos credentials for the internal communication.

Trino itself, as well as any users connecting to Trino with Kerberos, need a Kerberos principal. You need to create these users in Kerberos by using kadmin. In addition, the Trino coordinator needs a keytab file.

When using Kerberos authentication, client access to the Trino coordinator should use HTTPS; see “Encrypting Trino Client-to-Coordinator Communication”.

You can optionally set the Kerberos hostname for the coordinator, if you want Trino to use this value in the host part of the Kerberos principal instead of the machine’s hostname. You can also specify an alternate location of the Kerberos configuration file krb5.conf, different from the default /etc/krb5.conf:

http.server.authentication.krb5.principal-hostname=trino.example.com
http.authentication.krb5.config=/etc/trino/krb5.conf

For securing cluster internal communication with Kerberos, you need to specify valid Kerberos credentials for the internal communication and enable it:

internal-communication.kerberos.enabled=true

Make sure that you’ve also set up Kerberos on the worker nodes. The Kerberos principal for internal communication is built from http.server.authentication​.krb5.service-name after appending it with the host name of the node where Trino is running and the default realm from the Kerberos configuration.

Hive Metastore Thrift Service Authentication

In a kerberized Hadoop cluster, Trino connects to the Hive metastore Thrift service by using Simple Authentication and Security Layer (SASL) and authenticates by using Kerberos. You can easily enable Kerberos authentication for the metastore service in your catalog properties file:

hive.metastore.authentication.type=KERBEROS
hive.metastore.service.principal=hive/[email protected]
hive.metastore.client.principal=[email protected]
hive.metastore.client.keytab=/etc/trino/hive.keytab

This setting activates the use of Kerberos for the authentication to HMS. It also configures the Kerberos principal and keytab file location that Trino uses when connecting to the metastore service. The keytab file must be distributed to every node in the cluster.

Trino connects as the Kerberos principal specified by the property hive.metastore.client.principal and authenticates this principal by using the keytab specified by the hive.metastore.client.keytab property. It verifies that the identity of the metastore matches hive.metastore.service.principal.