[Solved] Grant read access to any index and Kibana for sg_anonymous

[Tototrash]

Hello there,

First, let me thank you Floraguun for that amazing project by giving the opportunity for people to kinda secure their setup without having to pay ! :)

Then, I'm using the 6.1.2-21.0 SG plugin on a 6.1.2 setup and I'm facing 2 needs that I'm sure you'll tell me how to overcome them:

1. I would like to grant read-only access to any index in my ES for anonymous users: the builtin "sg_readall" role is exactly what I want for anonymous users. 

I tried different stuff that failed like : adding a "sg_anonymous_backendrole" role and copying/pasting sg_readall role declaration, adding a "sg_anonymous" role mapping and add sg_anonymous in "users" etc.

2. I would like anonymous users to access Kibana (with a read-only role from 1.) without having the SG authentication form being displayed, as by definition anonymous users don't need any credential and functionally speaking it is useless to tell them to use generic credentials such as "readall/readall" just to go through the authentication form.

As you might understand I want my ES data to be quite "open", but only in read :) (I'll be the only admin).

Could you guide me on how I can implement these functionnal needs ?

Best regards !

Thomas.

[Jochen Kressin]

So if I understand you correctly you want to assign anonymous users to the sg_readall role right?

You have to options. As per doc:

# If none can be found the user will be authenticated as an "anonymous" user. This user has always the username "sg_anonymous"

# and one role named "sg_anonymous_backendrole". 

anonymous users have a fixed username and backend role. You need to map either the username or the backend role in sg_roles_mapping to the sg_readall Search Guard role, e.g.

sg_readall:

  backendroles:

    - readall

    - sg_anonymous_backendrole

OR

sg_readall:

  users:

    - sg_anonymous

  backendroles:

    - readall

For 2, have you tried to deactivate the login form? In that case we simply pass all requests and HTTP headers from KI to ES, where authenication takes place. In kibana.yml set:

searchguard.basicauth.enabled: false

[Tototrash]

Thank you very much Jochen, both points are solved :

* I used the first solution for the first point 

* I used searchguard.basicauth.enabled for the second. In a near future, it would be nice to allow direct anonymous access to Kibana without auth form but still have the "Login" button on the bottom-left side for users that can authenticated (because today it's either anonymous only, authentication only)

Best regards !

[Jochen Kressin]

So please head over to the Kibana Plugin GitHub issue tracker and open a feature request:

https://github.com/floragunncom/search-guard-kibana-plugin/issues

I can't promise when we have time to work on this, but at least we can add it to the backlog. Also, we do appreciate contributions and pull requests ;)

[Jesus M. Gonzalez-Barahona]

I've used exactly this configuration, but I have observed something weird:

* When I launch Elasticsearch and Kibana from scratch, and I try to see the dashboard, I see:

-------------

Error: no permissions for [indices:data/write/update] and User [name=sg_anonymous, roles=[sg_anonymous_backendrole], requestedTenant=null]: [security_exception] no permissions for [indices:data/write/update] and User [name=sg_anonymous, roles=[sg_anonymous_backendrole], requestedTenant=null]
value/<@http://localhost:5601/bundles/kibana.bundle.js?v=16397:16:214022
processQueue@http://localhost:5601/bundles/commons.bundle.js?v=16397:35:132456
scheduleProcessQueue/<@http://localhost:5601/bundles/commons.bundle.js?v=16397:35:133349
$digest@http://localhost:5601/bundles/commons.bundle.js?v=16397:35:144239
$apply@http://localhost:5601/bundles/commons.bundle.js?v=16397:35:147007
done@http://localhost:5601/bundles/commons.bundle.js?v=16397:35:100015
completeRequest@http://localhost:5601/bundles/commons.bundle.js?v=16397:35:104697
createHttpBackend/</xhr.onload@http://localhost:5601/bundles/commons.bundle.js?v=16397:35:105435
----------

for each of the indexes in the dashboard.

But if I comment out the line I included in kibana.yml:

#searchguard.basicauth.enabled: false

and launch Kibana again, I get the login form, then I log in with admin/admin, and I see (as expected) the dashboard. The curious think is that now, if I logout, remove the above comment (leaving the line), and relaunch Kibana, now I can see the dashboard, with no error message. Now, everything works as expected.

Any clue about this?

Just in case it matters, I've observed that when I launch Kibana from the command line for the second time (with the line commented out), I get the following message after authenticating:

------------
request [12:19:52.824] [error][uncaught] { name: 'Error',
  message: '[index_not_found_exception] no such index, with { resource.type="index_expression" & resource.id="_searchguard" & index_uuid="_na_" & index="_searchguard" }',
  stack: '[index_not_found_exception] no such index, with { resource.type="index_expression" & resource.id="_searchguard" & index_uuid="_na_" & index="_searchguard" } :: {"path":"/_searchguard/api/permissionsinfo","query":{},"statusCode":404,"response":"{\\"error\\":{\\"root_cause\\":[{\\"type\\":\\"index_not_found_exception\\",\\"reason\\":\\"no such index\\",\\"resource.type\\":\\"index_expression\\",\\"resource.id\\":\\"_searchguard\\",\\"index_uuid\\":\\"_na_\\",\\"index\\":\\"_searchguard\\"}],\\"type\\":\\"index_not_found_exception\\",\\"reason\\":\\"no such index\\",\\"resource.type\\":\\"index_expression\\",\\"resource.id\\":\\"_searchguard\\",\\"index_uuid\\":\\"_na_\\",\\"index\\":\\"_searchguard\\"},\\"status\\":404}"}\n    at respond (/home/grimoirelab/kibiter-6.1.0-2-linux-x86_64/node_modules/elasticsearch/src/lib/transport.js:295:15)\n    at checkRespForFailure (/home/grimoirelab/kibiter-6.1.0-2-linux-x86_64/node_modules/elasticsearch/src/lib/transport.js:254:7)\n    at HttpConnector.<anonymous> (/home/grimoirelab/kibiter-6.1.0-2-linux-x86_64/node_modules/elasticsearch/src/lib/connectors/http.js:159:7)\n    at IncomingMessage.bound (/home/grimoirelab/kibiter-6.1.0-2-linux-x86_64/node_modules/elasticsearch/node_modules/lodash/dist/lodash.js:729:21)\n    at emitNone (events.js:91:20)\n    at IncomingMessage.emit (events.js:185:7)\n    at endReadableNT (_stream_readable.js:974:12)\n    at _combinedTickCallback (internal/process/next_tick.js:80:11)\n    at process._tickDomainCallback (internal/process/next_tick.js:128:9)' }
 error  [12:19:52.788]  [index_not_found_exception] no such index, with { resource.type="index_expression" & resource.id="_searchguard" & index_uuid="_na_" & index="_searchguard" } :: {"path":"/_searchguard/api/permissionsinfo","query":{},"statusCode":404,"response":"{\"error\":{\"root_cause\":[{\"type\":\"index_not_found_exception\",\"reason\":\"no such index\",\"resource.type\":\"index_expression\",\"resource.id\":\"_searchguard\",\"index_uuid\":\"_na_\",\"index\":\"_searchguard\"}],\"type\":\"index_not_found_exception\",\"reason\":\"no such index\",\"resource.type\":\"index_expression\",\"resource.id\":\"_searchguard\",\"index_uuid\":\"_na_\",\"index\":\"_searchguard\"},\"status\":404}"}
    at respond (/home/grimoirelab/kibiter-6.1.0-2-linux-x86_64/node_modules/elasticsearch/src/lib/transport.js:295:15)
    at checkRespForFailure (/home/grimoirelab/kibiter-6.1.0-2-linux-x86_64/node_modules/elasticsearch/src/lib/transport.js:254:7)
    at HttpConnector.<anonymous> (/home/grimoirelab/kibiter-6.1.0-2-linux-x86_64/node_modules/elasticsearch/src/lib/connectors/http.js:159:7)
    at IncomingMessage.bound (/home/grimoirelab/kibiter-6.1.0-2-linux-x86_64/node_modules/elasticsearch/node_modules/lodash/dist/lodash.js:729:21)
    at emitNone (events.js:91:20)
    at IncomingMessage.emit (events.js:185:7)
    at endReadableNT (_stream_readable.js:974:12)
    at _combinedTickCallback (internal/process/next_tick.js:80:11)
    at process._tickDomainCallback (internal/process/next_tick.js:128:9)
----------

The message does not appear anymore when I relaunch Kibana after uncommenting the line.

All of this is for search-guard-6:6.1.0-21.0 (Elasticsearch plugin) and search-guard-kibana-plugin-6.1.0-10.zip (Kibana plugin).

Saludos, and thanks for SafeGuard!

        Jesus.

On Monday, February 12, 2018 at 9:00:14 PM UTC+1, Tototrash wrote:

[Jesus M. Gonzalez-Barahona]

After some debugging, I've figured out what happened. Because of my specific setup, Kibana needs to write to its ES index when I try to view the dashboard for the first time. And that is where it fails, since the unauthenticated user only has read permission.

The way of solving this would be having a way of authenticating, in addition to anonymous. I'm opening a new thread for framing the issue more in detail. Sorry for the noise here.

         Jesus.

[Jochen Kressin]

Regarding the Kibana error message: We've seen that a couple of times now, but so far could not reproduce it consistently. We're working on a fix though. The error message should only appear once after the login, right? Which browser and operating system are you using?

[Jesus M. Gonzalez-Barahona]

I'm using Firefox 59.0b7, but it happens in Chrome as well. In both cases on Debian GNU/Linux.

I have Kibana and Elasticsearch in a single (Debian-based) container. If it is important to reproduce the error, I can try to produce a clean version of the container just in case you want to have a look at it.

But in any case, my guess is that in Kibana 6, for some reason, the first time you do something (like creating the default index pattern), Kibana creates the .kibana index. In my case, I'm uploading dasboards, visualizations and everything directly via Elasticsearch, and it is very likely that the first time I go to Kibana, it needs to either create something in .kibana, or to update it somehow. And AFAIK, the anonymous user does not have permissions for that. That would explain why if I shutdown kibana, switch kibana.yml to using auth, boot Kibana again, and now when I authenticate and l go to the dashboard, there is no error. And if I reboot once again, now with no auth (anonymous), the error does not show up again, because it no longer needs to write in .kibana. (I've seen this behavior consistently)

But this is just a theory, I didn't debug the scenario up to the point I'm sure.

Saludos,

       Jesus.

[Jochen Kressin]

Yes, that is correct. If you log in to Kibana, create a saved object (like an index pattern), this saved object gets written to the .kibana index. If the index is not present, it gets created. That's why any Kibana user needs permissions to the .kibana index if the user shall be able to create index patterns, visualization etc.

The role definition for the sg_kibana_user and the .kibana index looks like:

  indices:
    '?kibana':
      '*':
        - MANAGE
        - INDEX
        - READ
        - DELETE

So it depends what you want to allow for the anonymous user. If this user should also be able to create index patterns, visualizations etc. you need to grant the privileges outlined above. You can also fine-tune them, if you don't want this user to delete anything, remove the DELETE permissions.

If the user should not be able to create any saved object, including index patterns, grant READ only. In this case an error is displayed if the user tries to do so.

In addition, the user should also have READ permissions to the actual data indices.

[Jesus M. Gonzalez-Barahona]

All clear. Thanks!

       Jesus.