Users and roles
editUsers and roles
editDefault elastic user
editWhen the Elasticsearch resource is created, a default user named elastic is created automatically, and is assigned the superuser role.
Its password can be retrieved in a Kubernetes secret, whose name
is based on the Elasticsearch resource name: <elasticsearch-name>-es-elastic-user.
For example, the password of the elastic user for an Elasticsearch cluster named quickstart can be retrieved with:
kubectl get secret quickstart-es-elastic-user -o go-template='{{.data.elastic | base64decode}}'
To rotate this password, refer to: Rotate auto-generated credentials.
Disabling the default elastic user
editIf your prefer to manage all users via SSO, for example using SAML Authentication or OpenID Connect, you can disable the default elastic superuser by setting the auth.disableElasticUser field in the Elasticsearch resource to true:
apiVersion: elasticsearch.k8s.elastic.co/v1
kind: Elasticsearch
metadata:
name: elasticsearch-sample
spec:
version: 8.17.0
auth:
disableElasticUser: true
nodeSets:
- name: default
count: 1
Creating custom users
editDo not run the elasticsearch-service-tokens command inside an Elasticsearch Pod managed by the operator. This would overwrite the service account tokens used internally to authenticate the Elastic stack applications.
Native realm
editYou can create custom users in the Elasticsearch native realm using Elasticsearch user management APIs.
File realm
editCustom users can also be created by providing the desired file realm content or a username and password in Kubernetes secrets, referenced in the Elasticsearch resource.
apiVersion: elasticsearch.k8s.elastic.co/v1
kind: Elasticsearch
metadata:
name: elasticsearch-sample
spec:
version: 8.17.0
auth:
fileRealm:
- secretName: my-filerealm-secret-1
- secretName: my-filerealm-secret-2
nodeSets:
- name: default
count: 1
You can reference several secrets in the Elasticsearch specification. ECK aggregates their content into a single secret, mounted in every Elasticsearch Pod.
Referenced secrets may be of one of two types:
- a combination of username and password as in Kubernetes basic authentication secrets
- a raw file realm content secret
A basic authentication secret can optionally also contain a roles file. It must contain a comma separated list of roles to be associated with the user. The following example illustrates this combination:
apiVersion: v1 kind: Secret metadata: name: secret-basic-auth type: kubernetes.io/basic-auth stringData: 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
If you specify the password for the elastic user through such a basic authentication secret then the secret holding the password described in Default elastic user will not be created by the operator.
The second option, a file realm secret, is composed of 2 entries. You can provide either one entry or both entries in each secret:
-
users: content of theusersfile. It specifies user names and password hashes, as described in the file realm documentation. -
users_roles: content of theusers_rolesfile. It associates each role to a list of users, as described in the file realm documentation.
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: Secret
apiVersion: v1
metadata:
name: my-filerealm-secret
stringData:
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
You can populate the content of both users and users_roles using the elasticsearch-users tool.
For example, invoking the tool in a Docker container:
# create a folder with the 2 files
mkdir filerealm
touch filerealm/users filerealm/users_roles
# create user 'myuser' with role 'monitoring_user'
docker run \
-v $(pwd)/filerealm:/usr/share/elasticsearch/config \
docker.elastic.co/elasticsearch/elasticsearch:8.17.0 \
bin/elasticsearch-users useradd myuser -p mypassword -r monitoring_user
# create a Kubernetes secret with the file realm content
kubectl create secret generic my-file-realm-secret --from-file filerealm
Creating custom roles
editRoles can be specified using the Role management API, or the Role management UI in Kibana.
Additionally, file-based role management can be achieved by referencing Kubernetes secrets containing the roles specification.
apiVersion: elasticsearch.k8s.elastic.co/v1
kind: Elasticsearch
metadata:
name: elasticsearch-sample
spec:
version: 8.17.0
auth:
roles:
- secretName: my-roles-secret-1
- secretName: my-roles-secret-2
nodeSets:
- name: default
count: 1
Several secrets can be referenced in the Elasticsearch specification. ECK aggregates their content into a single secret, mounted in every Elasticsearch Pod.
Each secret must have a roles.yml entry, containing the roles definition.
If you specify multiple roles with the same name in more than one secret, the last one takes precedence.
The following Secret specifies one role named click_admins:
kind: Secret
apiVersion: v1
metadata:
name: my-roles-secret
stringData:
roles.yml: |-
click_admins:
run_as: [ 'clicks_watcher_1' ]
cluster: [ 'monitor' ]
indices:
- names: [ 'events-*' ]
privileges: [ 'read' ]
field_security:
grant: ['category', '@timestamp', 'message' ]
query: '{"match": {"category": "click"}}'