Kibana: RBAC - Phase 3 - Feature Controls

[kobelb]

Overview

Phase 3 will implement the ability to hide features within each Space using a Basic license, in addition to defining feature level privileges to grant various levels of access to roles per space.

Space driven feature controls - Basic license

With a basic license, users will be able to hide features within spaces. It is important to note that this is _not_ a security feature, but instead a usability feature. This will allow users to customize each space to fit their needs, by hidings links and other functionality.

By default, all features are visible for every space. Hiding a feature is an opt-in decision. By extension, any new features that are added to Kibana will be visible by default, until they are explicitly hidden within a space. This allows new features to still be easily discovered when upgrading, and it reinforces the fact that this is _not_ a security feature.

Sample Screenshot

Security driven feature privileges - Standard/Gold/Platinum license

Once security is enabled, we will provide additional controls to actually secure access to specific features in Kibana. These controls will work regardless of whether Spaces are in use or not. Not only will this control the visibility of features in the UI, but it will also secure the Kibana API endpoints and prevent application bundles from being accessed.

With Spaces

When spaces are enabled, the Role Management screen will allow users to specify which features users are allowed to access within each space. Since each Space also controls the visibility of features, this will have additional logic to determine when a feature is shown/hidden. Configuring this does not preclude users from later disabling Spaces.

| Space Config | Role Config | Result |
| ------------ | ----------- | ------ |
| Feature Hidden | Feature Disabled | Feature not available |
| Feature Hidden | Feature Enabled | Feature not available |
| Feature Visible | Feature Disabled | Feature not available |
| Feature Visible | Feature Enabled | Feature available |

Users will be able to configure access via a UI similar to the following.

Without Spaces

When spaces are disabled, the Role Management screen will allow users to specify which features users are allowed to access within Kibana. Configuring this does not preclude users from later enabling Spaces.

Stack applications with custom privilege model

There are existing applications that implement their own privileges model that require the user to be explicitly granted various cluster and index privileges via a reserved role, which will not be able to be disabled using the security driven feature controls. Currently, there are two notable applications in this category: Machine Learning and Monitoring.

The access to these applications will continue to be driven by the reserved roles. We will be augmenting these reserved role definitions with the necessary changes, described more in-depth below, so that when the user is assigned the proper reserved role the application will be visible within Kibana. Prior to the introduction of Feature Controls, these applications have always been visible within Kibana, even if the user doesn't have the necessary privileges.

Technical Details

This phase builds rather heavily upon the RBAC - Phase 1 and RBAC - Phase 2 - Spaces infrastructure. The basis of which relies on the ability to assign Kibana specific privileges using Elasticsearch's application privileges which are then enforced by Kibana's server before granting the user access.

Privileges

The following is a list of privileges that will exist after this phase. Prior to this phase, we've only had base privileges, which allow users to assign access to all current and future features. This phase will be adding the feature privileges, which grant access to individual features.

Base Privileges

• all
• read

Feature Privileges

• Discover
  
  
  
  • all
  
  
  • read
  
  
• Visualize
  
  
  
  • all
  
  
  • read
  
  
• Dashboard
  
  
  
  • all
  
  
  • read
  
  
• Dev Tools
  
  
  
  • all
  
  
  • read
  
  
• Advanced Settings
  
  
  
  • all
  
  
  • read
  
  
• Index Patterns
  
  
  
  • all
  
  
  • read
  
  
• Timelion
  
  
  
  • all
  
  
  • read
  
  
• Graph
  
  
  
  • all
  
  
  • read
  
  
• Maps
  
  
  
  • all
  
  
  • read
  
  
• Canvas
  
  
  
  • all
  
  
  • read
  
  
• Infrastructure
  
  
  
  • all
  
  
  • read
  
  
• Logs
  
  
  
  • all
  
  
  • read
  
  
• Uptime
  
  
  
  • all
  
  
  • read
  
  

Actions

Each of these privileges will be associated with a set of actions per the ES application privileges.

The following is an example of the actions that are associated with Discover's all privilege:

[
  "login:",
  "version:7.0.0-alpha1",
  "app:kibana",
  "saved_object:search/bulk_get",
  "saved_object:search/get",
  "saved_object:search/find",
  "saved_object:search/create",
  "saved_object:search/bulk_create",
  "saved_object:search/update",
  "saved_object:search/delete",
  "saved_object:config/bulk_get",
  "saved_object:config/get",
  "saved_object:config/find",
  "saved_object:index-pattern/bulk_get",
  "saved_object:index-pattern/get",
  "saved_object:index-pattern/find",
  "ui:catalogue/discover",
  "ui:discover/show",
  "ui:discover/save"
  "ui:navLinks/kibana:discover",
]

Each of these actions corresponds to a specific authorization check which will be performed. For example, to determine whether the user is able to "find" a saved object of type "search", we check whether the user has the saved_object:search/find action, prior to permitting the user to perform the find operation. There are also actions for granting access to Kibana applications, APIs and various UI capabilities.

The relationship between privileges and actions allows us the flexibility to adjust the internal subsystems and their authorization checks while effectively granting the user the same functionality.

Plugin Extensibility

During a Kibana plugin's init lifecycle event, the plugin must register their feature to opt-in to Feature Controls. If a plugin does not opt-in to Feature Controls, their application will always be visible in the nav bar; however, they will not be granted authorization to any of the internal Kibana subsystems, such as Saved Objects.

The following is an example of registering a feature:

server.plugins.xpack_main.registerFeature({
  id: 'foo',
  name: 'Foo feature',
  icon: 'fooApp',
  navLinkId: 'foo', 
  app: ['foo', 'kibana'],
  catalogue: ['foo'],
  management: {
    kibana: ['foo'],
  },
  privileges: {
    all: {
      api: ['foo/execute'],
      savedObject: {
        all: ['foo'],
        read: ['config', 'index-pattern'],
      },
      ui: ['delete', 'save', 'show'],
    },
    read: {
      savedObject: {
        all: [],
        read: ['config', 'index-pattern', 'graph-workspace'],
      },
      ui: ['show'],
    }
  }
});

Dissecting the aforementioned feature registration, there are a few important things to note. Everything that is declared outside of the privileges subsection is used for both spaces driven feature controls and security driven feature privileges. When a feature is hidden using Spaces driven feature controls, we hide the navlink, application, catalogue entry and management section.

The privileges subsection allows the plugin author to determine the access to various subsystems when the user is assigned the feature specific all or read privileges, and also using the base all and read privileges. Everything that is declared outside the privileges subsection implicitly cascades into the privileges themselves. However, the app, catalogue and management sections are override-able at the privilege definition itself. There are additional items which are only used by the security driven feature privileges, which can only be specified as part of a privilege itself. These include authorized APIs, saved object types, and specific UI capabilities.

UI Capabilities

UI Capabilities are used for determining which capabilities should be enabled in the UI based on the Spaces disabled features and the user's privileges. When a feature is disabled using Spaces, all UI capabilities that are associated with that specific feature are disabled. Using the security driven feature privileges, different UI capabilities can be enabled or disabled based on the specific privilege.

Consuming UI Capabilities

To determine whether a specific UI capability is enabled, consumers can import uiCapabilities from ui/capabilities like the following to determine whether to render or disable specific funtionality:

import { uiCapabilities } from 'ui/capabilities';

const canSave = uiCapabilities.discover.save;

Registering UI Capabilities

Plugins in OSS which are driven by UI Capabilities must specify their full-list of capabilities within injectDefaultVars. The following illustrates the Timelion plugin doing so:

injectDefaultVars() {
        return {
          uiCapabilities: {
            timelion: {
              save: true,
            }
          }
        };
      },

This allows the OSS plugins to always check to determine whether they should be enabling the "save" capabilities.

If a plugin is within the x-pack plugin, we can take advantage of the aforementioned feature registration to automatically determine the UI capabilities based on the privileges, so this manual step in injectDefaultVars can be skipped.

Disabling UI Capabilites

Both the Spaces plugin and the Security plugin take advantage of the replaceInjectedVars lifecycle event to disable certain capabilities based on the disabled set of features for the Space, or based on the user's security privileges.

[kobelb]

For those following this Issue, I edited the description to flesh out the privileges that will be added, and began to elaborate upon the technical implementation.

[kobelb]

/cc @AlonaNadler @jinmu03

[timroes]

@kobelb I wonder what about privileges about reporting? These are not in the above list, but I think it makes sense (also see #24464 for a use-case), to give reporting it's own privileges so it can be configured on a per user basis.

[kobelb]

@timroes I think it definitely makes sense to move Reporting to this new model; however, we were considering it "out of scope" for the initial implementation, with the hope of working with the app team to move it over to the new granular privileges once we have the sufficient basis to do so.

[AlonaNadler]

@kobelb I know we talked about it in the past, and expecting users will have more granular requests for privileges within each app. There are couple services that will be available across Kibana such as alerting, reporting and maybe more in the future, these will be available in multiple locations in Kibana including within the solutions. Should we open a new issue for services privileges across applications?

[kobelb]

@AlonaNadler sure, opening separate issues for the features/applications that we'd like to be secured long-term that are currently out of scope for this phase would be great.

[kobelb]

For those following along, the description has been updated with the extension of this feature set to the basic license.

[DoubleAix]

will this feature be implemented by version 6.5 ? if not, when is it implemented?
our company use enterprise version now, but in our situation the privilege management of Kibana doesn't cope with our regulation.

[legrego]

@DoubleAix, Granular Application Privileges will not be available for 6.5. 6.5 introduces Spaces, which gives you a way to organize your saved objects, and control who has access to each space within Kibana.

Spaces was a prerequisite to implementing granular app privileges. While we can't comment on a specific release date, we have started working on this feature, so you should expect to see it in the near future! Keep an eye out on this issue if you'd like to follow along

[wirecutter313]

Will the "no access" privilege be an option for all of the applications? We have a use case where we may only want a group of users to only dashboards and discover.

I'm sure others would have a similar use case with various groupings.

[kobelb]

Will the "no access" privilege be an option for all of the applications? We have a use case where we may only want a group of users to only dashboards and discover.

Yup, you'll be able to only grant access to those 2 applications.

[fbaligand]

First, Granular Application Privileges will be great and very useful!

Then, I think there are more privileges to add :

• timelion_all
• timelion_read
• timelion_share
• ml_all
• ml_read
• infrastructure_all
• logs_all
• apm_all
• apm_read
• monitoring_all
• monitoring_read
• manage_reporting_all
• manage_reporting_read
• manage_watcher_all
• manage_license_all

[legrego]

Hey @fbaligand, I'm glad you'll find this useful! The privilege list in the issue was a bit out of date; I've just updated it to reflect our current plan.

Regarding your list, we will be offering support for Timelion, ML, Infra/Logs, APM, and Monitoring*. Reporting, Watcher, and License Management are not currently in scope for the initial release, but if that changes, we'll update this issue.

• The items I've marked with an asterix will just be an "all or nothing" approach, which will only determine if the application will be visible in Kibana. It won't control access to the features within those applications, since those are not governed by Kibana, but rather by Elasticsearch cluster/index privileges. For example, Machine Learning requires the manage_ml Cluster Privilege in order to work.

[fbaligand]

Thanks for the description update!
Nice to see all these items added!

Then, I think it would be fine to be able to hide « Management » tab. This is particularly useful for business users.

But maybe a nice way to do this is to disable manage* privileges and so Kibana does not display Management tab.
What do you think about the way to achieve « Management » tab display/hide?

[kobelb]

Then, I think it would be fine to be able to hide « Management » tab. This is particularly useful for business users.

But maybe a nice way to do this is to disable manage* privileges and so Kibana does not display Management tab.
What do you think about the way to achieve « Management » tab display/hide?

We completely agree and are working through a few options that we have in regard to the manner in which we'd like the Management tab to behave with this functionality.

[fbaligand]

Nice!

[kobelb]

The description has been updated to reflect the potential to ship the spaces driven feature controls separately from the security driven feature privileges. Additionally, we're now referring to this group of functionality as "feature controls" since they're no longer specifically tied to application or privileges. We also have decided to provide an extensible mechanism to allow applications/plugins to register their own features and optionally their own privileges.

[fbaligand]

The privileges list looks great!
Just few questions:

• does “discovery_all” means right to create a saved search ? To share a discover view ?
• I’m sad to see there is no reporting_read and reporting_all in the list.

[kobelb]

does “discovery_all” means right to create a saved search ? To share a discover view ?

It does, and it will allow the user to "share" it. More granular privileges will be added in subsequent phases.

I’m sad to see there is no reporting_read and reporting_all in the list.

Yeah... it's another subsequent phases item, as reporting uses it's own security model at the moment.

[monfera]

Canvas has been loading each workbook twice, which roughly doubles the workbook specific part of the loading latency, which is what scales with the workbook size and element contents ie. it'd be great to avoid it at all cost. As this issue has been open for some time, I'm wondering if it's possible to point out merged PRs or expedite some initial PR that'd allow Canvas bypass the need for duplicated workbook loading.

[kobelb]

@monfera it's not immediately obvious how your concerns are related to this issue, would you mind elaborating?

[monfera]

@kobelb unfortunately I don't have more info than answers from @cqliu1 and @w33ble subsequent to me asking why we're loading twice, at my link above.

Catherine wrote this:

We don't have a better way to check if a user has write permissions until granular app permissions goes into security

I haven't looked it enough to know why that is, or if there are workaround possibilities, assuming the solution for this issue is still some ways off.

[legrego]

@monfera I have a WIP here for this: https://github.com/elastic/kibana/pull/29264

[monfera]

Wow looks super promising, thanks @legrego!!!

[kobelb]

/cc @sophiec20 I'll be updating this issue with more details about how APM/Monitoring/ML will behave in this model a little later today

[fbaligand]

I’m very interested by this feature!
Particularly to limit Kibana applications visible to business clients.
Will this feature be available in Kibana 6.7 ?

[kobelb]

Will this feature be available in Kibana 6.7 ?

It will not, it's our primary focus at this point, but it missed the 6.7 release.

[fbaligand]

Ah, sad to hear this :(
So I guess it is planned for 7.0 release?

[cpmoore]

Sadly I guess this missed the 7.0 release as well?
Here's hoping for 7.1.

[wirecutter313]

Ya kinda the one thing I was looking forward to. This and the Dark Theme.

[nunosilvaaa]

when will this be released? i need those features 👍

[kobelb]

@nunosilvaaa 7.2

[nunosilvaaa]

@nunosilvaaa 7.2

thanks :)

[gabrielcalderon]

I can't wait for this feature!

[nunosilvaaa]

is there an ETA for this release?

[kobelb]

@nunosilvaaa there is not at the moment. Given the nature of software development, unexpected delays are incredibly common. I'd recommend keeping an eye on our blog for the release announcement https://www.elastic.co/blog/

[kobelb]

This is part of the 7.2 release.