No permissions on indices:data/read/search template when the permission is attached in the role

Good Afternoon everyone.

I’m trying to use a search template, but i’m constantly receiving this error:

{"error":{"root_cause":[{"type":"security_exception","reason":"no permissions for [indices:data/read/search/template] and User [name=application.user, backend_roles=[], requestedTenant=null]"}],"type":"security_exception","reason":"no permissions for [indices:data/read/search/template] and User [name=application.user, backend_roles=[], requestedTenant=null]"},"status":403}

I have already made the changes on the role i attached to the application user. I added this permission, but somehow it just don’t seem to apply. It gives me always the same error.

On this role, i’m giving only access to the index it needs to access (for security reasons)

When i apply the index pattern *, it works, but that’s not my objective. This role must not be able to read others.

Is There any thing i can do to make this index permission (indices:data/read/search/template) work when using specific index patterns? i dont really want to use * .

My cluster is running version 1.1, on AWS Open Search service.

@fellipe Try setting up do_not_fail_on_forbidden to true in opensearch.yml.

@pablo How can i access opensearch.yml when i’m using AWS opensearch service, and can’t access the CLI? Is there any other way i can change it by using the Dev tools or maybe some kind of command using CURL?

Something like this seems to work if creating a new role that has index_patterns: [“*”] and the required template permissions. Then add the roles to your user that has index permissions.

template_user:
 index_permissions:
  - index_patterns:
    - "*"
    allowed_actions:
    - "indices:data/read/search/template"
    - "indices:data/read/msearch/template"
    
template_admin:
 cluster_permissions:
 - "cluster:admin/script/get"
 - "cluster:admin/script/put"

Thanks for the answer @jnum, but giving all access to the indices is something i can’t do, because it would be too permissive, would break our application security logic.

My goal is using a user/role to every application i work with. Do you have any tips about that?

I need to be restrictive about the index patterns, only allowing what the user can use.

You can keep your roles that allow access to only some indices, but then add the template role (without your normal index permissions) as extra. If you try to use the templates to access indices where you don’t have permissions you will get errors. I don’t know why using templates needs index_patterns: *.

@fellipe Could you share your config.yml?

Would you mind sharing the role configuration of the application.user?

@pablo, as i told you before, i dont see a way to get access to these “system” files. As i’ve read on the internet, these yml files usually stay in the application folder, and i dont have access to it. I’m using an AWS OpenSearch which is a PaaS service, it just doesnt let me access its console.

Im annexing the role configuration attached to the application user down below.

@fellipe I’ve just repro your issue and the only setting that allows the search using the search template is the one suggested by @jnum

This has already been reported to the Dev team in GitHub.

Just to be clear on the security part. Setting indices: data/read/search/template permission to all indices doesn’t give access to the indices but only allows to execute search template.
If you run the search template against the index that you don’t have read permissions then you’ll get an error.

was this ever solved?

i have the exact problem but none of the previously described solution work.

in the specific my role has the following permissions

indexes: network-* , filebeat-* 
permission: read

do_not_fail_on_forbidden: true is also configured

when loggin in, the api call

api/saved_objects/_find?fields=title&per_page=1&search=*&search_fields=title&type=index-pattern

returns with:

{"statusCode":403,"error":"Forbidden","message":"no permissions for [indices:data/read/search] and User ...

adding the following permissions does nothing.

index: *
permissions: 
    - "indices:data/read/search/template"
    - "indices:data/read/msearch/template"

the only way i can get some progress is by granting:

index: *
permission: indices:data/read/search 

in that case, the previous call succeed

and returns

{
	"page": 1,
	"per_page": 1,
	"total": 4,
	"saved_objects": [{
		"type": "index-pattern",
		"id": "network-*",
		"attributes": {
			"title": "network-*"
		},
		"references": [],
		"migrationVersion": {
			"index-pattern": "7.6.0"
		},
		"updated_at": "2022-09-29T10:44:29.857Z",
		"version": "Wzk3LDdd",
		"namespaces": ["default"],
		"score": 1
	}]
}

unfortunately there are still problems as trying to access discover or dashboards

for the api call api/opensearch-dashboards/settings

the response is

{"statusCode":403,"error":"Forbidden","message":"no permissions for [indices:data/write/update] and User

for the api call /api/saved_objects/_bulk_get

the response is

{"statusCode":403,"error":"Forbidden","message":"no permissions for [] and User

the only way i can properly browse is to grant indices:data/read/search + get .
when the read permission is granted to * i obtain the following answer to the api call

api/saved_objects/_find?fields=title&per_page=1&search=*&search_fields=title&type=index-pattern

{
	"page": 1,
	"per_page": 10000,
	"total": 4,
	"saved_objects": [{
		"type": "index-pattern",
		"id": "network-*",
		"attributes": {
			"title": "network-*"
		},
		"references": [],
		"migrationVersion": {
			"index-pattern": "7.6.0"
		},
		"updated_at": "2022-09-29T10:44:29.857Z",
		"version": "Wzk3LDdd",
		"namespaces": ["default"],
		"score": 0
	}, {
		"type": "index-pattern",
		"id": "filebeat-*",
		"attributes": {
			"title": "filebeat-*"
		},
		"references": [],
		"migrationVersion": {
			"index-pattern": "7.6.0"
		},
		"updated_at": "2022-09-29T10:44:29.857Z",
		"version": "WzEwNCw3XQ==",
		"namespaces": ["default"],
		"score": 0
	}, {
		"type": "index-pattern",
		"id": "snmp-*",
		"attributes": {
			"title": "snmp-*"
		},
		"references": [],
		"migrationVersion": {
			"index-pattern": "7.6.0"
		},
		"updated_at": "2022-09-29T12:30:48.194Z",
		"version": "WzEwNyw3XQ==",
		"namespaces": ["default"],
		"score": 0
	}, {
		"type": "index-pattern",
		"id": "security-auditlog-*",
		"attributes": {
			"title": "security-auditlog-*"
		},
		"references": [],
		"migrationVersion": {
			"index-pattern": "7.6.0"
		},
		"updated_at": "2022-09-29T12:31:07.357Z",
		"version": "WzEwOCw3XQ==",
		"namespaces": ["default"],
		"score": 0
	}]
}

notice how a lot more indexes are returned compared to before