[feature-proposal] Dashboards security out of box

Feature request Is your feature request related to a problem? Please describe. Today, dashboards doesn’t have security(Authentication, Authorization, Role based access control (feature based, not index/doc based control)

A clear and concise description of what the problem is. Ex. I’m always frustrated when […]

Describe the solution you’d like

I’d like to install and get dashboards security out of box. below is initial thoughts about expected experience

1 Setup Use Case

1. User download dashboards artifacts
2. User start dashboards for the very first time, and see initial setup wizard page
3. Through initial setup page, user configure the connected backend for dashboards to store meta information.
4. User might choose supported authentication type, e.g. Base Auth, OpenID, etc
5. User configure the authentication type, configure the authentication
6. User configure the default admin
7. User created customized role, add other user, assign role or skip to finish
8. Initial setup done

2 Authentication

1. User login with chose authenticated method
2. Only granted feature is visible and access to user
3. User logout

3 Authorization - RBAC(Role based access control)

Role based access control is an approach to restricting system access to authorized users. In this system, user will be added multiple roles, privileges to features and resources will be granted to roles.

3.1 Role:

TODO: we need to build default/system role e.g. do we support anonymous role

3.2 Feature List

Initial proposal two level feature list as example. The first level is group of related feature/plugins, the second level the actual feature.

.
├── Dashboards
│   ├── Dashboard
│   ├── Discover
│   └── Visualize
├── Management
│   ├── Index Management
│   └── Stack Management
└── Solutions
    ├── Alerting
    ├── Machine Learning
    └── Observability

3.3 Access: Navigate, View, Update, Delete, System Admin

3.3.1 Feature based access control We want to propose role based feature access control, which admin could control what feature and which access level user could see and use.

Below are proposed typical privilege or access Dashboards will care

1. Navigate access(Visible) to the feature user could find in navigation/menu system
2. View(Readonly) access control whether feature is visible to user/role
3. All access (visible, read, edit, save, share)

3.3.2 Resource based access control (managed backend data)

• Like any file, database base system, CRUD(Create, Read, Update, Delete) access by given resource
• For OpenSearch resource, there are three hierarchy, Cluster --> Index --> Doc(by Rows) Fields (by Columns)

1. Read access whether user could read the data
2. Update access whether user could update the data
3. Delete access whether user could delete the data
4. Create access user could create the data

3.3.2.1 RBAC for OpenSearch

3.3.2.2 RBAC for multiple OpenSearch

3.3.2.3 RBAC for non-OpenSearch database

3.3.2.4 RBAC for third party service/data source integration e.g. Graphite - Timeline

3.3.3 Allow/Deny

there are two ways to manage access. Allow or Deny. Most of scenario we allow user/role to feature/resource. To be flexible, there are also case user has access to all resources, but only be prevent to specific feature/resource, that is deny rules.

4 Authorization - Service to Service

4.1 OAuth OAuth (Open Authorization[1][2]) is an open standard for access delegation, commonly used as a way for internet users to grant websites or applications access to their information on other websites but without giving them the passwords.

4.2 Pass credential from service to service

5 Examples

1. Mike is admin for both dashboards

2. Mary is VP of Operation who review and read dashboards created by DevOps team

3. John is one DevOps Lead who create dashboards and metrics to measure their sytem

Describe alternatives you’ve considered

1. Revise existing security plugins
2. Merge security plugins into dashboards

[seraphjiang]

Just curious whether the “out of box” way is to make it a native feature under src/ instead of plugins/

Good question, it means native feature and build-in functionality

Refer to below wiki as reference about OOTB https://en.m.wikipedia.org/wiki/Out_of_the_box_(feature)

[ashwin-pc]

Are there any plans in this proposal for 3rd party plugins to register their features to support the security model? e.g. a plugin should be able to register either routes or api’s that need specific auth roles to be accessible. And to take that a step further, provide options for an admin to specify which features need which auth role to access.