API to deploy ReadonlyREST configuration

1

I am trying to automate the configuration changes for ReadonlyREST.
Manually editing the ReadonlyREST configuration in the Kibana App (/app/readonlyrest_kbn) works, but I would like for this to be done by an automation solution.

Every time a new index is created for a project, the ReadonlyREST configuration needs to be adjusted by adding a section for it such as:

  • name: “Accountants indices”
    ldap_auth:
    name: “ldap1”
    groups: [“my_group”]
    indices: [“accounts”,“.kibana*”]
    kibana_access: rw
    kibana_index: “.kibana_my_group”
    kibana_hide_apps: [“readonlyrest_kbn”, “timelion”, “ml”, “infra:home”, “apm”, “uptime”, “siem”, “monitoring”, “kibana:management”]

How can I supply the ReadonlyREST configuration and Save it via the API so that this can be performed automatically ?

An alternative to this would be to generate the readonlyrest.yml, copy it to each elasticsearch node in the cluster and restart elasticsearch on each node.

My company is a ReadonlyREST Enterprise Subscriber.

  • Elasticsearch/Kibana version: 7.8.1
  • ReadonlyREST versions:
    ** readonlyrest-1.24.0_es7.8.1.zip
    ** readonlyrest_kbn_enterprise-1.24.0_es7.8.1.zip
2

The simplest way to automatically allow certain class of indices to a certain ACL block is to use indices name prefixes (for as much as possible) for example:

The accountants should create accounants_index1, accountants_index2, etc. So you can write:

indices: [".kibana", "accountants_*"]

And no changes are ever needed.

However, I understand this is not always possible. So the only other way is to use the settings API the Kibana App uses. But that is an internal API, so it’s undocuemnted and we are not able to guarantee it will remain unchanged in time. As a matter of fact, it’s recently received a facelift. Right @coutoPL?

3

I presume our two choices are:

  1. Adjust the configuration manually in the ReadonlyREST kibana app.
  2. Generate and deploy the readonlyrest.yml file on each node and then restart elasticsearch.

Is making this settings API official a feature being considered for the future ? It could just be 1 REST endpoint to receive the file contents on.

4

Yes, we have internal API and endpoint to reload config which works pretty much like this:

  • receive POST request with readonlyrest.yml content as a payload
  • validate the config
  • if config is valid, save it in ROR settings index
  • all nodes will be reloaded after scheduled interval (default 5s)

We could send a document how to use it but as Simone said, this is our internal API and we cannot guarantee that we won’t change it in a future (obviously we can notify you about the changes but we are not going to maintain backward compatibility of such API).

1 Like
5

OK, thank you for the information and your quick responses.

I think we can close this topic.

1 Like