-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Feature Controls - Role Management API Docs #34854
Conversation
Pinging @elastic/kibana-docs |
Pinging @elastic/kibana-security |
💚 Build Succeeded |
12c5796
to
dfd4c99
Compare
💚 Build Succeeded |
{ | ||
"base": [], | ||
"feature": { | ||
"discover": [ |
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.
This feature list might be overkill, but I wanted to show an example of a really customized role definition. I can scale it back if that'd be better.
`kibana`:: (array) An array of objects which specify the <<kibana-privileges>> for this role: | ||
[source,js] | ||
-------------------------------------------------- | ||
[{ |
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.
Rather than explain all this in prose, I thought it'd be easier to understand if I just had a well-documented JSON snippet instead.
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.
This is a good idea. However, some of the lines are hard to read because of horizontal scrolling. I made an attempt to edit them down.
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.
My only concern is that we can't link to the "Kibana Privileges" section when using comments within the JSON. Perhaps we could mirror the way that Elasticsearch's role API docs implement the "index privileges": https://www.elastic.co/guide/en/elasticsearch/reference/7.0/security-api-put-role.html
}] | ||
-------------------------------------------------- | ||
|
||
<1> <<features-api>> |
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.
note: This relies on the Features API docs created in #34575
Thanks, Gail! Co-Authored-By: legrego <[email protected]>
This comment has been minimized.
This comment has been minimized.
💚 Build Succeeded |
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.
LGTM
💚 Build Succeeded |
`kibana`:: (array) An array of objects which specify the <<kibana-privileges>> for this role: | ||
[source,js] | ||
-------------------------------------------------- | ||
[{ |
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.
My only concern is that we can't link to the "Kibana Privileges" section when using comments within the JSON. Perhaps we could mirror the way that Elasticsearch's role API docs implement the "index privileges": https://www.elastic.co/guide/en/elasticsearch/reference/7.0/security-api-put-role.html
@@ -2,14 +2,30 @@ | |||
[[kibana-privileges]] | |||
=== Kibana privileges | |||
|
|||
This section lists the Kibana privileges that you can assign to a role. | |||
Privileges have levels that you can use to manage which features users can access. Roles have privileges to determine whether users have write or read access. |
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.
Instead of trying to discuss the concept of "levels", would it simplify this to just have two sections: "Base privileges" and "Feature privileges"?
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 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 think that's perfect, since we won't be referencing this from the "Role Management UI docs", do you mind integrating this within the role api docs themselves?
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'll make those changes, but I'd prefer to wait on integrating until we have the rest of the doc updates in place: we have almost 10 references to this section today, so I want to see what those sections look like after we've updated them for Feature Controls.
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.
@kobelb Last we talked, we had discussed including more context here to help users understand where this is used. What are your thoughts on something like this?
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 like it!
💚 Build Succeeded |
💚 Build Succeeded |
💚 Build Succeeded |
💚 Build Succeeded |
Closing: cherry-picked commits into #35656 |
Summary
Updates the role management api documentation to reflect the new shape of Kibana privileges, including updated examples.
Related: #31053