Examples for the proxy_auth rule? #193
Comments
|
Sorry, |
|
Hi @parosio! Your GH issue comes in handy: I can reuse your snippets 👍 |
|
@parosio what type of authentication are you implementing in Nginx? |
|
Hi @sscarduzio! thank you for your reply. Currently, Nginx use basic authentication against a local htpasswd file. Btw, I've tried the following: but the elastic bootstrap complains: Using the proxy_auth rule in the user definition, on the other side, seems not working: from nginx access.log: |
|
the above is a YAML formatting error, un-indent the proxy_auth rule so it is inline with kibana_access |
|
Thanks. Nginx asks for credentials, then I have access to Kibana. I'm definetely missing something Below the first three (successful) request logs with the cfg above: |
|
With this configuration: I get a no-match and a forbidden result: |
|
Proxy auth should work configuring ReadonlyREST like this: [...]
- name: "::LOGSTASH::"
auth_key: logstash:**************
type: allow
actions: ["indices:admin/types/exists","indices:data/read/*","indices:data/write/*","indices:admin/template/*","indices:admin/create"]
indices: ["logstash-*"]
- name: "::KIBANA-SRV::"
auth_key: kibana:************
type: allow
- name: HQ ReadOnly
type: allow
kibana_access: ro
proxy_auth: "*" # or even ["user"] to restrict access to that one user.
indices: ["logstash-*", ".kibana", ".kibana-devnull"]ReadonlyREST does not need to know the password of "user", as authentication is delegated to nginx. Should this be not working, there's a bug. In which case, don't forget to name your ES version! :) |
|
Hi @sscarduzio, It seems my case. The readonlyrest version is 1.14; elasticsearch 5.2.0. With the elasticsearch.yml you suggested: stopped and restarted elastic. I've got the following results: nginx access.log: client: chrome 56 Elasticsearch log: Same (negative) results using Firefox: Elastic: The same with curl: I'm authenticated by nginx, but |
|
OK very well, will try to reproduce. Thanks @parosio. |
|
In your logs the request coming to ES has no x-forwarded-user header, it still carries the authorization header though. Are you sure the header is being written by nginx? See in the logs the HDR field where the header names found in the request are listed. |
|
Apparently yes. both requests have the x-forwarded-user header |
|
So basically Kibana is not forwarding X-Forwarded-User header? @innotech-research how can this work for you? |
|
I'm still thinking about this one. We're not currently a big user of kibana but we're under pressure to use it a lot more.
The simple solution is that kibana will natively forward the Authorization header. So if we configure the apache (or other web server) reverse proxy to put the username in that header instead of the X-Forwarded-User header, and allow the elastic plugin to be configurable on the header name (so that it can be configured to read the Authorization header) then it should all just work. The downside is that we're mis-using a standard header which might cause other unforeseen consequences.
The complex solution is to write a kibana plugin that will forward the X-Forwarded-User header. I haven't written a kibana plugin before so I have no idea of the level of complexity involved.
Grateful for any suggestions.
…________________________________
From: Simone Scarduzio <notifications@github.com>
Sent: 15 March 2017 15:08:34
To: sscarduzio/elasticsearch-readonlyrest-plugin
Cc: research; Mention
Subject: Re: [sscarduzio/elasticsearch-readonlyrest-plugin] Examples for the proxy_auth rule? (#193)
So basically Kibana is not forwarding X-Forwarded-User header? @innotech-research<https://github.com/innotech-research> how can this work for you?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#193 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AYu2c278zPY23CUD4jk8MpJ8BqraturLks5rl_7ygaJpZM4McgS7>.
|
|
I'm going to try and make this work without Kibana plugin. Hacking my way through crap as usual. Will update. |
|
I found you can configure Kibana with a white list of headers to pass through to Elasticsearch. By default, only the Authorization header is passed.
|
|
Hi @sscarduzio, thank you very much for this hint. One more question: which is the relation between the |
|
As far as we understand, we have these possibilities (not mutually exclusive):
Bob is a ReadOnly user. Other users authenticated by Nginx but not authorized are repeatedly asked for a valid authentication. |
|
The semantic of proxy_auth overlaps quite a bit with the groups feature. I suggest to keep it simple and avoid groups for your use case, and stick with listing user names inside the proxy_auth rule. PS: We definitely could do better on the UX of the rules in the future. I.e. less rules, more powerful. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello,
I'm trying to configure readonlyrest 1.14.0 (elastic 5.2) to use the authentication provided by nginx.
With the following configuration I get a simple role-based behavior: both
adminanduserare authenticated by Nginx and have the correct authorization (r/w for admin, ro for user)I'm unclear about how to use the proxy_auth rule to avoid the need to specify the auth_key for each user.
The nginx config is simply:
In elasticsearch.yml, besides the acl for logstash and kibana:
I've defined two "groups" and the users belonging to them:
I would get rid of the auth_key property, but cannot figure out how to.
The text was updated successfully, but these errors were encountered: