We have a lively internal discussion between dev/ops teams and we would like to have Searchguard team opinion. We currently use Elasticsearch 6.x.
Some developers want to expose Kibana dashboards to anonymous users on the Internet. These dashboards only access to some indices with public data.
They want to use a proxy webapp to perform the Searchguard authentification in order to use a Searchguard user that has only read-only access to some Kibana dashboards and Elasticsearch indices (that is configured in the Searchguard configuration).
However, the Elasticsearch cluster may also contains sensitive data in other indices.
Ops team fears about Internet anonymous users forging Kibana requests, especially using inline scripts, to gain access to sensitive indices or to execute arbitrary code on the Kibana / Elasticsearch servers.
Question:
Is this situation safe when using the Searchguard?
Is the ops team “paranoid”?
Hereby a schema to better understand the situation:
I think the best way to implement this scenario is to just use the anonymous auth feature of Search Guard and the Kibana plugin. IMHO there is no need to involve a proxy, if I understood your requirements correctly.
Search Guard supports anon authentication:
If a request does not carry any credentials, we assign it to a default anonymous user and backend role. You can then map this user / backend role to an SG role which has read access to your public indices only. The Kibana plugin supports anon auth as well:
Which means you can access Kibana without logging in. The requests are forwarded to ES/SG and get assigned to the anonymous user as outlined above. Regular users can hit the “login” button to perform a regular login.
You can also combine the anonymous authentication with the Kibana read-only mode:
If you assign the read-only mode to the anonymous role then the anonymous users will only see the “Dashboards” application.
Let me know if this helps!
···
On Tuesday, January 15, 2019 at 3:34:28 PM UTC+1, S. wrote:
Hi Searchguard team,
We have a lively internal discussion between dev/ops teams and we would like to have Searchguard team opinion. We currently use Elasticsearch 6.x.
Some developers want to expose Kibana dashboards to anonymous users on the Internet. These dashboards only access to some indices with public data.
They want to use a proxy webapp to perform the Searchguard authentification in order to use a Searchguard user that has only read-only access to some Kibana dashboards and Elasticsearch indices (that is configured in the Searchguard configuration).
However, the Elasticsearch cluster may also contains sensitive data in other indices.
Ops team fears about Internet anonymous users forging Kibana requests, especially using inline scripts, to gain access to sensitive indices or to execute arbitrary code on the Kibana / Elasticsearch servers.
Question:
Is this situation safe when using the Searchguard?
Is the ops team “paranoid”?
Hereby a schema to better understand the situation:
Thanks Jochen for all these details.
I understand the anonymous usage in an INTRANET network because you can be relatively confident with your users.
However, I was guessing about the couple “anonymous users + INTERNET access”, especially after reading this article because they say:
“Your first line of defense is to not expose Kibana directly to the internet.”
“The next step is to restrict access to known users.”
I thought that their recommendations were general and that is do not only apply for data hijacking.
So, if I correctly understand, you say that it’s safe to expose a Kibana instance on the INTERNET for ANONYMOUS users if:
Kibana and Elasticsearch are protected with Searchguard
Kibana is set to read-only mode for the define Searchguard role
This Searchguard role has only read-only access to public Elasticsearch indices
Is it correct?
···
Le mercredi 16 janvier 2019 12:37:47 UTC+1, Jochen Kressin a écrit :
Hi,
I think the best way to implement this scenario is to just use the anonymous auth feature of Search Guard and the Kibana plugin. IMHO there is no need to involve a proxy, if I understood your requirements correctly.
If a request does not carry any credentials, we assign it to a default anonymous user and backend role. You can then map this user / backend role to an SG role which has read access to your public indices only. The Kibana plugin supports anon auth as well:
Which means you can access Kibana without logging in. The requests are forwarded to ES/SG and get assigned to the anonymous user as outlined above. Regular users can hit the “login” button to perform a regular login.
You can also combine the anonymous authentication with the Kibana read-only mode:
If you assign the read-only mode to the anonymous role then the anonymous users will only see the “Dashboards” application.
Let me know if this helps!
On Tuesday, January 15, 2019 at 3:34:28 PM UTC+1, S. wrote:
Hi Searchguard team,
We have a lively internal discussion between dev/ops teams and we would like to have Searchguard team opinion. We currently use Elasticsearch 6.x.
Some developers want to expose Kibana dashboards to anonymous users on the Internet. These dashboards only access to some indices with public data.
They want to use a proxy webapp to perform the Searchguard authentification in order to use a Searchguard user that has only read-only access to some Kibana dashboards and Elasticsearch indices (that is configured in the Searchguard configuration).
However, the Elasticsearch cluster may also contains sensitive data in other indices.
Ops team fears about Internet anonymous users forging Kibana requests, especially using inline scripts, to gain access to sensitive indices or to execute arbitrary code on the Kibana / Elasticsearch servers.
Question:
Is this situation safe when using the Searchguard?
Is the ops team “paranoid”?
Hereby a schema to better understand the situation:
Well … exposing anything publicly on the internet always bears risks, so do not take me to court for my advice But having said that, the main point is that Search Guard enforces access control directly on the Elasticsearch level. Regardless of whether you connect to Elasticsearch with Kibana or curl or anything else, roles and permissions are always checked directly on ES. So by using the anon auth feature, you are “just” making sure that requests without any user credentials are assigned to a default Search Guard role (and do not get rejected immediately). After that, the access control of SG is the same high level, regardless whether the user has provided credentials or has been assigned to a SG role automatically by using the anon auth feature.
Regarding your questions, yes, I would say yes, but:
Kibana is set to read-only mode for the define Searchguard role
This is just icing on the cake. If the SG role that is being used for anon authentication just grants RO access to public indices, then this role is not able to make any changes to any ES index whatsoever. However, in Kibana these users would still see the “Management” navigation entry on the left side for example. If they would try to make any changes, they would get a security exception, since their SG role does not allow anything else than accessing public indices. This might be confusing for the users, so my suggestion was to use the read-only mode to limit the accessible Kibana areas to Dashboard only.
So from a security point of view 1) and 3) are sufficient, and 2) just contributes to the user experience.
Just as a side note, the article you quoted is from January 2017, where there have been a lot of ransomware attacks against unprotected ES clusters exposed on the internet. I guess that’s where the statements come from. You should of course never expose any ES/KI instance on the public internet without applying any sort of access control.
···
On Wednesday, January 16, 2019 at 2:29:45 PM UTC+1, S. wrote:
Thanks Jochen for all these details.
I understand the anonymous usage in an INTRANET network because you can be relatively confident with your users.
However, I was guessing about the couple “anonymous users + INTERNET access”, especially after reading this article because they say:
“Your first line of defense is to not expose Kibana directly to the internet.”
“The next step is to restrict access to known users.”
I thought that their recommendations were general and that is do not only apply for data hijacking.
So, if I correctly understand, you say that it’s safe to expose a Kibana instance on the INTERNET for ANONYMOUS users if:
Kibana and Elasticsearch are protected with Searchguard
Kibana is set to read-only mode for the define Searchguard role
This Searchguard role has only read-only access to public Elasticsearch indices
Is it correct?
Le mercredi 16 janvier 2019 12:37:47 UTC+1, Jochen Kressin a écrit :
Hi,
I think the best way to implement this scenario is to just use the anonymous auth feature of Search Guard and the Kibana plugin. IMHO there is no need to involve a proxy, if I understood your requirements correctly.
If a request does not carry any credentials, we assign it to a default anonymous user and backend role. You can then map this user / backend role to an SG role which has read access to your public indices only. The Kibana plugin supports anon auth as well:
Which means you can access Kibana without logging in. The requests are forwarded to ES/SG and get assigned to the anonymous user as outlined above. Regular users can hit the “login” button to perform a regular login.
You can also combine the anonymous authentication with the Kibana read-only mode:
If you assign the read-only mode to the anonymous role then the anonymous users will only see the “Dashboards” application.
Let me know if this helps!
On Tuesday, January 15, 2019 at 3:34:28 PM UTC+1, S. wrote:
Hi Searchguard team,
We have a lively internal discussion between dev/ops teams and we would like to have Searchguard team opinion. We currently use Elasticsearch 6.x.
Some developers want to expose Kibana dashboards to anonymous users on the Internet. These dashboards only access to some indices with public data.
They want to use a proxy webapp to perform the Searchguard authentification in order to use a Searchguard user that has only read-only access to some Kibana dashboards and Elasticsearch indices (that is configured in the Searchguard configuration).
However, the Elasticsearch cluster may also contains sensitive data in other indices.
Ops team fears about Internet anonymous users forging Kibana requests, especially using inline scripts, to gain access to sensitive indices or to execute arbitrary code on the Kibana / Elasticsearch servers.
Question:
Is this situation safe when using the Searchguard?
Is the ops team “paranoid”?
Hereby a schema to better understand the situation:
But having said that, the main point is that Search Guard enforces access control directly on the Elasticsearch level. Regardless of whether you connect to Elasticsearch with Kibana or curl or anything else, roles and permissions are always checked directly on ES. So by using the anon auth feature, you are “just” making sure that requests without any user credentials are assigned to a default Search Guard role (and do not get rejected immediately). After that, the access control of SG is the same high level, regardless whether the user has provided credentials or has been assigned to a SG role automatically by using the anon auth feature.