Define security roles for aliases

ahmadabulaban1993 · August 12, 2024, 11:29am

Versions (relevant - OpenSearch/Dashboard/Server OS/Browser):
OpenSearch: v2.16.0

Describe the issue:
I’ve created an index, with multiple aliases (aliases created with filter) related. Then I’ve define a role for each alias

Noticed that any user have one of these roles created can access the whole index and all other aliases. While it should be restricted to the alias related only

Configuration:

Create an index template with multiple aliases like below

{
  "index_patterns": [
    "messages-*"
  ],
  "template": {
    "aliases": {
      "all-messages": {},
      "messages-us": {
        "filter": {
          "term": {
            "country": "US"
          }
        }
      },
      "messages-uk": {
        "filter": {
          "term": {
            "country": "UK"
          }
        }
      },
      "messages-fr": {
        "filter": {
          "term": {
            "country": "FR"
          }
        }
      },
    }
.................

Create a role for each alias, example of one of those roles like:

"messages_us_index_role": {
    "reserved": false,
    "hidden": false,
    "cluster_permissions": [
      "indices:data/read/scroll"
    ],
    "index_permissions": [
      {
        "index_patterns": [
          "messages-us"
        ],
        "fls": [],
        "masked_fields": [],
        "allowed_actions": [
          "read"
        ]
      }
    ],
    "tenant_permissions": [],
    "static": false
  }

Create a user that own one of aliases roles (for example us_user own the role messages_us_index_role)
Try to search over messages-uk alias using us_user

Expected:
Return 403

Actual:
Return 200 and all data without any issues

Hint:
Noticed the following logs when I’ve change the opensearch logging level of org.opensearch.security package to debug

[2024-08-12T09:15:13,583][DEBUG][o.o.s.a.BackendRegistry  ] [opensearch-cluster-master-0] Rest user 'User [name=user-us, backend_roles=[messages-us], requestedTenant=null]' is authenticated
[2024-08-12T09:15:13,583][DEBUG][o.o.s.a.BackendRegistry  ] [opensearch-cluster-master-0] securitytenant 'null'
[2024-08-12T09:15:13,584][DEBUG][o.o.s.p.PrivilegesEvaluator] [opensearch-cluster-master-0] Evaluate permissions for User [name=api.uae.user, backend_roles=[sac-messages-ae-index], requestedTenant=null] on opensearch-cluster-master-0
[2024-08-12T09:15:13,584][DEBUG][o.o.s.p.PrivilegesEvaluator] [opensearch-cluster-master-0] Action: indices:data/read/search (SearchRequest)
[2024-08-12T09:15:13,584][DEBUG][o.o.s.p.PrivilegesEvaluator] [opensearch-cluster-master-0] Mapped roles: [messages_us_index_role]
[2024-08-12T09:15:13,584][DEBUG][o.o.s.r.IndexResolverReplacer] [opensearch-cluster-master-0] Resolve aliases, indices and types from SearchRequest
[2024-08-12T09:15:13,584][DEBUG][o.o.s.r.IndexResolverReplacer] [opensearch-cluster-master-0] Resolved pattern [messages-us] to indices: [messages-2024] and data-streams: []
[2024-08-12T09:15:13,585][DEBUG][o.o.s.p.PrivilegesEvaluator] [opensearch-cluster-master-0] RequestedResolved : Resolved [aliases=[messages-us], allIndices=[messages-2024], types=[*], originalRequested=[messages-us], remoteIndices=[]]

pablo · August 12, 2024, 10:45pm

@ahmadabulaban1993 As far as I’m aware OpenSearch doesn’t provide granular permission per alias.

github.com/opensearch-project/security

[FEATURE] Full resource name security for OpenSearch entities: Templates, Aliases, Pipelines

opened 12:33PM - 07 Nov 23 UTC

mrMigles

enhancement triaged

**Is your feature request related to a problem?** We're implementing security… configurations for OpenSearch based on database as a service approach. So we allow every user to work with indexes it owns, in our cases which start from {username} prefix. For example, **user1** can create/update/write/read to index **user1-test**, but can't to **user2-test**. We reached it with the role: ``` { "admin_role" : { "reserved" : false, "hidden" : false, "cluster_permissions" : [ "cluster_composite_ops", "indices:data/read/scroll/clear", "indices:admin/index_template/put", "indices:admin/index_template/get", "indices:admin/index_template/delete" ], "index_permissions" : [ { "index_patterns" : [ "${attr.internal.username}*" ], "allowed_actions" : [ "indices:*", ] }, { "index_patterns" : [ "*" ], "allowed_actions" : [ "indices:admin/resize" ] } ], "tenant_permissions" : [ ], "static" : false } } ``` We previously faced an issue, that it is not possible to strict creating aliases with specific name, but it's not critical, because created alias can't linked with index of user don't have permission to. Most important problem that we can't configure granular security for Index Templates. We would like **user to create only Template with allowed name** ({username} prefix), and **specify "index_pattern" only indexes, allowed by security pattern** ({username} prefix). But now **OpenSearch security requires to add template cluster wide permissions** and there are no granularity for name pattern. **What solution would you like?** 1. First of all I think we need additional configurations for Roles, targeted to Templates, Aliases and Pipelines (probably I missed something else). Something like: ``` "index_permissions" : [ { "index_patterns" : [ "${attr.internal.username}*" ], "allowed_actions" : [ "indices:*", ] } ], "template_permissions": [ "template_patterns" : [ "${attr.internal.username}*" ], "allowed_actions" : [ "template_all" ] } ], "alias_pemissions": [ "alias_patterns" : [ "${attr.internal.username}*" ], "allowed_actions" : [ "alias_all" ] } ] ``` And when user tries to access entity with some name it should be checked with granular permissions, not cluster. 2. There should be validation for Index Templates for `index_pattern` field to allow user to create templates only with index pattern they have an access (covered with their role). **Do you have any additional context?** Created after discussion [Add any other context or screenshots about the feature request here.](https://forum.opensearch.org/t/how-to-make-true-security-for-index-templates/16510)

github.com/opensearch-project/security

[Proposal] Resource Permissions

opened 10:07PM - 28 Jun 24 UTC

DarshitChanpura

triaged resource-permissions

## _High-Level Design_ ### Status Quo Currently, there is no mechanism provide…d by the security plugin for plugins to utilize to provide fine-grained access control to own resources created by each plugin. Some plugins have addressed this by implementing their own custom authorization mechanism, however it is not sustainable for each plugin to handle resource-level FGAC using their own custom implementation. For example, in [anomaly detection](https://opensearch.org/docs/latest/observing-your-data/ad/security/), granting permissions to delete detectors requires the user to be granted `cluster:admin/opendistro/ad/detector/delete`, which allows the user to delete all detectors in the cluster. Anomaly Detection has implemented their own authz mechanism. To avoid this the Security plugin should be the only place where authorization happens. To address this, we are introducing a new concept of Resource Permissions. This feature adds an additional step to the authorization evaluation, allowing plugins to define resource-specific permissions. ### **Feature Implementation** Once plugins define the resource permissions associated with resources, cluster admins can assign the relevant resource permissions to roles, which will then be evaluated within the Security plugin. Resource permissions can be defined in two ways: 1. Starts with `resource:<plugin-identifier>/<permission>` **(proposed)** 2. Starts with `<plugin-identifier>:<permission>` The main difference is the presence of the standard prefix `resource:`, **which simplifies validation [here](https://github.com/opensearch-project/OpenSearch/blob/2069bd805804dd93bd69695a4c6521cc6f2b9bb6/server/src/main/java/org/opensearch/transport/TransportService.java#L1097)**. The structure would look like: ``` # Allows users to use all Anomaly Detection functionality on selected resources, i.e., detectors anomaly_full_access: reserved: true cluster_permissions: - 'cluster_monitor' - 'cluster:admin/opendistro/ad/*' index_permissions: - index_patterns: - '*' allowed_actions: - 'indices_monitor' - 'indices:admin/aliases/get' - 'indices:admin/mappings/get' resource_permissions: - identifier_pattern: - 'detector1' - 'detector2' allowed_actions: - 'resource:ad/detectors/read' ``` **This allows admins to add a layer of control, restricting access to selected detectors instead of all detectors. Plugins like [alerting](https://opensearch.org/docs/latest/observing-your-data/alerting/security/), [ml-commons](https://quip-amazon.com/CBKNACJHvnRY/ML-Commons-Security-model-access-control), and flow-framework can similarly benefit by defining permissions at the resource level.** ### **Evaluation Flow Diagram** * ResourceAccessEvaluator.java ```mermaid flowchart TD A[Resource Access Evaluator.evaluate] A --> B{Does request have resources defined?} B -->|No| C[Return response as incomplete] B -->|Yes| D{Do roles have resource_permissions defined?} D -->|No| E[Return response as denied and mark complete] D -->|Yes| F[Evaluate resource_permissions for all roles] F --> G{Do resource_permissions match with supplied resource names?} G -->|Yes| H[Return response as allowed and mark complete] G -->|No| E H --> J[Return presponse] E --> J C --> J ``` * PrivilegesEvaluator.java’s evaluate() method with resource permissions check: ```mermaid flowchart TD A[PrivilegesEvaluator.evaluate] A --> B[Resolve roles] B --> C{Is bulk request for default tenant?} C -->|Yes| D[Evaluate and return presponse] C -->|No| E[Resolve all indices in the request] E --> F[Evaluate snapshot restore request] F -->|Complete| G[Return response] F -->|Incomplete| H[Evaluate security index access request] H -->|Complete| I[Return response] H -->|Incomplete| J[Evaluate protected index access request] J -->|Complete| K[Return response] J -->|Incomplete| L[Evaluate Resource Access request] L -->|Complete| M[Return response] L -->|Incomplete| N[Evaluate PIT request] N -->|Complete| O[Return response] N -->|Incomplete| P{Is cluster permission request?} P -->|Yes| Q[Evaluate cluster-level permissions and return response] P -->|No| R[Evaluater terms aggregation request] R -->|Complete| S[Return response] R -->|Incomplete| T[Perform DNFOF evaluation if enabled] T --> U[Return result] style L fill:green,stroke:#333,stroke-width:4px ``` ## _Low-Level Design_ ### **Design Questions** * Are we allowing a mix of roles with and without resource permissions? * If yes, what is the default behavior when none of the roles resolved for a user contain a resource permission? * Should the user be allowed permission to that resource? * If yes, there won’t be backward compatibility issues, but it is not ideal as the feature can be circumvented by not adding any resource permissions. * **(Proposed)** If no, there might be backward compatibility issues, especially in mixed cluster requests, which need thorough testing. * Should we allow `*` (match_all) patterns for accessing resources? OR should they be individually listed under the role? * *Note: `detector_c*` can still be allowed but the question here is, should `*` be prohibited as a resource_name pattern.* * Should `ressource_permissions` be hidden behind feature flag? * No, the primary purpose of introducing this feature is to move the authorization logic, implemented by individual plugins with resources, to Security plugin. ### File Changes 1. [ActionRequest.java](https://github.com/opensearch-project/OpenSearch/blob/main/server/src/main/java/org/opensearch/action/ActionRequest.java) 1. This base class is extended by every plugin’s implementation of transport request calls. Hence, the proposal is to add a standard class property `List<String> resources` . This should then be implemented by plugins to populate this property when handling an actionRequest after which [SecurityFilter.java](https://github.com/opensearch-project/security/blob/main/src/main/java/org/opensearch/security/filter/SecurityFilter.java) will intercept this call to perform privilege evaluation. *(It is important to note this change when creating a documentation to onboard plugin developers to this change)* 1. *Note: this is done for standardization purposes, however this can be skipped and left on the plugin developers to add this property to each request class. (Not recommended)* 2. [TransportService.java](https://github.com/opensearch-project/OpenSearch/blob/main/server/src/main/java/org/opensearch/transport/TransportService.java) 1. Add `resource:` as a valid transport action prefix [here](https://github.com/opensearch-project/OpenSearch/blob/2069bd805804dd93bd69695a4c6521cc6f2b9bb6/server/src/main/java/org/opensearch/transport/TransportService.java#L1097). 3. [RoleV7.java](https://github.com/opensearch-project/security/blob/main/src/main/java/org/opensearch/security/securityconf/impl/v7/RoleV7.java) 1. This class will now define a new type of class: `Resource` (Use the class [Index](https://github.com/opensearch-project/security/blob/main/src/main/java/org/opensearch/security/securityconf/impl/v7/RoleV7.java#L102) as reference) 2. Add this newly defined class as a property to the parent 4. ResourceAccessEvaluator.java *(new file)* 1. A new class that defines the evaluator method to verify the resource permissions. 2. This method should assume the resource names are passed in the request (the string list defined above). 3. **If no resources are present in the list, it should assume that the plugin has not opted into this feature and so should bypass this authorization check to return a success response.** 5. [PrivilegeEvaluator.java](https://github.com/opensearch-project/security/blob/main/src/main/java/org/opensearch/security/privileges/PrivilegesEvaluator.java) 1. Modify [evaluate()](https://github.com/opensearch-project/security/blob/main/src/main/java/org/opensearch/security/privileges/PrivilegesEvaluator.java#L229) method to add a check that calls the evaluator defined above. ### **Test Plan** 1. Add local tests in the security plugin. 2. Add mixed cluster tests. (To evaluate requests coming in during rolling-upgrade scenario) 3. Add tests in anomaly detection or other plugins that could leverage this feature. ### **Will the feature require a security review?** This feature will require a security review to confirm that it correctly evaluates the scope of the requested resource. ### Documentation The documentation should be added for this feature detailing how users can utilize this feature. -- ## _Next Steps_ - [ ] Open a META issue that tracks this feature - [ ] Add a task to update TransportService, in core repo, to accept a new action type prefix - [ ] Open a task to add this feature in Security Plugin (preferred if done via feature branch) - [ ] Open a follow-up issue to add tests for this feature - [ ] Open a PoC PR in anomaly detector plugin to demonstrate how this feature allows admins to allocate permissions to individual resources.

Topic		Replies	Views
How to make true security for Index templates Security discuss , configure	2	342	November 7, 2023
Roles and users Security configure	2	466	April 27, 2022
ISM and security permissions Security configure	8	82	August 15, 2024
Restrict access exclusively to 1 index Security discuss , configure	7	1180	August 9, 2024
Security and Aliases Security	3	43	November 19, 2024

Define security roles for aliases

Related topics