Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Keystore: Allow user to set their own password on the keystore #5737

Closed
1 of 2 tasks
ph opened this issue Nov 28, 2017 · 8 comments
Closed
1 of 2 tasks

Keystore: Allow user to set their own password on the keystore #5737

ph opened this issue Nov 28, 2017 · 8 comments
Labels
good first issue Indicates a good issue for first-time contributors libbeat Stalled Team:Integrations Label for the Integrations team

Comments

@ph
Copy link
Contributor

ph commented Nov 28, 2017

The current keystore currently uses a blank password "" and doesn't allow the user to configure the password on the keystore. The internal implementation has everything in place to support a user provided password.

Logstash is moving forward to allow user to setup an environment variable named LOGSTASH_KEYSTORE_PASS, that could be use to decrypt and create new keys in the keystore.

TODO

  • Add password support to the keystore
  • Add reading password for start scripts

Follow up issue from #5687

related issues: elastic/elasticsearch#22475

@ph ph added the libbeat label Nov 28, 2017
@ph ph self-assigned this Nov 28, 2017
@ph
Copy link
Contributor Author

ph commented Nov 28, 2017

This was discussed in a call with @joshbressers @jakelandis

@joshbressers Do we have more details about how ES is planning to do that? I just have found the meta issue.

I am interested about your opinion @andrewkroh

@ph
Copy link
Contributor Author

ph commented Feb 13, 2018

Looking through Logstash documentation:

It should not be complicated to add support for user defined password via the environment, we already use an empty string as the password. We should probably follow the convention set by Logstash and use {beatname}_KEYSTORE_PASS.

@andrewkroh
Copy link
Member

andrewkroh commented Feb 13, 2018

While it may not be completely avoidable, I'd prefer to keep secrets out of the environment as much as possible. I'd prefer reading from stdin where possible. This gives us more control over the memory where the secrets are stored. We can then do things to protect this memory and can wipe it when done.

I think we should consider using the "ASKPASS" scheme followed by other tools like SSH and Git. Basically we would read from the terminal if we can or use the tool specified in BEAT_ASKPASS if a terminal isn't present. (You can make the logic more smart than what I described.)

With systemd we should use systemd-ask-password to collect the password. It will use the appropriate means to collect the input from the user and output it to our process.

As we receive the password into memory we should consider adding some additional protections to the memory like ensuring that the password and any unencrypted secrets are not swapped to disk (mlock). We could also surround the data with some mprotect guard pages such that if something tries to read our protected memory that we wipe it and exit.

edit: And if the Beats needs a password we should get it early on because we want to add a seccomp filter that prevents execve and you want be able to invoke the ASKPASS program afterwards.

@joshbressers
Copy link

I filed an issue for elasticsearch around needing a password to unlock the keystore
elastic/elasticsearch#32691

@urso urso added good first issue Indicates a good issue for first-time contributors [zube]: Backlog labels Jan 13, 2020
@andresrc andresrc added Team:Integrations Label for the Integrations team and removed Team:Beats labels Mar 6, 2020
@ph ph removed their assignment Apr 30, 2020
@Ihaim-crypto
Copy link

Hello,
Is there an estimated version in which this is planned to be released?
according to the latest API (Filebeat f.e), you can't create a Keystore with user password
It is a valuable security concern for usage.

@botelastic
Copy link

botelastic bot commented Apr 21, 2022

Hi!
We just realized that we haven't looked into this issue in a while. We're sorry!

We're labeling this issue as Stale to make it hit our filters and make sure we get back to it as soon as possible. In the meantime, it'd be extremely helpful if you could take a look at it as well and confirm its relevance. A simple comment with a nice emoji will be enough :+1.
Thank you for your contribution!

@botelastic botelastic bot added the Stalled label Apr 21, 2022
@wolframhaussig
Copy link

👍

@botelastic botelastic bot removed the Stalled label Oct 11, 2022
@botelastic
Copy link

botelastic bot commented Oct 11, 2023

Hi!
We just realized that we haven't looked into this issue in a while. We're sorry!

We're labeling this issue as Stale to make it hit our filters and make sure we get back to it as soon as possible. In the meantime, it'd be extremely helpful if you could take a look at it as well and confirm its relevance. A simple comment with a nice emoji will be enough :+1.
Thank you for your contribution!

@botelastic botelastic bot added the Stalled label Oct 11, 2023
@botelastic botelastic bot closed this as completed Apr 8, 2024
jbudz added a commit to elastic/kibana that referenced this issue May 6, 2024
This adds support a password protected keystore. The UX should match
other stack products.

Closes #21756.

```
[jon@mbpkbn1]/tmp/kibana-8.15.0-SNAPSHOT% bin/kibana-keystore create --password
A Kibana keystore already exists. Overwrite? [y/N] y
Enter new password for the kibana keystore (empty for no password): ********
Created Kibana keystore in /tmp/kibana-8.15.0-SNAPSHOT/config/kibana.keystore

[jon@mbpkbn1]/tmp/kibana-8.15.0-SNAPSHOT% bin/kibana-keystore add elasticsearch.username
Enter password for the kibana keystore: ********
Enter value for elasticsearch.username: *************

[jon@mbpkbn1]/tmp/kibana-8.15.0-SNAPSHOT% bin/kibana-keystore add elasticsearch.password
Enter password for the kibana keystore: ********
Enter value for elasticsearch.password: ********

[jon@mbpkbn1]/tmp/kibana-8.15.0-SNAPSHOT% bin/kibana
...
Enter password for the kibana keystore: ********
[2024-04-30T09:47:03.560-05:00][INFO ][root] Kibana is starting

[jon@mbpkbn1]/tmp/kibana-8.15.0-SNAPSHOT% bin/kibana-keystore has-passwd
Keystore is password-protected

[jon@mbpkbn1]/tmp/kibana-8.15.0-SNAPSHOT% ./bin/kibana-keystore show elasticsearch.username
Enter password for the kibana keystore: ********
kibana_system

[jon@mbpkbn1]/tmp/kibana-8.15.0-SNAPSHOT% ./bin/kibana-keystore remove elasticsearch.username
Enter password for the kibana keystore: ********

[jon@mbpkbn1]/tmp/kibana-8.15.0-SNAPSHOT% ./bin/kibana-keystore show elasticsearch.username
Enter password for the kibana keystore: ********
ERROR: Kibana keystore doesn't have requested key.

[jon@mbpkbn1]/tmp/kibana-8.15.0-SNAPSHOT% bin/kibana-keystore passwd
Enter password for the kibana keystore: ********
Enter new password for the kibana keystore (empty for no password):
[jon@mbpkbn1]/tmp/kibana-8.15.0-SNAPSHOT% ./bin/kibana-keystore has-passwd
Error: Keystore is not password protected

[jon@mbpkbn1]/tmp/kibana-8.15.0-SNAPSHOT% ./bin/kibana
...
[2024-04-30T09:49:03.220-05:00][INFO ][root] Kibana is starting
```

## Password input

Environment variable usage is not consistent across stack products. I
implemented `KBN_KEYSTORE_PASSWORD_FILE` and `KBN_KEYSTORE_PASSWORD` to
be used to avoid prompts. @elastic/kibana-security do you have any
thoughts?


- `LOGSTASH_KEYSTORE_PASS` -
https://www.elastic.co/guide/en/logstash/current/keystore.html#keystore-password
- `KEYSTORE_PASSWORD` -
https://www.elastic.co/guide/en/elasticsearch/reference/current/docker.html#docker-keystore-bind-mount
- `ES_KEYSTORE_PASSPHRASE_FILE` -
https://www.elastic.co/guide/en/elasticsearch/reference/current/rpm.html#rpm-running-systemd
- Beats discussion, unresolved:
elastic/beats#5737


## Release note
Adds password support to the Kibana keystore.
@zube zube bot removed the [zube]: Done label Jul 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Indicates a good issue for first-time contributors libbeat Stalled Team:Integrations Label for the Integrations team
Projects
None yet
Development

No branches or pull requests

7 participants