How does Presto work with LDAP?

LDAP stands for Lightweight Directory Access Protocol and is 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 on what LDAP is or how it works. If you are interested in learning more there is plenty of information in books or on the web such as https://ldap.com. Let’s take a look at an example directory structure and how Presto can use LDAP to authenticate.

Figure 11-1. Example LDAP Directory Structure storing entries of users.

Given the directory, let’s say we want to authenticate user matt using the Presto CLI.

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

In LDAP, there are several operation types to 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 what Presto uses for supporting LDAP authentication. In order to bind, you need to supply and identify 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 only supported by Presto for LDAP authentication.

When the user name is password to the Presto coordinator from the client, the CLI in our example, Presto will replace this user name in the bind pattern and send this as a security principal and the password as the security credentials as part of the bind request for LDAP. In our example, this principal uses to match the distinguished name in the directory structure is uid=matt,OU=people,DC=prestosql,DC=io. Each entry in the LDAP directory may consist of a number of attributes. One such attribute is userPassword for which the bind operation uses to match the password sent.

Figure 11-2. LDAP Authentication using the bind operator for an external LDAP service

Presto can also further restrict access based on group memberships. We will learn more about the importance of groups in the authorization sections. But 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 only allow people in the engineering group authenticate with Presto. In our example, we want users matt and martin to be able to authenticate to Presto, but not user justin.

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

Taking our example, the above filter will restrict users from the base distinguished name that belongs to the developers group in LDAP. If user justin tries to authenticate, the bind will succeed since justin is a valid user (assuming he entered his password), but will be further filtered out because he does not belong to the developers group.

Creating Java Keystore Java Truststore

The Java keytool² is a command line tool for creating and managing keystores and truststores. Let’s go over a simple example for creating a Java keystore and truststore. These commands are included in the accompanying Git repository we’ve created for the book. For simplicity, we will use self-signed certificates. But on the Git repository we also provide examples for simulating a CA to demonstrate how the certificate chain works.

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

The keystore.jks generate is the one you want to specify in the property. The password is the one you want to specify in the property. In this example we’re using what is referred to as a wildcard certificate. We specify the Common Name (CN) to be *.example.com. This certificate can be shared by all the nodes on the Presto cluster assuming they belong to the same domain. This certificate would work with coordinator.example.com, worker1.example.com, worker2.example.com, etc. The disadvantage to this approach is any node under the example.com domain can use the certificate. You could 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 coordinator.example.com, worker1.example.com, worker2.example.com, etc. 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 but makes it challenging when scaling a Presto cluster as the new nodes will require certificates bound to the full domain.

For simplicity, we’re using a self-signed certificate for the Java keystore. When connecting a Presto client to the Presto coordinator, the Presto coordinator will send it’s certificate for the client to verify its authenticity. A truststore is used to verify the authenticity by containing the Presto coordinator certificate if self signed, or a certificate chain if signed by a CA. We’ll discuss later about 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 which was want to key secret. In order to create a custom trust store, we will export the certificate from the keystore and import into a trust store.

First on the coordinator where your keystore was created we will export the certificate.

This will create a file presto_server.cer. Next we will create the truststore using this certificate.

Since the certificate is self-signed, this keytool command will prompt you if you want to trust this certificate. We want to trust it so simply type yes and the truststore.jks is created. Now you can safely distribute this trust store to any machine you wish to connect the the Presto coordinator from a client.

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

Encrypting Inter Presto Cluster Communication

Next, let’s look at how to secure inter cluster communication. Inter cluster communication means that the communication between the Presto workers and Presto coordinator uses HTTP over TLS as we did with the client to Presto coordinator encryption. While the client to Presto coordinator communication may be over an untrusted network, the internal Presto cluster is generally deployed on a more secure network making secured inter cluster communication more optional. However if you’re concerned about a malicious being able to get on to the network of the Presto cluster, communication can be encrypted.

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

Figure 11-8. Secured communication over HTTP between the nodes in the Presto Cluster

The same method of performing the TLS handshake to establish trust between the client and server and create an encrypted channel works the same way for the inter cluster communication. Communication in the cluster is bi-directional 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 the node can act as both, it needs the keystore which contains both the private key and public key wrapped in the certificate.

As when we configured the coordinator for client to coordinator secured communication, the workers must also enable HTTPS. On the coordinator and each worker node, you need to add the following lines to add to your config.properties.

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

BEING IMPORTANT NOTE

Once you have everything working, it’s important to disable the HTTP enabled by setting http-server.http.enabled=false in the config.properties. Otherwise a user could still connect over HTTP.

END IMPORTANT NOTE

Certificate Authority vs. Self-Signed Certificates

When you try out Presto for the first time and work to get it configured securely, it’s easiest to use a self signed certificate. However, in practice it may not be allowed in your organization as they are much less secure and susceptible to attacks in certain situations. Therefore you may use a certificate that was digitally signed by a CA.

In this approach you still create a keystore as we discussed earlier. But you then create a Certificate Signing Request (CSR) to send the CA to be signed. The CA will verify you are who you say you are and issue you a certificate signed by them. The certificate is them imported into your keystore. This CA signed certificate is presented to the client instead of the original self-signed one.

The more interesting part is with the Java truststore. Java provides a default trust store which may contain the CA already. In which case the certificate presented to the client can be verified by the default truststore. Using the Java default truststore is something cumbersome and may not contain the CA. Or perhaps your organization has its own internal CA for issuing organizational certifications to employees and services. So if you’re using a CA, it’s still recommended to create your own truststore for Presto to use. However, you can import the CA certificate chain instead of the actual certificates being used for Presto. A certificate chain is a list of 2 or more TLS certificates where each certificate in the chain is signed by the next one in the chain. At the top of the chain is the root certificate and this is always self-signed by the CA itself. It is used to sign the downstream certificates known as intermediate certificates. When you are issued a certificate for Presot, it will be signed by an intermediate certificate which is the first one in the chain. The advantage to this is if there are multiple certificates for multiple Presto clusters or that certificates are reissued, you don’t need to reimport them into your truststore each time. It’s less often for the CA to reissue an intermediate or root certificate.

Figure 11-9. Presto using a certificate issued by a CA. The truststore only contains the intermediate and root certificates of the CA. The TLS certificate from the Presto coordinator is verified using this certificate chain in the client truststore

Let’s say you had your Presto certificate signed by a CA. In order for the Presto client to trust it, we need to create a trust store containing the intermediate and root certificates. As in the earlier example where we imported the Presto self-signed certificate, we will do the same to import the CA certificate chain.

Note that there may be more than a single intermediate certificate and we’re using a single one here for simplicity.

Certificate Authentication

One of the authentication methods in Presto is Certificate Authentication. As we learned in the encryption section, the communication between the client and Presto coordinator can be secured using TLS. As part of the TLS handshake, the server provides the client a certificate so that the client can authenticate the server is who they say that are. Mutual TLS is where the client as a part of the handshake provides a certificate to the server to be authenticated. The server will verify the certificate in the same way we have seen the client verify the certificate. The server will have a trust store that contains the CA chain or the self-signed certificate for verification.

Figure 11-10. Secured communication over HTTP between Presto Clients and the Presto Coordinator using mutual TLS

In order to configure the Presto coordinator for mutual TLS authentication, we need to add some additional properties in the config.properties file. We will add in bold the new properties we need to add.

http-server.http.enabled=false http-server.https.enabled=true http-server.https.port=8443 http-server.https.keystore.path=/etc/presto/presto_keystore.jks http-server.https.keystore.key=slickpassword http-server.https.truststore.path=/etc/presto/presto_truststore.jks http-server.https.truststore.key=slickpassword node.internal-address-source=FQDN internal-communication.https.required=true internal-communication.https.keystore.path=/etc/presto/presto_keystore.jks internal-communication.https.keystore.key=slickpassword http-server.authentication.type=CERTIFICATE

The property http-server.authentication indicates the type of authentication to use. In this case Presto is using certificate authentication. This will indicate to the Presto coordinate to use the full TLS handshake for mutual authentication. In particular, the server side, Presto coordinator, will send a certificate request message as part of the full TLS handshake to the client to provide the signed certificate for verification by the Presto coordinator. In addition, we configure the truststore on the coordinator in order to verify the certificate presented by the client. Let’s use our command to connect from the CLI to Presto.

$ ./presto-cli --server https://presto-coordinator.example.com:8443 --truststore-path ~/truststore.jks --truststore-password password --user matt

presto> select * from system.runtime.nodes; Error running command: Authentication failed: Unauthorized

You’ll find that authentication failed. This is because the client did not use the keystore that have the certificate to provide the client certificate to the Presto coordinator for mutual authentication. Let’s modify our command to include a keystore. Note that this keystore is different than the keystore on the Presto cluster. This keystore specifically contains the key pair for the client. Let’s first create our keystore on the client side.

$ keytool -genkeypair -alias presto_server -dname CN=matt -validity 10000 -keyalg RSA -keysize 2048 -keystore client-keystore.jks -keypass password -storepass password

In this example, you’ll see that we set the CN to user matt. In this case, it’s more than likely this is a self signed certificate or an organization has its own internal CA. Let’s specify the client keystore in the CLI command

$ ./presto-cli --server https://presto-coordinator.example.com:8443 --truststore-path ~/truststore.jks --truststore-password password --keystore-path ~/client-keystore.jks --keystore-password password --user matt

presto> select * from system.runtime.nodes; Query failed: Access Denied: Authenticated user AuthenticatedUser[username=CN=matt, principal=CN=matt] cannot become user matt

Now that we have authenticated, authorization is failing. Recall that authentication proves who you are where authorization controls what you can do. In the case of certificate authentication, Presto will extract the subject distinguished name from the X.509 certificate³. This value is used the principal to compare to the user name. Recall the user name is either specified exclitily such as using the --user option in the CLI. Or the CLI using the operating system user name implicitly. In this case the user matt was being compared to the distinguished common name in the certificate CN=matt. One workaround is to simply pass the option to the CLI --user CN=matt, but that it cumbersome. Let’s leverage the built in file-based System Access Control we learned earlier for some customization.

First we need to create a file in the Presto installation directly etc/access-control.properties on the Presto coordinator..

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

Next we need to create the rules.json file on the Presto coordinator as the path location specified in the access-control.properties file.

{ “catalogs”: [ { “allow”: true } ], “principals”: [ { “principal”: “CN=(.*)”, “principal_to_user”: “$1”, “allow”: true } ] }

In this example, we are matching a princical regex with a capturing group. We then use that capturing group to map the principal to user. In our example, the regex will match CN=matt where matt is part of the capturing group to map to the user. Once you create these files and restart the Presto coordinator both the certificate authentication and authorization of that subject principal to the user will work.

presto> select * from system.runtime.nodesG -[ RECORD 1 ]+-------------------------------------------------------- node_id | i-0779df73d79748087 http_uri | https://coordinator.example.com:8443 node_version | 312 coordinator | true state | active -[ RECORD 2 ]+-------------------------------------------------------- node_id | i-0d3fba6fcba08ddfe http_uri | https://worker-1.example.com:8443 node_version | 312 coordinator | false state | active

Hive Connector Authentication

Apache Hadoop comprises of many different components such as HDFS, NameNode, Zookeeper, HiveServer, Hive Metastore Service, YARN, and others. We learned earlier in this chapter about Presto’s integration with Kerberos as one of the options for client to Presto authentication. Hadoop has fairly standardized on Kerberos as the de facto authentication mechanism and any enterprise using Hadoop has secured it with Kerberos. This means that any software either internal Hadoop components or external to Hadoop need to be able to authenticate to Hadoop using Kerberos. The Presto Hive connector has Kerberos integration and when configuring the Hive connector to query data from HDFS in a secured Hadoop cluster, it must be configured. Recall from {Chapter X} on the Hive connector, that Hive is essentially 3 parts.

Hive runtime

Hive metastore

Hive warehouse table format on HDFS (or other distributed storage)

As we learned, the Hive connector is a bit of a misnomer because it does not use the Hive runtime. It replaces the Hive runtime in this stack but still leverages the Hive Metastore Service and knowledge of the Hive table format in order to query data directly on disk. In order for Presto to use those two, Presto needs to authenticate to the Hive Metastore Service and HDFS. The section will focus on the Presto specific integration points with Hadoop. For more information about security with Hive or Hadoop see Programming in Hive (O’Reilly) and Hadoop: The Definitive Guide (O’Reilly).