(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:
- Kibana needs full access and can log in with an user:pass
- Kibana X-Pack needs to connect without a user or pass due to an limitation in X-Pack
- 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 127.1.1.1, the Kibana Xpack service connects to 127.1.1.2, 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: ["127.0.0.1"]
# Kibana service
- name: "::KIBANA::"
auth_key: kibanauser:kibanapass
verbosity: error
hosts_local: ["127.1.1.1"]
# 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: ["127.1.1.2"]
verbosity: error
And then in kibana.yml:
elasticsearch.url: "http://127.1.1.1:9200"
elasticsearch.username: "kibanauser"
elasticsearch.password: "kibanapass"
xpack.monitoring.elasticsearch.url: "http://127.1.1.2:9200"
Theoretically, a person on the CLI could access 127.1.1.2:9200 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: ["127.0.0.1"]
# Kibana service
- name: "::KIBANA::"
auth_key: kibana:readonlyrest
verbosity: error
hosts_local: ["127.1.1.1"]
Will give you a test build ASAP.