Movatterモバイル変換

[0]ホーム
URL:

Loading
  1. Elastic Docs/
  2. Deploy and manage/
  3. Users and roles/
  4. Cluster or deployment/
  5. User authentication/
  6. Internal authentication

File-based user authentication

You can manage and authenticate users with the built-infile realm. With thefile realm, users are defined in local files on each node in the cluster.

Thefile realm is useful as a fallback or recovery realm. For example, you might use this realm in cases where the cluster is unresponsive or the security index is unavailable, or when you forget the password for your administrative users. In this type of scenario, thefile realm is a convenient workaround: you can define a newadmin user in thefile realm and use it to log in and reset the credentials of all other users. For a walkthrough of this process, refer toFile-based access recovery. Refer toenabling a file realm user for recovery for a video walkthrough.

Important
  • In self-managed deployments, as the administrator of the cluster, it is your responsibility to ensure the same users are defined on every node in the cluster. The Elastic Stack security features do not deliver any mechanism to guarantee this.
  • You can't add or manage users in thefile realm using theuser APIs, or using the KibanaManagement > Security > Users page.

You don’t need to explicitly configure afile realm. Thefile andnative realms are added to the realm chain by default. Unless configured otherwise, thefile realm is added first, followed by thenative realm. You can define only onefile realm on each node.

  1. (Optional) Add a realm configuration toelasticsearch.yml under thexpack.security.authc.realms.file namespace. At a minimum, you must set the realm’sorder attribute.

    For example, the following snippet shows afile realm configuration that sets theorder to zero so the realm is checked first:

    xpack.security.authc.realms.file.file1.order: 0

  2. (Optional) For self-managed deployments, you can change how often theusers andusers_roles files are checked.

    By default, Elasticsearch checks these files for changes every 5 seconds. You can change this default behavior by changing theresource.reload.interval.high setting in theelasticsearch.yml file.

    Warning

    Becauseresource.reload.interval.high is a common setting in Elasticsearch, changing its value may effect other schedules in the system.

  3. In self-managed deployments, if either of these settings is modified, perform arolling restart of the Elasticsearch nodes for your changes to take effect.

    In Elastic Cloud on Kubernetes, changes are automatically propagated.

In a self-managed Elasticsearch cluster, all the data about the users for thefile realm is stored in two files on each node in the cluster:users andusers_roles. Both files are located inES_PATH_CONF and are read on startup.

In an Elastic Cloud on Kubernetes deployment, you can pass file realm user information in two ways:

  1. Usingusers anduser_roles files, which are passed using file realm content secrets
  2. Using Kubernetes basic authentication secrets

You can reference several secrets in the Elasticsearch specification. ECK aggregates their content into a single secret, mounted in every Elasticsearch Pod.

Important

In a self-managed cluster, theusers andusers_roles files are managed locally by the node and arenot managed globally by the cluster. This means that with a typical multi-node cluster, the exact same changes need to be applied on each and every node in the cluster.

A safer approach would be to apply the change on one of the nodes and have the files distributed or copied to all other nodes in the cluster (either manually or using a configuration management system such as Puppet or Chef).

users andusers_roles files contain all of the information about users in the file realm.

Theusers file stores all the users and their passwords. Each line in the file represents a single user entry consisting of the username and hashed and salted password.

rdeniro:$2a$10$BBJ/ILiyJ1eBTYoRKxkqbuDEdYECplvxnqQ47uiowE7yGqvCEgj9Walpacino:$2a$10$cNwHnElYiMYZ/T3K4PvzGeJ1KbpXZp2PfoQD.gfaVdImnHOwIuBKSjacknich:{PBKDF2}50000$z1CLJt0MEFjkIK5iEfgvfnA6xq7lF25uasspsTKSo5Q=$XxCVLbaKDimOdyWgLCLJiyoiWpA/XDMe/xtVgn1r5Sg=
Tip

To limit exposure to credential theft and mitigate credential compromise, the file realm stores passwords and caches user credentials according to security best practices. By default, a hashed version of user credentials is stored in memory, using a salted sha-256 hash algorithm and a hashed version of passwords is stored on disk salted and hashed with the bcrypt hash algorithm. To use different hash algorithms, seeUser cache and password hash algorithms.

Theusers_roles file stores the roles associated with the users. For example:

admin:rdeniropower_user:alpacino,jacknichuser:jacknich

Each row maps a role to a comma-separated list of all the users that are associated with that role.

You can edit files and secrets that containusers andusers_roles manually, or you can edit them using a tool.

Manually

You can passusers anduser_roles files to Elastic Cloud on Kubernetes using a file realm secret:

apiVersion: elasticsearch.k8s.elastic.co/v1kind: Elasticsearchmetadata:  name: elasticsearch-samplespec:  version: 9.3.0  auth:    fileRealm:    - secretName: my-filerealm-secret-1    - secretName: my-filerealm-secret-2  nodeSets:  - name: default    count: 1

A file realm secret is composed of two entries: ausers entry and ausers_roles entry. You can provide either one entry or both entries in each secret.

If you specify multiple users with the same name in more than one secret, the last one takes precedence. If you specify multiple roles with the same name in more than one secret, a single entry per role is derived from the concatenation of its corresponding users from all secrets.

The following secret specifies three users and their respective roles:

kind: SecretapiVersion: v1metadata:  name: my-filerealm-secretstringData:  users: |-    rdeniro:$2a$10$BBJ/ILiyJ1eBTYoRKxkqbuDEdYECplvxnqQ47uiowE7yGqvCEgj9W    alpacino:$2a$10$cNwHnElYiMYZ/T3K4PvzGeJ1KbpXZp2PfoQD.gfaVdImnHOwIuBKS    jacknich:{PBKDF2}50000$z1CLJt0MEFjkIK5iEfgvfnA6xq7lF25uasspsTKSo5Q=$XxCVLbaKDimOdyWgLCLJiyoiWpA/XDMe/xtVgn1r5Sg=  users_roles: |-    admin:rdeniro    power_user:alpacino,jacknich    user:jacknich

Using a tool

To avoid editing these files manually, you can use theelasticsearch-users tool:

You can also add file-based authentication users usingKubernetes basic authentication secrets.

A basic authentication secret can optionally contain aroles entry. It must contain a comma separated list of roles to be associated with the user. The following example illustrates this combination:

apiVersion: v1kind: Secretmetadata:  name: secret-basic-authtype: kubernetes.io/basic-authstringData:  username: rdeniro    # required field for kubernetes.io/basic-auth  password: mypassword # required field for kubernetes.io/basic-auth  roles: kibana_admin,ingest_admin  # optional, not part of kubernetes.io/basic-auth
Tip

To create custom roles that can be referenced in this list refer toDefining roles > File-based role management.

You can make this file available to Elastic Cloud on Kubernetes by adding it as a file realm secret:

apiVersion: elasticsearch.k8s.elastic.co/v1kind: Elasticsearchmetadata:  name: elasticsearch-samplespec:  version: 8.16.1  auth:    fileRealm:    - secretName: secret-basic-auth  nodeSets:  - name: default    count: 1
Note

If you specify the password for theelastic user through a basic authentication secret, then the secret holding the password described inBuilt-in users in self-managed clusters will not be created by the operator.

[8]ページ先頭
©2009-2026 Movatter.jp