Unable to set permissions for PUT index_template

I’m using ODFE 1.12 and I’m trying to set permissions for the new ES templates APIs (PUT _component_template, PUT _index_template).

I wasn’t able to find the exact permissions, that should be:

  • indices:admin/component_template/put
  • indices:admin/index_template/put

I also tried different combinations of action groups (e.g. cluster_all, indices_all) but I always get the following error:

no permissions for [indices:admin/index_template/put]

The only way I found to make this work is to give admin-like permissions (*).

Is there something I am missing or there are missing permissions in ODFE?

Thanks. Best regards.

You could first create a new action group, let’s say “template-admin”:
And you give the action group indices:admin/index_template/put and any other permission that might become necessary:

Then you can create a new role (or update existing role). Where you add the index_patterns that you want the role to be able to manage, you must also add the template-admin to the allowed_actions .

After that you must make sure that your user is mapped to that role.

Hi @alex, did you manage to get it working using the above instructions?

Hi Anthony,
thanks for checking, I had no time yet to test this.

Hi @Anthony @oscark

I tried this

unfortunately, creation and usage of a new action group didn’t help

adding indices:admin/index_template/put (and indices:admin/index_template/* at all) on “cluster” level doesn’t change anything, and when we add this permission on index level (index_permissions works only when we put index_patterns: ["*"]. If i put index pattern to name of the index which is specified in index patterns inside the template, or to name of the template i want to create, I still get no permissions for no permissions for [indices:admin/index_template/put] ).

What index permissions should i put there?

Is there any chance that validation of this permission will be moved on cluster-level (saying if I put indices:admin/index_template/put on cluster_permissions, it will be validated properly as it is done for legacy index templates?

Should I create an issue on GitHub? I can provide more information there with steps to reproduce and expeted/actual behavior

for template components it works fine, we can define permissions on cluster-level:

PUT _opendistro/_security/api/roles/my_role_create_component_template
  "cluster_permissions": ["cluster:admin/component_template/put"
  "index_permissions": [],
  "tenant_permissions": []

works fine

@NovikovEvgeny i’m also hitting the same symptoms on AWS OpenSearch Service 1.0.

Was this resolved for you or otherwise raised on Github?

Can I please bump up this thread? I’m encountering the same issue on OpenSearch 1.2.3

Adding the legacy index privilege to ‘cluster_permissions’ works for me, but ‘indices:admin/index_template/*’ does not work regardless if I put it in the ‘cluster_permissions’ or under individual ‘index_permissions’ with specific index patterns.

Also encountering the same problem with adding privileges for aliases

Can you elaborate on what you are trying to achieve?
If you need to give access to create templates, below permission should suffice:

Cluster permission: cluster_manage_index_templates
with ‘read’ access to the index in question.

For alias, you can add “manage_aliases” to index permission, together with “read” access, which should give you needed access.

If this doesn’t work, can you provide steps to reproduce please


I have the same problem with templates as @silver_searcher.
My configured role is

  "test-user-role" : {
    "reserved" : false,
    "hidden" : false,
    "cluster_permissions" : [
    "index_permissions" : [
        "index_patterns" : [
        "dls" : "",
        "fls" : [ ],
        "masked_fields" : [ ],
        "allowed_actions" : [
    "tenant_permissions" : [ ],
    "static" : false

I have tried to create template by ‘test-user’ user with above role

curl -u test-user:*** -XPUT http://localhost:9200/_index_template/test -H "Accept:application/json" -H  "Content-Type:application/json" -d'{
  "index_patterns": [
  "template": {
    "settings": {
      "number_of_shards": 3,
      "number_of_replicas": 1

but I have received the following error:

{"error":{"root_cause":[{"type":"security_exception","reason":"no permissions for [indices:admin/index_template/put] and User [name=test-user, backend_roles=[], requestedTenant=null]"}],"type":"security_exception","reason":"no permissions for [indices:admin/index_template/put] and User [name=test-user, backend_roles=[], requestedTenant=null]"},"status":403}

Moreover, I noticed that cluster_manage_index_templates action group contains indices:admin/template/* permissions, not indices:admin/index_template/* that are specified in error.

Besides, adding indices:admin/index_template/put permission does not solve the problem.

I reproduced the issue (was using the legacy _template instead of _index_template).

As _index_template (like _template) requires global permissions on elasticsearch/opensearch, the permission needs to be applied globally.

There is a bug it seems, where opensearch doesn’t read the cluster permission indices:admin/index_template/put from the cluster permission section (I’d recommend to raise a ticket for this on github), however a quick workaround should be to apply only this permission to all indices (*). The functionality would remain the same. Correct me if I’m wrong

Separate role for templates helped to solve my problem.
Thank you very much!

Hi @Anthony

Thanks for the feedback. Adding indices:admin/index_template/put under index_permissions with * indeed works as a workaround.

Re: alias, I’m able to retrieve it if I’m targetting an index specifically such as GET /index-001/_alias, however GET /_alias does not work, presumably because I don’t have access to the internal indices like .kibana. It works if I add blanket alias permissions again under index_permissions with *, but that means the user is also able to see all internal indices

Is this really the intended behavior? In Elasticsearch, calling GET /_alias returns only the list of indices/aliases that the user has permissions to (so it’s filtered, w/o the internal indices), but it doesn’t outright reject the whole operation

  reserved: true
    - "cluster_monitor"
    - "cluster_manage_index_templates"
  - index_patterns:
    - "index-*"
      - "read"
      - "write"
      - "create_index"
      - "manage_aliases"

This does not seem to be possible currently, I would recommend raising a feature request on github to filter aliases and referencing this thread there and github issue here, to keep a trail

Thanks @Anthony .
I had the same problem, and I can confirm this workaround.
I have also create the github issue with the reference to this thread: