Kibana spins in redirect loop


(Simone Scarduzio) #21

If you preserve logs in chrome console, do you see any 403/401? Is it redirecting without ES rejecting any request? Can you share the current settings?


(Barry Kaplan) #22

Zero console logs in the browser.

Yes it is redirecting without any rejections – but lots of allows.

elasticsearch.yml

action.destructive_requires_name: false
bootstrap.memory_lock: true
cloud.node.auto_attributes: true
cluster.name: ror
cluster.routing.allocation.awareness.attributes: aws_availability_zone
cluster.routing.allocation.node_concurrent_recoveries: 4
discovery.ec2.endpoint: ec2.us-east-1.amazonaws.com
discovery.ec2.groups: s-ror-es
discovery.ec2.host_type: private_ip
discovery.ec2.node_cache_time: 10s
discovery.zen.hosts_provider: ec2
discovery.zen.minimum_master_nodes: '1'
network.host: 10.11.136.187
node.attr.aws_availibility_zone: us-east-1a
node.attr.aws_instance_type: m4.xlarge
node.data: true
node.ingest: true
node.master: true
node.name: s-ror-es-1
path.data:
- /data1/es
path.logs: /var/log/elasticsearch
script.max_compilations_rate: 100/5m
search.remote.connect: false
thread_pool.bulk.queue_size: 200
xpack.graph.enabled: false
xpack.ml.enabled: false
xpack.monitoring.collection.enabled: true
xpack.monitoring.enabled: true
xpack.security.enabled: false
xpack.watcher.enabled: false

readonlyrest.yml

readonlyrest:
  access_control_rules:
  -   auth_key: elastic:elastic
      name: CONSUL-SRV
  -   auth_key: kibana:kibana
      name: KIBANA-SRV
  -   auth_key: admin:admin
      kibana_access: admin
      name: ADMIN
  -   filter: '{"bool": { "must": { "match": { "customer_gender": "MALE" }}}}'
      groups:
      - male
      indices:
      - .kibana
      - kibana_sample_data_ecommerce
      kibana_access: ro
      name: MALE
  -   filter: '{"bool": { "must": { "match": { "customer_gender": "FEMALE" }}}}'
      groups:
      - female
      indices:
      - .kibana
      - kibana_sample_data_ecommerce
      kibana_access: ro
      name: FEMALE
  prompt_for_basic_auth: false
  users:
  -   auth_key: john:john
      groups:
      - male
      username: john
  -   auth_key: jane:jane
      groups:
      - female
      username: jane

kibana.yml

elasticsearch.password: kibana
elasticsearch.url: http://10.11.136.187:9200
elasticsearch.username: kibana
logging.dest: /var/log/kibana/kibana.log
server.host: 0.0.0.0
xpack.graph.enabled: false
xpack.ml.enabled: false
xpack.monitoring.enabled: false
xpack.monitoring.kibana.collection.enabled: false
xpack.security.enabled: false
xpack.watcher.enabled: false

(Barry Kaplan) #23

So far I have been running firefox. Just reran in chrome, same behavior.

Also zero console logs.


(Barry Kaplan) #24

“This Basil. This Basil’s hand. This smack on head.”

Yea, really bad stupid user error here.

I changed the filter to

          filter: '{"match_all": {}}'

and no redirect loop. That caused a light bulb.

Looking at the acl, of course kibana must fail, and fail exactly in the way it did. The filter applied also to the .kibana index.

        - name: MALE
          groups: [male]
          kibana_access: ro
          indices: [ ".kibana", "kibana_sample_data_ecommerce"]  #<<<<<
          filter: '{"term": {"customer_gender": "MALE"}}'

So of course it needed to be

        - name: MALE-K
          groups: [male]
          kibana_access: ro
          indices: [ ".kibana"]

        - name: MALE-V
          groups: [male]
          indices: [ "kibana_sample_data_ecommerce"]
          filter: '{"term": {"customer_gender": "MALE"}}'

And now we don’t prevent kibana (not ror-kibana, just kibana) from getting to .kibana.