Allow providing cleartext passwords for creating ES users

[joscha-alisch]

Proposal

Currently, to create users via the operator, you can enhance the file realm of ES by providing secrets files with the username and the salted and hashed password just as ES uses it.

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=

This is very nice as a first step, but now every user of the operator needs to go through the hassle of running elasticsearch-users as described in the users and roles docs.

It would be great to be able to specify the user passwords as cleartext and have the operator handle the hashing as described by @sebgl here: #728 (comment)

They provide an example of how this could look, which I think would work fine

kind: Secret
apiVersion: v1
metadata:
  name: es-users-file-realm
stringData:
  # users_cleartext will be internally derived into 'users' by ECK, with a hash of the provided passwords
  # (the current secret is kept unmodified by ECK)
  users_cleartext: |-
    username1:cleartextpassword

Use case. Why is this important?
At the moment there are additional steps in our pipeline we need to maintain, be it the hashing of the passwords or creating users via the API. Moving this logic into the operator would allow us to simplify our setup.

[krjackso]

I ran into this recently as well - we are using Vault as the source of truth for our secrets, and sync them to kubernetes secrets. We would like to be able to create ES users with plaintext passwords so we are not required to double-store the values as both plaintext (for injecting into filebeat, signalfx, other auxillary services), and encoded (for the fileRealm usage). Ideally the passwords could be specified as just a single property in a secret, not using stringData, so that we can use existing vault-secret syncing solutions going forward.

As a workaround for now, I am just using the single "elastic" user everywhere and managing the *-es-elastic-user secret outside of the operator.

[pebrc]

One way to keep the existing structure compatible with the cleartext approach while at the same time facilitating mounting the secret e.g. as an environmental variable would be the following approach:

apiVersion: elasticsearch.k8s.elastic.co/v1
kind: Elasticsearch
metadata:
  name: elasticsearch-sample
spec:
  version: 8.1.0
  auth:
    fileRealm:
    - secretName: es-users-file-realm
  nodeSets:
  - name: default
    count: 1
---
kind: Secret
apiVersion: v1
metadata:
  name: es-users-file-realm
stringData:
  # any unknown key/value pair will be internally transformed into 'users' by ECK, with a hash of the provided passwords
  # known key/value pairs are `users_roles` and `users` which contain raw file realm configuration as documented today. 
 my-user: cleartextpassword
 users_roles: |-
    admin:my-user

Any unknown key on the top level would be interpreted as a clear text username/password combination. The advantages are:

• it is backwards compatible with the current structure of the secret
• it allows mounting the selective keys of the secret into Pods that act as Elasticsearch clients (if they reside in the same namespace as Elasticsearch)

The disadvantages are:

• no uses can be named users or users_roles
• it is a somewhat implicit convention (explicit is usually better)

[pebrc]

We discussed this a bit more internally and prefer a different secret format for clear-text passwords now:

apiVersion: elasticsearch.k8s.elastic.co/v1
kind: Elasticsearch
metadata:
  name: elasticsearch-sample
spec:
  version: 8.1.0
  auth:
    fileRealm:
    - secretName: es-users-file-realm
  nodeSets:
  - name: default
    count: 1
---
kind: Secret
apiVersion: v1
metadata:
  name: es-users-file-realm
type: kubernetes.io/basic-auth
stringData:
  username: my-user
  password:  cleartextpassword
  users_roles: |-
    admin:my-user

This follows the Kubernetes basic-auth secret type. It also makes the user name a value which can be mounted into clients, instead of being a key and thus necessary knowledge that needs to be shared out of band.

We would also make it so that you could override/set the password for the elastic superuser this way (even though we do not recommend using this user for productive use cases, but rather recommend creating a user with minimal privileges)

kind: Secret
apiVersion: v1
metadata:
  name: es-users-file-realm
type: kubernetes.io/basic-auth
stringData:
  username: elastic
  password:  cleartextpassword