Deprecating kibana_user and kibana_dashboard_only_user roles #46456
Conversation
|
run elasticsearch-ci/1 |
legrego
force-pushed
the
deprecate-kibana-roles
branch
from
8c00ac5
to
503ce9a
Compare
|
@elastic/kibana-security @elastic/es-security - I'm interested in getting your feedback on this. I took a fairly easy/straightforward approach, but I'm open to other ideas. |
|
This seems reasonable to me, conceptually. I'll defer to the ES team on the actual code changes. |
legrego
added
:Security/Authorization
|
@elasticmachine update branch |
| @@ -117,7 +117,7 @@ If {security-features} are enabled, you must provide a valid user ID and | |||
| password so that {filebeat} can connect to {kib}: | |||
|
|
|||
| .. Create a user on the monitoring cluster that has the | |||
| {stack-ov}/built-in-roles.html[`kibana_user` built-in role] or equivalent | |||
| {stack-ov}/built-in-roles.html[`kibana_admin` built-in role] or equivalent | |||
There was a problem hiding this comment.
Does filebeat need to connect as kibana_admin or would a less privileged role suffice ?
There was a problem hiding this comment.
@legrego What's our recommendation here? What privileges does filebeat need in order to use the Kibana API to setup dashboards etc?
| to any user who authenticates against the `oidc1` OpenID Connect realm: | ||
|
|
||
| [source,console] | ||
| -------------------------------------------------- | ||
| PUT /_security/role_mapping/oidc-kibana | ||
| { | ||
| "roles": [ "kibana_user" ], | ||
| "roles": [ "kibana_admin" ], |
There was a problem hiding this comment.
I'd be wary of suggesting to add kibana_admin to all users of the realm as consumers of the docs tend to follow our examples verbatim
| to any user who authenticates against the `saml1` realm: | ||
|
|
||
| [source,console] | ||
| -------------------------------------------------- | ||
| PUT /_security/role_mapping/saml-kibana | ||
| { | ||
| "roles": [ "kibana_user" ], | ||
| "roles": [ "kibana_admin" ], |
There was a problem hiding this comment.
I'd be wary of suggesting to add kibana_admin to all users of the realm as consumers of the docs tend to follow our examples verbatim
|
When chatting with @tvernum, he mentioned the potential for something to be implemented in Elasticsearch to allow roles to be transparently renamed and the old ones deprecated. Tim will be leaving for holiday tomorrow, so it might be worth-while for us to temporarily put this on hold until he gets a chance to weigh-in. |
# Conflicts: # client/rest-high-level/src/test/java/org/elasticsearch/client/documentation/SecurityDocumentationIT.java
|
@legrego I've picked this up and will address @jkakavas's comments. I've updated your PR with 2 additions:
I'm considering adding additional deprecation warnings when assigning these roles to users (in Can you check the deprecation reasons I added to the 2 Kibana roles - are you happy with them? It's up to you whether you want to include them in the UI. |
|
@legrego Are you happy for us to merge this & officially deprecate this role in 7.6? Or wait for 7.7? |
I'd like @kobelb to weigh in here too... but I think we can officially deprecate on the ES side for 7.6 as long as we're comfortable with the corresponding Kibana UI changes not being ready in time. They're still in a draft state pending a design review, so I don't expect to make feature freeze there. We have doc updates to make on our side as well, but we can hit that for 7.6, especially since they don't have to be done in time for feature freeze. |
As long as we can get the doc updates in for 7.6, I'm alright with us merging the Elasticsearch changes. |
| {kibana-ref}/kibana-privileges.html#kibana-feature-privileges[{kib} feature privileges] | ||
| instead). | ||
| Grants read-only access to the {kib} Dashboard in every | ||
| {kibana-ref}/xpack-spaces.html[Space in {kib}]. |
There was a problem hiding this comment.
| {kibana-ref}/xpack-spaces.html[Space in {kib}]. | |
| {kibana-ref}/xpack-spaces.html[space in {kib}]. |
| @@ -87,8 +89,14 @@ see {kibana-ref}/using-kibana-with-security.html[Configuring Security in {kib}]. | |||
| NOTE: This role should not be assigned to users as the granted permissions may | |||
| change between releases. | |||
|
|
|||
| [[built-in-roles-kibana-admin]] `kibana_admin`:: | |||
| Grants access to all features in {kib}. For more information on {kib} authorization, | |||
| see {kibana-ref}/xpack-security-authorization.html[Kibana Authorization]. | |||
There was a problem hiding this comment.
| see {kibana-ref}/xpack-security-authorization.html[Kibana Authorization]. | |
| see {kibana-ref}/xpack-security-authorization.html[Kibana authorization]. |
| Grants access to all features in {kib}. For more information on Kibana authorization, | ||
| (This role is deprecated, please use the | ||
| <<built-in-roles-kibana-admin,`kibana_admin`>> role instead.) | ||
| Grants access to all features in {kib}. For more information on {kib} authorization, | ||
| see {kibana-ref}/xpack-security-authorization.html[Kibana Authorization]. |
There was a problem hiding this comment.
| see {kibana-ref}/xpack-security-authorization.html[Kibana Authorization]. | |
| see {kibana-ref}/xpack-security-authorization.html[Kibana authorization]. |
| @@ -127,7 +135,8 @@ Grants the minimum privileges required for any user of {monitoring} other than t | |||
| required to use {kib}. This role grants access to the monitoring indices and grants | |||
| privileges necessary for reading basic cluster information. This role also includes | |||
| all {kibana-ref}/kibana-privileges.html[Kibana privileges] for the {stack-monitor-features}. | |||
| Monitoring users should also be assigned the `kibana_user` role. | |||
| Monitoring users should also be assigned the `kibana_admin` role, or another role | |||
| with {kibana-ref}/xpack-security-authorization.html[access to the {kib} instance] | |||
There was a problem hiding this comment.
| with {kibana-ref}/xpack-security-authorization.html[access to the {kib} instance] | |
| with {kibana-ref}/xpack-security-authorization.html[access to the {kib} instance]. |
| that will be used to generate reports. | ||
| user has access to only their own reports. | ||
| Reporting users should also be assigned additional roles that grant | ||
| {kibana-ref}/xpack-security-authorization.html[Access to {kib}] as well as read |
There was a problem hiding this comment.
| {kibana-ref}/xpack-security-authorization.html[Access to {kib}] as well as read | |
| {kibana-ref}/xpack-security-authorization.html[access to {kib}] as well as read |
| . Assign your {kib} users the `kibana_user` role and your `logstash_reader` | ||
| role. | ||
| . Assign your {kib} users a role that grants | ||
| {kibana-ref}/xpack-security-authorization.html[Access to {kib}] |
There was a problem hiding this comment.
| {kibana-ref}/xpack-security-authorization.html[Access to {kib}] | |
| {kibana-ref}/xpack-security-authorization.html[access to {kib}] |
| access to Kibana see {kibana-ref}/xpack-security-authorization.html[Kibana Authorization]. | ||
| This user now has administrative access to all features in {kib}. | ||
| For more information about granting access to Kibana see | ||
| {kibana-ref}/xpack-security-authorization.html[Kibana Authorization]. |
There was a problem hiding this comment.
| {kibana-ref}/xpack-security-authorization.html[Kibana Authorization]. | |
| {kibana-ref}/xpack-security-authorization.html[Kibana authorization]. |
This change adds a new `kibana_admin` role, and deprecates the old `kibana_user` and`kibana_dashboard_only_user`roles. The deprecation is implemented via a new reserved metadata attribute, which can be consumed from the API and also triggers deprecation logging when used (by a user authenticating to Elasticsearch). Some docs have been updated to avoid references to these deprecated roles. Backport of: elastic#46456 Co-authored-by: Tim Vernum <tim@adjective.org> Co-authored-by: Larry Gregory <legrego@users.noreply.github.com>
This change adds a new `kibana_admin` role, and deprecates the old `kibana_user` and`kibana_dashboard_only_user`roles. The deprecation is implemented via a new reserved metadata attribute, which can be consumed from the API and also triggers deprecation logging when used (by a user authenticating to Elasticsearch). Some docs have been updated to avoid references to these deprecated roles. Backport of: #46456 Co-authored-by: Larry Gregory <lgregorydev@gmail.com>
…#46456) This change adds a new `kibana_admin` role, and deprecates the old `kibana_user` and`kibana_dashboard_only_user`roles. The deprecation is implemented via a new reserved metadata attribute, which can be consumed from the API and also triggers deprecation logging when used (by a user authenticating to Elasticsearch). Some docs have been updated to avoid references to these deprecated roles. Co-authored-by: Tim Vernum <tim@adjective.org> Co-authored-by: Larry Gregory <legrego@users.noreply.github.com>
This is a proposal for the Elasticsearch portion of elastic/kibana#25722:
kibana_adminreserved role, with the same privileges as the currentkibana_userrole.kibana_userandkibana_dashboard_only_userroles by introducing a new_deprecatedmetadata flag on each of these roles.On its own, the new
_deprecatedmetadata flag does nothing. The intent is for the Kibana UI to read this flag and inform the user that the role is deprecated.I could see benefit in adding a deprecation response header when a user with a deprecated role authenticates to ES, but I'm not sure where to begin with a change like that, or if it'd even be a welcome change. Open to suggestions there, but we could even do that in a followup PR.
Companion Kibana PR with proposed UI changes: elastic/kibana#45045