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.

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.