Submitting requests on behalf of other users
editSubmitting requests on behalf of other users
editElasticsearch roles support a run_as
privilege that enables an authenticated user to
submit requests on behalf of other users. For example, if your external
application is trusted to authenticate users, Elasticsearch can authenticate the external
application and use the run as mechanism to issue authorized requests as
other users without having to re-authenticate each user.
To "run as" (impersonate) another user, the first user (the authenticating user)
must be authenticated by a mechanism that supports run-as delegation. The second
user (the run_as
user) must be authorized by a mechanism that supports
delegated run-as lookups by username.
The run_as
privilege essentially operates like a secondary form of
delegated authorization. Delegated authorization applies
to the authenticating user, and the run_as
privilege applies to the user who
is being impersonated.
- Authenticating user
For the authenticating user, the following realms (plus API keys) all support
run_as
delegation: native
, file
, Active Directory, JWT, Kerberos, LDAP and
PKI.
Service tokens, the Elasticsearch Token Service, SAML 2.0, and OIDC 1.0 do not
support run_as
delegation.
-
run_as
user
For the run_as
user, the the following realms support delegated
run_as
lookups by username: native
, file
, Active Directory, LDAP.
To support run_as
in the LDAP realm, you have to run in
user search mode. For Active Directory, you need
to configure a bind_dn
and secure_bind_password
.
Service tokens, the Elasticsearch Token Service, PKI, SAML 2.0, OIDC 1.0, Kerberos, JWT,
and API keys do not support delegated run_as
lookups.
To submit requests on behalf of other users, you need to have the run_as
privilege in your roles. For example, the following request
creates a my_director
role that grants permission to submit request on behalf
of jacknich
or redeniro
:
POST /_security/role/my_director?refresh=true { "cluster": ["manage"], "indices": [ { "names": [ "index1", "index2" ], "privileges": [ "manage" ] } ], "run_as": [ "jacknich", "rdeniro" ], "metadata" : { "version" : 1 } }
To submit a request as another user, you specify the user in the
es-security-runas-user
request header. For example:
curl -H "es-security-runas-user: jacknich" -u es-admin -X GET http://localhost:9200/
The run_as
user passed in through the es-security-runas-user
header must be
available from a realm that supports delegated authorization lookup by username.
Realms that don’t support user lookup can’t be used by run_as
delegation from
other realms.
For example, JWT realms can authenticate external users specified in JWTs, and
execute requests as a run_as
user in the native
realm. Elasticsearch will retrieve the
indicated runas
user and execute the request as that user using their roles.
Apply the run_as
privilege to roles
editYou 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.
Roles for the authenticated user and the run_as
user are not merged. If
a user authenticates without specifying the run_as
parameter, only the
authenticated user’s roles are used. If a user authenticates and their roles
include the run_as
parameter, only the run_as
user’s roles are used.
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
).