Question on Kibana Integration

titan1978 · March 20, 2018, 6:57pm

(I haven’t yet purchased the Kibana PRO/ENTERPRISE license and neither do I have a Trial license yet. Am trying to do some basic Kibana Integration with my ROR enabled elastic stack. Successful POC will allow me to trigger a purchase of the PRO License FYI). POC intent is to get Kibana to Load successfully with the default internal kibana/kibana elasticpassword and allow me to navigate all the features of kibana-elasticsearch by default without any Basic Authentication Popups.

WITHOUT purchasing the PRO/ENTERPRISE/TRIAL license, what all can I do by default?
Am getting a Basic Authentication Challenge whilst bringing up Kibana! I was hoping with the kibana/kibana yml configuration - at the very least Kibana will come up - write the necessary indexes etc. However, I get a foribidden error RANDOMLY with this configuration. The odd thing is - sometimes I do get the user correctly as kibana and the KIBANA-SRV rule passes, but other most of the other times it fails as below. Any suggestions?

FORBIDDEN by default req={ ID:419936870-1449684158#181, TYP:GetFieldMappingsRequest, CGR:N/A, USR:[no basic auth header], BRS:false, ACT:indices:admin/mappings/fields/get, OA:10.203.122.154, DA:10.203.121.87, IDX:.kibana, MET:GET, PTH:/.kibana/_mapping/*/field/_source, CNT:<N/A>, HDR:{Connection=keep-alive, content-length=0, host=converse-elasticsearch.clouddqt.capitalone.com, X-Forwarded-For=10.203.121.86, 10.203.123.205, X-Forwarded-Port=443, X-Forwarded-Proto=https}, HIS:[Rout53 Access->[actions->false, x_forwarded_for->true]], [Global Write/Admin Access->[auth_key->false]], [::KIBANA-SRV::->[auth_key->false]], [::RO::->[auth_key->false]], [::RW::->[auth_key->false]] }

I have configured

kibana.yml

elasticsearch:username: “kibana”
elasticsearch.password: “kibana”

readonlyrest.yml

readonlyrest:
access_control_rules:

- name: "Rout53 Access"
  type: allow
  x_forwarded_for: ["0.0.0.0/0"]
  actions: ["cluster:monitor/*","indices:data/read/*", "indices:admin/get", "indices:admin/aliases", "indices:admin/aliases/*", "indices:admin/analyze", "indices:monitor/*"]
  verbosity: error

- name: "Global Write/Admin Access"
  auth_key: "elastic:$apr1$JRxL0HOz$ndMHCirazDfTZznLy.icH1"
  type: allow
  actions: ["indices:data/write/*","indices:admin/*", "cluster:admin/*"]

- name: "::KIBANA-SRV::"
  kibana_access: ro
  auth_key: **kibana:kibana**

- name: "::RO::"
  auth_key: ro:dev
  kibana_access: ro
  indices: [ ".kibana", ".kibana-devnull", "logstash-*"]
  kibana_hide_apps: ["readonlyrest_kbn", "timelion", "kibana:dev_tools", "kibana:management"]

- name: "::RW::"
  auth_key: rw:dev
  kibana_access: rw
  indices: [".kibana", ".kibana-devnull", "logstash-*"]
  kibana_hide_apps: ["readonlyrest_kbn", "timelion", "kibana:dev_tools", "kibana:management"]

sscarduzio · March 20, 2018, 11:26pm

Well, you are describing the long standing Kibana bug I was talking about.

However, a very shitty way to mitigate this is to open up the ACL for those certain actions. A bit like you did for the ELB health checks.
Maybe as a “proof of concept” it will momentarily do the trick.

Talking about POC and demos: I’d hate to come across as the classical pushy seller, but - if you need - I can simply hand you over a link to the trial of the Kibana plugin. No strings attached.

titan1978 · March 21, 2018, 2:52am

@sscarduzio Thank you. Thats very forthcoming - once I had my kibana working I was planning on using the trial to prototype and demo to mesh the last part of this - multi tenancy. A readiliy available link would help speed things along.

to this point : Maybe as a “proof of concept” it will momentarily do the trick.
I assume this bug is regardless of whether or not its a Proof of Concept or not? Are you suggesting that I hack the Kibana flow across the environment spectrum (DEV/QA/PROD) until an “official” fix is available?

sscarduzio · March 21, 2018, 3:14am

Maybe it’s semantics, but in my understanding I supposed a POC would not reach QA/PROD.
I just suggested to pin some holes in the ACL in a controlled environment, if you just need to show off what’s possible.

About the bug. This bug in Kibana in 2016 and never resolved. I know because was the one reporting it. Personally I lost hope.

github.com/elastic/kibana

Kibana sometimes sends HTTP requests to Elasticsearch without credentials

opened 05:40AM - 21 Dec 16 UTC

closed 01:51PM - 18 Jan 23 UTC

sscarduzio

bug Team:Security

**Kibana version**: 5.1.1 **Elasticsearch version**: 5.1.1 **Server OS ver…sion**:OSX 10.11.6 **Browser version**: Chrome 54 **Browser OS version**: OSX 10.11.6 **Original install method (e.g. download page, yum, from source, etc.)**: unzipped the tarball **Description of the problem including expected versus actual behavior**: Kibana server sends **some** HTTP request without authorization header. **Steps to reproduce**: 1. Have an Elasticsearch v5.1.1 instance running allowing only requests with HTTP Basic Auth credentials. 2. Configure said credentials in kibana.yml as "elasticsearch.username" and "elasticsearch.password". 3. Wait for ES to reach green status, and Kibana to find Elasticsearch. 4. Create some dummy data points ```bash curl -X POST -H "Content-Type: application/json" -H "Authorization: Basic bG9nc3Rhc2g6bG9nc3Rhc2g=" -H "Cache-Control: no-cache" -d '{"index":{"_id":null,"_index":"logstash-2016.10.28","_type":"logs","_routing":null}} {"message":"","@version":"1","@timestamp":"2016-10-28T09:15:28.998Z","host":"hilbert.local"} {"index":{"_id":null,"_index":"logstash-2016.10.28","_type":"logs","_routing":null}} {"message":"","@version":"1","@timestamp":"2016-10-28T09:15:29.267Z","host":"hilbert.local"} {"index":{"_id":null,"_index":"logstash-2016.10.28","_type":"logs","_routing":null}} {"message":"","@version":"1","@timestamp":"2016-10-28T09:15:29.267Z","host":"hilbert.local"} {"index":{"_id":null,"_index":"logstash-2016.10.28","_type":"logs","_routing":null}} {"message":"","@version":"1","@timestamp":"2016-10-28T09:15:29.267Z","host":"hilbert.local"} {"index":{"_id":null,"_index":"logstash-2016.10.28","_type":"logs","_routing":null}} {"message":"","@version":"1","@timestamp":"2016-10-28T09:15:29.268Z","host":"hilbert.local"} {"index":{"_id":null,"_index":"logstash-2016.10.28","_type":"logs","_routing":null}} {"message":"","@version":"1","@timestamp":"2016-10-28T09:15:29.268Z","host":"hilbert.local"} {"index":{"_id":null,"_index":"logstash-2016.10.28","_type":"logs","_routing":null}} {"message":"","@version":"1","@timestamp":"2016-10-28T09:15:29.268Z","host":"hilbert.local"} {"index":{"_id":null,"_index":"logstash-2016.10.28","_type":"logs","_routing":null}} {"message":"","@version":"1","@timestamp":"2016-10-28T09:15:29.268Z","host":"hilbert.local"} {"index":{"_id":null,"_index":"logstash-2016.10.28","_type":"logs","_routing":null}} {"message":"","@version":"1","@timestamp":"2016-10-28T09:15:29.269Z","host":"hilbert.local"} {"index":{"_id":null,"_index":"logstash-2016.10.28","_type":"logs","_routing":null}} {"message":"","@version":"1","@timestamp":"2016-10-28T09:15:29.269Z","host":"hilbert.local"} {"index":{"_id":null,"_index":"logstash-2016.10.28","_type":"logs","_routing":null}} {"message":"","@version":"1","@timestamp":"2016-10-28T09:15:29.269Z","host":"hilbert.local"} {"index":{"_id":null,"_index":"logstash-2016.10.28","_type":"logs","_routing":null}} {"message":"","@version":"1","@timestamp":"2016-10-28T09:15:29.269Z","host":"hilbert.local"} {"index":{"_id":null,"_index":"logstash-2016.10.28","_type":"logs","_routing":null}} {"message":"","@version":"1","@timestamp":"2016-10-28T09:15:29.269Z","host":"hilbert.local"}' "http://localhost:9200/_bulk" ``` 5. Switch on Wireshark. 6. Start exploring and searching with Kibana 7. Observe in wireshark that Kibana skips sending the credentials for some requests, like in this screenshot: ![screenshot](http://i.imgur.com/7M3B9bS.png) > See how Authorization header is not present!** **Errors in browser console (if relevant)**: **Provide logs and/or server output (if relevant)**: ``` error [09:12:03.308] Error: Authentication Exception at respond (/me/tmp/kibana-5.1.1-darwin-x86_64/node_modules/elasticsearch/src/lib/transport.js:289:15) at checkRespForFailure (/me/tmp/kibana-5.1.1-darwin-x86_64/node_modules/elasticsearch/src/lib/transport.js:248:7) at HttpConnector.<anonymous> (/me/tmp/kibana-5.1.1-darwin-x86_64/node_modules/elasticsearch/src/lib/connectors/http.js:164:7) at IncomingMessage.wrapper (/me/tmp/kibana-5.1.1-darwin-x86_64/node_modules/elasticsearch/node_modules/lodash/lodash.js:4994:19) 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:74:11) at process._tickDomainCallback (internal/process/next_tick.js:122:9) ```

titan1978 · March 21, 2018, 4:52pm

@sscarduzio Ah - I meant if the Proof of Concept is approved - when we take it to PROD - we cant depend on the kibana/kibana due to the bug so the same “hack” for allowing a custom ACL for kibana events would need to get promoted to PROD?

sscarduzio · March 21, 2018, 5:32pm

Well of course if you promote the PoC to prod as is, you will expose production data to flaws. So by all means, I suggest to use the appropriate tools if your PoC has chances to go straight to prod.