Bug 1328693

I'm not quite sure of the problem here, as you mentioned, elasticsearch by default is not accessable outside the localhost. This is because end users aren't supposed to be connecting to elasticsearch directly, they should be connecting through kibana only (and fluentd will input the data). If people wish to enable security, they should do it at the kibana layer, not the elasticsearch layer.

As mentioned in that link you have, elasticsearch itself has no security, this is by design, as security introduces performance problems and elasticsearch maintains to be highly performant. I do not recommend doing the instructions in that link, but instead exploring options for securing kibana.

Regards,

Graeme

Perfect, Graeme, thanks for looking at it. Was talking to other security folks who said that saying the obvious (don't open up access to db) is sometimes a good thing. Docs, could you perhaps write a security note that mentions both keeping the default elasticsearch restrictions and securing Kibana?

Hi Summer,

Thank you for raising this bug. We have noted the comments from Graeme as well, and will add a note to the documentation to provide some clarification.

Kind regards,

Andrew

Assigning to Radek for review.

Radek - could you reach out to Summer for review of the changes when ready?

Summer / Graeme,

I have an short note ready that will instruct users to keep the ports used by Elasticsearch protected; however, I'd appreciate hearing your opinion on this:

Would it be appropriate to describe https://www.elastic.co/products/shield as a mechanism for securing and restricting access to Kibana? This looks like the most comprehensive solution, but it's also very complex, so it might be overkill. And most importantly, the software must be downloaded and installed as a plug-in from upstream.

The blog post mentioned in comment 0 shows how to use nginx with HTTP auth, but I'm afraid we only have nginx in SCL, which means users would have to enable another repo and deal with SCL configuration. Would using "native" HTTP auth in Apache be sensible? Or do you guys have any other suggestions?

I'd recommend getting in touch with the GSS folk to see what is supported specifically for the OpTools. (Can we at least mention Nginx as an option?) Without RH support, I would just say that it can be done (and should be if users are going to access) without mentioning 'how' specifics.

Just to clarify here, if all you want to do is secure kibana, there is no need for elasticsearch shield nor nginx. This can be done with plain old apache security mechanisms. Because we don't ship or support shield or nginx as part of RHOS, this is the only mechanism we should be discussing here.

The information I received from various parties indicates that using nginx and managing Kibana users via htpasswd/htaccess is the preferred way. I agree that the traditional security mechanisms in Apache are sufficient for this, so let's document the way they can be used to secure Kibana.

Definitely want the product devs to do your tech review, Radek; Graeme?

Filed bug 1337486 to track the advanced configuration and copied the configuration that was discussed by email. For now, I suggest we put the following text into the documentation:

...
11. Open the firewall on the system to allow connections to Fluentd, Elasticsearch, and httpd:

# firewall-cmd --zone=public --add-port=4000/tcp --permanent
# firewall-cmd --zone=public --add-port=9200/tcp --permanent
# firewall-cmd --zone=public --add-service=http --permanent
# firewall-cmd --reload

Important

The information provided by Kibana and Elasticsearch is available to anyone without any authentication. To restrict access to these services, ensure that the system or the open TCP ports (80, 4000, and 9200) are only accessible from trusted hosts. 
...

Sound sensible?

Radek, looks good from a 'be warned' standpoint, thanks.

Thanks, Summer. I've republished the guide with this (temporary) change. As you might have seen in bug 1337486, the actual security guidance is likely to be added soon now.