Skip to content
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

Merged
merged 5 commits into from
Apr 20, 2021

Conversation

jkakavas
Copy link
Member

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).
@jkakavas jkakavas added :Security/Authorization Roles, Privileges, DLS/FLS, RBAC/ABAC v8.0.0 v7.13.0 labels Apr 14, 2021
@elasticmachine elasticmachine added the Team:Security Meta label for security team label Apr 14, 2021
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-security (Team:Security)

@jkakavas
Copy link
Member Author

cc @bytebilly

}

private static RoleDescriptor buildEditorRoleDescriptor() {
return new RoleDescriptor("editor",
Copy link
Member

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()

Copy link
Contributor

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!

Copy link
Member

@legrego legrego Apr 15, 2021

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

Copy link
Member

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.

Copy link
Contributor

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.

Copy link
Member

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

@jkakavas
Copy link
Member Author

ping @albertzaharovits

new RoleDescriptor.IndicesPrivileges[] {
// Stack
RoleDescriptor.IndicesPrivileges.builder()
.indices("/~(([.]|ilm-history-).*)/")
Copy link
Contributor

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() },
Copy link
Contributor

@albertzaharovits albertzaharovits Apr 20, 2021

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" .

Copy link
Contributor

@albertzaharovits albertzaharovits left a 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 😁

@albertzaharovits
Copy link
Contributor

@bytebilly I worry about having all-encompassing hard-coded roles like this.
As soon as the user is required to think beyond "all users read/write all data" it's back to square 0, it has to learn about the low level details, ie the indices backing features used by solutions and the privileges required for them.
I think having viewer and editor per feature, eg apm-viewer, ml-editor would help with composability.

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.

@bytebilly
Copy link
Contributor

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 have "per-solution" fine-grained roles (or better, building blocks) in scope for phase 2 (more here).

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!

@jkakavas
Copy link
Member Author

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.

@jkakavas jkakavas merged commit 5a7b1c6 into elastic:master Apr 20, 2021
jkakavas added a commit to jkakavas/elasticsearch that referenced this pull request Apr 20, 2021
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).
jkakavas added a commit that referenced this pull request Apr 20, 2021
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).
gtback added a commit to gtback/elasticsearch that referenced this pull request May 17, 2021
This comment is out of date since elastic#71710.
jrodewig pushed a commit that referenced this pull request May 17, 2021
This comment is out of date since #71710.
jrodewig added a commit that referenced this pull request May 17, 2021
This comment is out of date since #71710.

Co-authored-by: Greg Back <1045796+gtback@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Security/Authorization Roles, Privileges, DLS/FLS, RBAC/ABAC Team:Security Meta label for security team v7.13.0 v8.0.0-alpha1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants