kibana/docs/spaces/index.asciidoc

143 lines
5.2 KiB
Plaintext
Raw Normal View History

Spaces Phase 1 (#21408) ### Review notes This is generally ready for review. We are awaiting https://github.com/elastic/elasticsearch/issues/32777 to improve handling when users do not have any access to Kibana, but this should not hold up the overall review for this PR. This PR is massive, there's no denying that. Here's what to focus on: 1) `x-pack/plugins/spaces`: This is, well, the Spaces plugin. Everything in here is brand new. The server code is arguably more important, but feel free to review whatever you see fit. 2) `x-pack/plugins/security`: There are large and significant changes here to allow Spaces to be securable. To save a bit of time, you are free to ignore changes in `x-pack/plugins/security/public`: These are the UI changes for the role management screen, which were previously reviewed by both us and the design team. 3) `x-pack/test/saved_object_api_integration` and `x-pack/test/spaces_api_integration`: These are the API test suites which verify functionality for: a) Both security and spaces enabled b) Only security enabled c) Only spaces enabled What to ignore: 1) As mentioned above, you are free to ignore changes in `x-pack/plugins/security/public` 2) Changes to `kibana/src/server/*`: These changes are part of a [different PR that we're targeting against master](https://github.com/elastic/kibana/pull/23378) for easier review. ## Saved Objects Client Extensions A bulk of the changes to the saved objects service are in the namespaces PR, but we have a couple of important changes included here. ### Priority Queue for wrappers We have implemented a priority queue which allows plugins to specify the order in which their SOC wrapper should be applied: `kibana/src/server/saved_objects/service/lib/priority_collection.ts`. We are leveraging this to ensure that both the security SOC wrapper and the spaces SOC wrapper are applied in the correct order (more details below). ### Spaces SOC Wrapper This wrapper is very simple, and it is only responsible for two things: 1) Prevent users from interacting with any `space` objects (use the Spaces client instead, described below) 2) Provide a `namespace` to the underlying Saved Objects Client, and ensure that no other wrappers/callers have provided a namespace. In order to accomplish this, the Spaces wrapper uses the priority queue to ensure that it is the last wrapper invoked before calling the underlying client. ### Security SOC Wrapper This wrapper is responsible for performing authorization checks. It uses the priority queue to ensure that it is the first wrapper invoked. To say another way, if the authorization checks fail, then no other wrappers will be called, and the base client will not be called either. This wrapper authorizes users in one of two ways: RBAC or Legacy. More details on this are below. ### Examples: `GET /s/marketing/api/saved_objects/index-pattern/foo` **When both Security and Spaces are enabled:** 1) Saved objects API retrieves an instance of the SOC via `savedObjects.getScopedClient()`, and invokes its `get` function 2) The Security wrapper is invoked. a) Authorization checks are performed to ensure user can access this particular saved object at this space. 3) The Spaces wrapper is invoked. a) Spaces applies a `namespace` to be used by the underlying client 4) The underlying client/repository are invoked to retrieve the object from ES. **When only Spaces are enabled:** 1) Saved objects API retrieves an instance of the SOC via `savedObjects.getScopedClient()`, and invokes its `get` function 2) The Spaces wrapper is invoked. a) Spaces applies a `namespace` to be used by the underlying client 3) The underlying client/repository are invoked to retrieve the object from ES. **When only Security is enabled:** (assume `/s/marketing` is no longer part of the request) 1) Saved objects API retrieves an instance of the SOC via `savedObjects.getScopedClient()`, and invokes its `get` function 2) The Security wrapper is invoked. a) Authorization checks are performed to ensure user can access this particular saved object globally. 3) The underlying client/repository are invoked to retrieve the object from ES. ## Authorization Authorization changes for this project are centered around Saved Objects, and builds on the work introduced in RBAC Phase 1. ### Saved objects client #### Security without spaces When security is enabled, but spaces is disabled, then the authorization model behaves the same way as before: If the user is taking advantage of Kibana Privileges, then we check their privileges "globally" before proceeding. A "global" privilege check specifies `resources: ['*']` when calling the [ES _has_privileges api.](https://www.elastic.co/guide/en/elasticsearch/reference/current/security-api-has-privileges.html). Legacy users (non-rbac) will continue to use the underlying index privileges for authorization. #### Security with spaces When both plugins are enabled, then the authorization model becomes more fine-tuned. Rather than checking privileges globally, the privileges are checked against a specific resource that matches the user's active space. In order to accomplish this, the Security plugin needs to know if Spaces is enabled, and if so, it needs to ask Spaces for the user's active space. The subsequent call to the `ES _has_privileges api` would use `resources: ['space:marketing']` to verify that the user is authorized at the `marketing` space. Legacy users (non-rbac) will continue to use the underlying index privileges for authorization. **NOTE** The legacy behavior implies that those users will have access to all spaces. The read/write restrictions are still enforced, but there is no way to restrict access to a specific space for legacy auth users. #### Spaces without security No authorization performed. Everyone can access everything. ### Spaces client Spaces, when enabled, prevents saved objects of type `space` from being CRUD'd via the Saved Objects Client. Instead, the only "approved" way to work with these objects is through the new Spaces client (`kibana/x-pack/plugins/spaces/lib/spaces_client.ts`). When security is enabled, the Spaces client performs its own set of authorization checks before allowing the request to proceed. The Spaces client knows which authorization checks need to happen for a particular request, but it doesn't know _how_ to check privileges. To accomplish this, the spaces client will delegate the check security's authorization service. #### FAQ: Why oh why can't you used the Saved Objects Client instead!? That's a great question! We did this primarily to simplify the authorization model (at least for our initial release). Accessing regular saved objects follows a predictible authorization pattern (described above). Spaces themselves inform the authorization model, and this interplay would have greatly increased the complexity. We are brainstorming ideas to obselete the Spaces client in favor of using the Saved Objects Client everywhere, but that's certainly out of scope for this release. ## Test Coverage ### Saved Objects API A bulk of the changes to enable spaces are centered around saved objects, so we have spent a majority of our time automating tests against the saved objects api. **`x-pack/test/saved_object_api_integration/`** contains the test suites for the saved objects api. There is a `common/suites` subfolder which contains a bulk of the test logic. The suites defined here are used in the following test configurations: 1) Spaces only: `./spaces_only` 2) Security and spaces: `./security_and_spaces` 3) Security only: `./security_only` Each of these test configurations will start up ES/Kibana with the appropriate license and plugin set. Each set runs through the entire test suite described in `common/suites`. Each test with in each suite is run multiple times with different inputs, to test the various permutations of authentication, authorization type (legacy vs RBAC), space-level privileges, and the user's active space. ### Spaces API Spaces provides an experimental public API. **`x-pack/test/spaces_api_integration`** contains the test suites for the Spaces API. Similar to the Saved Objects API tests described above, there is a `common/suites` folder which contains a bulk of the test logic. The suites defined here are used in the following test configurations: 1) Spaces only: `./spaces_only` 2) Security and spaces: `./security_and_spaces` ### Role Management UI We did not provide any new functional UI tests for role management, but the existing suite was updated to accomidate the screen rewrite. We do have a decent suite of jest unit tests for the various components that make up the new role management screen. They're nested within `kibana/x-pack/plugins/security/public/views/management/edit_role` ### Spaces Management UI We did not provide any new functional UI tests for spaces management, but the components that make up the screens are well-tested, and can be found within `kibana/x-pack/plugins/spaces/public/views/management/edit_space` ### Spaces Functional UI Tests There are a couple of UI tests that verify _basic_ functionality. They assert that a user can login, select a space, and then choose a different space once inside: `kibana/x-pack/test/functional/apps/spaces` ## Reference Notable child PRs are listed below for easier digesting. Note that some of these PRs are built on other PRs, so the deltas in the links below may be outdated. Cross reference with this PR when in doubt. ### UI - Reactify Role Management Screen: https://github.com/elastic/kibana/pull/19035 - Space Aware Privileges UI: https://github.com/elastic/kibana/pull/21049 - Space Selector (in Kibana Nav): https://github.com/elastic/kibana/pull/19497 - Recently viewed Widget: https://github.com/elastic/kibana/pull/22492 - Support Space rename/delete: https://github.com/elastic/kibana/pull/22586 ### Saved Objects Client - ~~Space Aware Saved Objects: https://github.com/elastic/kibana/pull/18862~~ - ~~Add Space ID to document id: https://github.com/elastic/kibana/pull/21372~~ - Saved object namespaces (supercedes #18862 and #21372): https://github.com/elastic/kibana/pull/22357 - Securing saved objects: https://github.com/elastic/kibana/pull/21995 - Dedicated Spaces client (w/ security): https://github.com/elastic/kibana/pull/21995 ### Other - Public Spaces API (experimental): https://github.com/elastic/kibana/pull/22501 - Telemetry: https://github.com/elastic/kibana/pull/20581 - Reporting: https://github.com/elastic/kibana/pull/21457 - Spencer's original Spaces work: https://github.com/elastic/kibana/pull/18664 - Expose `spaceId` to "Add Data" tutorials: https://github.com/elastic/kibana/pull/22760 Closes #18948 "Release Note: Create spaces within Kibana to organize dashboards, visualizations, and other saved objects. Secure access to each space when X-Pack Security is enabled"
2018-10-01 13:09:33 +02:00
[role="xpack"]
[[xpack-spaces]]
== Spaces
Spaces enable you to organize your dashboards and other saved
objects into meaningful categories. Once inside a space, you see only
the dashboards and saved objects that belong to that space.
Spaces Phase 1 (#21408) ### Review notes This is generally ready for review. We are awaiting https://github.com/elastic/elasticsearch/issues/32777 to improve handling when users do not have any access to Kibana, but this should not hold up the overall review for this PR. This PR is massive, there's no denying that. Here's what to focus on: 1) `x-pack/plugins/spaces`: This is, well, the Spaces plugin. Everything in here is brand new. The server code is arguably more important, but feel free to review whatever you see fit. 2) `x-pack/plugins/security`: There are large and significant changes here to allow Spaces to be securable. To save a bit of time, you are free to ignore changes in `x-pack/plugins/security/public`: These are the UI changes for the role management screen, which were previously reviewed by both us and the design team. 3) `x-pack/test/saved_object_api_integration` and `x-pack/test/spaces_api_integration`: These are the API test suites which verify functionality for: a) Both security and spaces enabled b) Only security enabled c) Only spaces enabled What to ignore: 1) As mentioned above, you are free to ignore changes in `x-pack/plugins/security/public` 2) Changes to `kibana/src/server/*`: These changes are part of a [different PR that we're targeting against master](https://github.com/elastic/kibana/pull/23378) for easier review. ## Saved Objects Client Extensions A bulk of the changes to the saved objects service are in the namespaces PR, but we have a couple of important changes included here. ### Priority Queue for wrappers We have implemented a priority queue which allows plugins to specify the order in which their SOC wrapper should be applied: `kibana/src/server/saved_objects/service/lib/priority_collection.ts`. We are leveraging this to ensure that both the security SOC wrapper and the spaces SOC wrapper are applied in the correct order (more details below). ### Spaces SOC Wrapper This wrapper is very simple, and it is only responsible for two things: 1) Prevent users from interacting with any `space` objects (use the Spaces client instead, described below) 2) Provide a `namespace` to the underlying Saved Objects Client, and ensure that no other wrappers/callers have provided a namespace. In order to accomplish this, the Spaces wrapper uses the priority queue to ensure that it is the last wrapper invoked before calling the underlying client. ### Security SOC Wrapper This wrapper is responsible for performing authorization checks. It uses the priority queue to ensure that it is the first wrapper invoked. To say another way, if the authorization checks fail, then no other wrappers will be called, and the base client will not be called either. This wrapper authorizes users in one of two ways: RBAC or Legacy. More details on this are below. ### Examples: `GET /s/marketing/api/saved_objects/index-pattern/foo` **When both Security and Spaces are enabled:** 1) Saved objects API retrieves an instance of the SOC via `savedObjects.getScopedClient()`, and invokes its `get` function 2) The Security wrapper is invoked. a) Authorization checks are performed to ensure user can access this particular saved object at this space. 3) The Spaces wrapper is invoked. a) Spaces applies a `namespace` to be used by the underlying client 4) The underlying client/repository are invoked to retrieve the object from ES. **When only Spaces are enabled:** 1) Saved objects API retrieves an instance of the SOC via `savedObjects.getScopedClient()`, and invokes its `get` function 2) The Spaces wrapper is invoked. a) Spaces applies a `namespace` to be used by the underlying client 3) The underlying client/repository are invoked to retrieve the object from ES. **When only Security is enabled:** (assume `/s/marketing` is no longer part of the request) 1) Saved objects API retrieves an instance of the SOC via `savedObjects.getScopedClient()`, and invokes its `get` function 2) The Security wrapper is invoked. a) Authorization checks are performed to ensure user can access this particular saved object globally. 3) The underlying client/repository are invoked to retrieve the object from ES. ## Authorization Authorization changes for this project are centered around Saved Objects, and builds on the work introduced in RBAC Phase 1. ### Saved objects client #### Security without spaces When security is enabled, but spaces is disabled, then the authorization model behaves the same way as before: If the user is taking advantage of Kibana Privileges, then we check their privileges "globally" before proceeding. A "global" privilege check specifies `resources: ['*']` when calling the [ES _has_privileges api.](https://www.elastic.co/guide/en/elasticsearch/reference/current/security-api-has-privileges.html). Legacy users (non-rbac) will continue to use the underlying index privileges for authorization. #### Security with spaces When both plugins are enabled, then the authorization model becomes more fine-tuned. Rather than checking privileges globally, the privileges are checked against a specific resource that matches the user's active space. In order to accomplish this, the Security plugin needs to know if Spaces is enabled, and if so, it needs to ask Spaces for the user's active space. The subsequent call to the `ES _has_privileges api` would use `resources: ['space:marketing']` to verify that the user is authorized at the `marketing` space. Legacy users (non-rbac) will continue to use the underlying index privileges for authorization. **NOTE** The legacy behavior implies that those users will have access to all spaces. The read/write restrictions are still enforced, but there is no way to restrict access to a specific space for legacy auth users. #### Spaces without security No authorization performed. Everyone can access everything. ### Spaces client Spaces, when enabled, prevents saved objects of type `space` from being CRUD'd via the Saved Objects Client. Instead, the only "approved" way to work with these objects is through the new Spaces client (`kibana/x-pack/plugins/spaces/lib/spaces_client.ts`). When security is enabled, the Spaces client performs its own set of authorization checks before allowing the request to proceed. The Spaces client knows which authorization checks need to happen for a particular request, but it doesn't know _how_ to check privileges. To accomplish this, the spaces client will delegate the check security's authorization service. #### FAQ: Why oh why can't you used the Saved Objects Client instead!? That's a great question! We did this primarily to simplify the authorization model (at least for our initial release). Accessing regular saved objects follows a predictible authorization pattern (described above). Spaces themselves inform the authorization model, and this interplay would have greatly increased the complexity. We are brainstorming ideas to obselete the Spaces client in favor of using the Saved Objects Client everywhere, but that's certainly out of scope for this release. ## Test Coverage ### Saved Objects API A bulk of the changes to enable spaces are centered around saved objects, so we have spent a majority of our time automating tests against the saved objects api. **`x-pack/test/saved_object_api_integration/`** contains the test suites for the saved objects api. There is a `common/suites` subfolder which contains a bulk of the test logic. The suites defined here are used in the following test configurations: 1) Spaces only: `./spaces_only` 2) Security and spaces: `./security_and_spaces` 3) Security only: `./security_only` Each of these test configurations will start up ES/Kibana with the appropriate license and plugin set. Each set runs through the entire test suite described in `common/suites`. Each test with in each suite is run multiple times with different inputs, to test the various permutations of authentication, authorization type (legacy vs RBAC), space-level privileges, and the user's active space. ### Spaces API Spaces provides an experimental public API. **`x-pack/test/spaces_api_integration`** contains the test suites for the Spaces API. Similar to the Saved Objects API tests described above, there is a `common/suites` folder which contains a bulk of the test logic. The suites defined here are used in the following test configurations: 1) Spaces only: `./spaces_only` 2) Security and spaces: `./security_and_spaces` ### Role Management UI We did not provide any new functional UI tests for role management, but the existing suite was updated to accomidate the screen rewrite. We do have a decent suite of jest unit tests for the various components that make up the new role management screen. They're nested within `kibana/x-pack/plugins/security/public/views/management/edit_role` ### Spaces Management UI We did not provide any new functional UI tests for spaces management, but the components that make up the screens are well-tested, and can be found within `kibana/x-pack/plugins/spaces/public/views/management/edit_space` ### Spaces Functional UI Tests There are a couple of UI tests that verify _basic_ functionality. They assert that a user can login, select a space, and then choose a different space once inside: `kibana/x-pack/test/functional/apps/spaces` ## Reference Notable child PRs are listed below for easier digesting. Note that some of these PRs are built on other PRs, so the deltas in the links below may be outdated. Cross reference with this PR when in doubt. ### UI - Reactify Role Management Screen: https://github.com/elastic/kibana/pull/19035 - Space Aware Privileges UI: https://github.com/elastic/kibana/pull/21049 - Space Selector (in Kibana Nav): https://github.com/elastic/kibana/pull/19497 - Recently viewed Widget: https://github.com/elastic/kibana/pull/22492 - Support Space rename/delete: https://github.com/elastic/kibana/pull/22586 ### Saved Objects Client - ~~Space Aware Saved Objects: https://github.com/elastic/kibana/pull/18862~~ - ~~Add Space ID to document id: https://github.com/elastic/kibana/pull/21372~~ - Saved object namespaces (supercedes #18862 and #21372): https://github.com/elastic/kibana/pull/22357 - Securing saved objects: https://github.com/elastic/kibana/pull/21995 - Dedicated Spaces client (w/ security): https://github.com/elastic/kibana/pull/21995 ### Other - Public Spaces API (experimental): https://github.com/elastic/kibana/pull/22501 - Telemetry: https://github.com/elastic/kibana/pull/20581 - Reporting: https://github.com/elastic/kibana/pull/21457 - Spencer's original Spaces work: https://github.com/elastic/kibana/pull/18664 - Expose `spaceId` to "Add Data" tutorials: https://github.com/elastic/kibana/pull/22760 Closes #18948 "Release Note: Create spaces within Kibana to organize dashboards, visualizations, and other saved objects. Secure access to each space when X-Pack Security is enabled"
2018-10-01 13:09:33 +02:00
{kib} creates a default space for you.
After you create your own
spaces, you're asked to choose a space when you log in to Kibana. You can change your
current space at any time by using the menu.
Spaces Phase 1 (#21408) ### Review notes This is generally ready for review. We are awaiting https://github.com/elastic/elasticsearch/issues/32777 to improve handling when users do not have any access to Kibana, but this should not hold up the overall review for this PR. This PR is massive, there's no denying that. Here's what to focus on: 1) `x-pack/plugins/spaces`: This is, well, the Spaces plugin. Everything in here is brand new. The server code is arguably more important, but feel free to review whatever you see fit. 2) `x-pack/plugins/security`: There are large and significant changes here to allow Spaces to be securable. To save a bit of time, you are free to ignore changes in `x-pack/plugins/security/public`: These are the UI changes for the role management screen, which were previously reviewed by both us and the design team. 3) `x-pack/test/saved_object_api_integration` and `x-pack/test/spaces_api_integration`: These are the API test suites which verify functionality for: a) Both security and spaces enabled b) Only security enabled c) Only spaces enabled What to ignore: 1) As mentioned above, you are free to ignore changes in `x-pack/plugins/security/public` 2) Changes to `kibana/src/server/*`: These changes are part of a [different PR that we're targeting against master](https://github.com/elastic/kibana/pull/23378) for easier review. ## Saved Objects Client Extensions A bulk of the changes to the saved objects service are in the namespaces PR, but we have a couple of important changes included here. ### Priority Queue for wrappers We have implemented a priority queue which allows plugins to specify the order in which their SOC wrapper should be applied: `kibana/src/server/saved_objects/service/lib/priority_collection.ts`. We are leveraging this to ensure that both the security SOC wrapper and the spaces SOC wrapper are applied in the correct order (more details below). ### Spaces SOC Wrapper This wrapper is very simple, and it is only responsible for two things: 1) Prevent users from interacting with any `space` objects (use the Spaces client instead, described below) 2) Provide a `namespace` to the underlying Saved Objects Client, and ensure that no other wrappers/callers have provided a namespace. In order to accomplish this, the Spaces wrapper uses the priority queue to ensure that it is the last wrapper invoked before calling the underlying client. ### Security SOC Wrapper This wrapper is responsible for performing authorization checks. It uses the priority queue to ensure that it is the first wrapper invoked. To say another way, if the authorization checks fail, then no other wrappers will be called, and the base client will not be called either. This wrapper authorizes users in one of two ways: RBAC or Legacy. More details on this are below. ### Examples: `GET /s/marketing/api/saved_objects/index-pattern/foo` **When both Security and Spaces are enabled:** 1) Saved objects API retrieves an instance of the SOC via `savedObjects.getScopedClient()`, and invokes its `get` function 2) The Security wrapper is invoked. a) Authorization checks are performed to ensure user can access this particular saved object at this space. 3) The Spaces wrapper is invoked. a) Spaces applies a `namespace` to be used by the underlying client 4) The underlying client/repository are invoked to retrieve the object from ES. **When only Spaces are enabled:** 1) Saved objects API retrieves an instance of the SOC via `savedObjects.getScopedClient()`, and invokes its `get` function 2) The Spaces wrapper is invoked. a) Spaces applies a `namespace` to be used by the underlying client 3) The underlying client/repository are invoked to retrieve the object from ES. **When only Security is enabled:** (assume `/s/marketing` is no longer part of the request) 1) Saved objects API retrieves an instance of the SOC via `savedObjects.getScopedClient()`, and invokes its `get` function 2) The Security wrapper is invoked. a) Authorization checks are performed to ensure user can access this particular saved object globally. 3) The underlying client/repository are invoked to retrieve the object from ES. ## Authorization Authorization changes for this project are centered around Saved Objects, and builds on the work introduced in RBAC Phase 1. ### Saved objects client #### Security without spaces When security is enabled, but spaces is disabled, then the authorization model behaves the same way as before: If the user is taking advantage of Kibana Privileges, then we check their privileges "globally" before proceeding. A "global" privilege check specifies `resources: ['*']` when calling the [ES _has_privileges api.](https://www.elastic.co/guide/en/elasticsearch/reference/current/security-api-has-privileges.html). Legacy users (non-rbac) will continue to use the underlying index privileges for authorization. #### Security with spaces When both plugins are enabled, then the authorization model becomes more fine-tuned. Rather than checking privileges globally, the privileges are checked against a specific resource that matches the user's active space. In order to accomplish this, the Security plugin needs to know if Spaces is enabled, and if so, it needs to ask Spaces for the user's active space. The subsequent call to the `ES _has_privileges api` would use `resources: ['space:marketing']` to verify that the user is authorized at the `marketing` space. Legacy users (non-rbac) will continue to use the underlying index privileges for authorization. **NOTE** The legacy behavior implies that those users will have access to all spaces. The read/write restrictions are still enforced, but there is no way to restrict access to a specific space for legacy auth users. #### Spaces without security No authorization performed. Everyone can access everything. ### Spaces client Spaces, when enabled, prevents saved objects of type `space` from being CRUD'd via the Saved Objects Client. Instead, the only "approved" way to work with these objects is through the new Spaces client (`kibana/x-pack/plugins/spaces/lib/spaces_client.ts`). When security is enabled, the Spaces client performs its own set of authorization checks before allowing the request to proceed. The Spaces client knows which authorization checks need to happen for a particular request, but it doesn't know _how_ to check privileges. To accomplish this, the spaces client will delegate the check security's authorization service. #### FAQ: Why oh why can't you used the Saved Objects Client instead!? That's a great question! We did this primarily to simplify the authorization model (at least for our initial release). Accessing regular saved objects follows a predictible authorization pattern (described above). Spaces themselves inform the authorization model, and this interplay would have greatly increased the complexity. We are brainstorming ideas to obselete the Spaces client in favor of using the Saved Objects Client everywhere, but that's certainly out of scope for this release. ## Test Coverage ### Saved Objects API A bulk of the changes to enable spaces are centered around saved objects, so we have spent a majority of our time automating tests against the saved objects api. **`x-pack/test/saved_object_api_integration/`** contains the test suites for the saved objects api. There is a `common/suites` subfolder which contains a bulk of the test logic. The suites defined here are used in the following test configurations: 1) Spaces only: `./spaces_only` 2) Security and spaces: `./security_and_spaces` 3) Security only: `./security_only` Each of these test configurations will start up ES/Kibana with the appropriate license and plugin set. Each set runs through the entire test suite described in `common/suites`. Each test with in each suite is run multiple times with different inputs, to test the various permutations of authentication, authorization type (legacy vs RBAC), space-level privileges, and the user's active space. ### Spaces API Spaces provides an experimental public API. **`x-pack/test/spaces_api_integration`** contains the test suites for the Spaces API. Similar to the Saved Objects API tests described above, there is a `common/suites` folder which contains a bulk of the test logic. The suites defined here are used in the following test configurations: 1) Spaces only: `./spaces_only` 2) Security and spaces: `./security_and_spaces` ### Role Management UI We did not provide any new functional UI tests for role management, but the existing suite was updated to accomidate the screen rewrite. We do have a decent suite of jest unit tests for the various components that make up the new role management screen. They're nested within `kibana/x-pack/plugins/security/public/views/management/edit_role` ### Spaces Management UI We did not provide any new functional UI tests for spaces management, but the components that make up the screens are well-tested, and can be found within `kibana/x-pack/plugins/spaces/public/views/management/edit_space` ### Spaces Functional UI Tests There are a couple of UI tests that verify _basic_ functionality. They assert that a user can login, select a space, and then choose a different space once inside: `kibana/x-pack/test/functional/apps/spaces` ## Reference Notable child PRs are listed below for easier digesting. Note that some of these PRs are built on other PRs, so the deltas in the links below may be outdated. Cross reference with this PR when in doubt. ### UI - Reactify Role Management Screen: https://github.com/elastic/kibana/pull/19035 - Space Aware Privileges UI: https://github.com/elastic/kibana/pull/21049 - Space Selector (in Kibana Nav): https://github.com/elastic/kibana/pull/19497 - Recently viewed Widget: https://github.com/elastic/kibana/pull/22492 - Support Space rename/delete: https://github.com/elastic/kibana/pull/22586 ### Saved Objects Client - ~~Space Aware Saved Objects: https://github.com/elastic/kibana/pull/18862~~ - ~~Add Space ID to document id: https://github.com/elastic/kibana/pull/21372~~ - Saved object namespaces (supercedes #18862 and #21372): https://github.com/elastic/kibana/pull/22357 - Securing saved objects: https://github.com/elastic/kibana/pull/21995 - Dedicated Spaces client (w/ security): https://github.com/elastic/kibana/pull/21995 ### Other - Public Spaces API (experimental): https://github.com/elastic/kibana/pull/22501 - Telemetry: https://github.com/elastic/kibana/pull/20581 - Reporting: https://github.com/elastic/kibana/pull/21457 - Spencer's original Spaces work: https://github.com/elastic/kibana/pull/18664 - Expose `spaceId` to "Add Data" tutorials: https://github.com/elastic/kibana/pull/22760 Closes #18948 "Release Note: Create spaces within Kibana to organize dashboards, visualizations, and other saved objects. Secure access to each space when X-Pack Security is enabled"
2018-10-01 13:09:33 +02:00
[role="screenshot"]
image::spaces/images/change-space.png["Change current space menu"]
Kibana supports spaces in several ways. You can:
[[spaces-getting-started]]
* <<spaces-managing, View&comma; create&comma; and delete spaces>>
* <<spaces-control-feature-visibility, Control feature access based on user needs>>
* <<spaces-control-user-access, Control feature access based on user privileges>>
* <<spaces-moving-objects, Move objects between spaces>>
* <<spaces-default-route, Configure a Space-level landing page>>
* <<spaces-delete-started, Disable the Spaces feature>>
[float]
==== Required permissions
The `kibana_admin` role or equivilent is required to manage **Spaces**.
[float]
[[spaces-managing]]
=== View, create, and delete spaces
Open the main menu, then click *Stack Management > Spaces* for an overview of your spaces. This view provides actions
for you to create, edit, and delete spaces.
[role="screenshot"]
image::spaces/images/space-management.png["Space management"]
[float]
==== Create or edit a space
You can create as many spaces as you like. Click *Create a space* and provide a name,
URL identifier, optional description.
The URL identifier is a short text string that becomes part of the
{kib} URL when you are inside that space. {kib} suggests a URL identifier based
on the name of your space, but you can customize the identifier to your liking.
You cannot change the space identifier once you create the space.
{kib} also has an <<spaces-api, API>>
if you prefer to create spaces programatically.
[role="screenshot"]
image::spaces/images/edit-space.png["Space management"]
[float]
==== Delete a space
Deleting a space permanently removes the space and all of its contents.
Find the space on the *Spaces* overview page and click the trash icon in the Actions column.
You can't delete the default space, but you can customize it to your liking.
[float]
[[spaces-control-feature-visibility]]
=== Control feature access based on user needs
You have control over which features are visible in each space.
For example, you might hide Dev Tools
in your "Executive" space or show Stack Monitoring only in your "Admin" space.
You can define which features to show or hide when you add or edit a space.
Controlling feature
visibility is not a security feature. To secure access
to specific features on a per-user basis, you must configure
<<xpack-security-authorization, Kibana Security>>.
[role="screenshot"]
image::spaces/images/edit-space-feature-visibility.png["Controlling features visiblity"]
[float]
[[spaces-control-user-access]]
=== Control feature access based on user privileges
When using Kibana with security, you can configure applications and features
based on your users privileges. This means different roles can have access
to different features in the same space.
Power users might have privileges to create and edit visualizations and dashboards,
while analysts or executives might have Dashboard and Canvas with read-only privileges.
See <<adding_kibana_privileges>> for details.
[role="screenshot"]
image::spaces/images/spaces-roles.png["Controlling features visiblity"]
[float]
[[spaces-moving-objects]]
=== Move saved objects between spaces
To <<managing-saved-objects-copy-to-space, copy objects>> from one space to another, open the main menu,
then click *Stack Management > Saved Objects*.
Alternately, you can move objects using {kib}'s <<managing-saved-objects-export-objects, import and export>>
interface.
. Navigate to the space that contains your saved objects.
. Export your saved objects.
. Navigate to the space where you want to import the objects.
. Import your saved objects.
. (Optional) Delete objects in the export space that you no longer need.
{kib} also has beta <<saved-objects-api-import, import>> and
<<saved-objects-api-export, export>> APIs if you want to automate this process.
[float]
[[spaces-default-route]]
=== Configure a Space-level landing page
You can create a custom experience for users by configuring the {kib} landing page on a per-space basis.
The landing page can route users to a specific dashboard, application, or saved object as they enter each space.
To configure the landing page, use the default route setting in
<<kibana-general-settings, Stack Management > {kib} > Advanced settings>>.
For example, you might set the default route to `/app/kibana#/dashboards`.
[role="screenshot"]
image::spaces/images/spaces-configure-landing-page.png["Configure space-level landing page"]
[float]
[[spaces-delete-started]]
=== Disable and version updates
Spaces are automatically enabled in {kib}. If you don't want use this feature,
you can disable it
by setting `xpack.spaces.enabled` to `false` in your
`kibana.yml` configuration file.
If you are upgrading your
version of {kib}, the default space will contain all of your existing saved objects.