# Kerberos authentication#

Trino can be configured to enable Kerberos authentication over HTTPS for clients, such as the Trino CLI, or the JDBC and ODBC drivers.

To enable Kerberos authentication for Trino, configuration changes are made on the Trino coordinator. No changes are required to the worker configuration. The worker nodes continue to connect to the coordinator over unauthenticated HTTP. However, if you want to secure the communication between Trino nodes with SSL/TLS, configure Secure internal communication.

## Environment configuration#

### Kerberos services#

You will need a Kerberos KDC running on a node that the Trino coordinator can reach over the network. The KDC is responsible for authenticating principals and issuing session keys that can be used with Kerberos-enabled services. KDCs typically run on port 88, which is the IANA-assigned port for Kerberos.

### MIT Kerberos configuration#

Kerberos needs to be configured on the Trino coordinator. At a minimum, there needs to be a kdc entry in the [realms] section of the /etc/krb5.conf file. You may also want to include an admin_server entry and ensure that the Trino coordinator can reach the Kerberos admin server on port 749.

[realms]
TRINO.EXAMPLE.COM = {
kdc = kdc.example.com
}

[domain_realm]
.trino.example.com = TRINO.EXAMPLE.COM
trino.example.com = TRINO.EXAMPLE.COM


The complete documentation for krb5.conf is hosted by the MIT Kerberos Project. If you are using a different implementation of the Kerberos protocol, you will need to adapt the configuration to your environment.

### Kerberos principals and keytab files#

The Trino coordinator needs a Kerberos principal, as do users who are going to connect to the Trino coordinator. You need to create these users in Kerberos using kadmin.

In addition, the Trino coordinator needs a keytab file. After you create the principal, you can create the keytab file using kadmin

kadmin
> ktadd -k /etc/trino/trino.keytab [email protected]
> ktadd -k /etc/trino/trino.keytab trino/[email protected]


Note

Running ktadd randomizes the principal’s keys. If you have just created the principal, this does not matter. If the principal already exists, and if existing users or services rely on being able to authenticate using a password or a keytab, use the -norandkey option to ktadd.

### Configuration for TLS#

When using Kerberos authentication, access to the Trino coordinator must be through HTTPS and TLS.

## System access control plugin#

A Trino coordinator with Kerberos enabled probably needs a System access control plugin to achieve the desired level of security.

## Trino coordinator node configuration#

You must make the above changes to the environment prior to configuring the Trino coordinator to use Kerberos authentication and HTTPS. After making the following environment changes, you can make the changes to the Trino configuration files.

### config.properties#

Kerberos authentication is configured in the coordinator node’s config.properties file. The entries that need to be added are listed below.

http-server.authentication.type=KERBEROS

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

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

http-server.https.keystore.path=/etc/trino/keystore.jks



Property

Description

http-server.authentication.type

Authentication type for the Trino coordinator. Must be set to KERBEROS.

http-server.authentication.krb5.service-name

The Kerberos service name for the Trino coordinator. Must match the Kerberos principal.

http-server.authentication.krb5.principal-hostname

The Kerberos hostname for the Trino coordinator. Must match the Kerberos principal. This parameter is optional. If included, Trino uses this value in the host part of the Kerberos principal instead of the machine’s hostname.

http-server.authentication.krb5.keytab

The location of the keytab that can be used to authenticate the Kerberos principal.

http.authentication.krb5.config

The location of the Kerberos configuration file.

http-server.https.enabled

Enables HTTPS access for the Trino coordinator. Should be set to true.

http-server.https.port

HTTPS server port.

http-server.https.keystore.path

The location of the Java Keystore file that is used to secure TLS.

http-server.https.keystore.key

The password for the keystore. This must match the password you specified when creating the keystore.

http-server.authentication.krb5.user-mapping.pattern

Regex to match against user. If matched, user will be replaced with first regex group. If not matched, authentication is denied. Default is (.*).

http-server.authentication.krb5.user-mapping.file

File containing rules for mapping user. See User mapping for more information.

node.internal-address-source

Kerberos is typically sensitive to DNS names. Setting this property to use FQDN ensures correct operation and usage of valid DNS host names.

Note

Monitor the CPU usage on the Trino coordinator after enabling HTTPS. Java prefers the more CPU-intensive cipher suites, if you allow it to choose from a big list. If the CPU usage is unacceptably high after enabling HTTPS, you can configure Java to use specific cipher suites by setting the http-server.https.included-cipher property to only allow cheap ciphers. Non forward secrecy (FS) ciphers are disabled by default. As a result, if you want to choose non FS ciphers, you need to set the http-server.https.excluded-cipher property to an empty list in order to override the default exclusions.

http-server.https.included-cipher=TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256
http-server.https.excluded-cipher=


The Java documentation lists the supported cipher suites.

### access-controls.properties#

At a minimum, an access-control.properties file must contain an access-control.name property. All other configuration is specific for the implementation being configured. See System access control for details.

## User mapping#

After authenticating with Kerberos, the Trino server receives the user’s principal which is typically similar to an email address. For example, when alice logs in Trino might receive [email protected]. By default, Trino will use the full Kerberos principal name, but this can be mapped to a shorter name using a user-mapping pattern. For simple mapping rules, the http-server.authentication.krb5.user-mapping.pattern configuration property can be set to a Java regular expression, and Trino will use the value of the first matcher group. If the regular expression does not match, the authentication is denied. For more complex user-mapping rules, see User mapping.

## Troubleshooting#

Getting Kerberos authentication working can be challenging. You can independently verify some of the configuration outside of Trino, to help narrow your focus when trying to solve a problem.

### Kerberos verification#

Ensure that you can connect to the KDC from the Trino coordinator using telnet.

$telnet kdc.example.com 88  Verify that the keytab file can be used to successfully obtain a ticket using kinit and klist $ kinit -kt /etc/trino/trino.keytab [email protected]
\$ klist


### Java keystore file verification#

Verify the password for a keystore file and view its contents using Inspect and validate keystore

You can enable additional Kerberos debugging information for the Trino coordinator process by adding the following lines to the Trino jvm.config file

-Dsun.security.krb5.debug=true
-Dlog.enable-console=true


-Dsun.security.krb5.debug=true enables Kerberos debugging output from the JRE Kerberos libraries. The debugging output goes to stdout, which Trino redirects to the logging system. -Dlog.enable-console=true enables output to stdout to appear in the logs.

The amount and usefulness of the information the Kerberos debugging output sends to the logs varies depending on where the authentication is failing. Exception messages and stack traces can provide useful clues about the nature of the problem.