[RFC] Permission Control for UI Settings in OpenSearch Dashboards

[SuZhou-Joe]

trafficstars

Background

With the introduction of the workspace feature in OpenSearch Dashboards, we implemented permission control for saved objects. During this implementation, we identified that certain configurations within UI settings should only be modifiable by specific users (e.g., dashboard administrators) while remaining readable by all users. This RFC proposes approaches to implement permission-controlled UI settings.

Problem Statement

Currently, UI settings lack a permission control mechanism, meaning any user with access to OpenSearch Dashboards can modify any UI setting. We need a solution that allows certain UI settings to be read by all users but modified only by users with specific permissions (e.g., dashboard administrators).

Below are issues that features get broken when some UI settings get incorrectly configured.

• https://github.com/opensearch-project/OpenSearch-Dashboards/issues/747

Proposed Options

Option 1: Add a new saved object controlled by ACL and a new scope

This approach involves creating a new saved object to store permission-controlled settings, leveraging the existing ACL framework.

Implementation Details:

1. Register UI settings with a scope attribute:

uiSettings: {
  "someConfig": {
    ...,
    "scope": Scope.dashboardAdmin
  }
}

2. Store these settings in a new saved object:

{
  "type": "config",
  "id": "admin_3.0.0",
  "config": {
    "someConfig": "someValue"
  },
  "permissions": {
    "read": {
      "users": ["*"]
    }
  }
}

3. The permissions field with read: { users: ["*"] } ensures all users can read the config, but only dashboard admins can update/delete it.

Pros:

• Utilizes the existing ACL wrapper for permission checks, aligning with the original design
• Provides a consistent approach for handling permissions across saved objects
• Clear separation between regular UI settings and permission-controlled settings

Cons:

• Introduces a new saved object, increasing system complexity
• Requires additional storage and management for these objects

Option 2: Add a new wrapper for permission check and a new setting attribute

This approach extends the existing UI settings framework with a new attribute for permission control.

Implementation Details:

1. Register UI settings with a managedBy attribute:

uiSettings: {
  "someConfig": {
    ...,
    "managedBy": "dashboardAdmin"
  }
}

2. Implement a new wrapper to verify if the requesting user has the required role before allowing updates.

Pros:

• More straightforward implementation that builds on the existing UI settings structure
• No need to introduce a new saved object
• Potentially simpler to understand and maintain

Cons:

• Requires extending the UI settings framework
• Introduces a new permission control wrapper separate from the ACL system, potentially causing confusion
• Less consistent with how permissions are handled elsewhere in the system

Recommendation

I recommend Option 1 for the following reasons:

1. Architectural consistency: It leverages the existing ACL framework that was designed specifically for permission control, maintaining consistency in how permissions are handled throughout the system.

2. Separation of concerns: By using a dedicated saved object type for permission-controlled settings, we maintain a clearer separation between regular settings and those requiring special permissions.

3. Future extensibility: This approach would more easily accommodate future permission models or additional permission-controlled features.

While it does introduce a new saved object, the benefits of consistency with the existing permission model outweigh this drawback. The additional complexity is justified by the improved permission model and alignment with the system's architecture.

Backwards Compatibility

This change should be backward compatible as existing UI settings will continue to function as before. New permission-controlled settings will be introduced gradually as needed.

Security Considerations

This implementation enhances security by restricting who can modify sensitive settings. Care should be taken to ensure that the permission checks cannot be bypassed.

Open Questions

• Should we consider a more granular permission model beyond just "dashboardAdmin"?
• How will this interact with other security plugins or custom security implementations?
• What is the migration strategy for existing settings that should be permission-controlled?