RBAC, OLS and Spaces

[elasticmachine]

Original comment by @kobelb:

Kibana Custom Privileges

Kibana custom privileges will be specified using the custom privileges defined on the Elasticsearch roles which is being tracked here. If users wish to specify different privileges for different logical instances of Kibana, they will be able to specify a namespace in their kibana.yml and the custom privileges will be scoped to that namespace.

For example, custom privileges will by default be defined in the kibana: namespace and if the user wishes to create a separate Kibana "cluster" that different users have access to they will be able to specify the namespace in the kibana.yml, for example kibana-marketing and all custom privileges will be within the kibana-marketing: namespace.

Phases

The roll-out of RBAC, OLS and Spaces will occur in a series of phases which build upon each other.

Phase 1 - Remove access to .kibana from end-users

#18178

Prior to these changes, end-users have had direct access to the .kibana index, which prevents us from applying the granular access control of OLS and RBAC. The first step in preparing for OLS and RBAC requires us to no longer allow the end-users direct access to the .kibana index, but instead to force all requests to go through the Kibana server which will enforce its’ own access control.

These changes will have negligible impact on most end-users. However, if they are using DLS/FLS to provide read-only-access to Kibana, this will break their implementation and objects that were private will now be public to all authorized users of Kibana. The following built-in roles will no longer have privileges to the .kibana index, but will instead have the following Kibana custom privileges:

• kibana_user: all
• kibana_dashboard_only_user: read

The role management page in Kibana will be modified to allow users to assign the Kibana custom privileges to roles, and any custom Kibana end-user roles will need to be modified to match the built-in roles. All Kibana server code that reads/writes to the .kibana index will need to be modified to use the internal Kibana user and enforce access control based on the custom privileges.

If we wish for this and/or subsequent phases to be shipped in a minor release, we’ll have to create separate kibana_user and kibana_dashboard_only_user roles and the user would have to opt-in to this functionality via a kibana.yml setting.

Phase 2 - Spaces

#18948

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 elastic/elasticsearch#29820

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.

Phase 3 - Feature Control

#20277

Phase 3 will implement granular privileges over a number of Kibana applications, powered by the Kibana privileges that can be defined on roles. The way in which these are modeled and enforced by the custom privileges is still largely to be determined.
The following is a preliminary and incomplete list of privileges:

• Visualizations
  • Read-only
  • Write
• Saved Searches
  • Read-only
  • Write
• Dashboard
  • Read-only
  • Write
• Timelion
  • Read-only
  • Write
• Graph
  • Read-only
  • Write
• Dev Tools
• Global Kibana Advanced Settings
• Index Patterns

Phase 4 - OLS

ACL

To enable OLS, an ACL with the following format will be attached to all securable objects:

{
  "owner": 123456789,
  "read": {
    "users": [ { id: 123456789, can_share: true } ],
    "roles": [ { id: "role_one", can_share: false } ]
  },
  "write": {
    "users": [ { id: 123456789, can_share: true } ],
    "roles": [ { id: "role_one", can_share: false } ]
  }
}

The users and roles above reference Elasticsearch users and roles. In addition to the Elasticsearch roles, we will utilize a role of * to denote all authenticated users.

If the user has write they will implicitly be granted read. When a user or role is assigned read or write they will be able to specify whether this user or role will be able to share the securable object with others. If the user has read and they can share the object, they will only be able to add other users and roles to read. If the user has write and they can share the object, they will be able to add other users and roles to write and read.

Implicit read permissions

When a user has read access to a Dashboard, they will implicitly be granted read access to all related Visualizations and Saved Searches. The same logic will apply once Index Patterns themselves are made securable and if a user has read access to a Visualization or Saved Search, they will be implicitly granted read access to the Index Pattern.

This simplifies the access model and allows users to assign access to the object that they intuitively wish to share without having to concern themselves with the graph of related objects. It also simplifies the technical implementation so we don’t have to explicitly assign access to the related objects and then determine if/when it should be removed when a parent object’s ACL is modified.

When a user is implicitly granted read access to a Visualization or Saved Search, it won’t show up in the user’s list of Visualizations or Saved Searches, it will only be accessible in the Dashboard UI/API. This is similar to how we’ll implement it technically, we’ll allow users to gain access to the related objects via the Dashboard, which will implicitly be granting them read access.

Summary

Phase 4 will make Saved Searches, Dashboards, Visualizations, Index Patterns and other Kibana applications (Machine Learning, Graph, Timelion) saved objects securable based on the previously described ACL.

When an object has no owner, it emulates the way that Kibana currently functions without OLS where all authenticated Kibana users have full permissions. This is purely to support migrations from older versions of Kibana that didn’t have OLS, or users that were running Kibana without security and then enabling security with OLS. An additional “Claim unowned object” privilege will be added to the kibana_user role, and the user will have to have this privilege to claim these unowned objects.

The introduction of owned Index Patterns necessitates the addition of per-user Kibana Advanced Settings, as the default index pattern is defined here. An additional section will be added to the Advanced Settings page to allow a user to override any advanced setting, the same capability will be added to the index management page.

When a securable object has no owner, they will see a dialog similar to the following allowing them to make themselves the owner:

A securable object with no owner will be represented by the non-existence of an ACL.

When a securable object has an owner, they will see a dialog similar to the following allowing them to transfer ownership and define which users and roles can read/write the object:

System administrators will always be able to transfer ownership amd modify the ACL of a securable object, incase a user erroneously claims ownership of an owned object.

All users that have a role granting them a Kibana custom privilege for the specific Kibana instance will be listed, and all roles that have a Kibana custom privilege for the Kibana specific instance will be listed as well.

It should be noted that for Kibana to be able to fully enumerate users, we will have to introduce the concept of user profiles in Kibana (that could potentially power the user specific settings) or have Elasticsearch create users for non-native realms. Currently, Elasticsearch is unable to enumerate all users for SAML/LDAP/etc. realms as these are powered by role mappings.

The list of Saved Searches, Dashboards, Visualizations and Index Patterns will have an owner column added, similar to the following:

From this phase forward, all new securable objects will be owned by the creator and they will have to share them with others. This same logic applies to objects that are imported. They will be owned by the user importing them, and can then be shared.

Additional Kibana applications (Graph, Timelion) will be modified to support a similar mechanism of claiming/transferring ownership, and listing the current owner.

In the future, there’s potential for the Kibana admin to be able to define default permissions for different users, or to use RBAC to limit users being able to create private or public securable objects. However, this level of control will not be introduced in this phase, as it might not be needed and it increases the complexity and implementation time.

[elasticmachine]

Original comment by @AlonaNadler:

@kobelb nice plan! looking forward to it,
Reading through it I had a few questions:

• Say a company grant executives a read permission to a dashboard without a write permission, does it mean they won't be able to share the dashboard unless given a write permission as well?
• In phase 2, when a user creates a new object, is it private by default?
• If a dashboard was public and a user claimed ownership can everyone still see the dashboard (assuming the user didn't change anything in the read/write/share)
• if I see a dashboard which I'm not the owner, will I have a way to know who is the owner or who shared it with me? (I think it will be good to know)

The list of Saved Searches, Dashboards, Visualizations and Index Patterns will have an owner column added,
This is great, can we take advantage of that and add created date and last modified?

• In order to specify who can read/write/share an object, will the owner need to enter the email address of each user? how can an owned dashboard be public?

[elasticmachine]

Original comment by @kobelb:

Say a company grant executives a read permission to a dashboard without a write permission, does it mean they won't be able to share the dashboard unless given a write permission as well?

The way that it's currently envisioned, the executives would have to be granted the share privilege which grants more privileges than write to be able to share it with others. I wanted the privileges to be hierarchical because it makes thing simpler technically, for example we don't have to worry about weird situations where a user can edit a securable object but they can't view it. However, whether share grants write or vice-versa is something I've flipped back and forth on while spec'ing out the approach.

My current thinking is that the ability to modify who can access a securable object is a more privileged operation than being able to edit the securable object itself. If we were to switch this and make the hierarchy: read, share, write then if a user was to have the share privilege they would be able to view the document and modify the access for the document, inherently allowing them to assign other users/roles to the write privilege effectively giving them a privilege they don't have themselves.

In phase 2, when a user creates a new object, is it private by default?

Yes

If a dashboard was public and a user claimed ownership can everyone still see the dashboard (assuming the user didn't change anything in the read/write/share)

If a user claimed ownership, it would effectively make the securable object private and they would then have to add all users to the write privilege to make it public with all users being able to view/edit it.

if I see a dashboard which I'm not the owner, will I have a way to know who is the owner or who shared it with me? (I think it will be good to know)

The Dashboards listing page will have an owner column added to it, which will reflect who owns the Dashboard. If another user (with the share privilege) was the one who shared it with me, this wouldn't be visible in the owner column, it would just display the original owner.

The list of Saved Searches, Dashboards, Visualizations and Index Patterns will have an owner column added, this is great, can we take advantage of that and add created date and last modified?

We can, it's somewhat tangential though as it's not dependent on the owner, but I can see it being helpful in general.

In order to specify who can read/write/share an object, will the owner need to enter the email address of each user? how can an owned dashboard be public?

We'll likely use an autocomplete input to allow user/role selection; however, this decision will be largely deferred to the design team. User selection won't be explicitly dependent on e-mail address, as certain identity providers (SAML/LDAP) don't necessarily have to provide this information to us. Once a Dashboard is owned, they can add * to the write privilege to make the Dashboard viewable and editable to all authenticated users. I edited the above spec to reference the * role since you asked these questions, as it's something that I was envisioning being available but failed to document.

[elasticmachine]

Original comment by @uboness:

If we were to switch this and make the hierarchy: read, share, write then if a user was to have the share privilege they would be able to view the document and modify the access for the document, inherently allowing them to assign other users/roles to the write privilege effectively giving them a privilege they don't have themselves.

@kobelb first an foremost, do whatever you think is right here... you own this.

IMO, share is less restrictive than edit. I can definitely see someone creating something and sharing it with a bunch of groups/roles, but wants to remain the only one controlling its content. It will feel strange if sharing immediately automatically provides editing/write privileges on an object.

just a side note about the statement above. If user A has a share priv. and she shares it with user B, then while sharing, user A will need to define the priv B has on the object... and it can only be up to the priv level A has on the doc. For example... if user A only has share priv (that is, read and share), the A can share the object with B and allow B to have either read or share priv... but not write as A herself doesn't have that priv.

this feels like the "right" behaviour to have... keep in mind that you will anyway need a way to define what access level the user you share the object with has on it.... it's super common in similar systems (e.g. see how google docs work). The only addition here is that you limit the options based on the current user privs on the object.

we don't have to add this complexity form day one... but if we decide that this is a direction we eventually want to go towards, it would be good to start with something that will naturally grow there. Meaning the privileges hierarchy needs to be set properly from day one.

another option is to only start with read and write priv and leave share priv for a later phase... this means that either users can always share anything they can access or only users with write privileges an share objects... however, you will still need to let them define the privileges on the objects they're sharing (you can't get away from that I'm afraid :)).

But again... this is just an input... you'll need to be making the final decisions here :)

[elasticmachine]

Original comment by @kobelb:

@uboness I just looked at how google docs does the edit/share functionality again, and it looks like when you allow a user to edit a document they're implicitly granted the "share" privilege but under the advanced settings you're able to explicitly deny them the ability to share it:

It breaks away from the strict hierarchy of the privileges, but I'm starting to think that it makes this easier for end-users to grasp. This could be modeled with the revised ACL:

{
  "owner": 123456789,
  "read": {
    "users": [ 123456789 ],
    "roles": [ "role_one" ]
  },
  "write": {
    "users": [ 123456789 ],
    "roles": [ "role_one" ]
  },
  writersCanShare: true

My only concern with this ACL is that we apply the writersCanShare logic to all writers, and we don't have the ability to specify this on an individual role/user.

[elasticmachine]

Original comment by @uboness:

My only concern with this ACL is that we apply the writersCanShare logic to all writers, and we don't have the ability to specify this on an individual role/user.

++ that was my first reaction to it as well

again... we could start by saying "if you have write, you can share" and add the restriction later (either by introducing another share priv in the middle or by adding a writeAndShare priv (which is higher than write) or by adding a share flag:

{
  "owner": 123456789,
  "read": {
    "users": [ { "id": "123456789", "can_share": true } ],
    "roles": [ { "id": "role_one", "can_share": false } ]
  },
  "write": {
    "users":  [ { "id": "123456789", "can_share": true } ],
    "roles": [ { "id": "role_two", "can_share": false } ]
  }
}

(personally I prefer either the first or the second option)

[elasticmachine]

Original comment by @joshbressers:

I wonder if we shouldn't focus on the workflow instead of the raw permissions. Let's use a dashboard for this example.

It's assumed whoever creates a dashboard can share it which by definition must grant read access.
A user can also be given write access to a document.

Should we allow read-only users to share a dashboard? I could see value in this.

Would we expect a user with write access to be able to add or remove others who can view a dashboard? Can they grant write access to a read-only user?

If we think about this from an elasticsearch style permissions model. If you can write to a document you can modify permissions. A filesystem model is a bit different. You can have access but not be able to grant others access.

If we rename "share" to "administrator", does it change the way we view this?

[elasticmachine]

Original comment by @legrego:

I like the idea of being able to give read-only users the "share"
permission too. I know this breaks the hierarchical model, but I'd like to
explore this approach if it doesn't add a ton of additional complexity.

In my mind, renaming "share" to "administrator" implies additional
permissions that aren't actually being granted. I'd expect an administrator
to have the delete permission, for example, and that wouldn't be the case
if I understand this correctly.

On Thu, Mar 15, 2018 at 9:17 AM Josh Bressers EMAIL REDACTED
wrote:

I wonder if we shouldn't focus on the workflow instead of the raw
permissions. Let's use a dashboard for this example.

It's assumed whoever creates a dashboard can share it which by definition
must grant read access.
A user can also be given write access to a document.

Should we allow read-only users to share a dashboard? I could see value in
this.

Would we expect a user with write access to be able to add or remove
others who can view a dashboard? Can they grant write access to a read-only
user?

If we think about this from an elasticsearch style permissions model. If
you can write to a document you can modify permissions. A filesystem model
is a bit different. You can have access but not be able to grant others
access.

If we rename "share" to "administrator", does it change the way we view
this?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub

.

[elasticmachine]

Original comment by @AlonaNadler:

I agree, sharing is a lower permission than editing, more users are consumers of dashboards and need to share in order to collaborate, they might not edit existing dashboards. If it simplifies, Google sheets model sounds good solution as well, if you have read you can share.

[elasticmachine]

Original comment by @kobelb:

I like what @uboness proposed at the ACL level. It provides us with the ability to specify users who can read and optionally share, as well as users who can write and optionally share; without deviating from how we'll likely present these choices to the end-user.

When the end-user is determining who to assign access, they will likely first and foremost choose whether the user should be able to read or write the securable object, then they'll decide whether the user should be able to share it as well.

I'm going to update the proposal above to reflect the new ACL and how we could present these options to the user.

[elasticmachine]

Original comment by @kobelb:

I'm treating this issue as a "living issue" in that I've been updating it based on discussions that happen here and in other side-channels, but I'll be sure to call-out what exactly has been changed within these comments. I'm trying to prevent having to switch this proposal to being in a versioned file for ease of consumption, but if the current approach is losing too much historical information we can reconsider.

After further discussions, I've decided to use the custom privileges defined on the Elasticsearch role and will be using cluster-wide custom privileges with a namespace to support separate Kibana instances; as opposed to the custom privileges on a specific Elasticsearch index to denote access to different instances of Kibana. I've updated the Kibana Custom Privileges section above to reflect this.

[elasticmachine]

Original comment by @kobelb:

/cc @clintongormley

[elasticmachine]

Original comment by @alexfrancoeur:

@kobelb This is fantastic! Thanks for putting this amount of detail in the meta issue. It was easy to consume and the phases make sense to me. I have a few questions, some may seem a bit dumb but I wasn't able to clarify from the description of the issue.

• For the same objects, can you define users that have read access that share and others that have read access and do not? Couldn't tell if this was possible given the format or UI screenshots provided at the top of the issue

• While not explicitly shown, I imagine users would be able to edit who has access and permissions through the "Actions" tab as well. Is that correct?

• If the owner of the object (user A) has given share / read permissions to user B and user B remove users that user A has shared the object with? Or does user B only have control over the users they've shared the object with?

However, if they are using DLS/FLS to provide read-only-access to Kibana, this will break their implementation and objects that were private will now be public to all authorized users of Kibana.

• Is Phase 1 considered a breaking change given then sentence above? Seems like a significant change to make all objects public. In past discussions I have, it sounds only like a handful of users are doing this.

• Will there be a separate UI for creating custom Kibana roles?

An additional section will be added to the Advanced Settings page to allow a user to override any advanced setting, the same capability will be added to the index management page.

• Woah! User specific settings!? Sounds like this the first step towards "Kibana Profiles". Nice!

When a securable object has no owner, they will see a dialog similar to the following allowing them to make themselves the owner

• What's the experience for "claiming ownership" as users upgrade to utilize OLS from an older version. Can anyone claim an object? From the subsequent comments, it sounds like this is the case. If an admin chooses to incorporate OLS on an upgrade, what's the experience for them to bulk assign ownership here? For the environments that need this feature most, I imagine they'll have 100's of dashboards and visualizations. Would we push them towards an API?

All users that have a role granting them a Kibana custom privilege for the specific Kibana instance will be listed, and all roles that have a Kibana custom privilege for the Kibana specific instance will be listed as well.

• By default, if there are no custom namespaces are we going to be showing all roles available in order share with?

• Are there plans for human readable (and filtered) groups? Or are we putting ownership on the admins to make public facing role names that can be consumable to an end user and make sense?

• Can users be assigned to multiple custom namespaces?

• Can a user who has been given write access to an object transfer it's ownership? I assume not but want to confirm

[elasticmachine]

Original comment by @kobelb:

For the same objects, can you define users that have read access that share and others that have read access and do not? Couldn't tell if this was possible given the format or UI screenshots provided at the top of the issue

Yup, you can, apologies for the crude mock-ups. The actual design will come from the design team, which should make this a lot clearer.

While not explicitly shown, I imagine users would be able to edit who has access and permissions through the "Actions" tab as well. Is that correct?

I'll defer to the design team where this is made available.

if the owner of the object (user A) has given share / read permissions to user B and user B remove users that user A has shared the object with? Or does user B only have control over the users they've shared the object with?

In this situation, user B will be able to remove all users, including those that user A might have added. It's not perfect, but I'm afraid trying to prevent this would make this rather complicated to explain to the end-user.

Is Phase 1 considered a breaking change given then sentence above? Seems like a significant change to make all objects public. In past discussions I have, it sounds only like a handful of users are doing this.

Yeah, it's definitely a breaking change, even though it's not an approach that we "support". We'll make sure to word the release notes accordingly, and if it ships in a minor it'll only be for those customers that opt-in.

Will there be a separate UI for creating custom Kibana roles?

I'll defer to design on this one :) Technically, there's no reason why we couldn't have one Elasticsearch role grant the user access to Kibana via the custom privileges and grant them access to the underlying Elasticsearch indices, but if design thinks it makes more sense to the end-users we can do so.

What's the experience for "claiming ownership" as users upgrade to utilize OLS from an older version. Can anyone claim an object? From the subsequent comments, it sounds like this is the case. If an admin chooses to incorporate OLS on an upgrade, what's the experience for them to bulk assign ownership here? For the environments that need this feature most, I imagine they'll have 100's of dashboards and visualizations. Would we push them towards an API?

We'll introduce the "claim ownership of unowned objects" privilege at this point, but this will be something all Kibana users have by default. Currently, Phase 2 doesn't include any bulk assignment screens but it's possible for us to add them at a later date if we determine they are necessary. There's potential for us to provide them with scripts of some sort to bulk assign objects to a single user, or create dedicated UIs for this management, but they increase the complexity of implementation, so I'd like to see if we really need them before adding them.

By default, if there are no custom namespaces are we going to be showing all roles available in order share with?

All Kibana roles will be shown. If the user wishes to segment this further, the current recommendation will be to use ECE/Cloud to assist with managing multiple instances of Kibana. This is dealing more with multi-tenancy, which isn't our focus with implementing OLS/RBAC.

Are there plans for human readable (and filtered) groups? Or are we putting ownership on the admins to make public facing role names that can be consumable to an end user and make sense?

For the time being, we will be using Elasticsearch roles as the single method of logically grouping together users. There's potential for us to add the concept of Kibana specific groups at a later date, but we'll likely always want to support sharing with a specific Role, and once again this simplifies our technical implementation and I'm hoping will make it easier for end-users to grasp. Only time will tell though :)

Can users be assigned to multiple custom namespaces?

Yup, they'd be given another Role that grants them access to another instance of Kibana.

Can a user who has been given write access to an object transfer it's ownership? I assume not but want to confirm

Only the owner of an object, and system administrators will be able to transfer ownership.

[elasticmachine]

Original comment by @jimgoodwin:

I like this plan!
Questions:
Is someone actually working on being able to enumerate users either in Kibana or in Elasticsearch?
What will that experience be like for users, will they get a registration page from Kibana?
Role names aren't very descriptive or could be confusing have we given thought to having some way to describe the intent of the role with some metadata text?
Am I right in saying that only the owner and the administrator can change the ACL on an object ?
Have we thought about any "convenience" methods on say a Dashboard to recursively change the acl's

[elasticmachine]

Original comment by @kobelb:

Is someone actually working on being able to enumerate users either in Kibana or in Elasticsearch?

When we add the ability to specify user specific settings in this phase, we can use the same approach to be able to enumerate all users which have logged into Kibana. I just created a discuss issue in x-pack-elasticsearch to see if we'd like to do this on the Elasticsearch side: LINK REDACTED

What will that experience be like for users, will they get a registration page from Kibana?

I'm assuming you're asking what the experience would be like for users if we're storing this information in Kibana itself. In this situation, we could transparently create these documents in the .kibana index as soon as the user logs in, if they don't exist already.

Role names aren't very descriptive or could be confusing have we given thought to having some way to describe the intent of the role with some metadata text?

You've brought up a good point, this hasn't been discussed yet, but is something we should consider. The Elasticsearch Role allows us to specify free-form "metadata" that we could take advantage of.

Am I right in saying that only the owner and the administrator can change the ACL on an object ?

Yes, you are correct.

Have we thought about any "convenience" methods on say a Dashboard to recursively change the acl's

Not specifically through the Dashboard, but there's been discussion about integrating this via the Management -> Saved Objects screen. It's currently out of scope for the specified phases though.

[elasticmachine]

Original comment by @clintongormley:

What is the purpose of having an owner of an object? How is it different from just granting the creator read, write, share, and delete permissions? The only other purposes i can think of are:

• showing who created the document
• separating "my objects" from "objects shared with me"

Do we need those functionalities?

Perhaps instead of making all objects unowned when we migrate users, we just grant all rights on existing objects to all users?

[elasticmachine]

Original comment by @kobelb:

What is the purpose of having an owner of an object? How is it different from just granting the creator read, write, share, and delete permissions?

I do see the benefit organizationally of know which objects are the ones that I created, vs the ones that have been shared with me as well.

The main other use-case the concept of ownership enables is ensuring you retain access when the securable object is shared with others. With the concept of ownership, if I create a Visualization and then allow other users to write and share the object, I can ensure that these new users don't remove me from the access list, since I'm the owner and only I and system administrators can transfer ownership.

Without the concept of ownership, if I was to allow other users to write and share the object they could then remove my access from the Visualization.

[elasticmachine]

Original comment by @clintongormley:

Without the concept of ownership, if I was to allow other users to write and share the object they could then remove my access from the Visualization.

OK, fair enough

[elasticmachine]

Original comment by @AlonaNadler:

Another side benefit of ownership model is the ability to create a private object. There several of requests for that, e.g. customers want to have a private dashboard/visualization work on it and make it public only once its ready. @brandon correct me if I'm wrong, if an owner doesn't give permission to anyone, the object is private and available/visible only to the object owner

[elasticmachine]

Original comment by @kobelb:

Another side benefit of ownership model is the ability to create a private object. There several of requests for that, e.g. customers want to have a private dashboard/visualization work on it and make it public only once its ready. @brandon correct me if I'm wrong, if an owner doesn't give permission to anyone, the object is private and available/visible only to the object owner

The concept of private objects is enabled with the concept of ownership, but it could also be modeled without the separate "owner" field and simply just:

{
  "write": {
    "users": [ { id: <alonas_user_id>, can_share: true } ],
  }
}

so it's not explicitly an advantage of the concept of ownership itself.

[elasticmachine]

Original comment by @kobelb:

After much discussion this week, an alternate Phase 2 has been proposed that implements workspaces (which we had previously planned to implement after Phase 3). I've updated the issue description to re-classify OLS in Phase 2 as "Phase 2a" and workspaces as "Phase 2b".

[elasticmachine]

Original comment by @kobelb:

Changes have been made the above description as a result of the product review, and we will be implementing spaces as the Phase 2.

[bvilnis]

Hey,
Just wondering if there is a rough ETA for the release on any of the aforementioned features? In particular the ability for multi-user support in Kibana via X-Pack? (being able to lock certain users to certain dashboards etc.)
I'm about to start the process of building a new cloud workflow for collecting, storing and displaying environmental telemetry data for the Australian mining sector and am keen to use the ELK stack for it but would need the ability to create and lockdown different dashboards for different clients as they cannot be seeing each other's data.
Any chance on a 2018 rollout for this kind of functionality?

[kobelb]

@benny-v we're currently focusing our attention on the Spaces phase outlined above, which we should release within 2018. There's potential for you to use this to create a space for each different client and restrict access based on these spaces.

Phase 4, which implements true object level security is farther out on our roadmap.

[toddferg]

Would it be possible to hide apps in addition to Read-only/write?

[legrego]

@toddferg Granular Application Privileges will allow you to hide applications per space, and secure access to spaces on a per-role basis.

We're actively working on this now, so it's not quite available yet

[fbaligand]

I have a problem with the fact that a report is not tagged per space and that reporting Index can’t be defined per space : from a security point of view, a report could contain sensible data (particularly csv report), so if all reports from any index pattern is stored in the same reporting index, that is to say that all users can access data from any index through its reports.
IMHO, this is an important security issue.

[kobelb]

I have a problem with the fact that a report is not tagged per space and that reporting Index can’t be defined per space : from a security point of view, a report could contain sensible data (particularly csv report), so if all reports from any index pattern is stored in the same reporting index, that is to say that all users can access data from any index through its reports.
IMHO, this is an important security issue.

It's arguable whether reports should be filtered based on which Space that you're in, but given that reports are only visible to the author that created them, this isn't a security issue.

[fbaligand]

Indeed :)

Thus I just tried to access all reports using GET .reporting*/_search with a user authorized simply to "reporting_user" role, and I get no results. So far the same user is able to create a report through and view it in Management app.

So this is secure enough for me :)

[kobelb]

Closing this issue as only OLS is left to be implemented, so I created a separate issue for this here: #39259