-
Notifications
You must be signed in to change notification settings - Fork 24.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add new predefined reserved roles #71710
Conversation
This change adds two new reserved roles in Elasticsearch, viewer and editor Solutions will use these roles in order to provide,out of the box, a role for full access to data and configuration with no access to cluster management(editor) and a role for read only access to data again with no access to cluster management (viewer).
Pinging @elastic/es-security (Team:Security) |
cc @bytebilly |
...src/test/java/org/elasticsearch/xpack/core/security/authz/store/ReservedRolesStoreTests.java
Show resolved
Hide resolved
} | ||
|
||
private static RoleDescriptor buildEditorRoleDescriptor() { | ||
return new RoleDescriptor("editor", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bytebilly would we expect the editor
role to be able to create/update/delete Kibana spaces? Or is this a task reserved for administrators?
If we need the editor to manage spaces, then this role would instead need to grant the all
application privilege, and the reserved_ml_admin
privilege (all
does not automatically grant ML access until 8.0):
RoleDescriptor.ApplicationResourcePrivileges.builder()
.application("kibana-.kibana")
.resources("*").privileges("all")
.build()
RoleDescriptor.ApplicationResourcePrivileges.builder()
.application("kibana-*")
.resources("*").privileges("reserved_ml_admin")
.build()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@legrego I'm not sure to follow your comment. We are not using the all
shortcut but rather assigning all individual permissions (happy to simplify if we can do differently).
Could you also explain why there is kibana-.kibana
in the first row, and kibana-*
in the second one? Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for not being clear -- If we want editors to be able to manage spaces, then we have to use the all
shortcut in order to achieve this. We don't have a dedicated "manage spaces" privilege today (elastic/kibana#51759), and so it's currently gated behind this all
privilege
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you also explain why there is kibana-.kibana in the first row, and kibana-* in the second one? Thanks!
That is an implementation detail of Kibana's "reserved privileges", and is something we can potentially simplify in 8.x once Kibana drops support for multi-tenant setups. The -*
at the end indicates that this privilege will be granted to all Kibana tenants, not just the default .kibana
tenant.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Larry and I had a sync on that, and he is checking if using his proposed approach will give UX problems or not. Based on that, we can define if we want to use one approach or the other.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't get a chance to verify this today. I struggled to get ES to build locally, and my time was quite limited today. I'm on PTO until Wednesday (after feature freeze), so please don't hold this PR up on me. We can tweak the application privileges definition following FF if we have to without any real interruption
ping @albertzaharovits |
new RoleDescriptor.IndicesPrivileges[] { | ||
// Stack | ||
RoleDescriptor.IndicesPrivileges.builder() | ||
.indices("/~(([.]|ilm-history-).*)/") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought this is supposed to look like /@&~(([.]|ilm-history-).*)/
, but tests say it works anyway.
RoleDescriptor.ApplicationResourcePrivileges.builder() | ||
.application("kibana-.kibana") | ||
.resources("*") | ||
.privileges("read").build() }, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are other indices that might be of interest such as: .monitoring-*
and .ml-*
, and maybe others (search for ".
in ReservedRolesStore
).
Only pointing it out, I don't have the full picture, but those two fit the PR description "full access to data and configuration" .
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The java code is correct 😁
@bytebilly I worry about having all-encompassing hard-coded roles like this. Also, since authorization is shared between Cloud/Kibana/ES, I think it would be easier for maintenance if there was such a feature that other stack components could provision roles without writing ES code, eg something like a REST role provider. |
Thanks @albertzaharovits for the feedback, let me try to add more context on this iteration. The fact that roles are "generic" is intentional, with the goal is to provide a good getting started experience that will let users to explore and share their deployments with others. We decided to hardcode roles for the sake of time and complexity, but I agree we could consider something more structured. We discussed to use a YML file that is "ingested" at boot time, but also the API based way is an option. Happy to discuss more on a possible proposal. I hope this clarify, let me know if you still have concerns! |
I'll merge this since the implementation captures the decided decision for phase 1 and what this should look like for the next minor version. |
This change adds two new reserved roles in Elasticsearch, viewer and editor Solutions will use these roles in order to provide,out of the box, a role for full access to data and configuration with no access to cluster management(editor) and a role for read only access to data again with no access to cluster management (viewer).
This change adds two new reserved roles in Elasticsearch, viewer and editor Solutions will use these roles in order to provide,out of the box, a role for full access to data and configuration with no access to cluster management(editor) and a role for read only access to data again with no access to cluster management (viewer).
This comment is out of date since elastic#71710.
This comment is out of date since #71710.
This change adds two new reserved roles in Elasticsearch,
viewer
and
editor
Solutions will use these roles in order to provide,out of the box,
a role for full access to data and configuration with no access to
cluster management(editor) and a role for read only access to data
again with no access to cluster management (viewer).