[Proposal] Resource Permissions and Sharing

[DarshitChanpura]

This proposal has seen few edits of designs, please read through comments to understand the latest approach.

---

Updated as of: 28-Aug-2025

[HLD] Resource Sharing & Access Control in OpenSearch

1) Overview

Starting in OpenSearch v3.2.0, the Resource Sharing & Access Control framework enables document-level authorization for plugin-defined resources.
Key highlights:

• 1:1 backing sharing indices per resource index (clean ownership & isolation).
• Automatic evaluation via ResourceAccessEvaluator (no plugin in-house verification via filter_by_backend_role).
• Dashboards-native APIs to fetch, update, and list sharing info.
• Migration API to move legacy per-plugin sharing into security-owned indices.
• Action-groups defined by plugins will be the ones available for sharing.

Feature flag (experimental, default: false):

plugins.security.experimental.resource_sharing.enabled: true

---

2) Motivation

Problems: index-scoped RBAC can’t restrict specific documents; plugins built custom auth; no central UX for sharing.

Solution: standardize sharing with:

• Backing sharing index per resource index
• Central evaluation in Security Plugin
• First-class Dashboards APIs & UI for access management

---

3) Architecture & Components

• Resource Plugins define resources (stored in system indices) and register a ResourceSharingExtension.

• Security Plugin:

  • Maintains Index→SharingIndex mapping
  • Stores sharing docs in per-plugin backing indices
  • Runs ResourceAccessEvaluator for auto authz
  • Exposes Dashboards Share APIs and List-Accessible API

3.1 Architecture (with Dashboards flows)

flowchart TD
    U[User / OpenSearch Dashboards] -->|Create/Read/Update/Delete| PL[Resource Plugin]

    subgraph Security[Security Plugin]
      API[Security REST Endpoints - Dashboards Share & List-Accessible]
      RAE[ResourceAccessEvaluator - automatic evaluation]
      MAP[Index - SharingIndex Mapping]
    end

    subgraph Data[System Indices - Per Plugin]
      RIDX1[(Resource Index A)]
      RSIDX1[(Sharing Index A)]
      RIDX2[(Resource Index B)]
      RSIDX2[(Sharing Index B)]
    end

    PL --> RIDX1
    PL --> RIDX2

    %% Auto-eval for resource requests
    PL --> RAE
    RAE --> MAP
    MAP -->|resolve| RSIDX1
    MAP -->|resolve| RSIDX2

    %% Dashboards Access Mgmt flows
    U -->|Share UI GET/PUT/PATCH| API
    API --> MAP
    MAP --> RSIDX1 & RSIDX2

Loading

---

4) Data Model (Per-Plugin Backing Sharing Index)

Each resource index has a backing sharing index storing the sharing document:

{
  "resource_id": "resource-123",
  "created_by": {
    "user": "abc"
  },
  "share_with": {
    "READ_ONLY": {
      "users": ["user1", "user2"],
      "roles": ["viewer_role"],
      "backend_roles": ["data_analyst"]
    },
    "READ_WRITE": {
      "users": ["admin_user"],
      "roles": ["editor_role"],
      "backend_roles": ["content_manager"]
    }
  }
}

Field	Type	Description
resource_id	String	Unique document ID in the resource index
created_by	Object	{ "user": <username> }
share_with	Object	Access-level → principals (READ_ONLY, READ_WRITE)

Mapping: Resource index → Sharing index (convention):

• .plugins-ml-model-group → .plugins-ml-model-group-sharing
• ad-detectors → ad-detectors-sharing

Note: The relationship between entries in this index and the resource metadata stored in plugin’s index is many-to-one.

Access scope is defined in 3 ways:

• public: A shared_with entry exists, and contains users entry mapped to * .
• restricted: A shared_with entry exists, and contains users entry not mapped to * .
• private: A shared_with entry is empty or doesn’t exist.

Here are 3 examples of entries in resource_sharing index, one for each scope.

1. Private:

{
  "resource_id": "<doc_id>",
  "created_by": {
    "user": "darshit"
  }
}

2. Restricted:

{
  "resource_id": "<doc_id>",
  "created_by": {
    "user": "darshit"
  },
  "share_with": {
    "read_only": {
      "users": [
        "derek"
      ],
      "roles": [],
      "backend_roles": []
    },
    "read_write": {
      "users": [
        "craig"
      ],
      "roles": [],
      "backend_roles": []
    }
  }
}

3. Public:

{
  "resource_id": "<doc_id>",
  "created_by": {
    "user": "darshit"
  },
  "share_with": {
    "read_only": {
      "users": ["*"],
      "roles": ["*"],
      "backend_roles": ["*"]
    },
    "read_write": {
      "users": [
        "*"
      ],
      "roles": ["*"],
      "backend_roles": ["*"]
    }
  }
}

NOTE: Each user, role and backend_role must be individually added as there is no pattern matching at present by design.

---

5) Automatic Access Evaluation

All DocRequest paths are intercepted by the Security Filter and evaluated by ResourceAccessEvaluator.

5.1 Evaluation flow

sequenceDiagram
    participant User
    participant Plugin as Resource Plugin
    participant SecFilter as Security Filter
    participant RAE as ResourceAccessEvaluator
    participant Map as Index→SharingIndex Mapping
    participant RSIDX as Backing Sharing Index

    User->>Plugin: Request (e.g., GET /resource/{id})
    Plugin->>SecFilter: Routed through security
    SecFilter->>RAE: Evaluate (user, roles, backend_roles, action)
    RAE->>Map: Resolve sharing index for resource_type
    Map-->>RAE: sharing_index_name
    RAE->>RSIDX: Fetch sharing doc by resource_id
    RSIDX-->>RAE: share_with + created_by
    RAE->>RAE: Check required access level
    alt Allowed
        RAE-->>SecFilter: ALLOW
        SecFilter-->>Plugin: Proceed
        Plugin-->>User: 200 OK
    else Denied
        RAE-->>SecFilter: DENY
        SecFilter-->>Plugin: 403 Forbidden
        Plugin-->>User: 403
    end

Loading

---

6) Dashboards APIs (Access Management UI)

Base path (security dashboards endpoints):

/_plugins/_security/api/resource/share

6.1 Fetch Sharing Info (Dashboards)

GET /_plugins/_security/api/resource/share?resource_id=<id>&resource_type=<idx>

Response:

{
  "sharing_info": {
    "resource_id": "resource-123",
    "created_by": { "user": "abc" },
    "share_with": {
      "READ_ONLY": { "users": ["alice"], "roles": [], "backend_roles": [] },
      "READ_WRITE": { "users": ["bob"] }
    }
  }
}

6.2 Replace Sharing (PUT)

PUT /_plugins/_security/api/resource/share

Body:

{
  "resource_id": "resource-123",
  "resource_type": "sample-resource-index",
  "share_with": {
    "READ_ONLY": { "users": ["alice"] },
    "READ_WRITE": { "users": ["bob"] }
  }
}

6.3 Patch Sharing (non-destructive)

PATCH /_plugins/_security/api/resource/share

Body (example):

{
  "resource_id": "resource-123",
  "resource_type": "sample-resource-index",
  "add": {
    "READ_ONLY": { "users": ["charlie"] }
    "FULL_ACCESS": { "users": ["alice"] }
  },
  "revoke": {
    "READ_ONLY": { "users": ["alice"] },
    "READ_WRITE": { "users": ["bob"] }
  }
}

6.4 List Available Resource Types

(available as drop-down in UI to fetch corresponding sharing records)

GET /_plugins/_security/api/resource/types

As user alice, above http request would return following response:
Response:

{
  "types": [
    {
      "type": "org.opensearch.sample.SampleResource",
      "index": ".sample_resource",
      "action_groups": ["sample_read_only", "sample_read_write", "sample_full_access"]
    }
  ]
}

6.5 List Accessible Resources (for UI tables)

GET /_plugins/_security/api/resource/list?resource_type=<idx>

As user alice, above http request would return following response:
Response:

{
  "resources": [
    {
      "resource_id": "resource-123",
      "created_by": {
        "user": "abc"
      },
      "share_with": {
        "READ_ONLY": {
          "users": [
            "alice"
          ],
          "roles": [],
          "backend_roles": []
        }
      },
     "can_share": false
    },
    {
      "resource_id": "resource-456",
      "created_by": {
        "user": "def"
      },
      "share_with": {
        "FULL_ACCESS": {
          "users": [
            "alice"
          ]
        }
      }
     "can_share": true
    }
  ]
}

6.5 Dashboards flows (integrated)

sequenceDiagram
    participant UI as Dashboards UI (Access Mgmt)
    participant API as Security Dashboards Share API
    participant Core as Security Plugin Core
    participant Map as Index→SharingIndex Mapping
    participant RSIDX as Backing Sharing Index

    rect rgb(120,120,120)
    UI->>API: GET /share?resource_id&resource_type
    API->>Core: Authz (owner/admin/share-manager)
    Core->>Map: Resolve sharing index
    Map-->>Core: sharing_index_name
    Core->>RSIDX: GET sharing doc
    RSIDX-->>Core: sharing_info
    Core-->>UI: 200 (sharing_info)
    end

    rect rgb(120,120,120)
    UI->>API: PUT/PATCH /share
    API->>Core: Validate + authorize
    Core->>Map: Resolve sharing index
    Map-->>Core: sharing_index_name
    Core->>RSIDX: Upsert / Patch sharing doc
    RSIDX-->>Core: ack (updated doc)
    Core-->>UI: 200 (updated sharing_info)
    end

    rect rgb(120,120,120)
    UI->>API: GET /share/accessible?resource_type&from&size
    API->>Core: Compute principals (user/roles/backend_roles)
    Core->>RSIDX: Query share_with contains principals
    RSIDX-->>Core: [resource_ids...], total
    Core-->>UI: 200 {resource_ids, total, page}
    end

Loading

---

7) Plugin Developer Requirements

• Mark resource indices as system indices (prevents direct access).

• Implement ResourceSharingExtension and register via:

  src/main/resources/META-INF/services/org.opensearch.security.spi.ResourceSharingExtension
  

• Declare action-groups per resource in resource-action-groups.yml file:

  src/main/resources/resource-action-groups.yml
  

• Depend on opensearch-security-spi (compileOnly) and extend security plugin (optional).

• Rely on ResourceAccessEvaluator via Security Filter for access verification. Do not call verifyAccess unless a hierarchical evaluation is needed.

• Use client methods where applicable (share, revoke, getAccessibleResourceIds) for non-filter flows (e.g., management tasks).

---

8) Migration API (to per-index backing sharing)

POST /_plugins/_security/api/resources/migrate

Request (example):

{
  "source_index": "sample-plugin-index",
  "username_path": "/owner",
  "backend_roles_path": "/access/backend_roles",
  "default_access_level": "READ_ONLY"
}

Summary response:

{
  "summary": "Migration complete. migrated 10; skippedNoUser 2; failed 1",
  "skippedResources": ["doc-17", "doc-22"]
}

Migration flow

sequenceDiagram
    participant Admin as Cluster Admin
    participant MAPI as Migration API
    participant Core as Security Plugin (Migration)
    participant Src as Resource Index
    participant RSIDX as Backing Sharing Index

    Admin->>MAPI: POST /resources/migrate {...}
    MAPI->>Core: Validate + resolve backing sharing index
    Core->>Src: Scroll documents
    loop each doc
        Core->>RSIDX: Upsert sharing doc<br>{resource_id, created_by.user,share_with[default].backend_roles}
    end
    RSIDX-->>Core: Stats
    Core-->>Admin: 200 OK (summary)

Loading

---

9) Security Rules & Best Practices

• Keep system index protection ON to prevent direct index access.
• Least privilege: share only required principals; avoid wildcards unless necessary.
• Owners & super-admins retain full control irrespective of config.
• Ensure consistent resource_id handling between the resource index and sharing index.

---

10) End-to-End Lifecycle (happy path)

sequenceDiagram
    participant Dev as Plugin Dev
    participant Plugin as Resource Plugin
    participant Sec as Security Plugin
    participant UI as Dashboards
    participant User as End User

    Dev->>Plugin: Implement ResourceSharingExtension + DocRequest
    Plugin->>Sec: Register (SPI) on startup
    User->>Plugin: Create resource (doc in resource index)
    UI->>Sec: PUT/PATCH /share (configure share_with)
    Sec->>Sec: Write to backing sharing index
    User->>Plugin: Read/Search resource
    Plugin->>Sec: (Security Filter) → ResourceAccessEvaluator
    Sec-->>Plugin: ALLOW / DENY
    Plugin-->>User: Response (200 / 403)

Loading

---

11) License

Apache 2.0 — © OpenSearch Contributors.

---

Visual representations: #4500 (comment)

---

Old designs: #4500 (comment)

[shikharj05]

Thanks for the proposal @DarshitChanpura ! This looks interesting! High-level comments-

From what I understand, this proposal is targeting current roles and adding new resource_permissions to the existing RBAC system. What are your thoughts about treating resources as entities and allowing admins/users to tie up ACLs with a resource? For example, treating detector as a resource and access control will be defined on this resource (i.e. close to the entity being evaluated).

This proposal talks in depth about plugins, can you add an example if such a resource is added by core. This could also pave the way for treating indices as resources and tying down an ACL with them.

As this is introducing a new field/permission model, should this be a new config_version ? Also, there's another RFC to retire V6 #4493 , I think we can use this opportunity to define how new permissions models/config_version changes should be added and older ones removed. Thoughts @DarshitChanpura @cwperks ?

[shikharj05]

Adding few more comments on each design question-

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.

For backwards compatibility, I think this should be introduced with default behavior of treating * as a resource on a role that doesn't have any explicit definitions of resource_permissions. I agree that this might not be the best security behavior, however, it allows for smoother upgrades and easier migration path for customers. To negate circumventing of the feature, for any new roles being created, resource_permissions must be explicitly added (maybe, we can add similar requirement for updates to existing roles). Thoughts?

For example, an existing role without resource permissions specified would be treated as equal to the following-

# Allow users to read Anomaly Detection detectors and results
anomaly_read_access:
  reserved: true
  cluster_permissions:
    - 'cluster:admin/opendistro/ad/detector/info'
    - 'cluster:admin/opendistro/ad/detector/search'
    - 'cluster:admin/opendistro/ad/detector/validate'
    - 'cluster:admin/opendistro/ad/detectors/get'
    - 'cluster:admin/opendistro/ad/result/search'
    - 'cluster:admin/opendistro/ad/result/topAnomalies'
    - 'cluster:admin/opendistro/ad/tasks/search'
  resource_permissions:
    - '*'

This would allow users upgrading to newer versions of OpenSearch where these permissions are introduced while letting users/admins define more granular access control methods.

[shikharj05]

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.

For the reasons mentioned in previous comment, I think * needs to be allowed.

[shikharj05]

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.

I agree with the requirement, however, this could also break existing customers. If we can cover migrations/upgrades with enough tests, it should be okay to use a feature flag to enable it. However, I would prefer a flag to turn this functionality on/off smoothly for initial release as this could be a breaking change.

[shikharj05]

File Changes

For file change, kindly consider the changes being brought in by #3870 and ensure changes are compatible with the RFC.

RoleV7.java

Since this introduces a new class in existing model, do you know if contents of this class are sent over transport channel with requests? If so, this could cause issues during ugprades in a mixed-version cluster.

[stephen-crawford]

[Triage] Hi @DarshitChanpura, thanks for filing this issue. This proposal/rfc is for the resource permissions you are working on. I will go ahead and mark it as triaged.

[DarshitChanpura]

@shikharj05 Thank you for your comments.

What are your thoughts about treating resources as entities and allowing admins/users to tie up ACLs with a resource? For example, treating detector as a resource and access control will be defined on this resource (i.e. close to the entity being evaluated).

Not sure if i completely understand what an ACL is. However, this proposal introduces 1 more layer which is closer to the resource being evaluated.

This proposal talks in depth about plugins, can you add an example if such a resource is added by core. This could also pave the way for treating indices as resources and tying down an ACL with them.

Index permissions should cover this correct? Or are you talking about merging resource permissions and index permissions? I'm not aware of any "resource" introduced by core.

As this is introducing a new field/permission model, should this be a new config_version ? Also, there's another RFC to retire V6 #4493 , I think we can use this opportunity to define how new permissions models/config_version changes should be added and older ones removed. Thoughts @DarshitChanpura @cwperks ?

We can consider this as a new config version, however the scope of #4493 might not overlap with this as that RFC discusses retiring v6 and this RFC talks about introducing a new property to a role. Having said that this should be be tested in mixed cluster scenario.

For backwards compatibility, I think this should be introduced with default behavior of treating * as a resource on a role that doesn't have any explicit definitions of resource_permissions. I agree that this might not be the best security behavior, however, it allows for smoother upgrades and easier migration path for customers. To negate circumventing of the feature, for any new roles being created, resource_permissions must be explicitly added (maybe, we can add similar requirement for updates to existing roles). Thoughts?

Proposed path for roles with no resource_permissions is to skip Resource Permissions evaluation entirely which essentially mimics * behavior. "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." If plugin has opted in to resource permissions, we should not allow * access to all resources as this would essentially by-pass resource permissions evaluation.

I would prefer a flag to turn this functionality on/off smoothly for initial release as this could be a breaking change.

Agreed.

File Changes
For file change, kindly consider the changes being brought in by #3870 and ensure changes are compatible with the RFC.
RoleV7.java

Since that is still in draft state I have not considered those changes here.

Since this introduces a new class in existing model, do you know if contents of this class are sent over transport channel with requests? If so, this could cause issues during ugprades in a mixed-version cluster.

Agreed. This will have to be tested. Can you elaborate on what contents will be sent over transport channel?

[DarshitChanpura]

@nibix would love your inputs on this.

[cwperks]

Resource permissions can be defined in two ways:

2. Starts with <plugin-identifier>:<permission>

@DarshitChanpura I think a good aim for action naming is to make them as succinct as possible to help cluster admins understand what they do based off of this short name. We could have the prefix of the action name be the resource type and allow plugins to specify what the type of resource is.

i.e. In Anomaly-Detection the resource type could be anomalydetector and for ML-Commons it could be modelgroup. Think of indices as a type of resource and resource permissions as a generalization on index permissions.

anomalydetector:admin/create is more succinct then resource:ad/admin/create, but I could see how the resource: prefix could also be helpful for consistency.

[DarshitChanpura]

anomalydetector:admin/create is more succinct then resource:ad/admin/create, but I could see how the resource: prefix could also be helpful for consistency.

I agree with succinct naming, however the prefixes for transport actions are statically defined here. If we were to define plugin names as prefixes instead of resource: it becomes impossible to validate the prefix and without this validation the transport action flow fails here. Hence, I think we should have a common prefix: resource:.

[nibix]

@DarshitChanpura

Interesting proposal! That moves OpenSearch quite a bit into the direction of a whole application platform.

My comments (completely IMHO) below:

Configuration structure

Resource permissions can be defined in two ways:

1. Starts with resource:<plugin-identifier>/<permission> (proposed)
2. Starts with <plugin-identifier>:<permission>

I can understand the motivation for both. Both have pros and cons. The pro about <plugin-identifier>:<permission> is that the plugin is easy to recognize for the user. The pro about resource:<plugin-identifier>/<permission> is that the validation in TransportService and also the logic routing in PrivilegesEvaluator is more easy. However, it might be confusing that the first component after the resource: prefix is actually not the resource, but a string representing the plugin? How about using the format plugin:<plugin-identifier>/<resource>/<permission> instead?

However, I would like to take one step back first. Do I see it correctly that we have these dimensions?

• Plugin: Like Anomaly detection, or alerting, ...
• Plugin-specific resource type: Plugins might be managing more than one resource types, especially alerting seems to have quite a few
• Individual instances of one resource type.

While I am pretty sure that these dimensions can be modeled with the proposed resource_permissions structure, I am wondering whether it still will be easy to grasp when there are several plugins with several resource types in the game.

Generally, to verify the real-world suitability of a new config format, I like to recommend to actually create some complete real-world examples, which incorporate several features for several different cases.

Backwards compatibility considerations

I have read the discussions about backwards compat. Just some random thoughts about this:

• Are there considerations in which version these permissions shall be introduced? In a major release one might be more liberal about breaking changes than in a minor release.
• As some of the plugins might have implemented their own authz mechanisms now, these also need to be considered in the migration process. As soon as the security plugin gets responsible for authz, the plugins authz mechanisms should be no longer in effect.
• One way around this would be to require the plugins to introduce new APIs which are then protected by the new scheme, while the old APIs are protected by the old scheme and can be removed eventually. But that might also introduce further and bigger issues 🤔
• I would strongly recommend not to assume that roles without resource permissions indicate full permissions in order to stay backwards compat. That would be very counter-intuitive. If such a strong backwards compatibility is required, I'd go with a feature flag instead.

Code infrastructure: Extending ActionRequest

I can think about two different way of extending ActionRequest. I am wondering about what way you were thinking.

Approach a): Add an empty method that can be overridden:

public abstract class ActionRequest extends TransportRequest {

    public ActionRequest() {
        super();
    }

    public ActionRequest(StreamInput in) throws IOException {
        super(in);
    }
 
    /**
      * NEW NEW NEW .. to be overridden by whoever wants to
      */
    public List<String> getResources() {
       return Collections.emptyList();
    }

    public abstract ActionRequestValidationException validate();

    public boolean getShouldStoreResult() {
        return false;
    }

    @Override
    public void writeTo(StreamOutput out) throws IOException {
        super.writeTo(out);
    }
}

Approach b): Include the actual resource information here.

public abstract class ActionRequest extends TransportRequest {

    private final List<String> resources;

    public ActionRequest() {
        super();
        this.resources = Collections.emptyList();
    }

    public ActionRequest(List<String> resources) {
        super();
        this.resources = resources;
    }

    public ActionRequest(StreamInput in) throws IOException {
        super(in);
        if (in comes from resource aware node) {
           this.resources = in.readList();
        }
    }
 
    public List<String> getResources() {
       return this.resources;
    }

    @Override
    public void writeTo(StreamOutput out) throws IOException {
        super.writeTo(out);

        if (out is resource aware node) {
           out.writeList(this.resources);
        }
    }
}

• One advantage of approach b) would be that it makes it very easy for plugins to gradually enhance their existing actions.

• One disadvantage of approach b) would be that such requests likely already carry the resource information - yet there is no standardized way to access and retrieve it. In approach b) there would be the need to store it redundantly - which would create the risk of inconsistencies.

• Yet, both approaches would be a slight deviation from the present quite strict segmentation of action and request types by interfaces and super-classes (compare IndicesRequest, AliasesRequest, BroadcastRequest, ...). If ActionRequest is extended, it gets very easy to also add resource priv requirements to IndicesRequests. The question would be whether that makes sense.

• One thing that needs to be clarified is: Shall such requests support resource wildcards (*) and resource name patterns (my_resource_*)? For indices requests, it is standard that wildcards and patterns are supported, so it would be intuitive if resource requests would be supporting these as well. However, resource requests can only carry the patterns. They are most likely lacking the dependencies to resolve these patterns to concrete resource names. This probably can be only done by a central component in the plugin, possibly the TransportAction instance which is responsible for processing the requests. Possibly, one needs to have a further interface which TransportActions need to implement in order to extract concrete resource names from requests.

Code infrastructure: Privilege meta data

I am deviating from the proposal a bit to make a related observation: In core OpenSearch, there is also no standardized interface to deduce required privileges from action requests. Instead, the security plugin has a quite involved logic to deduce required privileges from requests. See for example:

security/src/main/java/org/opensearch/security/privileges/PrivilegesEvaluator.java

Lines 601 to 631 in 2b5a811

	private Set<String> evaluateAdditionalIndexPermissions(final ActionRequest request, final String originalAction) {
	// --- check inner bulk requests
	final Set<String> additionalPermissionsRequired = new HashSet<>();
	if (!isClusterPerm(originalAction)) {
	additionalPermissionsRequired.add(originalAction);
	}
	if (request instanceof ClusterSearchShardsRequest) {
	additionalPermissionsRequired.add(SearchAction.NAME);
	}
	if (request instanceof BulkShardRequest) {
	BulkShardRequest bsr = (BulkShardRequest) request;
	for (BulkItemRequest bir : bsr.items()) {
	switch (bir.request().opType()) {
	case CREATE:
	additionalPermissionsRequired.add(IndexAction.NAME);
	break;
	case INDEX:
	additionalPermissionsRequired.add(IndexAction.NAME);
	break;
	case DELETE:
	additionalPermissionsRequired.add(DeleteAction.NAME);
	break;
	case UPDATE:
	additionalPermissionsRequired.add(UpdateAction.NAME);
	break;
	}
	}
	}

security/src/main/java/org/opensearch/security/resolver/IndexResolverReplacer.java

Lines 623 to 808 in 2b5a811

	private boolean getOrReplaceAllIndices(final Object request, final IndicesProvider provider, boolean allowEmptyIndices) {
	final boolean isDebugEnabled = log.isDebugEnabled();
	final boolean isTraceEnabled = log.isTraceEnabled();
	if (isTraceEnabled) {
	log.trace("getOrReplaceAllIndices() for " + request.getClass());
	}
	boolean result = true;
	if (request instanceof BulkRequest) {
	for (DocWriteRequest ar : ((BulkRequest) request).requests()) {
	result = getOrReplaceAllIndices(ar, provider, false) && result;
	}
	} else if (request instanceof MultiGetRequest) {
	for (ListIterator<Item> it = ((MultiGetRequest) request).getItems().listIterator(); it.hasNext();) {
	Item item = it.next();
	result = getOrReplaceAllIndices(item, provider, false) && result;
	/*if(item.index() == null || item.indices() == null || item.indices().length == 0) {
	it.remove();
	}*/
	}
	} else if (request instanceof MultiSearchRequest) {
	for (ListIterator<SearchRequest> it = ((MultiSearchRequest) request).requests().listIterator(); it.hasNext();) {
	SearchRequest ar = it.next();
	result = getOrReplaceAllIndices(ar, provider, false) && result;
	/*if(ar.indices() == null || ar.indices().length == 0) {
	it.remove();
	}*/
	}
	} else if (request instanceof MultiTermVectorsRequest) {
	for (ActionRequest ar : (Iterable<TermVectorsRequest>) () -> ((MultiTermVectorsRequest) request).iterator()) {
	result = getOrReplaceAllIndices(ar, provider, false) && result;
	}
	} else if (request instanceof PutMappingRequest) {
	PutMappingRequest pmr = (PutMappingRequest) request;
	Index concreteIndex = pmr.getConcreteIndex();
	if (concreteIndex != null && (pmr.indices() == null || pmr.indices().length == 0)) {
	String[] newIndices = provider.provide(new String[] { concreteIndex.getName() }, request, true);
	if (checkIndices(request, newIndices, true, allowEmptyIndices) == false) {
	return false;
	}
	((PutMappingRequest) request).indices(newIndices);
	((PutMappingRequest) request).setConcreteIndex(null);
	} else {
	String[] newIndices = provider.provide(((PutMappingRequest) request).indices(), request, true);
	if (checkIndices(request, newIndices, false, allowEmptyIndices) == false) {
	return false;
	}
	((PutMappingRequest) request).indices(newIndices);
	}
	} else if (request instanceof RestoreSnapshotRequest) {
	if (clusterInfoHolder.isLocalNodeElectedClusterManager() == Boolean.FALSE) {
	return true;
	}
	final RestoreSnapshotRequest restoreRequest = (RestoreSnapshotRequest) request;
	final SnapshotInfo snapshotInfo = SnapshotRestoreHelper.getSnapshotInfo(restoreRequest);
	if (snapshotInfo == null) {
	log.warn(
	"snapshot repository '" + restoreRequest.repository() + "', snapshot '" + restoreRequest.snapshot() + "' not found"
	);
	provider.provide(new String[] { "*" }, request, false);
	} else {
	final List<String> requestedResolvedIndices = IndexUtils.filterIndices(
	snapshotInfo.indices(),
	restoreRequest.indices(),
	restoreRequest.indicesOptions()
	);
	final List<String> renamedTargetIndices = renamedIndices(restoreRequest, requestedResolvedIndices);
	// final Set<String> indices = new HashSet<>(requestedResolvedIndices);
	// indices.addAll(renamedTargetIndices);
	if (isDebugEnabled) {
	log.debug("snapshot: {} contains this indices: {}", snapshotInfo.snapshotId().getName(), renamedTargetIndices);
	}
	provider.provide(renamedTargetIndices.toArray(new String[0]), request, false);
	}
	} else if (request instanceof IndicesAliasesRequest) {
	for (AliasActions ar : ((IndicesAliasesRequest) request).getAliasActions()) {
	result = getOrReplaceAllIndices(ar, provider, false) && result;
	}
	} else if (request instanceof DeleteRequest) {
	String[] newIndices = provider.provide(((DeleteRequest) request).indices(), request, true);
	if (checkIndices(request, newIndices, true, allowEmptyIndices) == false) {
	return false;
	}
	((DeleteRequest) request).index(newIndices.length != 1 ? null : newIndices[0]);
	} else if (request instanceof UpdateRequest) {
	String[] newIndices = provider.provide(((UpdateRequest) request).indices(), request, true);
	if (checkIndices(request, newIndices, true, allowEmptyIndices) == false) {
	return false;
	}
	((UpdateRequest) request).index(newIndices.length != 1 ? null : newIndices[0]);
	} else if (request instanceof SingleShardRequest) {
	final SingleShardRequest<?> singleShardRequest = (SingleShardRequest<?>) request;
	final String index = singleShardRequest.index();
	String[] indices = provider.provide(index == null ? null : new String[] { index }, request, true);
	if (!checkIndices(request, indices, true, allowEmptyIndices)) {
	return false;
	}
	singleShardRequest.index(indices.length != 1 ? null : indices[0]);
	} else if (request instanceof FieldCapabilitiesIndexRequest) {
	// FieldCapabilitiesIndexRequest does not support replacing the indexes.
	// However, the indexes are always determined by FieldCapabilitiesRequest which will be reduced below
	// (implements Replaceable). So IF an index arrives here, we can be sure that we have
	// at least privileges for indices:data/read/field_caps
	FieldCapabilitiesIndexRequest fieldCapabilitiesRequest = (FieldCapabilitiesIndexRequest) request;
	String index = fieldCapabilitiesRequest.index();
	String[] newIndices = provider.provide(new String[] { index }, request, true);
	if (!checkIndices(request, newIndices, true, allowEmptyIndices)) {
	return false;
	}
	} else if (request instanceof IndexRequest) {
	String[] newIndices = provider.provide(((IndexRequest) request).indices(), request, true);
	if (checkIndices(request, newIndices, true, allowEmptyIndices) == false) {
	return false;
	}
	((IndexRequest) request).index(newIndices.length != 1 ? null : newIndices[0]);
	} else if (request instanceof Replaceable) {
	String[] newIndices = provider.provide(((Replaceable) request).indices(), request, true);
	if (checkIndices(request, newIndices, false, allowEmptyIndices) == false) {
	return false;
	}
	((Replaceable) request).indices(newIndices);
	} else if (request instanceof BulkShardRequest) {
	provider.provide(((ReplicationRequest) request).indices(), request, false);
	// replace not supported?
	} else if (request instanceof ReplicationRequest) {
	String[] newIndices = provider.provide(((ReplicationRequest) request).indices(), request, true);
	if (checkIndices(request, newIndices, true, allowEmptyIndices) == false) {
	return false;
	}
	((ReplicationRequest) request).index(newIndices.length != 1 ? null : newIndices[0]);
	} else if (request instanceof MultiGetRequest.Item) {
	String[] newIndices = provider.provide(((MultiGetRequest.Item) request).indices(), request, true);
	if (checkIndices(request, newIndices, true, allowEmptyIndices) == false) {
	return false;
	}
	((MultiGetRequest.Item) request).index(newIndices.length != 1 ? null : newIndices[0]);
	} else if (request instanceof CreateIndexRequest) {
	String[] newIndices = provider.provide(((CreateIndexRequest) request).indices(), request, true);
	if (checkIndices(request, newIndices, true, allowEmptyIndices) == false) {
	return false;
	}
	((CreateIndexRequest) request).index(newIndices.length != 1 ? null : newIndices[0]);
	} else if (request instanceof ResizeRequest) {
	// clone or shrink operations
	provider.provide(((ResizeRequest) request).indices(), request, true);
	provider.provide(((ResizeRequest) request).getTargetIndexRequest().indices(), request, true);
	} else if (request instanceof CreateDataStreamAction.Request) {
	provider.provide(((CreateDataStreamAction.Request) request).indices(), request, false);
	} else if (request instanceof ReindexRequest) {
	result = getOrReplaceAllIndices(((ReindexRequest) request).getDestination(), provider, false) && result;
	result = getOrReplaceAllIndices(((ReindexRequest) request).getSearchRequest(), provider, false) && result;
	} else if (request instanceof BaseNodesRequest) {
	// do nothing
	} else if (request instanceof MainRequest) {
	// do nothing
	} else if (request instanceof ClearScrollRequest) {
	// do nothing
	} else if (request instanceof SearchScrollRequest) {
	// do nothing
	} else if (request instanceof PutComponentTemplateAction.Request) {
	// do nothing
	} else {
	if (isDebugEnabled) {
	log.debug(request.getClass() + " not supported (It is likely not a indices related request)");
	}
	result = false;
	}
	return result;
	}

(especially this one is pure horror)

Could it make sense to extend the proposal to enhance ActionRequests and TransportActions to provide their required privileges - independently whether these are plugin resources or core indices, core aliases or core data streams?

New config version

So far the proposal for the new configuration is a pure super-set of the previous configuration. Thus, the new properties can be considered as a "progressive enhancement", which does not make a new config version necessary.

I guess that introducing new config versions introduces significant pains (migration processes, tools, etc), which should be avoided if possible.