Kbn_ent tenancy problems

1

ror_1.16.16
kbn_ent_1.16.16
ELK 6.2.2

I log into Kibana and both users use the default .kibana-6 index, I do not see a tenancy dropdown button, and all of the apps that are configured to hide are still shown. Not sure if I am missing something obvious or not.

For example:

  1. Logging in as test:test you can see the ReadonlyREST app but will get permission denied when going into it
  2. Logging in as testadm:testadm ReadonlyREST app works properly
  3. Both users are presented with the same list of Kibana apps.

readonlyrest:
response_if_req_forbidden: Forbidden by ReadonlyREST ES plugin
prompt_for_basic_auth: false
audit_collector: true

access_control_rules:

#########################################################
# Allow Kibana monitoring to work
#########################################################
- name: "::Kibana XPack Monitoring::"
  type: allow
  actions: ["cluster:monitor/*","cluster:admin/xpack/*","indices:data/read/*","indices:data/write/*","indices:admin/*"]
  indices: [".kibana*",".monitoring*"]
  hosts: ["127.0.0.1"]
  verbosity: error

#####################################################################################
# These credentials have no limitations, and shall be used only by the Kibana daemon.
#####################################################################################
- name: "::KIBANA::"
  type: allow
  auth_key: kibana:readonlyrest
  verbosity: error


#####################################################################################
# Local Groups
#####################################################################################
- name: "::Personal::RW::Local"
  type: allow
  groups: ["kibana-personal"]
  kibana_access: rw
  kibana_hide_apps: ["readonlyrest_kbn", "timelion", "kibana:dev_tools", "kibana:monitoring", "kibana:management"]
  kibana_index: ".kibana_@{user}"
  actions: ["indices:data/read/*"]

- name: "::Admin::Local"
  type: allow
  groups: ["kibana-admin"]
  kibana_access: admin
  indices: ["*"]
  actions: ["indices:data/read/*","cluster:admin/rradmin/"]

- name: "::InfoSec::RO::Local"
  type: allow
  groups: ["kibana-ro-infosec"]
  kibana_access: ro
  kibana_hide_apps: ["readonlyrest_kbn", "timelion", "kibana:dev_tools", "kibana:monitoring", "kibana:management"]
  kibana_index: ".kibana_infosec"
  actions: ["indices:data/read/*"]
  indices: ["infosec*","firewall*"]

- name: "::InfoSec::RW::Local"
  type: allow
  groups: ["kibana-rw-infosec"]
  kibana_access: rw
  kibana_hide_apps: ["readonlyrest_kbn", "timelion", "kibana:dev_tools", "kibana:monitoring"]
  kibana_index: ".kibana_infosec"
  actions: ["indices:data/read/*"]
  indices: ["infosec*","firewall*"]


#####################################################################################
# Local Users
#####################################################################################
users:
- username: testadm
  auth_key: testadm:testadm
  groups: ["kibana-personal", "kibana-admin", "kibana-rw-infosec"]

- username: test
  auth_key: test:test
  groups: ["kibana-personal", "kibana-ro-infosec"]

image
image177×896 8.19 KB

2

Found the problem. The first rule for XPack monitoring screws it all up.

Is there any way to write a rule based on the IP that was accessed (destination IP)? For example, xpack could write to 127.1.1.1 and ROR could be configured to allow restricted access for the unauthenticated xpack, kibana would access 127.1.1.3 and ROR would be configured for full on authentication, etc.

3

Hi @brian! Good job finding the issue, you are the second customer this month I see having the whole ROR ACL made useless while attempting to allow X-Pack monitoring.

Where did you find that snippet? If it’s in the docs somewhere I’d like to remove it or put warnings.

To your request: we have the hosts rule, if you want to try with that.

4

Found the snippet in the forum here :wink:

Hosts rule is for source IP though? I tried to configure it as above but the ‘host’ is always 127.0.0.1 since I am using a localhost Elasticsearch install with Kibana.

By having some way to reference what IP was accessed (an IP from the elasticsearch.yml “network.host” variable), if Kibana is using a locally installed Elasticsearch instance then it would be possible to use many different loopback IP addresses and filter the rules based on which loopback address was used. Could allow for things such as “curl localhost:9200” from bash could be fully allowed in ROR without restriction, xpack could access the same install at 127.1.1.2:9200 and get a different ROR rule that allows it to do its thing against the .kibana and .monitoring indexes without authentication, and kibana itself could access 127.1.1.3:9200 and ROR would apply full authentication. Its a big hackish, bout would allow for a means to tailor certain rules for certain usese.

Like so in kibana.yml

xpack.monitoring.elasticsearch.url: “127.1.1.2:9200”

Then in ROR config

- name: "::Monitoring::"
  type: allow
  actions: ["cluster:monitor/*","cluster:admin/xpack/*","indices:data/read/*","indices:data/write/*","indices:admin/*"]
  indices: [".kibana*",".monitoring*"]
  network.host: ["127.1.1.2"]      
  verbosity: error