User Impersonation with X-Pack: Integrating Third Party Auth with Kibana

X-Pack Security is a fantastic way to secure your cluster, providing both authentication and authorization via RBAC. The authentication aspect is managed by services known as realms. Security ships with a handful of built-in realms that give you the flexibility to choose how you identify your users.

For many use cases, this works extremely well -- want to manage everything internally to Elasticsearch? The Native realm is your go-to. Already using LDAP within your organization? We’ve got you covered with the LDAP realm! There’s even an Active Directory realm if you’re a Windows shop.

But what if you want to use X-Pack Security with an authentication service not covered by one of these built-in realms? You have a couple options:

Use a reverse proxy to handle the third party authentication in conjunction with X-Pack Security’s impersonation feature and one or more of the built in realms.

Contact us to find out where your favorite authentication system (e.g. OAuth, SAML, Kerberos) is on our roadmap for direct support.

In this blog, I’ll walk you through a working example of the second option! We can use an authentication system like Google Sign-In to protect Kibana and translate my Google account name to a Native realm user in X-Pack Security; from there, we let Security handle authorization.

To do so, I’ll be using Bitly’s oauth2_proxy to handle the Google authentication layer and Nginx to pass the necessary* headers to Kibana. My overall architecture will look something like this:

*Important Note: The above configuration will only work in Kibana 5.x or later. This is because we’ve implemented an additional way to trigger a login event by passing basic auth headers (rather than entering credentials in the Security UI login screen). K 5.x also allows you to whitelist headers, which allows us to pass our special “run as” header.

Install Elasticsearch + Kibana (with X-Pack for both)

First we’ll need to install an instance of Elasticsearch and Kibana (5.2+ preferred). You can pick whichever installation method you’d like, but I personally find the zipped distributions to be easiest for testing.

If you’re following along with a Kibana version prior to 5.2, you’ll want to disable Monitoring as the necessary headers won’t be passed:

xpack.monitoring.enabled: false

Start Elasticsearch and Kibana

$ bin/elasticsearch
$ bin/kibana

Load Sample Data and Prepare Kibana

Our Elasticsearch instance is mostly empty at this point (there are some system indices for Monitoring and Security, but nothing really tangible to experiment with). Let’s grab some from the Kibana docs:

You can use the built-in elastic superuser account for the different API calls. I’d recommend loading all three data types (accounts, shakespeare, and logs) as it will help tie into the Security roles we’ll be defining later on.

Once the data has been ingested, log into Kibana and define your index patterns:

Create Our X-Pack Security Users and Roles

We’ll need to create a Native realm user to associate with our Google account. If my account was user1@elastic.co, I’d create a Native realm user called user1. Let’s create a user who can read the shakespeare and bank indices, but has no access to our logstash-* indices.

Try It Out

You may notice that the current signed in user is our “Service Account” (the full name of the nginx user we made earlier. Even though we’re “logged in” via the nginx user, every action we perform is really executed as user1 and encompasses all its authorization privileges defined in X-Pack Security. If we were to take a peek at the audit log, we can see this in action:

(note: In the above screenshot, I’m logging into Kibana directly as I hadn’t linked a Google account to a Native realm user with superuser privileges).

Now if we click Retry we’ll see we have access!

Much better :)

Closing Thoughts

Now you’ve seen a working example of a Kibana instance protected by SSO via Google Sign-In and X-Pack Security. I can seamlessly login to Kibana while logged into all my other Oauth2 protected services. However, this is merely for testing purposes and for a real production deployments, you’d also want to:

Harden the proxies

Implement TLS throughout

Define more restrictive users and roles where appropriate

X-Pack Security’s user impersonation feature is a powerful tool that provides a means to tie into many other authentication services that simply are not built into Security today. As long as you have some type of application layer that can handle the authentication and pass the necessary headers, you have a viable solution. User impersonation isn’t limited to just Native realm users, it also supports LDAP (and by extension, Active Directory)-- just imagine the possibilities!