Support file realm in the Elasticsearch spec #728
Comments
|
Do we have an overview over the use cases where we think the file realm will be required, and the native realm (or other realms) would not be suitable? |
|
For now, we have had very few cases:
Custom roles can be set using the API. My feeling is that it is a "nice to have" with a low priority for the moment. |
|
The ability to add roles and users via files or config to the CRD is very much wanted. I am trying to monitor the cluster using the Prometheus exporter, and it requires As a workaround (a very ugly one) I added this block to the nodeGroup config: I could not find any existing role that covers Fetching metrics is a very common scenario (I would expect), so I hope a more native solution can be implemented in the operator. Enjoying the operator otherwise ;) Thanks. |
|
Suggested: check the current implementation is sufficient (can create user, can create/define roles) and document it. |
|
ECK does not prevent the normal use of the native realm. By enabling the user native authentication: apiVersion: elasticsearch.k8s.elastic.co/v1beta1
kind: Elasticsearch
metadata:
name: z
spec:
version: 7.4.0
nodeSets:
- name: master
count: 1
config:
xpack.security.authc.realms.native.native1.order: 0Users and roles can be created using the security APIs: > es() {
local uri=$1 && shift
curl -sku $AUTH -H 'Content-type: application/json' https://$IP:9200$uri $@
}
> es /_security/role/myrole -d '{
"cluster": ["monitor"],
"applications": [{
"application": "kibana-.kibana",
"privileges": ["all"],
"resources": ["*"]
}]
}'
{"role":{"created":true}}
> es /_security/user/myuser -d '{
"roles": ["myrole"],
"password": "buoPM@v<k7b{0rks[90Bq3gUG<n6"
}'
{"created":true}Documentation pages: |
|
Users can use the file realm today from ECK with some restrictions, most notably there is no way to define new roles in In order to do that one needs to create a secret of the following form: apiVersion: v1
data:
name: $USERNAME_BASE64
passwordHash: $BCRYPT_BASE64
userRoles: $COMMA_SEP_ROLES_BASE64
kind: Secret
metadata:
labels:
common.k8s.elastic.co/type: user
elasticsearch.k8s.elastic.co/cluster-name: $CLUSTER_NAME
name: custom-user-cd2tccd654
ownerReferences:
- apiVersion: elasticsearch.k8s.elastic.co/v1beta1
blockOwnerDeletion: true
controller: true
kind: Elasticsearch
name: $CLUSTER_NAME
uid: $CLUSTER_RESOURCE_UID
type: OpaqueWhen generating the Bcrypt hash it is important to use a bcrypt version that produces This is assuming Elasticsearch is configured to use the default |
|
Any plans for adding custom roles via Kubernetes objects? I understand all this is possible to do by using the ES API, but I would prefer to do this natively via Kubernetes. We have many clusters, so automation is a must. Writing a sidecar or extra service for role and user management seems unnecessary. |
|
We decided to implement support for the file realm (roles & users), targeting ECK version |
|
So before digging into the implementation I reminded myself the way things currently work. In Elasticsearch3 files, on each node, control the file realm.
In ECKWe aggregate those 3 files a single secret mounted in all Elasticsearch nodes: This file is generated from:
We have an internal mechanism in place to generate the Kibana user automatically by listing secrets labeled with: common.k8s.elastic.co/type: user
elasticsearch.k8s.elastic.co/cluster-name: $CLUSTER_NAMEThose secrets are expected to contain the user name, a password hash and a list of roles for the user, as outlined by @pebrc above. |
|
I'm trying to come up with different ways things can be exposed. tl;dr of the examples below. There are several alternatives:
RolesThey can be defined in yaml format: click_admins:
run_as: [ 'clicks_watcher_1' ]
cluster: [ 'monitor' ]
indices:
- names: [ 'events-*' ]
privileges: [ 'read' ]
field_security:
grant: ['category', '@timestamp', 'message' ]
query: '{"match": {"category": "click"}}'I see several options to specify them.
spec:
version: 7.5.0
count: 3
fileRealm:
roles:
click_admins:
run_as: [ 'clicks_watcher_1' ]
cluster: [ 'monitor' ]
indices:
- names: [ 'events-*' ]
privileges: [ 'read' ]
field_security:
grant: ['category', '@timestamp', 'message' ]
query: '{"match": {"category": "click"}}'Pros: does not involve extra resources. Uses the same convention as the In the CRD definition, we can either:
spec:
version: 7.5.0
count: 3
fileRealm:
roles:
- configMapName: click_admins_roles
- configMapName: another_one
---
kind: ConfigMap
apiVersion: v1
metadata:
name: click_admins_roles
data:
# data herePros: we're consistent with the way we handle secureSettings. Role resources can be shared across several Elasticsearch resources in the same namespace. Data can have several representations there: a. Key is the role name, value is the raw yaml content kind: ConfigMap
apiVersion: v1
metadata:
name: click_admins_roles
data:
click_admins: |-
run_as: [ 'clicks_watcher_1' ]
cluster: [ 'monitor' ]
indices:
- names: [ 'events-*' ]
privileges: [ 'read' ]
field_security:
grant: ['category', '@timestamp', 'message' ]
query: '{"match": {"category": "click"}}'
another_role:
cluster: ['all']Pros: feels like native use of the key/value format. b. Key is irrelevant, value is the raw roles file content kind: ConfigMap
apiVersion: v1
metadata:
name: click_admins_roles
data:
roles: |-
click_admins:
run_as: [ 'clicks_watcher_1' ]
cluster: [ 'monitor' ]
indices:
- names: [ 'events-*' ]
privileges: [ 'read' ]
field_security:
grant: ['category', '@timestamp', 'message' ]
query: '{"match": {"category": "click"}}'
another_role:
cluster: ['all']Pros: ConfigMap can be generated from a
Same as option 2, with same data format alternatives, expect this time we use Secrets instead of ConfigMaps: spec:
version: 7.5.0
count: 3
fileRealm:
roles:
- secretName: click_admins_roles
- secretName: another_one
---
kind: Secret
apiVersion: v1
metadata:
name: click_admins_roles
data:
# data here (base64)Pros: useful if users don't want roles to be public information?
Instead of an explicit reference in the Elasticsearch CRD, we could use a labeling convention. All ConfigMaps labeled with spec:
version: 7.5.0
count: 3
---
kind: ConfigMap
apiVersion: v1
metadata:
name: click_admins_roles
labels:
common.k8s.elastic.co/type: roles
data:
# data herePros: keep the Elasticsearch CRD minimal.
Same as 4) but use Secrets instead of ConfigMaps. Users
Some options below.
spec:
version: 7.5.0
count: 3
fileRealm:
users:
- secretName: my-es-users
- secretName: my-other-users
---
kind: Secret
apiVersion: v1
metadata:
name: my-es-users
data:
custom-username1: <base64-version-of-the-hash>
custom-username2: <base64-version-of-the-hash>Pros: pretty close to the way users are defined in Elasticsearch
spec:
version: 7.5.0
count: 3
fileRealm:
users:
- secretName: my-es-user
- secretName: my-other-user
---
kind: Secret
apiVersion: v1
metadata:
name: my-es-user
data:
name: <username-base64>
passwordHash: <hash-base64>
password: <cleartext-password-base64> # <--- optional
roles: <role1,role2 - base64> # <--- (or defined elsewhere)Pros: allows us to specify the user roles, and maybe to compute the hash ourselves.
spec:
version: 7.5.0
count: 3
fileRealm:
users_roles:
user_a: role1,role2,role3
user_b: role3Alternatives: can reference a ConfigMap instead, or a secret.
spec:
version: 7.5.0
count: 3
fileRealm:
users:
user_a: <hash of the password>
user_b: <hash of the password>
users_roles:
user_a: role1,role2,role3
user_b: role3Pros: everything in one place. Makes sense if roles are also defined this way.
spec:
version: 7.5.0
count: 3
fileRealm:
secretName: es-file-realm
---
kind: Secret
apiVersion: v1
metadata:
name: es-file-realm
data:
users: <content of the users file, base64>
roles: <content of the roles file, base64>
users_roles: <content of the users_roles file, base64>Pros: very close to Elasticsearch native format, nothing new to learn here for advanced ES users. |
|
The more I think about it, the more I like the very last option: just use a single secret that contains the 3 required files (raw content), as described in the Elasticsearch documentation. No magic at all. We just point users to the official doc. |
|
IMHO everything related to the users should be in a Secret if it's possible (incl. hashes, e.g. on Linux they are in a shadow file) I agree that My concern with the all in one approach is that it does not easily allow the user to reuse the roles definitions ... but I'm not sure it is really big deal either. spec:
version: 7.5.0
count: 3
fileRealm:
- secretName: es-users-file-realm
- secretName: es-roles-file-realm
---
kind: Secret
apiVersion: v1
metadata:
name: es-users-file-realm
data:
users: <content of the users file, base64>
roles: <content of the roles file, base64>
---
kind: Secret
apiVersion: v1
metadata:
name: es-roles-file-realm
data:
users_roles: <content of the users_roles file, base64>This way |
|
I like the all-in-one approach too, and I agree with @barkbay that allowing to specify multiple secrets would be good and also consistent with what we do for secure settings. My only concern is that we cannot offer any convenience for users when it comes to password hashing. But maybe that is acceptable. |
|
Let's move forward with the raw file content merged from multiple secrets. I think we can maybe implement helpers around password hashing in a second time. 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 |
|
In case we ever want to support more security realms in the future, I think we should add an extra spec:
version: 7.5.0
count: 3
realms:
file:
- secretName: es-users-file-realm
- secretName: es-roles-file-realmIt could also make sense to have this under a |
|
We discussed this again with @thbkrkr and are wondering how to best handle users passwords. The main use case for this feature seems to be driven by GitOps-like operations. You have your manifest stored somewhere in Git and you just apply it to auto-deploy Elasticsearch, and auto-create any users you want. I can then imagine those users passwords are mounted into Pods of other applications running in K8s, or used by applications running outside the Kubernetes cluster. Being able to specify the hash is nice if you know how to compute it, and if you already have another way to store the password somewhere (and maybe mount it where necessary). However I feel like we cannot ignore the case where you'd like users to be created and their password mounted into other pods, but you don't actually care that much about specifying the password itself. Similar to how we auto-create the I think there are 3 different ways we can deal with users passwords:
Number 3 seems important to me so should probably be considered in the CRD design. It would require ECK to manipulate 2 secrets:
Not sure how to best express this through the CRD. |
|
I'm fiddling with the following CRD schema: apiVersion: elasticsearch.k8s.elastic.co/v1
kind: Elasticsearch
metadata:
name: elasticsearch-sample
spec:
version: 7.5.0
realms:
file:
content:
- secretName: my-file-realm
- secretName: my-file-realm-2
users:
- secretName: my-user
- secretName: my-user2
---
kind: Secret
apiVersion: v1
metadata:
name: my-file-realm
stringData:
users: <content of the users file>
roles: <content of the roles file>
users_roles: <content of the roles file>
---
kind: Secret
apiVersion: v1
metadata:
name: my-user
stringData:
name: my-user-name
roles: role1,role2,role3 # optional
passwordHash: # optional
password: # optionalIt spits the file realm spec into 2 sections:
Secrets referenced in the
I think it would give some additional flexibility and ease of use for user management, but has the following drawbacks:
|
|
Few things to consider as part of this design are: It's useful in certain scenarios to be able to access the password for a certain account by mounting that secret in another pod. If plaintext passwords are being considered, we should think about a key-value structure for the secret that does not hinder such usage. There have been some questions about changing the passwords of file realm users after the cluster is created. Currently this can be done manually in a disruptive way with the following steps:
It would be good to have a simpler and safer process for changing passwords as that is a reasonable thing that users might want to do on a fairly regular basis. Perhaps its also worth thinking a little bit more about the request in #2408 and create a design that does not explicitly rely on secrets only. I have seen environments where ephemeral secrets from Vault are injected into pods by a sidecar as a file volume instead of a secret. |
|
We discussed this topic on a meeting with @thbkrkr and @barkbay and came with the following design, pretty close to the one expressed in this comment, but with a clear separation between roles and users: apiVersion: elasticsearch.k8s.elastic.co/v1
kind: Elasticsearch
metadata:
name: elasticsearch-sample
spec:
version: 7.5.0
realms:
file:
roles:
- secretName: my-roles-1
- secretName: my-roles-2
users:
- secretName: my-user-1
- secretName: my-user-2
---
kind: Secret
apiVersion: v1
metadata:
name: my-roles-1
stringData:
click_admins: |-
run_as: [ 'clicks_watcher_1' ]
cluster: [ 'monitor' ]
indices:
- names: [ 'events-*' ]
privileges: [ 'read' ]
field_security:
grant: ['category', '@timestamp', 'message' ]
query: '{"match": {"category": "click"}}'
another_role: |-
cluster: [ 'all' ]
---
kind: Secret
apiVersion: v1
metadata:
name: my-user-1
stringData:
name: my-user-name
roles: role1,role2,role3 # optional
passwordHash: # optional
password: # optional
|
|
Thanks, this addresses most of my concerns. Couple of things that stood out to me are:
|
Indeed. I'm wondering if we could setup, additionally, multiple users in a single secret. Same schema as above but one level deeper basically: The downside is that it becomes harder to mount this into Pods. But may be useful for our internal users?
That seems pretty hard to do. I understand the need for mounting eg. Certificates in a Pod through a special kind of volume. But I don't really see a way ECK could "reconcile" multiple users from multiple volumes (?). Would we need to mount these volumes in the ECK Pod? |
|
Something does not work quite well with the idea of auto-creating passwords if not specified:
I think as a general rule of thumb we should not modify anything in a user-provided secret (except, maybe, annotations). |
Nesting is not great and makes it tricky to mount the secret somewhere else as you say. Does Kubernetes even allow nested objects in the
I haven't thought about this a lot. Off the top of my head, it could be either: (a) Let users take care of mounting the files themselves and just provide us with a file path realms:
file:
users:
file: /mnt/path/to/user.yaml(b) Let users specify a volume array and let the operator merge those into the pod volumes array and mount them into the container at a pre-defined path. realms:
file:
users:
- name: userfile1
gitRepo:
directory: /passwords
repositroy: git.url
revision: xxxx
- name: userfile2
secret:
secretName: mysecret |
Yes, that would just be a re. mounting something other than secrets: in any case, it looks like something we could add later on, as another reference at the same level as |
That would be very awkward (and likely require a breaking change to the CRD) if we do find that we need to support sources other than secrets. I'd be inclined to at least follow a schema that can be easily extended to other sources even if the initial implementation only supports secrets. |
|
Some updates: About the CRD format @charith-elastic I get your point and I think we're on the same page. I like your option b), but I think for now we should maybe not reuse k8s volume array type directly, and instead come up with our own that we may later on extend with the k8s volume array type? My only concern is the consistency with how we define secureSettings which don't have the extra I wish we had that Native vs. File realm We talked offline about how we should maybe expose the native realm instead of the file realm because Elasticsearch documentation mentions the file realm is mostly for fallback/recovery. Discussing this further with the Elasticsearch team, we concluded there is no particular concern in having ECK rely on the file realm. It perfectly fits the use case here. Auto-generating passwords Because of this problem it's pretty hard for us to auto-generate passwords in a user-provided secret. Some alternatives:
Both do not feel right to me.
My current feeling is that it would be nice to auto-hash the provided password to the right format (it does not require us to update the user's secret content). And maybe it's OK to not have the password generation feature. |
We're working on getting that removed from the documentation, the caveat is not necessary. I am double checking that the plan here is to use the |
Interesting, thanks for bringing that up. No, I think we did not plan to use it. Internally, ECK already relies on the file realm for "internal" users (the default For end-users (the purpose of this issue), so far 2 alternatives stand out:
Happy to hear your thoughts about it @jasontedor. There might be better alternatives we did not consider. |
Agreed this is challenging, especially because k8s does not provide any functionality to encrypt any resource types at rest, only secrets. I didn't even see any k/k issue where this was brought up as a proposal. We should avoid storing any secret data in anything but a secret resource. I looked into other operators that might need similar functionality, and saw that cert-manager stores the secret data for certs in secrets as well for reference.
This makes sense to me I think. It seems like this is an overall challenge in k8s and not just for us, and I don't see any good way to use it. Anyone who is determined to use autogenerated passwords is likely to have this need for more than just ECK and can use a broader solution. I thought it might be okay to require the hashes be generated, since I figured most people using this feature would have automation around it and would not be handrolling the secrets. But it appears that Helm does not currently have a bcrypt function. They use sprig, which has bcrypt implemented, but only as part of an htpasswd function. We may be able to open a PR with bcrypt support though if we wanted to. That said, as @sebgl if we can generate the hash at runtime and there is no need to update the secret with the hash, I think I am okay with making the hash optional. One thing I might be missing though for both the secret and the volume array suggestions -- the assumption is that we would aggregate all secrets/volumes into one secret which is then mounted into the pod, correct? Is there a way to easily do that for volumes? Compared to how we do it currently |
The concern I have comes from the past when Cloud managed plugins on their own, rather than using the However, it seems that our docs offer more guarantees and say this:
Similarly, we specify the format of the
So while we strongly encourage the use of the tools, it seems that we are willing to accept manually managing these files and offer some guarantees about their internal structure that we couldn't break in a minor release. Given this, I would be okay with not relying on the tool as long as @tvernum is too. |
CLI issuesI think you're fine creating the files by hand, as long as you're strict about following exactly what ES produces. The sorts of caveats are the ones like that which @pebrc mentioned earlier about needing But we do support people who do what @sebgl mentioned in point (1) of an earlier comment. Administrators may use ES tooling to produce a file in 1 place and copy it to their cluster. And we do not presume that their central tooling used the exact same version of those tools as their cluster has. There are people who generated files manually at some point in time and then copied those files into Ansible/Salt/Puppet/etc and now use them to deploy new clusters with potentially newer ES versions. That's fine. We also, for obvious reasons, support upgrading old clusters with existing files to newer ES versions without running file migration tools. That's not to say we would never require a migration tool, but we haven't so far, and we'd do our best to support BWC for a reasonable period of time before we required admins to upgrade the file format. However, you do risk missing out on potential new features that we might add. Theoretically, purely as an example, we might add IP restrictions, or date/time restrictions to users and support including those restrictions in the Realm vs RolesI do want to raise a comment about "file realm" vs "file roles". I think this has settled to a place where users and roles are being handled separately which is good. This issue, and all the conversations I was aware of until now had talked about the "File realm", but API based users can be assigned roles from As a further example of this lack of connection, file based roles ( When administrators fail to appreciate the distinction between realms (which control users) and role providers, they end up with incorrect mental models which lead them to incorrect conclusions (like thinking that disabling the file realm with turn off support for I would encourage you to do your best to treat users and roles as different things, so that people who use ECK don't get led into that incorrect understanding. Kibana RolesKibana roles rely on application privileges stored in ES roles. For example if you want to provide a user with access to a specific Kibana space, but not to other spaces, you need Kibana-specific applications privileges. Which is to say, that no matter what you do in ECK, the roles you manage will be limited to use of ES features & APIs, and not Kibana features unless you create them via the Kibana API. I think that's an entirely reasonable limitation, but you should be aware of it up front. |
|
@tvernum thanks, your point about realms vs. roles is very important and I think we (I, at least) were mistaken here. Based on what you said it does not make sense to have a I'm thinking about having both apiVersion: elasticsearch.k8s.elastic.co/v1
kind: Elasticsearch
metadata:
name: elasticsearch-sample
spec:
version: 7.6.0
auth:
fileRealm:
- secretName: my-secret-name
- secretName: my-secret-2
roles:
- secretName: my-roles-1
- secretName: my-roles-2I think this also gives us room for extensibility in the future if needed: apiVersion: elasticsearch.k8s.elastic.co/v1
kind: Elasticsearch
metadata:
name: elasticsearch-sample
spec:
version: 7.6.0
auth:
# createElasticUser: false
# saml:
# openIdConnect:
fileRealm:
- secretName: my-secret-name
# type: user
- secretName: my-secret-2
# type: rawContent
roles:
- secretName: my-roles-1
- secretName: my-roles-2
# - inline:
# my_role1:
# cluster: [ 'all' ]
# my_role2:
# run_as: [ 'clicks_watcher_1' ]
# cluster: [ 'monitor' ]I think there is real value in making it possible for users to specify kind: Secret
apiVersion: v1
metadata:
name: my-user-1
stringData:
name: my-user-name
roles: role1,role2,role3
password: mypassword
passwordHash: # optional, can be used instead of `password`Regarding the CLI usage, it is definitely simpler for ECK to not use it and build the expected file content directly. Which means we have to commit to support future changes in the file realm spec (eg. the hypothetic IP restriction field you mentioned). As you pointed out, we would have to anyway if we were to invoke the CLI ourselves. |
|
We discussed this again with the team in a Zoom meeting. We agreed on starting with a solution as close as possible to the Elasticsearch official documentation. That is, rely on Kubernetes secrets containing the expected file realm data: apiVersion: elasticsearch.k8s.elastic.co/v1
kind: Elasticsearch
metadata:
name: elasticsearch-sample
spec:
version: 7.6.0
auth:
roles:
- secretName: my-roles-1
fileRealm:
- secretName: my-filerealm-secret
---
# File realm in ES format (from the CLI or manually assembled)
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
---
# Roles in ES format
kind: Secret
apiVersion: v1
metadata:
name: my-roles-1
stringData:
click_admins: |-
run_as: [ 'clicks_watcher_1' ]
cluster: [ 'monitor' ]
indices:
- names: [ 'events-*' ]
privileges: [ 'read' ]
field_security:
grant: ['category', '@timestamp', 'message' ]
query: '{"match": {"category": "click"}}'
another_role: |-
cluster: [ 'all' ]We expect end users to come up with the right file realm secret content one way or another, for example by using the We also agreed on how this is maybe not the most convenient way to create users and passwords in a Kubernetes environment, hence keep the door open for extensibility. Some options listed in this issue could be implemented in the future:
I'm updating the first post accordingly. |
|
Know this isn't the correct ticket to ask this on, but thought I'd see if anyone can help. I'm running ECK 1.0.1 - is there any way to add users as secrets, as alluded to in this #728 (comment) message? Is anything additional required to make it work, or is there documentation anywhere about the spec required? |
|
I think it's better to embed the entire roles.yml file content into a # Roles in ES format
kind: Secret
apiVersion: v1
metadata:
name: my-roles-1
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"}}'
another_role:
cluster: [ 'all' ](instead of the example in the comment above). |
|
Hi, I just want to share how we actually implement user creation in our stack. Actually we create our users through batch command that is not so acceptable: Our goals is to provision Kibana user as a self service. In order to do that we expect to have a CRD for a user creation: Regards |
|
Hello quick clarification,
does it only take bcrypt, I tried sha256 w/ salt and it didn't seem to like it. it looked like this: i did not see logstash_writer among the roles in kibana, did something go wrong? |
|
or more important question, does this have to come from the elasticsearch users helper tool, not sure if something proprietary was going on there. |
|
The recommendation is to use the
The default password hashing algorithm in Elasticsearch is For further usability questions please use Elastic's discussion forums. |
|
thank you ill check out the discussion, i tried bcrypt as well and its not showing up in kibana (the user, or the custom role). Not sure if file realm doesn't actually get registered in kibana or not but also i dont see any complaints in particular anywhere about the user/filerealm format etc... [edit] about the kibana part, nvm...just read this
ive continued the discussion in the discuss forums though about if i can just use the bcrypt lib myself and provide the value in the secrets so thank you. |
|
For others as it was a bit painful for myself. A python example to generate password hash which seems to work: |
We followed the same process after changing the elastic superuser password
but still in elasticsearch logs we are getting below error |
This would allow users to inject their own users into the file realm.
The ES spec would contain the username and a reference to the password secret.
(or maybe just a reference to the secret that contains both usernames and password hashes?)
This issue explores a lot of options, we finally agreed on providing a way to setup secrets containing the "raw" file realm content as described in Elasticsearch docs:
Let's keep the door open for higher-level abstractions (eg. one secret per user with username and password fields) in the future.
The text was updated successfully, but these errors were encountered: