* Beginning to work on the role management APIs. Added docs for GET * Adding PUT docs * Adding PUT details * Adding delete docs * Fixing linking * Adding Kibana privileges section * Fixing dashboard only mode docs * Fixing a few more references to managing roles * Beginning to work on authorization docs, might be moving some to stack-docs * Collapsing authorization description in the kibana privileges page * Adding audit logging section * Revising the language on the Kibana role management section * Splitting back out the auth/privileges and adding legacy fallback details * Revising language around impact of disabling security * Changing Kibana to {kib} and Elasticsearch to {es} * Beginning to work on developer centric docs * Fixing some formatting, adding some diagrams * Adding note about the role management APIs * Adding overview, fixing small syntax issues * Fixing chunk name for transitioning to application privileges * Adjusting tone for the authorization introduction * Changing the tone and structure of the RBAC docs * Deleting blog stuff after refactoring * Addressing first round of peer review comments * Fixing endpoints links * Peer review suggested edits * Addressing other PR feedback
31 lines
1.5 KiB
Text
31 lines
1.5 KiB
Text
[role="xpack"]
|
|
[[xpack-security-authorization]]
|
|
=== Authorization
|
|
|
|
Authorizing users to use {kib} in most configurations is as simple as assigning the user
|
|
either the `kibana_user` or `kibana_dashboard_only_user` reserved role. If you're running
|
|
a single tenant of {kib} against your {es} cluster, this is sufficient and no other
|
|
action is required.
|
|
|
|
==== Multi-tenant {kib}
|
|
|
|
When running multiple tenants of {kib}, and changing the `kibana.index` in your `kibana.yml`, you
|
|
must create custom roles that authorize the user for that specific tenant. You can use
|
|
either the *Management / Security / Roles* page in {kib} or the <<role-management-api>>
|
|
to assign a specific <<kibana-privileges, Kibana privilege>> at that tenant. After creating the
|
|
custom role, you should assign this role to the user(s) that you wish to have access.
|
|
|
|
==== Legacy roles
|
|
|
|
Prior to {kib} 6.4, {kib} users required index privileges to the `kibana.index`
|
|
in {es}. This approach is deprecated starting in 6.4, and you will need to switch to using
|
|
<<kibana-privileges>> before 7.0. When a user logs into {kib} and they're using
|
|
a legacy role, the following is logged to your {kib} logs:
|
|
|
|
[source,js]
|
|
----------------------------------
|
|
<username> relies on index privileges on the Kibana index. This is deprecated and will be removed in Kibana 7.0
|
|
----------------------------------
|
|
|
|
To disable legacy roles from being authorized in {kib}, set `xpack.security.authorization.legacyFallback` to `false`
|
|
in your `kibana.yml`.
|