Missing actionstrings, [no info about user], and [s] notation

1
  1. We are seeing FORBIDDEN in our Elasticsearch logs with the following actions (for our datadog agent).
    indices:admin/seq_no/global_checkpoint_sync
    cluster:admin/voting_config/clear_exclusions
    cluster:admin/component_template/get

However, I don’t see the strings listed here: readonlyrest-docs/actionstrings/action_strings_es8.15.3.txt at master · beshu-tech/readonlyrest-docs · GitHub

Please advise what we should do here.

  1. What is the [no info about user] indicating? Can you elaborate in what situations no user would be defined? How can we mitigate this?

  2. Can you elaborate on what the [s] notation is in the action strings?
    For example: indices:monitor/fleet/global_checkpoints[s]

Should we actually add the [s] in our configurations?

2
  1. These first two are the internal ES actions. They should be passed by ROR.
    The 3rd one “cluster:admin/component_template/get” is component template-related action. It’s listed.

Could you please show the FORBIDDEN entry?

  1. The “[no info about user]” means that no Authorization header was attached to the request and ROR was not able to get the basic auth credentials. Probably it needs to be improved because Kibana can communicate with ES using Bearer token

  2. It’s ES notation. See this

BTW, did you created two blocks for the ECK probe and the ECK internal calls?

3
  1. These first two are the internal ES actions. They should be passed by ROR.
    The 3rd one “cluster:admin/component_template/get” is component template-related action. It’s listed.

Could you please show the FORBIDDEN entry?

Ok, after explicitly adding those two undocumented permissions, I stopped seeing the errors. If it happens again I will attach the full log.

  1. The “[no info about user]” means that no Authorization header was attached to the request and ROR was not able to get the basic auth credentials. Probably it needs to be improved because Kibana can communicate with ES using Bearer token

Ok, is this tracked as a bug/feature request? We would like this fixed in an upcoming release if possible.

  1. It’s ES notation.

Ok thank you. I did not need to add this permission explicitly.

4

Could you please show me the block where you added these?
Because I’m not sure if it’s a way to go.

Ok, is this tracked as a bug/feature request?

Yes, I created a ticket and it’ll be analyzed and possibly improved in the next ROR version.

5

Could you please show me the block where you added these?

Ok here is the block and we give the dd_agent user access to this group

  - name: "Allow monitoring"
    groups: ["monitoring"]
    actions:
    - cluster:monitor/*
    - cluster:admin/component_template/get
    - cluster:admin/desired_nodes/get
    - cluster:admin/shutdown/get
    - cluster:admin/slm/get
    - cluster:admin/snapshot/get
    - cluster:admin/voting_config/clear_exclusions # ES action, passed through by RoR
    - indices:admin/data_stream/get
    - indices:admin/get
    - indices:admin/index_template/get
    - indices:admin/seq_no/global_checkpoint_sync # ES action, passed through by RoR
    - indices:admin/template/get
    - indices:data/read/*
    - indices:monitor/*
    - indices:monitor/fleet/global_checkpoints
6

it’s really weird that a datalog agent needs these two actions. Are you sure that no other application uses the “monitoring” group?

7

Yes I am 100% sure no other user has access to that group. I just checked again.

8

ok, I don’t know how a datalog agent works. Maybe it needs it.
Anyway, it’s good you were able to resolve your issue.