Elasticsearch User Impersonation

User Impersonation: Submit requests on behalf of another user

by Cliff Staley on August 8, 2018

The best way to assure that security rules work as desired, is to test the configuration. Fortunately Search Guard come with User Impersonation feature that makes testing easy.

When do we need to impersonate the user? Assume that Jack has been granted permissions on an Elasticsearch cluster. If Jack encounters some issues with accessing the cluster, and admin user can login to the cluster on behalf of Jack. This is what user impersonation is and it allows admin to check if Jack’s permissions work properly and debug problems.

The same feature can be used for penetration testing. If Jack has been granted only read permissions, we can check if he is able to delete or alter data.

Let us see some example on a demo Search Guard installation with the Shakespeare dataset loaded. “To be, or not be” phrases can be searched by the readall user that comes with Search Guard demo installation:

curl -u readall:readall -k 'https://localhost:9200/shakespeare/_search?q=To+be+or+not+to+be&size=1'

Which gives us:

               "text_entry":"To be, or not to be: that is the question:"

In this case, we knew password of the readall user which is also readall. User impersonation allows us to achieve the same results without knowing the password of readall user.

To make it work, we add following lines to elasticsearch.yml and restart the cluster:

  - "readall"

This tells Search Guard that the user admin is allowed to impersonate as user readall. You can specify multiple users here, and wildcards are also supported. To allow the admin user to impersonate as any other user, we can simply use:

  - "*"

With this configuration we can now try to use the admin user to impersonate as readall:

curl -u admin:admin -H "sg_impersonate_as: readall" -k 'https://localhost:9200/shakespeare/_search?q=To+be+or+not+to+be&size=1'

We used an HTTP header sg_impersonate_as to specify which user we want to impersonate as. The request is now performed as readall. As expected, we get the same result from Elasticsearch as before.

But wait – the admin role has full access to all indices in the cluster. How do we know that impersonation really worked? Let us check if we are able to delete the index:

curl -u admin:admin -H "sg_impersonate_as: readall" -k -XDELETE 'https://localhost:9200/shakespeare/'

As expected a security exception is raised since the readall user has no permission to delete any index:

            "reason":"no permissions for [indices:admin/delete] and User [name=readall, roles=[readall], requestedTenant=null]"
      "reason":"no permissions for [indices:admin/delete] and User [name=readall, roles=[readall], requestedTenant=null]"

We can also check the Search Guard audit log to see that operation. The generated MISSING_PRIVILEGES event contains two user entries. The audit_request_initiating_user is admin, since we used admin to initiate the request. The audit_request_effective_user  is readallsince the request was performed in the context of the user readall.

User Impersonation Audit Log


With Search Guard User Impersonation it is possible to submit requests on behalf of another user. This makes it possible to debug permissions problems and for penetration testing.

Where to go next?

Image: shutterstock / Minerva Studio

Cliff StaleyUser Impersonation: Submit requests on behalf of another user

Join the conversation