Set LDAP bind password in elasticsearch_keystore

Elastic Stack Elasticsearch
1

Hello,

I have Elasticsearch 6.2.3 and I am trying to set the ldap bind password in the elasticsearch_keystore so that it will pull the setting on startup. I tried setting 'xpack.security.authc.realms.ldap1.bind_password' to my password in keystore but it doesn't seem to be using the vault. I had to hardcode the value in the elasticsearch.yml but that doesn't seem that secure to me.

If this should be available is there a way to make sure the value being set is correct or if elasticsearch is getting it from the vault at startup?

2

Elasticsearch keystore is useless. It does not provide data protection.

3

Well that's not good to hear.
In that case having the password in the config file is probably the right way for now. It would be nice to have these values encrypted using a vault of some kind or even encrypted in an index.

4

Hello @mitchellmaler,

Here are a few insights, I think might help with the bigger picture.

Currently (version 6.2.3), the LDAP bind password has to be inside the conf file. It is true that this is not "secure". Likely this will change in 6.3. The password will be stored inside the Elasticsearch keystore, very similar to what you have tried, and the current way will get deprecated.

Elasticsearch keystore is useless. It does not provide data protection.

Elasticsearch keystore does not yet provide data protection, only obfuscation. This is also something we are working right now. Trouble here is that there has to be some service feeding the secret required to decrypt the Elasticsearch keystore, because it is impossible for the human operator to be prompted for the password on all occasions/deployments for which password is required.

5

That is good to hear you guys are making progress in the keystore to add encryption.
Hopefully the ldap option does come in 6.3. I will keep a lookout for it.

6

Adding to what @Albert_Zaharovits said, I would like to point out that although the keystore is not password protected (which is openly stated in the documentation), that does not mean it is useless.

The fact that these secrets are not stored in your main configuration file means:

  • You can apply different file permissions (at the OS level) to reflect the different security needs of these settings. Your elasticsearch.yml can be readable by all operations staff, while the elasticsearch.keystore is locked down to be only accessed by your elasticsearch service account.
  • Similarly you can show your configuration file to other people (e.g. Elastic support) without having to redact passwords. Our support team appreciate when they can help troubleshoot a customer's problem without accidentally seeing secrets that they shouldn't have access to.
  • You can apply different backup policies. If you are concerned about passwords being stored within your offsite backups, you can choose to exclude this file from your backup policy, or to be independently encrypted in your backups (if your backup tooling supports that).
  • You can make changes to passwords independently of rolling out changes to the main configuration. That is, you can have different tools and processes to manage secrets, from the tools and processes you use to manage system configuration. (Bearing in mind, that right now you need to restart the elasticsearch node in order to reload the secrets).
7

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.