I’ve recently been working at a client who wanted to look at centralizing their server logs (something I’d strongly recommend to anyone with more than a couple of servers). After looking at various options, we decided to go with the ELK (Elasticsearch, Logstash, Kibana) stack using Kibana4.

However, giving public access to logs isn’t the best idea in terms of security, so we needed to ensure that only appropriate people could access the data. When we’d looked at Kibana3, we’d simply been able to place an .htaccess file to set up authentication, but with Kibana4 this wasn’t possible.

Kibana4 is an application which is accessed over port 5160 (it’s actually a node.js package fronting an html/js site). What we were able to do is set up Apache running over port 80 (in production, we’ll be moving this behind SSL to encrypt network traffic but the example is still useful) and have it act as a reverse proxy to control traffic to Kibana via port 5160 as shown below:



 To achieve this, we used the following Apache2 config file:

 lines 7-12 are the directives you’d typically use to setup Apache authentication in a standard configuration; in this case, we just display a login prompt and authenticate the username and password against the .htpasswd  file in /var/www/manager  (remember to create the file using htpasswd) but in our production setup we’re using ldap to authenticate an Active Directory setup.

The ProxyPass  directive specifies what we’ll connect to as the backend; in this case anything below / (i.e. everything) will be passed through to port 5601 – our Kibana app.  ProxyPassReverse  modifies the headers that come back from the Kibana server to appear as if they’re coming from our Apache setup.

This is all using the mod_proxy module in Apache, which has a number of configuration options available around timeouts, connection pooling and so on – see http://httpd.apache.org/docs/2.2/mod/mod_proxy.html for more information.