Introducing Kibana feature controls: Curating and securing feature access

We've continued to add new applications and features to Kibana with each release of the Elastic Stack. One of the common requests we've received is to have control over which features are available to which users.

Want to hide Dev Tools from the left navigation? Show Stack Monitoring only to admins? Or, maybe you want certain users to only have access to Dashboard and Canvas? Starting in Kibana 7.2, you can customize which features are available in each space, and you can control who has access to each feature using role-based access control.

Previously, hiding features could only be accomplished by disabling them in your kibana.yml file. This setting applied to all spaces, and all users. Now with feature controls, you have the ability to curate the Kibana experience for individual spaces and users.

Customizing available features using Spaces

You can now tailor the experience of individual spaces within Kibana. For example, you might choose to hide Dev Tools within your Marketing space if your marketing users don’t need the capabilities offered by Dev Tools.

Disabling features within spaces is primarily a usability feature, and applies to all users of the space. This works both with and without Kibana security. Enabling security allows you to secure access based on user role (see Granting access to features using security below). If this sounds interesting to you, give security a try — it’s free! If you’re not using security, then keep in mind that hiding features within a space will not prevent users from accessing the APIs directly.

Upgrade tip: All existing spaces have all features enabled by default, but you can update your existing spaces at any time.

Granting access to features using security

Prior to version 7.2, administrators could only grant read/all privileges on a per-space granularity. With feature controls, you can now grant read/all privileges at the feature level. This is a very powerful capability that allows administrators to specify fine-grained access policies for their Kibana features.

Upgrade tip: All existing roles will have access to all features. You can update your custom roles at any time to take advantage of feature controls.

Privilege types

There are a number of ways to grant access to Kibana features. If you’re upgrading from a previous version, some of these concepts will look familiar.

Base privileges

Base privileges are quick “shortcuts” that grant either read or all access to every feature. This extends to any feature that may be introduced in future versions of Kibana. The two available base privileges are “Read” and “All”:

Custom privileges

Custom privileges allow you to define which features are available to each user. Additionally, you can specify whether the user should have read or all access to each feature:

Granting privileges

You can choose to grant these privileges in one of two ways: globally or per space. Defining privileges globally allows users to access the specified features within every space. This includes spaces that you might create in the future. 

Defining privileges at the per-space level allows users to access the specified features only within the spaces you designate.

Roles are additive in nature. Users will receive the sum of all privileges granted to their assigned roles. This also applies to feature controls. For example, if you were to grant all access globally and then grant read access to an individual space, the rule that is specified globally takes precedence.

The role management interface guides you so that it’s clear you can’t revoke privileges that are granted globally. It also displays your effective privileges in the summary, so it’s obvious what you’re actually granting the user access to.

The interface will not protect you from specifying contradicting privileges across different roles, so take care when assigning roles to users. For example, if the “role1” role has Read privileges to the Discover application, but the “role2” role has no privileges to Discover, then a user assigned both of these roles would end up with read-only access to the Discover application.

Interaction of spaces and security

You can use both spaces and security at the same time to control access to features. You can hide features at the space level, and additionally secure access to features using role-based access control.

When used together, features are only available when they are visible in the space, and when the user is authorized for the feature: 

Conclusion

Go forth and customize your Kibana experience! You can now adjust it appropriately to allow multiple groups to use the same instance, and to allow different types of users to have different levels of access. If you're not ready to upgrade but want to give it a try, spin up an Elasticsearch Service cluster for free for 14 days. And while you're there, give our other premium features a try.

Let us know how things go! We are actively working on improving the user experience around feature controls, so your input is valuable. Check out the documentation, ask questions on Discuss, and create feature requests on GitHub.