Unable to set permissions for PUT index_template

Hi,
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

UPD:
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

@silver_searcher
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

Hello!

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

{
  "test-user-role" : {
    "reserved" : false,
    "hidden" : false,
    "cluster_permissions" : [
      "cluster_composite_ops",
      "cluster_manage_index_templates"
    ],
    "index_permissions" : [
      {
        "index_patterns" : [
          "test*"
        ],
        "dls" : "",
        "fls" : [ ],
        "masked_fields" : [ ],
        "allowed_actions" : [
          "crud",
          "create_index",
          "manage_aliases"
        ]
      }
    ],
    "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": [
    "test*"
  ],
  "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

my_user:
  reserved: true
  cluster_permissions:
    - "cluster_monitor"
    - "cluster_manage_index_templates"
  index_permissions:
  - index_patterns:
    - "index-*"
    allowed_actions:
      - "read"
      - "write"
      - "create_index"
      - "manage_aliases"

@silver_searcher
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:
https://github.com/opensearch-project/security/issues/1900