[feature-proposal] Dashboards security out of box

[seraphjiang]

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

[tianleh]

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

[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)

[kavilla]

Is there a corresponding issue for OpenSearch associated with this issue?

[seanneumann]

Is there a corresponding issue for OpenSearch associated with this issue?

https://github.com/opensearch-project/OpenSearch/issues/1029

[seraphjiang]

Is there a corresponding issue for OpenSearch associated with this issue?

we could take a look that RFC, but we should think from end user point view, before jump into backend implementation detail to avoid bias. In the case backend's RFC/Design doesn't support what end user need. We should raise the issue to their repo and ask for change.

besides https://github.com/opensearch-project/OpenSearch/issues/1029, another opensearch related item is https://github.com/opensearch-project/OpenSearch/issues/1618

[zengyan-amazon]

It seems to me typical RBAC may not suffice, in addition to access control against operations, we may also need to support resource level access control.

In the case of a typical RBAC, we have control against user permissions to perform certain operations, such as:

• user1 has RW permission to index-patterns/visualizations
• user2 has RO permission to dashboards/visualization/index-pattern etc. But it has no control on resources, which means, if a user can read index patterns, then they can access all index pattern documents.

This will be a discrepancy with OpenSearch, as OpenSearch provides access control at resource level. In the case when 2 department/org use the same OSD service, and requires some data isolation, they will have resource level access control on the OpenSearch side, but if OSD doens't have it, OSD users will see index-patterns (includes field names and types) of indices they have no access

[kgcreative]

Are we differentiating between Dashboards users and Engine (backend) users? How do we disambiguate between a user logging into Dashboards, vs a user logging into a Cluster? Will we pass credentials through?

[cliu123]

Through initial setup page, user configure the connected backend for dashboards to store meta information.

What does user configure at this step? Does user select a DB to store meta information and connect the DB to Dashboards?

[davidlago]

We should be more explicit about differentiating between Dashboard entities (visualizations, dashboards, index patterns) and backend entities (cluster, index, document, field)

[kgcreative]

Similar to @zengyan-amazon's comment, is there a plan to differentiate between access control to data, vs access control to dashboards objects. For example, what happens if a visualization has been shared with me, but I don't have access to the underlying indices or index patterns? Will the user see an error? Will they have a way to authenticate to the backing cluster?

[cliu123]

3.3.1 Feature based access control

One of the options is to combine this with role-based access control. Having static roles for features, mapping the static roles to users would grant users the permissions to the features.

[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.

[shanilpa]

Tracking use cases and additional discussions related to this topic in this thread: https://github.com/opensearch-project/ux/discussions/54. If you have use cases to consider, comments, or thoughts feel free to add to the discussion thread.