Submitting requests on behalf of other users

You can apply the run_as privilege when creating roles with the create or update roles API. Users who are assigned a role that contains the run_as privilege inherit all privileges from their role, and can also submit requests on behalf of the indicated users.

After a user successfully authenticates to Elasticsearch, an authorization process determines whether the user behind an incoming request is allowed to run that request. If the authenticated user has the run_as privilege in their list of permissions and specifies the run-as header, Elasticsearch discards the authenticated user and associated roles. It then looks in each of the configured realms in the realm chain until it finds the username that’s associated with the run_as user, and uses those roles to execute any requests.

Consider an admin role and an analyst role. The admin role has higher privileges, but might also want to submit requests as another user to test and verify their permissions.

First, we’ll create an admin role named my_admin_role. This role has manage privileges on the entire cluster, and on a subset of indices. This role also contains the run_as privilege, which enables any user with this role to submit requests on behalf of the specified analyst_user.

POST /_security/role/my_admin_role?refresh=true
{
  "cluster": ["manage"],
  "indices": [
    {
      "names": [ "index1", "index2" ],
      "privileges": [ "manage" ]
    }
  ],
  "applications": [
    {
      "application": "myapp",
      "privileges": [ "admin", "read" ],
      "resources": [ "*" ]
    }
  ],
  "run_as": [ "analyst_user" ],
  "metadata" : {
    "version" : 1
  }
}

Next, we’ll create an analyst role named my_analyst_role, which has more restricted monitor cluster privileges and manage privileges on a subset of indices.

POST /_security/role/my_analyst_role?refresh=true
{
  "cluster": [ "monitor"],
  "indices": [
    {
      "names": [ "index1", "index2" ],
      "privileges": ["manage"]
    }
  ],
  "applications": [
    {
      "application": "myapp",
      "privileges": [ "read" ],
      "resources": [ "*" ]
    }
  ],
  "metadata" : {
    "version" : 1
  }
}

We’ll create an administrator user and assign them the role named my_admin_role, which allows this user to submit requests as the analyst_user.

POST /_security/user/admin_user?refresh=true
{
  "password": "l0ng-r4nd0m-p@ssw0rd",
  "roles": [ "my_admin_role" ],
  "full_name": "Eirian Zola",
  "metadata": { "intelligence" : 7}
}

We can also create an analyst user and assign them the role named my_analyst_role.

POST /_security/user/analyst_user?refresh=true
{
  "password": "l0nger-r4nd0mer-p@ssw0rd",
  "roles": [ "my_analyst_role" ],
  "full_name": "Monday Jaffe",
  "metadata": { "innovation" : 8}
}

You can then authenticate to Elasticsearch as the admin_user or analyst_user. However, the admin_user could optionally submit requests on behalf of the analyst_user. The following request authenticates to Elasticsearch with a Basic authorization token and submits the request as the analyst_user:

curl -s -X GET -H "Authorization: Basic YWRtaW5fdXNlcjpsMG5nLXI0bmQwbS1wQHNzdzByZA==" -H "es-security-runas-user: analyst_user" https://localhost:9200/_security/_authenticate

The response indicates that the analyst_user submitted this request, using the my_analyst_role that’s assigned to that user. When the admin_user submitted the request, Elasticsearch authenticated that user, discarded their roles, and then used the roles of the run_as user.

{"username":"analyst_user","roles":["my_analyst_role"],"full_name":"Monday Jaffe","email":null,
"metadata":{"innovation":8},"enabled":true,"authentication_realm":{"name":"native",
"type":"native"},"lookup_realm":{"name":"native","type":"native"},"authentication_type":"realm"}
%

The authentication_realm and lookup_realm in the response both specify the native realm because both the admin_user and analyst_user are from that realm. If the two users are in different realms, the values for authentication_realm and lookup_realm are different (such as pki and native).