This security exception occurs when a user attempts to search an index without the required read privileges in their assigned role. The error indicates missing RBAC permissions for the search operation.
This error occurs when Elasticsearch's role-based access control (RBAC) system blocks a search request because the authenticated user lacks the necessary index privileges. The action "indices:data/read/search" represents the search operation on indices, and the security exception means the user's assigned roles do not include read permissions for the target index or indices. Elasticsearch security uses a permission model where users are assigned roles, and roles define what actions can be performed on which resources. When you see this error, it means the intersection of all the user's roles does not grant the "read" privilege for the index being queried. This commonly happens after enabling X-Pack security, when creating new users with limited roles, or when index permissions change but user roles are not updated accordingly. Even users with roles like "kibana_user" may encounter this if they don't have explicit read access to application indices.
First, identify which user is encountering the error and what roles they currently have assigned. Use the Security API to check:
# Get user details and assigned roles
GET /_security/user/<username>Or through Kibana:
1. Navigate to Management > Security > Users
2. Find the user and review their assigned roles
3. Note which roles are currently assigned
This will show you the starting point for diagnosing the permission issue.
Examine what privileges the user's roles actually grant. For each role assigned to the user:
# Get role details and index privileges
GET /_security/role/<role_name>Look for the "indices" section in the response. You need to verify:
- Does any role include the target index name or a pattern that matches it?
- Do those matching patterns include "read" or "all" in the privileges array?
Example role with proper search permissions:
{
"indices": [
{
"names": ["my-index-*"],
"privileges": ["read"]
}
]
}If the index is not listed or the privileges don't include "read", this is your issue.
If the user's roles lack read permissions, you need to either modify an existing role or create a new one with the proper privileges.
Option 1: Modify existing role via Kibana
1. Go to Management > Security > Roles
2. Select the role to edit
3. Under "Index privileges", add the index pattern
4. Select "read" privilege
5. Save the role
Option 2: Create new role via API
POST /_security/role/my_search_role
{
"indices": [
{
"names": ["my-index-*"],
"privileges": ["read"]
}
]
}Then assign the role to the user:
POST /_security/user/<username>/_password
{
"roles": ["existing_role", "my_search_role"]
}The user can now search indices matching the pattern.
After updating roles, verify the user can now perform searches:
# Authenticate as the user and test search
curl -u username:password -X GET "localhost:9200/my-index/_search?pretty"You should receive search results instead of a security exception. If using Kibana, refresh the page and try accessing the data again.
Troubleshooting: If the error persists:
- Verify the role was saved correctly with GET /_security/role/<role_name>
- Check that the index pattern actually matches your index names
- Ensure the user has the updated role list with GET /_security/user/<username>
- Wait a few moments for permission changes to propagate in the cluster
Principle of Least Privilege: When granting permissions, use specific index patterns rather than wildcards like "*" to limit access to only necessary indices. Consider using time-based patterns (e.g., "logs-2025-*") for better security.
Document and Field Level Security: You can further restrict access using document-level security (DLS) with query filters or field-level security (FLS) to hide sensitive fields. These add additional authorization layers beyond basic read privileges.
API Keys: For applications and services, use API keys instead of user credentials. API keys inherit permissions from the user who creates them but can be more easily rotated and monitored:
POST /_security/api_key
{
"name": "my-api-key",
"role_descriptors": {
"my-app-role": {
"indices": [
{
"names": ["my-index-*"],
"privileges": ["read"]
}
]
}
}
}Reserved Indices: System indices like .security, .kibana, and other dot-prefixed indices have special protection. Regular roles cannot access them - only built-in roles like superuser can. Never grant broad access to these indices.
Monitoring Permission Issues: Enable audit logging to track authorization failures and understand which users are attempting unauthorized actions. Configure in elasticsearch.yml:
xpack.security.audit.enabled: true
xpack.security.audit.logfile.events.include: ["access_denied", "authentication_failed"]Cross-Cluster Search: If searching remote clusters, the user needs both local permissions and the remote_indices privilege with appropriate cluster credentials configured.
QueryShardException: No mapping found for [field] in order to sort on
How to fix "QueryShardException: No mapping found for field in order to sort on" in Elasticsearch
IndexNotFoundException: no such index [index_name]
How to fix "IndexNotFoundException: no such index [index_name]" in Elasticsearch
DocumentMissingException: [index][type][id]: document missing
DocumentMissingException: Document missing
ParsingException: Unknown key for a START_OBJECT in [query]
How to fix "ParsingException: Unknown key for a START_OBJECT in [query]" in Elasticsearch
AggregationExecutionException: Aggregation [agg_name] does not support sampling
How to fix "AggregationExecutionException: Aggregation [agg_name] does not support sampling" in Elasticsearch