Hosts_local question


When should the hosts_local ACL rule match true, under what conditions? All of the combinations I have tried have come back “[hosts_local->false]”


  • name: "::Test::"
    hosts_local: [ “”, “” , “”]

This is the elasticsearch config: [ “”, “” , “”]

I have tried locally on the server via the curl command to all the above IP addresses. I have also tried from a different machine to address. Am I missing something obvious?

ELK 6.2.3
ROR 1.16.18

(Simone Scarduzio) #2

Hi @brian, your ES logs should show OA/DA (origin address, destination address) fields, so you can debug what addresses the request contains.

ALLOWED by { name: ‘::ADMIN_GRP::’, policy: ALLOW} req={ ID:1475216662–1212640048#16672, TYP:SearchRequest, CGR:N/A, USR:admin, BRS:false, KDX:.kibana_123, ACT:indices:data/read/search, OA:, DA:, IDX:.kibana_123, MET:POST, PTH:/.kibana_123/_search?size=10000&from=0&_source=index-pattern.title%2Ctype%2Ctitle, CNT:<OMITTED, LENGTH=80>, HDR:{authorization=Basic YWRtaW46ZGV2, Connection=keep-alive, Authorization=, content-type=application/json, Host=localhost:9200, Content-Length=80}, HIS:[::KIBANA-SRV::->[auth_key->false]], [::PERSONAL_GRP::->[auth_key->false]], [::ADMIN_GRP::->[kibana_access->true, auth_key->true, kibana_index->true]] }


ACL block:

- name: "::CLI::"
  type: allow
  hosts_local: [""]

The request:

[[email protected] ~]# curl
{“error”:{“root_cause”:[{“type”:“status_exception”,“reason”:“Forbidden by ReadonlyREST ES plugin”}],“type”:“status_exception”,“reason”:“Forbidden by ReadonlyREST ES plugin”},"

The error log:

FORBIDDEN by default req={ ID:1064258065-1857026019#543, TYP:MainRequest, CGR:N/A, USR:[no basic auth header], BRS:true, KDX:null, ACT:cluster:monitor/main, OA:, DA:, IDX:<N/A>, MET:GET, PTH:/, CNT:<N/A>, HDR:{Accept=/, content-length=0, Host=, User-Agent=curl/7.29.0}, HIS:[::CLI::->[hosts_local->false]] }

And from the debug messaging:

[DEBUG][t.b.r.a.b.Block ] [::CLI::] the request matches no rules in this block: { ID:1064258065-1857026019#543, TYP:MainRequest, CGR:N/A, USR:[no basic auth header], BRS:true, KDX:null, ACT:cluster:monitor/main, OA:, DA:, IDX:<N/A>, MET:GET, PTH:/, CNT:<N/A>, HDR:{Accept=/, content-length=0, Host=, User-Agent=curl/7.29.0}, HIS:[::CLI::->[hosts_local->false]] }

(Simone Scarduzio) #4

Fixed this in master and added unit test. :+1:Will give you a test build ASAP.

(Simone Scarduzio) #5

Here is the build with the fix, please let me know if all is good now!

(Sai) #6

Hi, I am getting the same issue with elastic search 6.2.1 and readonlyrest plugin readonlyrest-1.16.18_es6.2.1. Do you have fix for 6.2.1 too? Thanks

(Simone Scarduzio) #7

Hi, sure:

(Sai) #8

Great! Thanks @sscarduzio

(Sai) #9

Also I have one more issue. I am getting the same response for hosts setting. Does it work?

I verified that it is same as what I see in OA field in logs…

hosts: []

[2018-04-17T03:35:26,891][INFO ][t.b.r.a.ACL ] FORBIDDEN by default req={ ID:480489791-844682771#4625, TYP:MainRequest, CGR:N/A, USR:logstash(?), BRS:true, KDX:null, ACT:cluster:monitor/main, OA:, DA:, IDX:<N/A>, MET:HEAD, PTH:/, CNT:<N/A>, HDR:{Accept-Encoding=gzip,deflate, Authorization=Basic bG9nc3Rhc2g6bG9nc3Rhc2gwbmx5, Connection=Keep-Alive, content-length=0, Content-Type=application/json, Host=, User-Agent=Manticore 0.6.1}, HIS: }

(Simone Scarduzio) #10

why the “HIS” history bit is missing?

(Sai) #11

Thanks again @sscarduzio. Is there anything I should do to see this HIS history?

(Simone Scarduzio) #12

it should log all the blocks and rules the request is checked against as it walks down its way through the ACL.

(Sai) #13

Thanks for your input @sscarduzio. It’s YAML formatting issue. access_control_rules was in the same level as readonlyrest. After fixing that, things are looking good.

I am going through list of action rules mentioned @

Is there any documentation explaining which action should be used for what? I want to allow category indices (http://xxx:9200/_cat/indices?v) but don’t know which action to use?

Please advise.


(Simone Scarduzio) #14

Just send a _cat/indices request and read the ROR log line. It will print the ACT (action). Consider that this is so specific that you could just use uri_re rule to intercept the right HTTP path.

(Sai) #15

Great! Thanks @sscarduzio.

(Sai) #16

Hi @sscarduzio, one more question please. I am unable to create index patterns in Kibana with following rule:

  auth_key: kibanaadmin:admin0nly
  kibana_access: rw
  indices: [".kibana", "log_index-*"]

What am I missing?

I tried adding read indices ACT like below but did not get through…
actions: [“indices:data/read/*”]




Might be related, might not. I had weird problems when I did not specify a Kibana index. You might try that.

kibana_index: ".kibana"

kibana_index: is which index to use to store Kibana settings and kibana_access: is what permissions to grant to that index. These two deal with the inner workings of Kibana.

indices: is which indexes to give permission to and actions: is what permissions to give to them. From the perspective of a Kibana user, these two deal with the indexes that you see in Kibana and not the .kibana index itself.

(Simone Scarduzio) #18

This looks ok to me, even for writing the index pattern. Not sure how the rest of the settings looks like though.

Anyway, please show us the Elasticsearch log lines where you get the “FORBIDDEN” request when you try to create the index pattern.


(for future people searching, since the title of this thread is descriptive)

This feature is absolutely amazing especially when dealing with more then one service connecting to localhost:9200. Such as Kibana, Kibana X-Pack monitoring, CLI access, Curator, etc all running on the same host.

Also, many thanks @sscarduzio It took some time to fully embrace the flexibility of the permission architecture using ACL blocks but I’m starting to gain appreciation of it.

Take for instance Kibana, without the hosts_local: feature; it is very difficult to do the following all at the same time:

  1. Kibana needs full access and can log in with an user:pass
  2. Kibana X-Pack needs to connect without a user or pass due to an limitation in X-Pack
  3. You want to allow CLI access without authentication for basic RO troubleshooting

What you do is use a different loopback IP for each service and then use the hosts_local: variable to filter on it. That way multiple services all running on the same server can be distinguished from each other. In short, you can say “This ACL block apply only to this particular service”. RoR ACL is top->down first match so being able to distinguis one service from another is incredibly powerful. In the example below, the main Kibana service connects to, the Kibana Xpack service connects to, and the CLI for localhost:9200 allows basic view only troubleshooting options with zero authentication.

# Local command line
- name: "::CLI::"
  actions: ["cluster:monitor/*","indices:monitor/*"]
  hosts_local: [""]

# Kibana service
- name: "::KIBANA::"
  auth_key: kibanauser:kibanapass
  verbosity: error
  hosts_local: [""]

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

And then in kibana.yml:

elasticsearch.url: ""
elasticsearch.username: "kibanauser"
elasticsearch.password: "kibanapass"

xpack.monitoring.elasticsearch.url: ""

Theoretically, a person on the CLI could access and gain higher level privledges with zero authentication to the .kibana and .monitoring* indexes. The importance of this is debatable though, once a person has access to the server the user/password are in kibana.yml for full access anyways.

Another common usage would be to secure ONLY Kibana. Many users of ELK only use Kibana and could care less what is happening on the back end and only want security in Kibana itself. Adding security in the back end is an unnecessary nuisance since only administrators have access to that level anyways. Remove the actions: restriction to the above example and this will allow full access for everythign except for Kibana. In short it makes RoR only secure Kibana, nothing else.

# Local command line
- name: "::CLI::"
  hosts_local: [""]

# Kibana service
- name: "::KIBANA::"
  auth_key: kibana:readonlyrest
  verbosity: error
  hosts_local: [""]

(Sai) #20

[2018-04-23T02:19:03,598][INFO ][t.b.r.a.ACL ] FORBIDDEN by default req={ ID:1878695106–301404706#1022, TYP:FieldCapabilitiesRequest, CGR:N/A, USR:[no basic auth header], BRS:false, KDX:null, ACT:indices:data/read/field_caps, OA:, DA:, IDX:log_index-, MET:POST, PTH:/log_index-/_field_caps?fields=*&ignore_unavailable=true&allow_no_indices=false, CNT:<N/A>, HDR:{Connection=keep-alive, Content-Length=0, Host=}, HIS:[::LOGSTASH::->[auth_key->false]], [::DOCSHOUND::->[auth_key->false]], [::ES READONLY::->[auth_key->false]], [::ES ADMIN::->[auth_key->false]], [::KIBANA-SRV::->[auth_key->false]], [::KIBANA RW DEVELOPER::->[auth_key->false]], [::KIBANA RO DEVELOPER::->[auth_key->false]] }