Update ACL's via automation?

Users Feedback
1

We configure all of RoR via ansible, including the readonlyrest.yml acl’s. I see in the kibana plugin that we can edit the acl’s and have them ~immediately take affect. When the config is updated via kibana, where does the config get stored. Can I have the ansible playbooks do what kibana is doing rather updating the readonlyrest.yml and bouncing the es processes?

2

I see this was already asked, but not really answered with a viable solution.

3

This would be a major blocker for us. It’s simply not feasible to be updating configurations via a manual UI.

4

Hmm, using the UI is a bit worse than just above.

I just in a change, hit Save – bang, kibana is red. If this was a production cluster…

Is there no validation of the config before committing? Or am I missing something?

5

I see the document I posted in the ui was stored in .readonlyrest (that answers one question).

The syntax may be fine. Looks like I just locked myself out via kibana.

So if our automation posted config updates to .readonlyrest will they take affect? Without the kibana app being involved?

6

And now the readonlyrest.yml is ignored once there is a document in .readonlyrest?

7

@memelet yes it’s possible to update the ACL using the same API that the Kibana plugin is using. This is undocumented as it’s an internal API and may change in the future.

And yes it’s normal that the readonlyrest.yml file is ignored when a valid settings object is find inside the .readonlyrest index.

If you locked yourself out, delete the .readonlyrest index and the YAML file will take over on next reboot.
you might need to uninstall ROR from ES, delete the .readonlyrest index and then reinstall it if you are literally locked out.
But generally using the “kibana” daemon credentials saves the day :slight_smile:

8

In this case even kibana is locked out.

Would be nice to have a “system” user that lives outside readonlyrest: config.

Even better would be a startup parameter that indicates readonlyrest.yml should overwrite the .readonlyrest index.

So what is the “internal” api? Is it an elasticsearch http endpoint? Part of the es plugin?

9

What I changed that locked me was to uncomment the commented out lines below. Is there some interaction between users: and access_control:?

    readonlyrest:
      prompt_for_basic_auth: false
      audit_collector: true
      audit_serializer: tech.beshu.ror.requestcontext.DefaultAuditLogSerializer

#      users:
#        - username: john
#          auth_key: john:john
#          groups: [male]
#
#        - username: jane
#          auth_key: jane:jane
#          groups: [female]

      access_control_rules:
        #TODO Change username; limit permissions. (See TODO in _elasticsearch.yml#135)
        - name: CONSUL-SRV
          auth_key: elastic:{{ vault_elk_elastic_password }}

        - name: KIBANA-SRV
          auth_key: kibana:{{ vault_elk_kibana_password }}

        - name: ADMIN
          auth_key: admin:admin
          kibana_access: admin

#        - name: MALE
#          groups: [male]
#          kibana_access: ro
#          indices: [ ".kibana", "kibana_sample_data_ecommerce"]
#          kibana_hide_apps: "{{ kibana_ror_plant_hide_apps }}"
#
#        - name: FEMALE
#          groups: [female]
#          kibana_access: ro
#          indices: [ ".kibana", "kibana_sample_data_ecommerce"]
#          kibana_hide_apps: "{{ kibana_ror_plant_hide_apps }}"
10

And I’m not fully locked out, with the above fully uncommented this is allowed

$ curl --user admin:admin -H 'Content-Type: application/json' 10.11.136.187:9200/.readonlyrest/_search -d '
{
    "query": {
        "match_all": {}
    }
}' | jq .

but this is not

$ curl --user elastic:elastic -H 'Content-Type: application/json' 10.11.136.187:9200/.readonlyrest/_search -d '
{
    "query": {
        "match_all": {}
    }
}' | jq .

So I’m clearly not understanding the how the acl’s are working. Back to the docs…

11

Hi @memelet, the users section declares local users and associates them to local groups. There is no use to a list of users whose groups are not referenced inside an ACL block (i.e. you should have commented also the below part).

Anyway I’m not sure what makes you feel “locked out” when you still can access the system as admin and elastic.

12

Anyway I’m not sure what makes you feel “locked out” when you still can access the system as admin and elastic.

No, in this case no user was able to log in. But like I said, I may have posted cruft into the kibana app.

13

I don’t follow here. The top, the users:, were the users. The bottom, in access_control_rules, was just group definitions that the users were assigned to.

I’m incrementally working up to what the config will look like when I get to using jwt or proxy.

14

Wait, I take it back. I was locked out fully from the ui. No user could log in. From the api I could not delete any readonlyrest indices.

Still, given that it worked when I installed the exact same rules via readonlyrest.yml, I have to believe it was user error in pasting.

15

Are you able to share the playbooks you used for installing ror please? I have trouble getting the Kibana plugin to install and not time out

1 Like
16

Do you mean install the plugin in your Dockerfile? If so that is a matter of setting --max-old-space-size=... to enough memory. We use 4098. But it still take a long time.

17

Were not using dockerfiles tbh. Just an ansible playbook installing Kibana and the plugin on a centos 7 node.