mirror of
https://github.com/elastic/kibana.git
synced 2025-04-24 09:48:58 -04:00
[Docs] Add documentation on multiple tenants (#103125)
This commit is contained in:
parent
03c713123c
commit
c78c350a1d
3 changed files with 18 additions and 2 deletions
|
@ -30,6 +30,8 @@ Kibana supports spaces in several ways. You can:
|
|||
|
||||
The `kibana_admin` role or equivilent is required to manage **Spaces**.
|
||||
|
||||
TIP: Looking to support multiple tenants? See <<xpack-security-multiple-tenants, the Security documentation>> for more information.
|
||||
|
||||
[float]
|
||||
[[spaces-managing]]
|
||||
=== View, create, and delete spaces
|
||||
|
|
|
@ -6,7 +6,21 @@ The Elastic Stack comes with the `kibana_admin` {ref}/built-in-roles.html[built-
|
|||
|
||||
When you assign a user multiple roles, the user receives a union of the roles’ privileges. Therefore, assigning the `kibana_admin` role in addition to a custom role that grants {kib} privileges is ineffective because `kibana_admin` has access to all the features in all spaces.
|
||||
|
||||
NOTE: When running multiple tenants of {kib} by changing the `kibana.index` in your `kibana.yml`, you cannot use `kibana_admin` to grant access. You must create custom roles that authorize the user for that specific tenant. Although multi-tenant installations are supported, the recommended approach to securing access to {kib} segments is to grant users access to specific spaces.
|
||||
[[xpack-security-multiple-tenants]]
|
||||
==== Supporting multiple tenants
|
||||
|
||||
There are two approaches to supporting multi-tenancy in {kib}:
|
||||
|
||||
1. *Recommended:* Create a space and a limited role for each tenant, and configure each user with the appropriate role. See
|
||||
<<tutorial-secure-access-to-kibana, Securing access to {kib}>> for more details.
|
||||
2. deprecated:[7.13.0,"In 8.0 and later, the `kibana.index` setting will no longer be supported."] Set up separate {kib} instances to work
|
||||
with a single {es} cluster by changing the `kibana.index` setting in your `kibana.yml` file.
|
||||
+
|
||||
NOTE: When using multiple {kib} instances this way, you cannot use the `kibana_admin` role to grant access. You must create custom roles
|
||||
that authorize the user for each specific instance.
|
||||
|
||||
Whichever approach you use, be careful when granting cluster privileges and index privileges. Both of these approaches share the same {es}
|
||||
cluster, and {kib} spaces do not prevent you from granting users of two different tenants access to the same index.
|
||||
|
||||
[role="xpack"]
|
||||
[[xpack-kibana-role-management]]
|
||||
|
|
|
@ -11,7 +11,7 @@ This guide introduces you to three of {kib}'s security features: spaces, roles,
|
|||
[float]
|
||||
=== Spaces
|
||||
|
||||
Do you have multiple teams using {kib}? Do you want a “playground” to experiment with new visualizations or alerts? If so, then <<xpack-spaces,{kib} Spaces>> can help.
|
||||
Do you have multiple teams or tenants using {kib}? Do you want a “playground” to experiment with new visualizations or alerts? If so, then <<xpack-spaces,{kib} Spaces>> can help.
|
||||
|
||||
Think of a space as another instance of {kib}. A space allows you to organize your <<dashboard, dashboards>>, <<alerting-getting-started, alerts>>, <<xpack-ml, machine learning jobs>>, and much more into their own categories. For example, you might have a Marketing space for your marketeers to track the results of their campaigns, and an Engineering space for your developers to {apm-get-started-ref}/overview.html[monitor application performance].
|
||||
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue