mirror of
https://github.com/elastic/elasticsearch.git
synced 2025-04-25 15:47:23 -04:00
255c9a7f95
**Problem:** For historical reasons, source files for the Elasticsearch Guide's security, watcher, and Logstash API docs are housed in the `x-pack/docs` directory. This can confuse new contributors who expect Elasticsearch Guide docs to be located in `docs/reference`. **Solution:** - Move the security, watcher, and Logstash API doc source files to the `docs/reference` directory - Update doc snippet tests to use security Rel: https://github.com/elastic/platform-docs-team/issues/208
84 lines
3.7 KiB
Text
84 lines
3.7 KiB
Text
[role="xpack"]
|
|
[[configure-operator-privileges]]
|
|
=== Configure operator privileges
|
|
|
|
NOTE: {cloud-only}
|
|
|
|
Before you can use operator privileges, you must
|
|
<<enable-operator-privileges, enable the feature>> on all nodes in the cluster
|
|
and <<designate-operator-users,designate operator users>>.
|
|
|
|
[[enable-operator-privileges]]
|
|
==== Enable operator privileges
|
|
|
|
In order to use the operator privileges feature, it must be enabled explicitly
|
|
on each node in the cluster. Add the following setting in each
|
|
`elasticsearch.yml` file:
|
|
|
|
[source,yaml]
|
|
----------------------------
|
|
xpack.security.operator_privileges.enabled: true
|
|
----------------------------
|
|
|
|
If the node is already running before you make this change, you must restart
|
|
the node for the feature to take effect.
|
|
|
|
WARNING: The feature needs to be either enabled or disabled consistently across
|
|
all nodes in a cluster. Otherwise, you can get inconsistent behaviour depending
|
|
on which node first receives a request and which node executes it.
|
|
|
|
When operator privileges are enabled on a cluster,
|
|
<<operator-only-functionality,specific functionalities>> are restricted and can
|
|
be executed only by users who have been explicitly designated as operator users.
|
|
If a regular user attempts to execute these functionalities (even if they have
|
|
the `superuser` role), a security exception occurs.
|
|
|
|
[[designate-operator-users]]
|
|
==== Designate operator users
|
|
|
|
Operator users are just normal {es} users with special rights to perform
|
|
operator-only functionalities. They are specified in an `operator_users.yml`
|
|
file, which is located in the config directory (as defined by the `ES_PATH_CONF`
|
|
environment variable). Similar to
|
|
<<file-realm-configuration,other security config files>>, the
|
|
`operator_users.yml` file is local to a node and does not apply globally to the
|
|
cluster. This means, in most cases, the same file should be distributed or
|
|
copied to all nodes in a cluster.
|
|
|
|
The `operator_users.yml` file defines a set of criteria that an authenticating
|
|
user must match to be considered as an operator user. The following snippet
|
|
shows an example of such a file:
|
|
|
|
[source,yaml]
|
|
-----------------------------------
|
|
operator: <1>
|
|
- usernames: ["system_agent_1","system_agent_2"] <2>
|
|
realm_type: "file" <3>
|
|
auth_type: "realm" <4>
|
|
-----------------------------------
|
|
<1> A fixed value of `operator` signals the beginning of the definition.
|
|
<2> A list of user names allowed for operator users. This field is mandatory.
|
|
<3> The type of the authenticating realm allowed for operator users. The default
|
|
and only acceptable value is <<file-realm,`file`>>.
|
|
<4> The authentication type allowed for operator users. The default and only
|
|
acceptable value is `realm`.
|
|
|
|
You must specify at least the `usernames` field. If no other fields are
|
|
specified, their default values are used. All fields must be matched for a user
|
|
to be qualified as an operator user. You can also specify multiple groups of
|
|
criteria. This is currently not very useful since this feature does not yet
|
|
support other realms or authentication types.
|
|
|
|
There are also two implicit rules that affect which users are operator users:
|
|
|
|
1. If the authenticating user <<run-as-privilege,runs as>> another user, neither
|
|
of them are considered to be operator users.
|
|
2. All <<internal-users>> are implicitly operator users.
|
|
|
|
IMPORTANT: After a user is designated as an operator user, they are still
|
|
subject to regular <<authorization,RBAC user authorization>> checks. That is to
|
|
say, in addition to specifying that a user is an operator user, you must also
|
|
grant them the necessary {es} roles to perform their tasks. Consequently, it is
|
|
entirely possible that an operator user can encounter an "access denied" error
|
|
and fail to perform certain actions due to RBAC check failures. In short, an
|
|
operator user is *not* automatically a `superuser`.
|