Search Guard & Cloudflare

[NetwarSystem]

This question has a simple title, but I think I might be asking for help with a complex, multi-part problem.

All of my systems are Ubuntu, they are kept current re: Java openjdk-8-jre (now 8u191-b12-2ubuntu0.18.04.1), and we are happy with Elastic 6.5.4 and Search Guard 6-6.5.4-24.0. We are probably going to set up Elastic 7.x and make a transition once a couple of point upgrades are released.

Our topology is something I have not seen others mention here.

{Cloudflare CDN} → Apache reverse proxy → Kibana system → {Our Elasticsearch cloud}

We run a self signed Certificate Authority and this works fine on the public internet thanks to Cloudflare’s features. We qualified for the Search Guard academic license and we are just starting to get familiar with Tenants. The Apache reverse proxy is a legacy from when we just had Elasticsearch Community edition and we protected it with htpasswd. Both the proxy and the Kibana system have public IP addresses, we control the reverse DNS there, but we would never expose those addresses to the public; our system is used to examine online conflicts, and we have legitimate concerns regarding unwanted visitors. Cloudflare puts a stop to most of that, which is why we use it.

We service two different groups of researchers with the system. Both have the same requirements:

1. A couple of people handle the getting and cleaning of data, they have full access to the underlying system, and cross between the two groups.

2. Each group has at least one person in a managerial role, which means they have access to all of their tenants.

3. There are individuals who are involved in collection, they have a tenant they use (RW) and may be invited to see into others (RO).

4. We very much want to offer dashboards as embedded iframes. This is the part that is not obvious to me.

The Kibana system and the machines running Elasticsearch are in a stable configuration - by that I mean I could do a host certificate for the Kibana IP, but it isn’t clear that is the right way to do things.

I see various comments about using a reverse proxy for access and including needed headers, but these uniformly suggest Nginx rather than Apache. Is there some pressing reason to switch away from using Apache for this role? Is there a
complete configuration example out there somewhere?

I very much liked the demo setup for SG - would have given up on the system as too complex, had that not been available. I would like to see it extended such that there are some example users/roles in the standalone config, with pointers on how to separate the authentication & authorization, and I’m not the only one wrestling with how to do the proxy config.

I intend to forge ahead on this, and when it’s complete I’ll write a detailed post on what is required. I think there are some barriers to entry that are holding Search Guard back from broader adoption, which is a shame, because it’s a very nice system.

[jkressin]

Hi and thanks for your feedback,

I personally think the main disadvantage of Search Guard is the amount of features and the way the features can be combined. We are often asked for a (one) cookbook, but configuring SG for, say, Kerberos and LDAP is totally different from, say, using client certificate authentication or proxy authentication. At the moment we are planning to set up both a knowledgebase and cookbooks for the most common use cases. We hope that this will help getting SG up and running more quickly.

As to your questions (my answers are for SG6, we will improve the tenant handling with SG7):

The scenario with two different groups that have different levels of access to dashboards is quite common. What customers sometimes do to make the configuration and role definitions cleaner is to set up roles that grant access to indices on ES, and other roles that define the permissions to access tenants. You can then map the “index-roles” and the “tenant-roles” freely.

Note that with SG6 unfortunately it is not possible to use wildcards in tenant names. So if you want to grant a role access to all tenants, you need to list them all. This will likely change with SG7.

Chosing nginx over Apache in the docs and other articles is merely a personal preference. Any proxy that is able to add the user- and role header will do.

To help you with the configuration and to better understand your use case: Where does authentication and authorization take place?

• do you do that with Apache, means Apache forwards the already authenticated user and roles to KI/ES?
• or does Apache really just act as a proxy and auth/auth should be performed by Search Guard?

Plus, where do you store your users?

[NetwarSystem]

OK, I did find a config for Nginx, but this is not precisely what I need:

https://groups.google.com/forum/#!searchin/search-guard/nginx|sort:date/search-guard/fACcRC5yHvA/H9y93CMWBgAJ

When I get traffic from the proxy, I want the proxy itself to provide the authentication, because it’s just an iframe embed on a remote site, not one of our actual users. The ‘user’ here would be based on the domain name presented to the proxy with the request.

[NetwarSystem]

jkressin and I crossed on replies.

Right now our users are manually created in sg_internal_users.yml.

One of our clients has a Drupal site, the other has Wordpress. If we could sort out how to pass through credentials that would be nice. I would be excited if I could get that working by some time this summer - it’s not an immediate need.

[jkressin]

Got it, so the main issue is how to pass credentials for requests coming from Drupal / Wordpress. And those requests are being passed to Kibana via the Apache proxy, right?

If you use Basic Authentication as authentication type on Kibana then this should be fairly easy, and you actually do not need to set up proxy authentication (I hope I get your use case right):

• The requests from Wordpress are intercepted by Apache
• On Apache you have access to the domain name the request is coming from
• Depending on the domain name, you can add an HTTP Basic Authentication request header when forwarding the request to Kibana
• The Basic Auth header contains the (static) username and password base64 encoded
• When the request reaches Kibana, our plugin will detect that it already contains Basic Auth credentials
• It will then skip the login dialogue and pass the request to ES/SG, including the credentials
• You then just need to configure the user in internal_users.yml and assign one or more roles to it in the roles_mapping.yml file
• If the assigned Search Guard role(s) have the correct permissions set, for both the data (indices) and the tenants, the dashboard in the iframe should work out of the box

Is that what you are looking for? There are other ways, for example using anonymous authentication. But if the scenario above matches your use case, this is probably the easiest setup, because it basically does not require anything special apart from what you are already using.