Index priviliges

rafikkcmed · August 31, 2023, 9:52am

Hello,
i have to create a role by using the same logic than when we do it on kibana interface and then i create a user

example:

to do this i’m using these 2 rules:

and then, i create my user:

The issue is that when i try to display indices with dev tools by sending GET _cat/indices, i get all indices but what i’m expecting is to get only my index : dvdrental-dev1 !

And also, i can get all information of my ror configuration when i do a search on .readonlyrest index (which is not secure)

Thanks in advance

sscarduzio · August 31, 2023, 10:50am

You can create an ACL block that explicitly blocks access to “.readonlyrest” index. The settings are anyway managed via API calls to the ES plugin, never directly.

- name: "protect settings"
  indices: [".readonlyrest"]
  type: forbid

@coutopl can you follow up about the /_cat/indices ?

rafikkcmed · August 31, 2023, 11:51am

Thank you @sscarduzio
A user who is supposed to have access to the kibana interface will no longer be able to access it using the rule you gave me

My purpuse is to give index access with read privilege only for one index pattern that its name start by dvd-rental*

rafikkcmed · August 31, 2023, 2:29pm

I find my error,
in fact as i have many rules with my ror config, and one of them were valid so it took the lead.

coutoPL · August 31, 2023, 4:56pm

The privileges you configured are the xpack ones.
You should use ROR settings instead.

rafikkcmed · September 1, 2023, 12:50pm

hello @coutoPL ,
let take a look at these two rules :

  - name: ":: ES VIEWER   ::" 
    actions: ["indices:data/read/* "]  
    indices: ["dvdrental-dev*"]  
    groups: ["es-viewer-role"]

And:

 - name: ":: ES VIEWER   ::" 
    actions: ["indices:*"]  
    indices: ["dvdrental-dev*"]  
    groups: ["es-viewer-role"]

Could you explain to me why GET _cat/indices result is different?
Cause with the two rules, i give access just to one index 'dvdrental-dev*

Thank you

coutoPL · September 1, 2023, 6:21pm

I don’t have all the necessary context to answer your question.
But in the second block, I see a potential misconfiguration in the actions rule. Shouldn’t it be indices:* there?

Block by default has verbosity: info configured which means that for each handled request you should find in logs an “ALLOWED” (when some block was matched) or “FORBIDDEN” (when none block was matched) log.

It looks like this:

[INFO ][t.b.r.a.l.AccessControlLoggingDecorator] [es-ror-single] ALLOWED by { name: 'rwgroup 0', policy: ALLOW, rules: [auth_key,actions,indices] req={ ID:316963062-849947420#2427, TYP:PutComposableIndexTemplateAction$Request, CGR:<N/A>, USR:diana, BRS:true, KDX:null, ACT:indices:admin/index_template/put, OA:172.20.0.3/32, XFF:localhost:15601, DA:172.20.0.2/32, IDX:diana2*, MET:PUT, PTH:/_index_template/diana_test_index_template, CNT:<OMITTED, LENGTH=47.0 B> , HDR:Accept-Charset=utf-8, Authorization=<OMITTED>, Host=es-ror:9200, accept=application/vnd.elasticsearch+json; compatible-with=8, connection=close, content-length=47, content-type=application/vnd.elasticsearch+json; compatible-with=8, cookie=xxx tracestate=es=s:0, user-agent=Kibana/8.6.2, x-elastic-client-meta=es=8.4.0p,js=16.18.1,t=8.2.0,hc=16.18.1, x-elastic-product-origin=kibana, x-forwarded-for=localhost:15601, x-opaque-id=unknownId, x-ror-correlation-id=a83f6ba4-8294-485b-8602-5f0c6d09c4f0, x-ror-kibana-request-method=post, x-ror-kibana-request-path=/s/default/api/index_management/index_templates, HIS:[KIBANA-> RULES:[auth_key->false] RESOLVED:[indices=diana2*;template=ADD(diana_test_index_template:diana2*:)]], [ADMIN-> RULES:[auth_key->false] RESOLVED:[indices=diana2*;template=ADD(diana_test_index_template:diana2*:)]], [rwgroup Kibana-> RULES:[auth_key->true, kibana_access->false] RESOLVED:[user=diana;indices=diana2*;template=ADD(diana_test_index_template:diana2*:)]], [rwgroup 0-> RULES:[auth_key->true, actions->true, indices->true] RESOLVED:[user=diana;indices=diana2*;template=ADD(diana_test_index_template:diana2*:)]], }

This kind of log + ACL configuration are the necessary data to answer what happened. E.g. in the log above you will find:

[rwgroup 0-> RULES:[auth_key->true, actions->true, indices->true]

It means “rwgroup 0” was matched because all the rules in the block were matched.
But in the same log you will find also sth like this:

rwgroup Kibana-> RULES:[auth_key->true, kibana_access->false]

It means that “rwgroup Kibana” was not matched because the kibana_access rule failed to match (even the auth_key rule was matched).

When you check your logs according to the example shown above, you should be able to answer the question

rafikkcmed · September 8, 2023, 10:13am

Hello @coutoPL ,
When i have some cluster priviliges to add, for example:

I have this configuration:

I would like to know if the action section will be taken into account or may be i have to add it into kibana section like this:

Thanks in advance

coutoPL · September 8, 2023, 4:38pm

@rafikkcmed please don’t configure anything in this page. It’s xpack settings page and it should be hidden when ROR is installed. We are aware of this issue and we will fix it in ROR 1.51.0.

Use only ROR settings to configure your ACL rules.

rafikkcmed · September 11, 2023, 6:49am

hello @coutoPL ,
Sorry, but i can’t understund what do you mean?
Is there any possibility to configure cluster priviliges or not?
Thank you in advance.

sscarduzio · September 11, 2023, 12:49pm

rafikkcmed:

let take a look at these two rules :
  - name: ":: ES VIEWER ::" 
    actions: ["indices:data/read/* "]  
    indices: ["dvdrental-dev*"]  
    groups: ["es-viewer-role"]
image1909×308 67.8 KB

And:
 - name: ":: ES VIEWER ::" 
   actions: ["indices:*"]  
   indices: ["dvdrental-dev*"]  
   groups: ["es-viewer-role"]
image1730×242 40.6 KB

Could you explain to me why GET _cat/indices result is different?
Cause with the two rules, i give access just to one index 'dvdrental-dev*

As you discovered on your own (good job!), the ACL blocks are evaluated sequentially and we move to evaluating the next ACL block until all the rules in the block do match.

This is inherently different from the RBAC logic, where a user is granted the sum of the permissions of the roles they have assigned.

Another note: in your screenshot, you have a space before the asterisk: ..component_template/ *

Another thing: when you use groups, the users definition should never contain rules that express contraints (i.e. actions, indices, hosts, uri_re, headers), but rather authentication/authorization related rules.
The constraints should be associated to the actual ACL block.

I read again your case, and I thin that the _cat/indices should behave differently: only the permitted index should show. With the same rules in place you should try to get all documents in all indices, and it should return documents from the permitted indices only. I think _cat/indices should behave similarly.

I refer to this conf:

- name: ":: ES VIEWER ::" 
   actions: ["indices:data/read/* "]  
   indices: ["dvdrental-dev*"]  
   groups: ["es-viewer-role"]


 - name: ":: ES VIEWER ::" 
   actions: ["indices:*"]  
   indices: ["dvdrental-dev*"]  
   groups: ["es-viewer-role"]

authenticated as a user that belongs to “es-iewer-role” role.

@coutoPL am I right?

coutoPL · September 11, 2023, 3:11pm

Yes, _cat/indices request is handled as any other GET "/{index-involved-endpoint}`

coutoPL · September 11, 2023, 3:11pm

According to this: it was moved to sprint 1.52.0. Yesterday we released ROR 1.51.0

sscarduzio · September 11, 2023, 8:58pm

To be clear: the “issue we are aware” is that you still can access that xpack security setting, when you shouldn’t.

For the _cat/indices issue, we have an automated integration test to verify exactly this, and it passes. Plus, I tried personally and there was no way to make /_cat/indices list any indices you don’t have permissions for.

Please if you reproduce this case, share with us your complete ACL!