Integrate system indices with restricted indices names in security #69298
Assignees
Labels
>enhancement
:Security/Authorization
Roles, Privileges, DLS/FLS, RBAC/ABAC
Team:Security
Meta label for security team
Comments
jaymode
added
>enhancement
:Security/Authorization
|
Pinging @elastic/es-security (Team:Security) |
2 tasks
jaymode
added a commit
to jaymode/elasticsearch
that referenced
this issue
Jun 16, 2021
System indices should be treated as a special set of indices and not be accessible by all users. The existing security codebase has the notion of restricted indices, which are currently a subset of system indices. This change unifies the two concepts by making system indices the set of restricted indices. This means that going forward, consumers of system indices will need access to restricted indices. Closes elastic#69298
williamrandolph
added a commit
that referenced
this issue
Aug 20, 2021
System indices should be treated as a special set of indices and not be accessible by all users. The existing security codebase has the notion of restricted indices, which are currently a subset of system indices. This change unifies the two concepts by making system indices the set of restricted indices. This means that going forward, consumers of system indices will need access to restricted indices. Our intention is that this will be handled internally as much as possible. For example, restricted index access can be used implicitly by setting a valid origin on a request or using a system index plugin. In these cases, the security module will apply internally defined privileges when necessary. The main impact of this change for developers is that system index deletions will require superuser privileges, so we have to make sure we are using an admin role for test cleanup. Closes #69298 Co-authored-by: William Brafford <[email protected]> Co-authored-by: Albert Zaharovits <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In the security codebase and roles, there is the notion of restricted indices. This is a predefined list of index patterns that access should not be granted to by default; currently this includes the security indices and async search. For system indices, we should also restrict access and have them be included within restricted indices. This sounds simple but there are plumbing issues that will need to be worked through and a fair number of tests that will fail with this change; for example the kibana indices will become restricted and we currently have a test that asserts the kibana system role does not grant any restricted index access.
I had intended to handle this as part of #68919, but the issues would make that change large and harder to review. This issue is being opened instead so that the integration of system indices into restricted indices in security is tracked and not forgotten.
The text was updated successfully, but these errors were encountered: