Create keystore on package install#28928
Conversation
This commit removes the ability to specify that a plugin requires the keystore and instead creates the keystore on package installation or when Elasticsearch is started for the first time. The reason that we opt to create the keystore on package installation is to ensure that the keystore has the correct permissions (the package installation scripts run as root as opposed to Elasticsearch running as the elasticsearch user) and to enable removing the keystore on package removal if the keystore is not modified.
|
run packaging tests |
|
FYI @elastic/es-core-infra. |
rjernst
left a comment
There was a problem hiding this comment.
LGTM, just a suggestion about file naming
| /usr/share/elasticsearch/bin/elasticsearch-keystore create | ||
| chown root:elasticsearch "$ES_PATH_CONF"/elasticsearch.keystore | ||
| chmod 660 "$ES_PATH_CONF"/elasticsearch.keystore | ||
| md5sum "$ES_PATH_CONF"/elasticsearch.keystore > "$ES_PATH_CONF"/elasticsearch.keystore.md5sum |
There was a problem hiding this comment.
Maybe name this something to indicate it is only the "initial" md5 sum? Otherwise someone might look at it and expect it to be kept up to date as changes are made to the keystone?
There was a problem hiding this comment.
It could also have "install" in the name instead of "initial" (or anything to indicate is is only for the version created at install time).
|
run packaging tests |
| assert_file "$ESCONFIG" d root elasticsearch 2750 | ||
| assert_file "$ESCONFIG/elasticsearch.keystore" f root elasticsearch 660 | ||
|
|
||
| sudo -u elasticsearch "$ESHOME/bin/elasticsearch-keystore" list | grep "keystore.seed" |
There was a problem hiding this comment.
Is this keystore list command meant to be checked? Is this run with set -e somewhere?
There was a problem hiding this comment.
All commands in the packaging tests are run with set -e (unless explicitly flipped, which we do not currently do anywhere).
|
run packaging tests |
* master: [TEST] AwaitsFix QueryRescorerIT.testRescoreAfterCollapse Decouple XContentType from StreamInput/Output (elastic#28927) Remove BytesRef usage from XContentParser and its subclasses (elastic#28792)
|
run packaging tests |
|
test this please |
|
run packaging tests |
df95dcf to
d2f8fa9
Compare
|
run packaging tests |
1 similar comment
|
run packaging tests |
This commit removes the ability to specify that a plugin requires the keystore and instead creates the keystore on package installation or when Elasticsearch is started for the first time. The reason that we opt to create the keystore on package installation is to ensure that the keystore has the correct permissions (the package installation scripts run as root as opposed to Elasticsearch running as the elasticsearch user) and to enable removing the keystore on package removal if the keystore is not modified.
|
@jasontedor This item appears in the Breaking changes section of the release notes, but I don't think I see it in the "Breaking Changes" page. Should we add info there? |
Elasticsearch's keystore initial md5sum was added in elastic#28928 with the intention to allow us to remove the elasticsearch.keystore file upon package removal, if this hadn't been altered after installation. At that time this decision made perfect sense as the elasticsearch keystore only contains transient data by default ( keystore.seed ) that is meant to be useful for bootstrap related actions, and doesn't need to survive re-installations. With Security ON by default, we will be storing additional settings in the keystore upon installation(namely, the passwords for the PKCS#12 keystores used for TLS) and these have a more persistent nature. Since `remove` doesn't delete the configuration directories and files where said PKCS#12 keystores are stored, it makes sense to also not delete the elasticsearch.keystore which stores the passwords.
Elasticsearch's keystore initial md5sum was added in #28928 with the intention to allow us to remove the elasticsearch.keystore file upon package removal, if this hadn't been altered after installation. At that time this decision made perfect sense as the elasticsearch keystore only contains transient data by default ( keystore.seed ) that is meant to be useful for bootstrap related actions, and doesn't need to survive re-installations. With Security ON by default, we will be storing additional settings in the keystore upon installation(namely, the passwords for the PKCS#12 keystores used for TLS) and these have a more persistent nature. Since `remove` doesn't delete the configuration directories and files where said PKCS#12 keystores are stored, it makes sense to also not delete the elasticsearch.keystore which stores the passwords.
This commit removes the ability to specify that a plugin requires the keystore and instead creates the keystore on package installation or when Elasticsearch is started for the first time. The reason that we opt to create the keystore on package installation is to ensure that the keystore has the correct permissions (the package installation scripts run as root as opposed to Elasticsearch running as the elasticsearch user) and to enable removing the keystore on package removal if the keystore is not modified.