Setting up with Kibana 4 ? about elasticsearch-readonlyrest-plugin HOT 19 CLOSED

Ok, if someone changes the .kibana index name, we need one option for that... but keep it simple:

 - name: Allow kibana NEW saves user.   # PSEUDO CONF DON'T COPY PASTE! 
      type: allow
      kibana: ro+new            # ro/ro+new/rw
      kibana-index: .kibana     # optional, default: ".kibana"  , use "grep kibana_index kibana.yml"  to find yours
      auth_key: user:pass

 - name: Allow ES user.     # PSEUDO CONF DON'T COPY PASTE! 
      type: allow
      auth_key: user2:pass

i don't think that is possible to have more than one kibana index, so move that to a direct option name to keep thing in the same level
People with kibana need those options on the first example, direct access to ES, will use the second format. Using the kibana on the second example is useless, but do not break anything

from elasticsearch-readonlyrest-plugin.

Hi

Sscarduzio thanks. You're genius.
It works!

However, user who has only read only access is not able to open dashboards in kibana. I would like to give him possibility to open dashboards only in Read more, without possibility to save or remove anything.

I'm using ES 2.2.1. Aby ideas How to do that ?

Nevermind, I checked again, it works! THANKS !

from elasticsearch-readonlyrest-plugin.

I have tested it today with ES 2.3.0 and working fawlesly. I tried to install shield plugin for Kibana, hoping that the login screen will use basic auth and can be reused from this plugin, but at the end i realized that the shield is calling and api to the ES for verifying users.

But two of my thoughts to consider to enhance this plugin:

1. session timeout (i understand thatnit needs persistent storage for keeping session info) because currently after entering credentials it holding session forever and not able to logout
2. consider including .marvel* as "+" with .kibana permission

Anyway thanks, perfect job

from elasticsearch-readonlyrest-plugin.

I don't see why not, you could have a rule per user/access level like this:

readonlyrest:
    enable: true
    response_if_req_forbidden: <h1>Forbidden</h1>    
    access_control_rules:

    - name: Sales login
      type: allow
      indices: [sales-index, public-index]
      auth_key: sales:passwd1

    - name: Admin login
      type: allow
      indices: [accounts-index, sales-index, public-index]
      auth_key: admin:passwd2

Have a try and let me know.

from elasticsearch-readonlyrest-plugin.

Hey @nitram4: I've tested what you asked, and I understood that isolating what users can see in Kibana is not as trivial as I thought. But the good news is if all you want is a few distinct logins in Kibana, that's super easy!

Multiple login to the same Kibana dashboards (no index isolation)

In this scenario, the Kibana Node.js server logs in the same way browsers do: HTTP Basic Auth. We created a username and password for it too.

readonlyrest:
    enable: true
    response_if_req_forbidden: <h1>Forbidden</h1>    
    access_control_rules:

    - name: Kibana Server
      type: allow
      auth_key: server:1234567890

    - name: User1 login
      type: allow
      auth_key: user1:passwd1

    - name: User2
      type: allow
      auth_key: user2:passwd2

The two users will see identical dashboards inside Kibana.

PS: Don't forget to add these two properties on the kibana side ( edit conf/kibana.yml)

  elasticsearch.username: server
  elasticsearch.password: 1234567890

Now point your browser to Kibana and you should be asked username and password.
Insert credentials either for User1 or User2 and you're in.

I hope it helps!

_S

from elasticsearch-readonlyrest-plugin.

I'm also having problems setting up this with kibana. ES direct access works fine.

If i try to login with a readonly user (only GET) , it fails because it is needing sending POST requests:

Request URL:https://kibana.site.com/elasticsearch/_mget?timeout=0&ignore_unavailable=true&preference=1459269385442
Request Method:POST

this fails in this config

    - name: Accept user-ro user.
      type: allow
      methods: [GET]
      auth_key: user-ro:password

adding the POST method and adding the indices: [logstash-*-user-ro] to avoid users to overwrite dashboards, it also fails, from the ES log i see

Mar 29 18:27:15 ES1 elasticsearch[29397]: [2016-03-29 18:27:15,988][DEBUG][plugin.readonlyrest.acl.blocks.rules.impl] This request uses the index 'null' which is not in the list.
Mar 29 18:27:15 ES1 elasticsearch[29397]: [2016-03-29 18:27:15,988][DEBUG][plugin.readonlyrest.acl  ] [Accept user-ro user.] request matches no rules, forbidden by default: req: /_mget?timeout=0&ignore_unavailable=true&preference=1459268072486 - method: POST - origin addr: 192.168.0.10

adding indices: [logstash-*-user-ro,null] will not work

So is there any way of doing this?
my objective is first to protect the kibana dashboards and then later (if possible) restrict some indices to some users

So to start, maybe adding code to check the special "null" index requests to workaround those requests without any indices.

For blocking the GET/POST, kibana seems to need the POST for almost anything, so may be better to check for urls

from what i see, creating dashboards are like this:

 [Accept all requests from localhost/localnet.] request matches no rules, forbidden by default: req: /.kibana/dashboard/Testes2?op_type=create - method: POST - origin addr: 192.168.0.10

overwrite tries the same, gets 409 conflict and then the browse ask the user if they are sure to overwrite and it sends

 [Accept all requests from localhost/localnet.] request matches no rules, forbidden by default: req: /.kibana/dashboard/Testes2 - method: POST - origin addr: 192.168.0.10

visualizations are the same rules:

 request matches no rules, forbidden by default: req: /.kibana/visualization/CPU-usage-per-process2?op_type=create

So as in saved search

request matches no rules, forbidden by default: req: /.kibana/search/trash?op_type=create

So i would say that .kibana is a special index and that anything that is /.kibana/[^/]*/[^?]*\?op_type=create is a CREATION rule, /elasticsearch/.kibana/[^/]*/[^?]*$ is OVERWRITE rule.

can we use theuri_re: to create rules for this?

Sorry for the long post

from elasticsearch-readonlyrest-plugin.

Thanks for the detailed report, it does remind me a lot of the struggles I had last weekend.
I must say it’s quite a complex product which requires a lot of attention in order to be safely exposed in read only mode. But eventually I won :)
I’ll release very soon some new rule that are Kibana specific that will most likely solve all these issues.

On 29 Mar 2016, at 18:18, Daniel Mota Leite [email protected] wrote:

I'm also having problems setting up this with kibana. ES direct access works fine.

If i try to login with a readonly user (only GET) , it fails because it is needing sending POST requests:

Request URL:https://kibana.site.com/elasticsearch/_mget?timeout=0&ignore_unavailable=true&preference=1459269385442
Request Method:POST
this fails in this config

- name: Accept user-ro user.
  type: allow
  methods: [GET]
  auth_key: user-ro:password

adding the POST method and adding the indices: [logstash-*-user-ro] to avoid users to overwrite dashboards, it also fails, from the ES log i see

Mar 29 18:27:15 ES1 elasticsearch[29397]: [2016-03-29 18:27:15,988][DEBUG][plugin.readonlyrest.acl.blocks.rules.impl] This request uses the index 'null' which is not in the list.
Mar 29 18:27:15 ES1 elasticsearch[29397]: [2016-03-29 18:27:15,988][DEBUG][plugin.readonlyrest.acl ] [Accept user-ro user.] request matches no rules, forbidden by default: req: /_mget?timeout=0&ignore_unavailable=true&preference=1459268072486 - method: POST - origin addr: 192.168.0.10
adding indices: [logstash-*-user-ro,null] will not work

So is there any way of doing this?
my objective is first to protect the kibana dashboards and then later (if possible) restrict some indices to some users

So to start, maybe adding code to check the special "null" index requests to workaround those requests without any indices.

For blocking the GET/POST, kibana seems to need the POST for almost anything, so may be better to check for urls

from what i see, creating dashboards are like this:

[Accept all requests from localhost/localnet.] request matches no rules, forbidden by default: req: /.kibana/dashboard/Testes2?op_type=create - method: POST - origin addr: 192.168.0.10
overwrite tries the same, gets 409 conflict and then the browse ask the user if they are sure to overwrite and it sends

[Accept all requests from localhost/localnet.] request matches no rules, forbidden by default: req: /.kibana/dashboard/Testes2 - method: POST - origin addr: 192.168.0.10
visualizations are the same rules:

request matches no rules, forbidden by default: req: /.kibana/visualization/CPU-usage-per-process2?op_type=create
So as in saved search

request matches no rules, forbidden by default: req: /.kibana/search/trash?op_type=create
So i would say that .kibana is a special index and that anything that is /.kibana/[^/]/[^?]?op_type=create is a CREATION rule, /elasticsearch/.kibana/[^/]/[^?]$ is OVERWRITE rule.

can we use theuri_re: to create rules for this? how many uri_re can we use in the config

Sorry for the long post

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub #31 (comment)

from elasticsearch-readonlyrest-plugin.

Great news!! Thank you very much! :D

until then, i just tested this and it seems to work (not perfect, i don't really know if HEAD is needed and if i should also add the PUT):

    - name: Accept kibana access.
      type: allow
      methods: [GET,HEAD]
      uri_re: ^/.kibana/[^?]*$

    - name: Accept test user.
      type: allow
      methods: [GET,POST,HEAD]
      auth_key: test:password
      uri_re: ^/(_.*|logstash-.*-test.*|.kibana/[^?]*\?op_type=create)$

    - name: Forbit overwrite in kibana.
      type: forbid
      methods: [POST]
      uri_re: ^/.kibana/[^?]*$

But until the new versions is released, this should be enough

Again, thanks!

from elasticsearch-readonlyrest-plugin.

actually, after asking the password several times, it manage to overwrite a dashboard... that is weird how it manage to do that...

how the rules work? it will stop on the first that match, or it will match all rules the the last result is the one valid? do the rule ordering even change how things work?

from elasticsearch-readonlyrest-plugin.

The evaluation stops at the first block (block = sets of rules) where all the rules match. The blocks are evaluated in the order they appear in the configuration file.
I think uri_re is a bit too hacky and the guarantees it offers are quite brittle after all. That’s why I introduced real indices matching rules, and that’s why yesterday I made the kibana_actionrule.
This new rule basically checks the request “action” field matches any of the ones defined in the official Shield recommended configuration:

https://www.elastic.co/guide/en/shield/current/kibana.html https://www.elastic.co/guide/en/shield/current/kibana.html

I will commit it later today so you can test it.

On 30 Mar 2016, at 13:31, Daniel Mota Leite [email protected] wrote:

actually, after asking the password several times, it manage to overwrite a dashboard... that is weird how it manage to do that...

how the rules work? it will stop on the first that match, or it will match all rules the the last result is the one valid? do the rule ordering even change how things work?

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub #31 (comment)

from elasticsearch-readonlyrest-plugin.

Can you try this build? I built it for ES 2.2.1, I assume you had this because it's the latest.
https://github.com/sscarduzio/elasticsearch-readonlyrest-plugin/blob/master/download/elasticsearch-readonlyrest-v1.9.0_es-v2.2.1.zip?raw=true

Example configuration

readonlyrest:
    enable: true

    response_if_req_forbidden: <h1>Forbidden</h1>

    access_control_rules:

    - name: browser
      type: allow
      auth_key: user:pass
      kibana_access: ro

Configure Kibana 4 to use these credentials as well (or whitelist the Kibana server's IP, up to you) and then try to connect to Kibana with the browser. You'll be asked for a login and you won't be able to create dashboards or anything else.

You can create another user with write permission copy-pasting the same rule block but with kibana_access: rw.

from elasticsearch-readonlyrest-plugin.

tested and works perfectly! MANY THANKS!! 😄

i could even manage to build a config to allow one to save NEW search/visualization/dashboards, but denies delete and overwrites using this:

    - name: Allow NEW saves user.
      type: allow
      methods: [POST]
      auth_key: user:pass
      uri_re: ^/.kibana/.*\?op_type=create$

    - name: Allow semi-read-only user.
      type: allow
      methods: [GET,POST,HEAD]
      auth_key: user:pass
      kibana_access: ro

Of course, the ideal solution would be create a "kibana_access: ro-except-new-saved-objects" ;)

Anyway, with this i can give users access without having afraid for then to remove things

i'm going now to play with the indices lock, to see if they work too

from elasticsearch-readonlyrest-plugin.

Glad it helped, thanks for testing it!
Maybe you're right with proposing the third state (something like "ro+") would be useful, but here's the catch: the ".kibana" index name is just a default that people can change from conf/kibana.yml.

Then we should let people also tell us what's the name of their kibana index. How do you think an intuitive configuration would look like?

The only one that comes to my mind, I don't like because I'd avoid nesting properties, something like this for example:

    - name: Allow NEW saves user. # PSEUDO CONF DON'T COPY PASTE! 
      type: allow
      kibana: 
        access: ro
        conf_index: [.kibana, .kibana-devnull]  
      auth_key: user:pass

Looks way too complex and adds new unnecessary vocabulary that confuses the user. It's also very conf-error prone: people are already (rightfully) reporting bugs that ends up being indentation errors.

To be honest, if we manage to create a simple example where we achieve the wanted result with 2 blocks of old rules instead of one with combo-rules it's a small victory.

I'd like to talk again about this use case once the indices wild cards are implemented :)

from elasticsearch-readonlyrest-plugin.

Hello,
thanks staring to look as very lightweight version of huge enterprise Shield solution, but for many users are sufficient.
As you mentioned not simple to isolate indices for users, but on main page I see:

- name: Sales login
  type: allow
  indices: [sales-index, public-index]
  auth_key: sales:passwd1

- name: Admin login
  type: allow
  indices: [accounts-index, sales-index, public-index]
  auth_key: admin:passwd2

which looks like allowing/disallowing indices to users. Am I reading it wrong?
That would awesome, to have basic auth with user control over indices.

from elasticsearch-readonlyrest-plugin.

Yes the above will work under normal circumstances (an HTTP client using those exactly one or more of those configured indices).

The thing gets more complicated when - like for Kibana - the client sends queries for indices named with wildcards, which we're going to support really soon (eg: indices: [logstash-*] would match logstash-2016-04-01 and similarly named indices).

For now the shitty workaround would be to configure the indices rule like this:

  indices: [logstash-*, logstash-2016-04-01, logstash-2016-04-02] # and so on

but I suggest to wait for the wildcard index support because I'll implement that during the weekend :)

from elasticsearch-readonlyrest-plugin.

@danielmotaleite I like your idea, make kibana_index as an optional and not nested parameter. Ticks all the conf-file usability boxes. Will do :)

from elasticsearch-readonlyrest-plugin.

Hey @nitram4 thanks for the great feedback!

Sessions

I believe the expiring sessions would would be a nice feature, which by the way, not necessarily implies persistent storage: I can store in a cookie the last login time and return a status 401 + delete cookie if that timestamp is too old. What do you think?

Logout

I can expose a logout endpoint (where I actually delete your cookie), but there will be no button in the UI anyway, unless one adds it in the Kibana view (still doable).

Marvel pass through

Now we have indices wildcards and one could just add a block with indices: [.marvel*] in it, right? (ref: https://www.elastic.co/guide/en/marvel/current/installing-marvel.html)

Heck, one could go as far as auditing the Marvel dashboard and allowing only the actions necessary to the dashboard to work using the new actions I introduced recently. It would be nice to write an how-to recipe about that!

By the way, I never used Marvel (for the same reason I don't use Shield, I hate paywalls on OSS). Do you have a license? Maybe you can try the above solution. I could add log lines to show you the actions as they are received.

Shield plugin

The kibana shield plugin is apparently not open source, but I downloaded it and it's a node project with no obfuscation whatsoever. I'll investigate on the possibility to support it on the server side.

from elasticsearch-readonlyrest-plugin.

Well, we can close this after all :)

from elasticsearch-readonlyrest-plugin.

If handling the sessions is doable it would definitelly be needed feature.

In regards "paywalls" I see it the same way, but recently marvel became free in basic version (not allowing monitoring of multiple clusters) - https://register.elastic.co/marvel_register
I am about to use it in my production scenario so i will post my thoughts...

Using Kibana shield with this free auth plugin would be awesome, but im concern as i saw in the logs that is not using basic authnbut calling /api/ endpoint...

from elasticsearch-readonlyrest-plugin.