Roles and permissions troubleshooting
If a user has insufficient privileges to execute a particular request, or cannot be authenticated, Search Guard will print log statements on WARN level to the log file which help to identify the root cause. If this information is not enough to pinpoint the problem, please set the Search Guard log level to debug.
If a user cannot be authenticated by any configured authentication domains, Search Guard will log:
curl -Ss -k -u unauthenticated:unauthenticated -XGET "https://sgssl-0.example.com:9200/myindex/_search"
[c.f.s.a.BackendRegistry ] Authentication finally failed for unauthenticated
This typically means that the user
unauthenticated either does not exists, or the password is incorrect.
- that user exists in one of your configured authentication domains
- for example, check that the user is present in sg_internal_users.yml, LDAP, Active Directory etc.
- that the password is correct
If the user can log in but has insufficient privileges to perform a particular request, Search Guard will log a statement like:
curl -Ss -k -u hr_employee:hr_employee -XGET "https://sgssl-0.example.com:9200/logstash-*/_search"
[c.f.s.p.PrivilegesEvaluator] No index-level perm match for User [name=hr_employee, roles=[backendrole_1, backendrole_2], requestedTenant=null] Resolved [aliases=, indices=[logstash-2018.05.18, logstash-2018.05.19, logstash-2018.05.20], allIndices=[logstash-2018.05.18, logstash-2018.05.19, logstash-2018.05.20], types=[*], isAll()=false, isEmpty()=false] [Action [indices:data/read/search]] [RolesChecked [sg_own_index, sg_kibana_user, sg_human_resources]]
This log message contains all information needed for debugging:
Cluster vs. index permissions
Depending on whether the user lacksd a permission on the index- or cluster-level, Search Guard will log either:
No index-level perm match ...
No cluster-level perm match ...
which means that the role definition is either missing privileges on the index- or cluster-level:
rolename: indices: 'indexname': '*': - missing_privilege
rolename: cluster: - missing_privilege
Username and backend roles
The next line lists the username and the backend roles assigned to this user:
User [name=hr_employee, roles=[backendrole_1, backendrole_2], requestedTenant=null]
- that the username is the expected one
- that the backend roles for this user are correct.
Search Guard roles
This line lists all Search Guard roles the user is currently mapped to
RolesChecked [sg_own_index, sg_kibana_user, sg_human_resources]
In this example the user is mapped to three Search Guard roles,
- that the user has the expected Search Guard roles
If Search Guard roles are missing or are incorrect, check that the mapping between users/backend roles and Search Guard roles are correct.
Executed action / missing permissions
This line prints the missing permission that causes this request to fail:
- that the Search Guard role(s) for this user allow the execution of this request against the affected indices (see below)
- the permission can be either granted by assigning an action group like READ
- or by assigning the single permission
Using an action group:
sg_role: cluster: - ... indices: 'logstash-*': '*': - READ
Using single permissions:
sg_role: cluster: - ... indices: 'logstash-*': '*': - indices:data/read/search
This line lists all indices affected by this request:
Resolved [aliases=, indices=[logstash-2018.05.18, logstash-2018.05.19, logstash-2018.05.20], allIndices=[logstash-2018.05.18, logstash-2018.05.19, logstash-2018.05.20], types=[*],
Search Guard will resolve any wildcard or index alias to the concrete, underlying indices. In our sample query we used a wildcard:
curl ... -XGET "https://sgssl-0.example.com:9200/logstash-*/_search"
In the log statement, you can see that Search Guard has expanded
By default, Search Guard requires the user to have the required permission(s) for all concrete indices. If the user lacks permissions for one of the indices, the request will fail with a security exception.
Only return data from allowed indices
If you want Search Guard to return only data from allowed indices, and discard the security exceptions for the other ones, set do_not_fail_on_forbidden to true in sg_config.yml:
--- _sg_meta: type: "config" config_version: 2 sg_config: dynamic: kibana: do_not_fail_on_forbidden: true
This is the recommended setting when using Kibana.