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

Update securing-spaces.asciidoc #26652

Closed
wants to merge 1 commit into from
Closed

Conversation

derickson
Copy link
Contributor

Summary

Users following the instructions will be surprised to find that kibana_user gives blanket "all" access to spaces. kibana_user is a default role and cannot be modified so a new scheme will have to be created. Hopefully this notice will help people understand why users can still see and modify all roles until something is taken away from a user that was unrelated to spaces in version 6.4 and before.

Checklist

Use strikethroughs to remove checklist items you don't feel are applicable to this PR.

For maintainers

@kobelb kobelb self-requested a review December 4, 2018 19:53
image::spaces/images/securing-spaces.png["Securing spaces"]

Note that kibana ships with a built-in role called ```kibana_user``` which grants the **all** privilege as minimum access to all spaces. In order to restrict a user to only a subset of spaces, remember to not give the ```kibana_user``` role but but instead to create a custom scheme where new roles grant both Index Privileges **manage, read, index, delete** to the pattern ```.kibana*``` and the intended access to the correct subset of spaces.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We actually don't want to be creating roles with direct index access anymore, and should be recommending using the Kibana Privileges.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kobelb The built in kibana roles grant access to all spaces, so it's a circular argument for the person who wants to restrict some spaces for some users. I'm not sure what to suggest.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apologies for the confusion, I was attempting to suggest that we reword the following phrasing:

but but instead to create a custom scheme where new roles grant both Index Privileges manage, read, index, delete to the pattern .kibana* and the intended access to the correct subset of spaces.

but instead create a custom role that grants access to the correct subset of spaces using the role's Kibana privileges.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the section of the role page, which we refer to as the "Kibana privileges":

screen shot 2018-12-06 at 10 38 05 am

@elasticmachine

This comment has been minimized.

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@spalger spalger added the Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more! label Jul 1, 2019
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-security

@elasticmachine
Copy link
Contributor

💔 Build Failed

@legrego
Copy link
Member

legrego commented Jul 22, 2021

I'm going to close this due to inactivity - thanks!

@legrego legrego closed this Jul 22, 2021
@spalger spalger deleted the derickson-docs-kspaces-1 branch May 8, 2022 21:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more!
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants