Kibana Spaces #17970
Comments
|
Original comment by @cjcenizal:
Does anyone else find "Workspace" to be a confusing term? Are there examples of "Workspace" used by other products and services for this purpose? I'd find "Organization" or "Work group" to be clearer. For context, both LINK REDACTED and LINK REDACTED use the term "Organization" for this type of feature. |
|
Original comment by @spalger: I think we could use "Organization" or something similar, but I don't like the artificial limitation it implies. |
|
Original comment by @alexfrancoeur: I agree - when I think of a workspace I feel as if it's my own and is user specific. We don't want users creating workspaces for each user. "Groups", "Organization" or something similar might be better. We want the naming to hint that it's meant for a group of people. |
|
Original comment by @cjcenizal: I don't want to restrict how people choose to create/use workspaces either, but we should use a term that communicates meaning as clearly as possible. Personally, I think of a workspace as my desk surface. It's where I go to arrange my pens, notebooks, laptop, etc in a usable way. I think this term would map well to a feature that allows you to configure and save your Kibana UI, but it doesn't map well to a feature that lets you define "groups of people". |
|
Original comment by @alexfrancoeur: I wanted to link #11632 to this issue as I believe the new saved object API is a prerequisite for workspaces |
|
Original comment by @epixa: @alexfrancoeur It is not a technically a prerequisite, though it will probably make things at least easier to test if not easier to implement. |
|
Original comment by @snide: Notes for myself / design after talking with @epixa :
|
|
Original comment by @skearns64:
Are we planning to tie workspace access to specific roles, like we do with Dashboard-only mode (which isn't a security feature), or based on privileges to the underlying index used by the workspace (which would be a security feature)? |
|
Original comment by @epixa: From a UI interaction standpoint, people can think of workspaces as being associated with roles. This way you can create a workspace and assign roles at the same time, and see whether a given role has access to a workspace alongside things like dashboard only mode. Behind the scenes, I think the source of truth on this should be the underlying permissions, so it isn't possible to have workspaces/roles/permissions get out of sync and the same underlying security model that is used for kibana now can be used for workspaces tomorrow. |
|
Original comment by @joshbressers: We will have to be mindful of what happens when a role and a user's permissions don't agree. For example what would these two situations result in?
|
|
Original comment by @epixa: @joshbressers If we we rely on the resulting permissions behind the scenes rather than creating a separate explicit relationship between roles and workspaces, then we don't need to be mindful of this, as it is just using Elasticsearch's existing security model, which also happens to be Kibana's existing security model. In other words, how we handle permissions wouldn't change with the addition of workspaces, only the index in which a workspace's data is stored. You'd still need to manually grant access to non-kibana indices and the like. |
|
Original comment by @joshbressers: OK, good. I misunderstood your last comment. This makes more sense now. This is the right way to deal with this. |
|
Original comment by @snide: Some workspace spec designs, mostly in K7, but also did some concepts for how we could deal with selection in K6. Notes
|
|
Original comment by @alexfrancoeur: @snide if a user did not have any workspaces configured, would we show the current kibana server name or would this just be blank? |
|
Original comment by @snide: @alexfrancoeur CJ suggested "Default workspace" as the name, rather than "Kibana". I think we need to show it, even if only one exists. Again, this is another spot where calling these things "projects" makes more sense. |
|
Original comment by @cjcenizal: I agree that renaming this feature "Projects" will help. In terms of the default name, I think it might send a confusing message to name one "Kibana", because it sounds special/important, especially considering the app is called Kibana, we have a |
|
Original comment by @alexfrancoeur: @snide @cjcenizal If customized, the default workspace / project could take on the name of the kibana server name as well. Is that still confusing? For instance if users have kibana-prod, kibana-qa or kibana-dev - we could show that server name and provide the user with a reminder as to what environment they are in. This may be a separate issue but it seemed to gel with the proposed design. In regards to projects vs. workspaces, every customer I've spoken to thinks of using this concept for specific internal teams or external customers. To me, "workspace" sounds more in line with having a private area for that group or customer to work in. I see the benefits of "project" as it alludes to multiple projects within a group but I personally think workspaces makes more sense in context of how our users are thinking about the concept already. |
|
Original comment by @epixa: @alexfrancoeur We should treat server-side configurations such as server.name as sensitive information that shouldn't be exposed to end-users. That value could very well be a good name for the default workspace on one install, but it could be a sensitive internal network id or something like that in another. +1 to what @alexfrancoeur said about projects not feeling like the right name for this based on how customers plan to use it.
Why do you think that? Since users themselves will not be able to create workspaces, it seemed convenient that the whole concept of workspaces essentially just melted away if the user has no means to do anything with it. |
|
Original comment by @snide: @epixa None of these are great reasons, but I'll bring them up. It's obviously easier to design not showing it.
|
|
Original comment by @alexfrancoeur: In the latest Platform meeting we discussed dropping the "Work" from "Workspaces" and would like to call this feature Kibana Spaces. Everyone generally liked it, any thoughts from the group? |
|
Original comment by @cjcenizal: @alexfrancoeur My immediate impression is that it's too vague -- vaguer than Workspaces. 😄 Could you explain the thought process and why people liked this more? |
|
Original comment by @alexfrancoeur: @cjcenizal it was just a suggestion from @jimgoodwin and in the very brief discussion we had, the group seemed to like it. From my perspective it seems to be fairly common terminology for defining an area that a single person or group of people can work / collaborate in. LINK REDACTED) I feel like we're going to have to get a vote going soon |
|
Original comment by @alexfrancoeur: Latest spec doc from Spencer is in a google doc LINK REDACTED |
|
Original comment by @spalger: Sorry this issue has gotten stale. Many discussions happened in berlin/slack/zoom without any record or sharing and it has left people out of the loop. We still plan to have these discussions but I will post here every time things change to help keep everyone updated. Outer SpaceWe generally agree that space-limited apps like Dashboard need to be visually distinct from stack-limited apps like ML and Monitoring. We hope this will help the user understand that they are operating in a different context. See "Not every app is space-specific" in the google doc LINK REDACTED for more information about the distinction between space and stack limited apps. When a user who is used to their changes only affecting other users of the XYZ Space gets access to Outer Space, they will hopefully be able to tell when they are in which scope. See POC (below) for a visual example Routing/Default spaceWe plan to use a url prefix to designate which space a user is in; We think this will be a bigger issue than expected for a couple reasons:
To mitigate the BWC and saved link issues we are thinking that we might not include space information in the URL, but would try to infer it from the primary Saved Object loaded by the application. This would theoretically allow saved objects to move between spaces without their URL changing. This would have a pretty severe impact on how Kibana handles routing, increases the complexity of implementation significantly, and would require some other method to specify the space in API requests, but is possible. To mitigate the documentation and blog post URL issues, we're thinking that personal spaces could be used for requests that don't specify a specific space, rather than requiring a shared default space. Open SourceWe have discussed the possibility of implementing the core of Spaces in Kibana OSS and the security components in X-Pack. Doing this would make implementation much simpler across the board (especially if we decide that URLs can not include space specific information), would add a pretty nice feature to OSS Kibana assuming users didn't need access control, and diminishes the differences between the OSS and X-Pack UX by bringing Outer Space to open source. No authorization in KibanaIn order to prevent Kibana from being a threat to the security of the whole stack we are reevaluating the option of using elasticsearch for all authorization. This was the original approach we took, and we decided against it because:
Our current thinking is that:
The user without a spaceIt would be ideal if a user never successfully logged into Kibana and saw a message telling them they couldn't do anything, but this is currently the case until a user is given access to their first Space. Personal spaces would solve this, but requires one of:
POCLINK REDACTED In order to better understand how navigation/login/Outer Space will work I built a POC (major thanks to the folks working on LINK REDACTED!) that implements the following:
|
|
Original comment by @cjcenizal: @spalger Great job building out this POC! I love the attention to detail. So is Outer Space going to become a real thing???? |
|
Original comment by @spalger: Just met with @AlonaNadler, @skearns64, @tbragin, and @epixa. We ran way over, and @skearns64 and @tbragin had to leave on time but I think we made good progress recording: LINK REDACTED Discussion
Decisions
|
|
Original comment by @tbragin: Thanks for the notes, @spalger! I'm curious whether the decisions that were made on Tuesday affect our plans with the open-sourcing of the Spaces feature (aside from securing the Spaces). I think that's a big change from what we originally discussed, and would love to understand that further. I'll throw another chat on the calendar for Friday to hopefully dig into the reasoning behind that more. |
|
Original comment by @epixa: The rationale for putting the insecure notion of spaces in OSS and then having xpack secure it is simply that it dramatically simplifies things from a technical standpoint. More notes on this in a gist LINK REDACTED |
|
Original comment by @spalger: Chatted with Alona and we both worry that spaces will cause more confusion when people are trying to find a specific dashboard (especially when they aren't using Kibana very often). To address that I want to mockup two things:
|
|
Original comment by @snide: @spalger @AlonaNadler If you go in this direction please consider just wrapping this into global search, which we need anyway and can superset that issue. We need to have ONE search across Kibana, not many. No reason spaces / recently visited stuff can't appear in the global set. cc @timroes
|
|
Original comment by @epixa:
I think this is a real possibility, but it's not necessarily set in stone. A lot of it depends on how the feature evolves from a usage standpoint. For example, if the vast majority of organizations only have a couple spaces and the vast majority of users only belong to a single space, then the confusion will be much less than if spaces are widely used and many people belong to multiple spaces. And beyond sheer usage numbers, what people are actually creating spaces for will impact this a lot as well. For example, if it's common to set up spaces for teams within your company, "losing" a dashboard may not be very common. If you belong to a |
|
Original comment by @epixa: So in other words, I think we should keep an eye on this, but we shouldn't jump to any conclusions without seeing usage. |
|
Original comment by @kobelb: Based on our discussions the previous weeks, work on Spaces will begin again with the @elastic/kibana-security owning it. I've updated the description of this issue with the current approach. |
elasticmachine
added
Team:Core
epixa
added
enhancement
|
Closing this out in favor of #18948 which has more up to date information |
Original comment by @spalger:
When a user logs into Kibana, they will be presented with a spaces chooser that allows them to choose a space. From this point forward, all saved objects will be filtered and saved within that space. Spaces will be available in x-pack basic as an organization feature, and will be securable once Security is enabled.
An indicator of the selected workspace and a switcher will be displayed via the Kibana navigation bar.
Saved objects exist within a single space, and they cannot be shared between multiple workspaces. A systems administrator will be able to manage the spaces, via a UI similar to the following:
When a space is deleted, it will cascade the delete to all saved objects within the workspace. Additionally, Kibana UI Settings will be space specific, and the settings from the default workspace will be copied to the new space when it’s created.
Roles will grant read-only/write access to different spaces. This will utilize the custom privileges support that Elasticsearch is implementing in LINK REDACTED
There will always be a “default” space in Kibana. This is where saved objects that were created before spaces are enabled will go; and where dashboards, visualizations, etc. that are imported via Beats will be created, until their workflows are augmented to allow the user to choose a space.
Kibana’s URL routing will be modified to include the optional
/space/{spaceId}path, and if one is not present we will assume the default space. URLs for saved objects that were created before spaces is enabled will work as long as saved object continues to exist within the default space. If it’s moved to another workspace, the previous URLs (including short URLs) will no longer work and the user will get the equivalent of a 404.ML, APM, Monitoring and Reporting will exist outside of the context of spaces, and continue to use cluster-wide settings and indices. These applications should include some type of indicator that they aren’t within a space, so the user is aware that they are cluster-wide.
When saved objects are exported, we will omit the space in which they currently belong; and when they are imported they will be assigned to the currently selected space.
Tasks
Updated March 31 with decision to move forward with Index/X-Pack Security based approach to permissions.
Previous iterations backed up in a google doc LINK REDACTED for posterity sake.
Kibana Workspaces create "silos" in Kibana for different groups of people to work together. Saved Objects and configuration will be unique to each workspace.
Original breakdown
User Experience
kibana.yml/will determine which workspaces a user can accessHow/Implementation/Integration
.xpack-ws-{id}-{domain}format:.xpack-ws-{id}-kibanafor kibana saved objects.xpack-ws-{id}-reportingfor reporting jobs.xpack-workspaces.xpack-workspaces.xpack-ws-{id}-kibanaand.xpack-ws-{id}-reporting.xpack-workspaces,.xpack-ws-*-reporting, and.xpack-ws-*-kibanapatterns.xpack-workspacesindex exists.xpack-workspacesindex/app/:appname(just like today)/ws/:id/app/:appnamekbnIndexandbasePathUI vars will be injected based on the current workspace/api/:pluginand/ws/:id/api/:pluginUndecided
superuserrole?KbnServerinstancesKbnServerinstance that has modified configurationKbnServerinstances as necessaryKbnServerinstances when not used for some timeThe text was updated successfully, but these errors were encountered: