Elasticsearch keystore passphrase for startup scripts #44775

williamrandolph · 2019-07-23T20:22:10Z

The work here covers the tar, systemd, and docker use cases. The changes to Java will let Windows users provide a keystore password on standard input.

The approach here is as outlined in this comment: #32691 (comment)

The bin/elasticsearch script handles reading a keystore password either from standard input, from a file, or from a FIFO, and provides the password to the Elasticsearch runtime via standard input. Elasticsearch's bootstrap code simply reads from standard input when it detects a password-protected keystore.

I found some bugs in our keystore CLI code that relate to reading standard input. The problem appeared when I was running commands like bin/elasticsearch-keystore add -x bootstrap.password with a password-protected keystore. In short, we were using several different BufferedReader objects to read from standard input, and whichever BufferedReader read first would slurp more input into its buffer than needed, leaving nothing for the later BufferedReader to read. My solution was to wrap a single BufferedReader in the SystemTerminal class to handle all the input in non-interactive cases. I added unit tests for these cases, but my approach may be overly intrusive (a TestSystemTerminal class). I would be open to simpler approaches.

I also ran into a classic bug on OSX where every CLI command took five seconds to initialize logging. This meant that I couldn't use bin/elasticsearch-keystore list to check whether a keystore required a password or not. Instead, I used dd to check the value of the particular byte that serves as the encryption flag in the keystore file. It looked like I could only parameterize startup scripts by rpm/tar/zip, rather than darwin/linux/windows, so I went ahead and used dd in all the tar builds.

I have some notes for testing this work that may be useful as documentation. I'll post them as comments on this PR.

Relates #32691, #38498

- Subcommands of elasticsearch-keystore can handle (open and create) passphrase protected keystores - When reading a keystore, a user is only prompted for a passphrase only if the keystore is passphrase protected. Relates to: elastic#32691

- Moves the code to read the passphrase to KeyStoreWrapper - Adds a subcommand to elasticsearch-keystore for setting or changing the keystore's password

…arameterized in a followup PR so that we can run tests with encrypted keystores

…ore-cli-passphrase

…tore-cli-passphrase

…ntil we can provide the passphrase on startup

…tore-cli-passphrase

…into elasticsearch-keystore-cli-passphrase

- Default behavior when creating a keystore is now to set an empty string as the password (as is the current behavior) - Password can be set with the ChangeKeyStorePassword subcommand - Keystores can be created being password protected, by passing `-p` or `--password`. Users will be prompted to set the password. - Renamed passphrase to password everywhere for consistency

…into elasticsearch-keystore-cli-passphrase

- Move common functionality in a base class - Change behavior for -f that was also forcing creation of the keystore without this being documented or explained in the prompt - Allow user to indicate if autogenerated keystores should be password protected

…into elasticsearch-keystore-cli-passphrase

This is initial and exporatory work for incorporating keystore passwords in the Elasticsearch startup process. The "user interface" that prompts for and reads a password is in the bash startup script. The bash script uses existing command-line utilities to test whether the keystore exists and a password is needed; if so, the password is given to the Java startup process using a "here string" and a new command-line lag that alerts Java to data coming in over standard input. Known issues: Java code that reads from standard input is not thread-safe, initial keystore verification is unacceptably slow. Relates elastic#32691, elastic#38498

We now use the "Terminal" class, which encapsulates thread-safe access to stdin. Additionally, we now test for a particular "encrypted" byte flag in the keystore file rather than running the slow keystore utility, and we don't test the password before passing it to Elasticsearch, which avoids a second call to the keystore utility.

In a discussion meeting, it was pointed out to me that the keystore wapper object's hasPassword() method makes the standard input flag that I added redundant, so I'm backing out that fairly intrusive change to the Java code.

It's convenient to use the bin/elasticsearch-keystore list command to test whether or not the keystore is encrypted. When no password is supplied to an encrypted keystore, the command has a non-zero exit status. However, many JVMs on OSX with default networking configuration will take at least five seconds to run an elasticsearch-keystore command. This is because we have to initialize log4j 2, and that initialization code will call InetAddress.getLocalHost().getHostname(), which is the bit of code with the bug. Since all our OSX distributions come in tarballs, I've parameterized bin/elasticsearch so that we check the encrypted flag byte with "dd". It might be nice to do this just for Darwin distributions. For RPMs and Debian distros, we use the keystore tool for the check. I've also added a little bit more output to the bin/elasticsearch command, and improved handling of the case where the script fails to read any lines from standard input.

Java's classic buffered readers are efficient because they read more than is strictly needed for an operation and store it in a buffer. The implication of this is that you shouldn't use multiple buffered readers on the same input stream. Unfortunately, our CLI tools were doing this in a few places. Tests didn't catch this because our mock Terminal class doesn't reveal the problem. First, the SystemTerminal's readText method was creating a new BufferedReader per invocation, which meant that it cannot reliably read two lines in a row. There is a new TerminalTest that covers this case. The code fix was to lazily initialize a new BufferedReader the first time we try to read from standard input. Second, the AddStringKeyStoreCommand class created its own BufferedReader when the -x/--stdin option was supplied. I'm not sure what this flag really accomplishes, other than perhaps not printing a prompt. Without the flag, the input still comes in over stdin. At any rate, I've replaced the BufferedReader with an invocation of the Terminal and added a test in AddStringKeystoreCommandTests.

I've reworked the unit tests in accordance with gradlew check. Instead of setting System.in, I've created a test class specifically for the SystemTerminal. Unlike the MockTerminal we already have, it doesn't verify output, but it does exercise some code paths that the MockTerminal skips. I had to add a new protected method to the Terminal class, which is less than ideal. Perhaps these tests should be integration tests rather than unit tests.

This work makes it possible to mount a password-protected keystore in a docker image and provide that keystore's password as a docker environment variable. There is a little bit of trickery around dirty output from the keystore-list command, and the control flow might have gotten a little too tangled and nested, but I hope it works for a first cut.

…ch-keystore-init-passphrase

…tore-init-passphrase

This is something I did before but accidentally reverted in the merge. The issue is that tests can distinguish between "secret" mock input and standard input, but at runtime we can't have multiple buffered readers out there pulling in stdin. All the console I/O needs to be handled through the Terminal.

This is another bit that I missed when merging master. We don't "run as a role" on Windows, but we pretend like we do by setting the ownership of the keystore file manually.

williamrandolph

Checklist from taking a pass through my own PR code.

server/src/test/java/org/elasticsearch/cli/TerminalTests.java

server/src/test/java/org/elasticsearch/cli/MultiCommandTests.java

server/src/main/java/org/elasticsearch/cli/KeyStoreAwareCommand.java

qa/os/src/test/java/org/elasticsearch/packaging/util/Archives.java

qa/os/src/test/java/org/elasticsearch/packaging/test/PackagingTestCase.java

qa/os/src/test/java/org/elasticsearch/packaging/test/KeystoreManagementTests.java

libs/cli/src/main/java/org/elasticsearch/cli/Terminal.java

...keystore-cli/src/main/java/org/elasticsearch/common/settings/HasPasswordKeyStoreCommand.java

…tore-init-passphrase

williamrandolph · 2019-10-17T14:40:55Z

@elasticmachine run elasticsearch-ci/packaging-sample

williamrandolph · 2019-10-17T14:51:35Z

@elasticmachine test this please

williamrandolph · 2019-10-17T15:46:34Z

Ah, the failing test here will never pass, because now it is gone: https://github.com/elastic/infra/pull/15360

…tore-init-passphrase

williamrandolph · 2019-10-25T21:19:40Z

@elasticmachine run elasticsearch-ci/1

rjernst

Thanks for all the iterations here @williamrandolph. I left a few more minor thoughts but this LGTM.

distribution/tools/keystore-cli/src/test/java/org/elasticsearch/bootstrap/BootstrapTests.java

rjernst · 2019-10-25T22:24:19Z

server/src/main/java/org/elasticsearch/bootstrap/Bootstrap.java

+            throw new BootstrapException(e);
+        }
+
+        try (SecureString password = new SecureString(passChars)) {


future thought (doesn't need to be in this PR): maybe readPassphrase should return a SecureString.

server/src/main/java/org/elasticsearch/bootstrap/Bootstrap.java

server/src/test/java/org/elasticsearch/cli/TerminalTests.java

We don't need to duplicate the stream-reading logic in two places. Instead, the Bootstrap class can delegate the the Terminal method, while preserving its own specific error messages.

This commit allows a user to provide a keystore password on Elasticsearch startup, but only prompts when the keystore exists and is encrypted. The entrypoint in Java code is standard input. When the Bootstrap class is checking for secure keystore settings, it checks whether or not the keystore is encrypted. If so, we read one line from standard input and use this as the password. For simplicity's sake, we allow a maximum passphrase length of 128 characters. (This is an arbitrary limit and could be increased or eliminated. It is also enforced in the keystore tools, so that a user can't create a password that's too long to enter at startup.) In order to provide a password on standard input, we have to account for four different ways of starting Elasticsearch: the bash startup script, the Windows batch startup script, systemd startup, and docker startup. We use wrapper scripts to reduce systemd and docker to the bash case: in both cases, a wrapper script can read a passphrase from the filesystem and pass it to the bash script. In order to simplify testing the need for a passphrase, I have added a has-passwd command to the keystore tool. This command can run silently, and exit with status 0 when the keystore has a password. It exits with status 1 if the keystore doesn't exist or exists and is unencrypted. A good deal of the code-change in this commit has to do with refactoring packaging tests to cleanly use the same tests for both the "archive" and the "package" cases. This required not only moving tests around, but also adding some convenience methods for an abstraction layer over distribution-specific commands. I will write some user-facing documentation for these changes in a follow-up commit.

* Reload secure settings with password (#43197) If a password is not set, we assume an empty string to be compatible with previous behavior. Only allow the reload to be broadcast to other nodes if TLS is enabled for the transport layer. * Add passphrase support to elasticsearch-keystore (#38498) This change adds support for keystore passphrases to all subcommands of the elasticsearch-keystore cli tool and adds a subcommand for changing the passphrase of an existing keystore. The work to read the passphrase in Elasticsearch when loading, which will be addressed in a different PR. Subcommands of elasticsearch-keystore can handle (open and create) passphrase protected keystores When reading a keystore, a user is only prompted for a passphrase only if the keystore is passphrase protected. When creating a keystore, a user is allowed (default behavior) to create one with an empty passphrase Passphrase can be set to be empty when changing/setting it for an existing keystore Relates to: #32691 Supersedes: #37472 * Restore behavior for force parameter (#44847) Turns out that the behavior of `-f` for the add and add-file sub commands where it would also forcibly create the keystore if it didn't exist, was by design - although undocumented. This change restores that behavior auto-creating a keystore that is not password protected if the force flag is used. The force OptionSpec is moved to the BaseKeyStoreCommand as we will presumably want to maintain the same behavior in any other command that takes a force option. * Handle pwd protected keystores in all CLI tools (#45289) This change ensures that `elasticsearch-setup-passwords` and `elasticsearch-saml-metadata` can handle a password protected elasticsearch.keystore. For setup passwords the user would be prompted to add the elasticsearch keystore password upon running the tool. There is no option to pass the password as a parameter as we assume the user is present in order to enter the desired passwords for the built-in users. For saml-metadata, we prompt for the keystore password at all times even though we'd only need to read something from the keystore when there is a signing or encryption configuration. * Modify docs for setup passwords and saml metadata cli (#45797) Adds a sentence in the documentation of `elasticsearch-setup-passwords` and `elasticsearch-saml-metadata` to describe that users would be prompted for the keystore's password when running these CLI tools, when the keystore is password protected. Co-Authored-By: Lisa Cawley <[email protected]> * Elasticsearch keystore passphrase for startup scripts (#44775) This commit allows a user to provide a keystore password on Elasticsearch startup, but only prompts when the keystore exists and is encrypted. The entrypoint in Java code is standard input. When the Bootstrap class is checking for secure keystore settings, it checks whether or not the keystore is encrypted. If so, we read one line from standard input and use this as the password. For simplicity's sake, we allow a maximum passphrase length of 128 characters. (This is an arbitrary limit and could be increased or eliminated. It is also enforced in the keystore tools, so that a user can't create a password that's too long to enter at startup.) In order to provide a password on standard input, we have to account for four different ways of starting Elasticsearch: the bash startup script, the Windows batch startup script, systemd startup, and docker startup. We use wrapper scripts to reduce systemd and docker to the bash case: in both cases, a wrapper script can read a passphrase from the filesystem and pass it to the bash script. In order to simplify testing the need for a passphrase, I have added a has-passwd command to the keystore tool. This command can run silently, and exit with status 0 when the keystore has a password. It exits with status 1 if the keystore doesn't exist or exists and is unencrypted. A good deal of the code-change in this commit has to do with refactoring packaging tests to cleanly use the same tests for both the "archive" and the "package" cases. This required not only moving tests around, but also adding some convenience methods for an abstraction layer over distribution-specific commands. I will write some user-facing documentation for these changes in a follow-up commit. * Adjust docs for password protected keystore (#45054) This commit adds relevant parts in the elasticsearch-keystore sub-commands reference docs and in the reload secure settings API doc. * Cleanup after feature branch reconstruction The feature branch for the password-protected keystore, due to an accident, contains a large number of unrelated commits. In order to get a cleaner merge, I've cherry-picked the main commits that went into the feature branch against a branch derived from master — essentially, a rebase onto master. We've ignored some tests that will addressed in follow-up PRs to the feature branch.

) * Reload secure settings with password (elastic#43197) If a password is not set, we assume an empty string to be compatible with previous behavior. Only allow the reload to be broadcast to other nodes if TLS is enabled for the transport layer. * Add passphrase support to elasticsearch-keystore (elastic#38498) This change adds support for keystore passphrases to all subcommands of the elasticsearch-keystore cli tool and adds a subcommand for changing the passphrase of an existing keystore. The work to read the passphrase in Elasticsearch when loading, which will be addressed in a different PR. Subcommands of elasticsearch-keystore can handle (open and create) passphrase protected keystores When reading a keystore, a user is only prompted for a passphrase only if the keystore is passphrase protected. When creating a keystore, a user is allowed (default behavior) to create one with an empty passphrase Passphrase can be set to be empty when changing/setting it for an existing keystore Relates to: elastic#32691 Supersedes: elastic#37472 * Restore behavior for force parameter (elastic#44847) Turns out that the behavior of `-f` for the add and add-file sub commands where it would also forcibly create the keystore if it didn't exist, was by design - although undocumented. This change restores that behavior auto-creating a keystore that is not password protected if the force flag is used. The force OptionSpec is moved to the BaseKeyStoreCommand as we will presumably want to maintain the same behavior in any other command that takes a force option. * Handle pwd protected keystores in all CLI tools (elastic#45289) This change ensures that `elasticsearch-setup-passwords` and `elasticsearch-saml-metadata` can handle a password protected elasticsearch.keystore. For setup passwords the user would be prompted to add the elasticsearch keystore password upon running the tool. There is no option to pass the password as a parameter as we assume the user is present in order to enter the desired passwords for the built-in users. For saml-metadata, we prompt for the keystore password at all times even though we'd only need to read something from the keystore when there is a signing or encryption configuration. * Modify docs for setup passwords and saml metadata cli (elastic#45797) Adds a sentence in the documentation of `elasticsearch-setup-passwords` and `elasticsearch-saml-metadata` to describe that users would be prompted for the keystore's password when running these CLI tools, when the keystore is password protected. Co-Authored-By: Lisa Cawley <[email protected]> * Elasticsearch keystore passphrase for startup scripts (elastic#44775) This commit allows a user to provide a keystore password on Elasticsearch startup, but only prompts when the keystore exists and is encrypted. The entrypoint in Java code is standard input. When the Bootstrap class is checking for secure keystore settings, it checks whether or not the keystore is encrypted. If so, we read one line from standard input and use this as the password. For simplicity's sake, we allow a maximum passphrase length of 128 characters. (This is an arbitrary limit and could be increased or eliminated. It is also enforced in the keystore tools, so that a user can't create a password that's too long to enter at startup.) In order to provide a password on standard input, we have to account for four different ways of starting Elasticsearch: the bash startup script, the Windows batch startup script, systemd startup, and docker startup. We use wrapper scripts to reduce systemd and docker to the bash case: in both cases, a wrapper script can read a passphrase from the filesystem and pass it to the bash script. In order to simplify testing the need for a passphrase, I have added a has-passwd command to the keystore tool. This command can run silently, and exit with status 0 when the keystore has a password. It exits with status 1 if the keystore doesn't exist or exists and is unencrypted. A good deal of the code-change in this commit has to do with refactoring packaging tests to cleanly use the same tests for both the "archive" and the "package" cases. This required not only moving tests around, but also adding some convenience methods for an abstraction layer over distribution-specific commands. I will write some user-facing documentation for these changes in a follow-up commit. * Adjust docs for password protected keystore (elastic#45054) This commit adds relevant parts in the elasticsearch-keystore sub-commands reference docs and in the reload secure settings API doc. * Cleanup after feature branch reconstruction The feature branch for the password-protected keystore, due to an accident, contains a large number of unrelated commits. In order to get a cleaner merge, I've cherry-picked the main commits that went into the feature branch against a branch derived from master — essentially, a rebase onto master. We've ignored some tests that will addressed in follow-up PRs to the feature branch.

* Reload secure settings with password (#43197) If a password is not set, we assume an empty string to be compatible with previous behavior. Only allow the reload to be broadcast to other nodes if TLS is enabled for the transport layer. * Add passphrase support to elasticsearch-keystore (#38498) This change adds support for keystore passphrases to all subcommands of the elasticsearch-keystore cli tool and adds a subcommand for changing the passphrase of an existing keystore. The work to read the passphrase in Elasticsearch when loading, which will be addressed in a different PR. Subcommands of elasticsearch-keystore can handle (open and create) passphrase protected keystores When reading a keystore, a user is only prompted for a passphrase only if the keystore is passphrase protected. When creating a keystore, a user is allowed (default behavior) to create one with an empty passphrase Passphrase can be set to be empty when changing/setting it for an existing keystore Relates to: #32691 Supersedes: #37472 * Restore behavior for force parameter (#44847) Turns out that the behavior of `-f` for the add and add-file sub commands where it would also forcibly create the keystore if it didn't exist, was by design - although undocumented. This change restores that behavior auto-creating a keystore that is not password protected if the force flag is used. The force OptionSpec is moved to the BaseKeyStoreCommand as we will presumably want to maintain the same behavior in any other command that takes a force option. * Handle pwd protected keystores in all CLI tools (#45289) This change ensures that `elasticsearch-setup-passwords` and `elasticsearch-saml-metadata` can handle a password protected elasticsearch.keystore. For setup passwords the user would be prompted to add the elasticsearch keystore password upon running the tool. There is no option to pass the password as a parameter as we assume the user is present in order to enter the desired passwords for the built-in users. For saml-metadata, we prompt for the keystore password at all times even though we'd only need to read something from the keystore when there is a signing or encryption configuration. * Modify docs for setup passwords and saml metadata cli (#45797) Adds a sentence in the documentation of `elasticsearch-setup-passwords` and `elasticsearch-saml-metadata` to describe that users would be prompted for the keystore's password when running these CLI tools, when the keystore is password protected. Co-Authored-By: Lisa Cawley <[email protected]> * Elasticsearch keystore passphrase for startup scripts (#44775) This commit allows a user to provide a keystore password on Elasticsearch startup, but only prompts when the keystore exists and is encrypted. The entrypoint in Java code is standard input. When the Bootstrap class is checking for secure keystore settings, it checks whether or not the keystore is encrypted. If so, we read one line from standard input and use this as the password. For simplicity's sake, we allow a maximum passphrase length of 128 characters. (This is an arbitrary limit and could be increased or eliminated. It is also enforced in the keystore tools, so that a user can't create a password that's too long to enter at startup.) In order to provide a password on standard input, we have to account for four different ways of starting Elasticsearch: the bash startup script, the Windows batch startup script, systemd startup, and docker startup. We use wrapper scripts to reduce systemd and docker to the bash case: in both cases, a wrapper script can read a passphrase from the filesystem and pass it to the bash script. In order to simplify testing the need for a passphrase, I have added a has-passwd command to the keystore tool. This command can run silently, and exit with status 0 when the keystore has a password. It exits with status 1 if the keystore doesn't exist or exists and is unencrypted. A good deal of the code-change in this commit has to do with refactoring packaging tests to cleanly use the same tests for both the "archive" and the "package" cases. This required not only moving tests around, but also adding some convenience methods for an abstraction layer over distribution-specific commands. * Adjust docs for password protected keystore (#45054) This commit adds relevant parts in the elasticsearch-keystore sub-commands reference docs and in the reload secure settings API doc. * Fix failing Keystore Passphrase test for feature branch (#50154) One problem with the passphrase-from-file tests, as written, is that they would leave a SystemD environment variable set when they failed, and this setting would cause elasticsearch startup to fail for other tests as well. By using a try-finally, I hope that these tests will fail more gracefully. It appears that our Fedora and Ubuntu environments may be configured to store journald information under /var rather than under /run, so that it will persist between boots. Our destructive tests that read from the journal need to account for this in order to avoid trying to limit the output we check in tests. * Run keystore management tests on docker distros (#50610) * Add Docker handling to PackagingTestCase Keystore tests need to be able to run in the Docker case. We can do this by using a DockerShell instead of a plain Shell when Docker is running. * Improve ES startup check for docker Previously we were checking truncated output for the packaged JDK as an indication that Elasticsearch had started. With new preliminary password checks, we might get a false positive from ES keystore commands, so we have to check specifically that the Elasticsearch class from the Bootstrap package is what's running. * Test password-protected keystore with Docker (#50803) This commit adds two tests for the case where we mount a password-protected keystore into a Docker container and provide a password via a Docker environment variable. We also fix a logging bug where we were logging the identifier for an array of strings rather than the contents of that array. * Add documentation for keystore startup prompting (#50821) When a keystore is password-protected, Elasticsearch will prompt at startup. This commit adds documentation for this prompt for the archive, systemd, and Docker cases. Co-authored-by: Lisa Cawley <[email protected]> * Warn when unable to upgrade keystore on debian (#51011) For Red Hat RPM upgrades, we warn if we can't upgrade the keystore. This commit brings the same logic to the code for Debian packages. See the posttrans file for gets executed for RPMs. * Restore handling of string input Adds tests that were mistakenly removed. One of these tests proved we were not handling the the stdin (-x) option correctly when no input was added. This commit restores the original approach of reading stdin one char at a time until there is no more (-1, \r, \n) instead of using readline() that might return null * Apply spotless reformatting * Use '--since' flag to get recent journal messages When we get Elasticsearch logs from journald, we want to fetch only log messages from the last run. There are two reasons for this. First, if there are many logs, we might get a string that's too large for our utility methods. Second, when we're looking for a specific message or error, we almost certainly want to look only at messages from the last execution. Previously, we've been trying to do this by clearing out the physical files under the journald process. But there seems to be some contention over these directories: if journald writes a log file in between when our deletion command deletes the file and when it deletes the log directory, the deletion will fail. It seems to me that we might be able to use journald's "--since" flag to retrieve only log messages from the last run, and that this might be less likely to fail due to race conditions in file deletion. Unfortunately, it looks as if the "--since" flag has a granularity of one-second. I've added a two-second sleep to make sure that there's a sufficient gap between the test that will read from journald and the test before it. * Use new journald wrapper pattern * Update version added in secure settings request Co-authored-by: Lisa Cawley <[email protected]> Co-authored-by: Ioannis Kakavas <[email protected]>

jkakavas and others added 30 commits January 15, 2019 13:39

Address feedback

c74685f

- Moves the code to read the passphrase to KeyStoreWrapper - Adds a subcommand to elasticsearch-keystore for setting or changing the keystore's password

Allow creating obfuscated keystores without prompting for a passphrase

af3d5e9

Create obfuscated keystores for integTestCluster tasks. This can be p…

d118da4

…arameterized in a followup PR so that we can run tests with encrypted keystores

Merge remote-tracking branch 'origin/master' into elasticsearch-keyst…

041143e

…ore-cli-passphrase

Merge branch 'feature-pwd-protected-keystore' into elasticsearch-keys…

852533a

…tore-cli-passphrase

address feedback

668c438

Handle tests by creating obfuscated keystores by default - At least u…

95e1a78

…ntil we can provide the passphrase on startup

Merge branch 'feature-pwd-protected-keystore' into elasticsearch-keys…

bc5b99d

…tore-cli-passphrase

Merge remote-tracking branch 'origin/feature-pwd-protected-keystore' …

f095d90

…into elasticsearch-keystore-cli-passphrase

fix checkstyl

76ea066

Merge remote-tracking branch 'origin/feature-pwd-protected-keystore' …

500c79a

…into elasticsearch-keystore-cli-passphrase

revert unnecessary formatting changes

ba4a9ba

remove nopass again

2b74f64

Addresses feedback

ecc0ed6

- Move common functionality in a base class - Change behavior for -f that was also forcing creation of the keystore without this being documented or explained in the prompt - Allow user to indicate if autogenerated keystores should be password protected

Merge remote-tracking branch 'origin/feature-pwd-protected-keystore' …

ac5cf83

…into elasticsearch-keystore-cli-passphrase

address feedback

ca55074

Merge remote-tracking branch 'origin/feature-pwd-protected-keystore' …

690df96

…into elasticsearch-keystore-cli-passphrase

Remove command line flag for standard input

e390afe

In a discussion meeting, it was pointed out to me that the keystore wapper object's hasPassword() method makes the standard input flag that I added redundant, so I'm backing out that fairly intrusive change to the Java code.

Let bin/elasticsearch read passwd from FIFO/file

8c99702

Merge branch 'elasticsearch-keystore-cli-passphrase' into elasticsear…

9ab6cdf

…ch-keystore-init-passphrase

Merge branch 'feature-pwd-protected-keystore' into elasticsearch-keys…

c9c0b42

…tore-init-passphrase

Run chown on autocreated keystore on Windows tests

e548d55

This is another bit that I missed when merging master. We don't "run as a role" on Windows, but we pretend like we do by setting the ownership of the keystore file manually.

williamrandolph commented Oct 16, 2019

View reviewed changes

williamrandolph added 7 commits October 16, 2019 15:45

Simplify tests with StringReader

7eb26c2

Clarify purpose of unit test

36d61ae

Sundry trivial cleanup

6fc4994

Refactor big Powershell script string

94e6a3f

Get powershell output path via static method

1ef3dfb

Checkstyle - remove unused import

c31c88e

Merge branch 'feature-pwd-protected-keystore' into elasticsearch-keys…

6eb3e35

…tore-init-passphrase

Merge branch 'feature-pwd-protected-keystore' into elasticsearch-keys…

b85eed9

…tore-init-passphrase

rjernst approved these changes Oct 25, 2019

View reviewed changes

williamrandolph added 3 commits October 28, 2019 14:59

Use expectThrows instead of JUnit rule

56b83f1

Bootstrap's readPassphrase delegates to Terminal

f982f91

We don't need to duplicate the stream-reading logic in two places. Instead, the Bootstrap class can delegate the the Terminal method, while preserving its own specific error messages.

Remove unused imports

73e35e7

williamrandolph merged commit 0a0db4b into elastic:feature-pwd-protected-keystore Nov 11, 2019

This was referenced Nov 19, 2019

Documentation for keystore passwords at startup #49338

Closed

Add Windows-compatible testing for interacting with CLI over TTY #49340

Open

williamrandolph mentioned this pull request Jan 9, 2020

Add documentation for keystore startup prompting #50821

Merged

williamrandolph mentioned this pull request Jan 28, 2020

Password-protected Keystore Feature Branch PR (#51123) #51510

Merged

williamrandolph deleted the elasticsearch-keystore-init-passphrase branch May 23, 2022 17:27

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Elasticsearch keystore passphrase for startup scripts #44775

Elasticsearch keystore passphrase for startup scripts #44775

williamrandolph commented Jul 23, 2019 •

edited

Loading

williamrandolph left a comment

williamrandolph commented Oct 17, 2019

williamrandolph commented Oct 17, 2019

williamrandolph commented Oct 17, 2019

williamrandolph commented Oct 25, 2019

rjernst left a comment

rjernst Oct 25, 2019

Elasticsearch keystore passphrase for startup scripts #44775

Elasticsearch keystore passphrase for startup scripts #44775

Conversation

williamrandolph commented Jul 23, 2019 • edited Loading

williamrandolph left a comment

Choose a reason for hiding this comment

williamrandolph commented Oct 17, 2019

williamrandolph commented Oct 17, 2019

williamrandolph commented Oct 17, 2019

williamrandolph commented Oct 25, 2019

rjernst left a comment

Choose a reason for hiding this comment

rjernst Oct 25, 2019

Choose a reason for hiding this comment

williamrandolph commented Jul 23, 2019 •

edited

Loading