NOTE This is a continuation of my series on the deployment of Apache Drill on Azure. That said, there is nothing in this post that is specific to an Azure deployment though I will assume you are familiar with my topology when I reference servers by name.
In a previous post, I walked through the steps for enabling basic user authentication for a Drill cluster. To connect to Drill, users must now provide a valid user name and password combination, making the environment a bit more secure. That said, the Drill Web Console is collecting user name and password information over HTTP, meaning that someone could easily intercept a login attempt over the wire and see the credentials being passed to it.
In order to make the Web Console just a bit more secure, I will implement SSL encryption using a self-signed certificate. If this were a production instance with truly sensitive data, I might go a step further an make use of a certificate from a trusted authority as documented here, but a self-signed cert is good enough for my demonstration purposes.
The step to perform for this is pretty straightforward even if the documentation is a little cryptic. I need to add the http.ssl_enabled key with a value of true to the drill-override.conf file on each of my Drill servers:
sudo vi /drill/current/conf/drill-override.conf
Once open in vi, the contents may be modified as highlighted in red:
packages += “org.apache.drill.exec.rpc.user.security”,
pam_profiles: [ “sudo”, “myusername” ]
Now I restart my Drill servers and connect to the Web Console to verify that HTTPS is now being employed.
NOTE If you setup an environment similar to the one documented here, you will need to modify drill-web inbound rule on the Azure Load Balancer to direct traffic on port 443 to port 8047. In addition, Azure Load Balancer probes only support HTTP and TCP. You will need to change the probe to employ TCP on port 8047.