Add kibana_system_password and elasticsearch_keystore_entries#104
Merged
Add kibana_system_password and elasticsearch_keystore_entries#104
Conversation
When set, the kibana role changes the kibana_system user's password via the Elasticsearch security API and uses that value for the connection to Elasticsearch. When empty (default), behavior is unchanged — the auto- generated password from initial_passwords is used. The password change runs once on the CA host, authenticates as the elastic superuser, and updates the kibana_password fact so the template and keystore tasks pick up the new value transparently. Closes #102
Adds a dict variable that lets users put arbitrary secrets into the Elasticsearch keystore without writing custom tasks. Each entry is set with elasticsearch-keystore add -f -x, values passed via stdin. The role validates that none of the user-provided keys overlap with the eight keys managed internally (bootstrap.password, SSL keystore/truststore passwords, PEM key passphrases, autoconfiguration hash). If there is a conflict, the playbook fails immediately with an error listing all reserved keys and explaining why they cannot be set through this variable. On each run the role reads current values and only writes changed entries, so Elasticsearch is not restarted unnecessarily. Closes #103
Three changes to elasticsearch_keystore_entries: The show command previously used ignore_errors: true which would silently swallow real errors like permission denied or a corrupt keystore. Now it uses failed_when to only tolerate a missing key (rc != 0 when the key isn't in the keystore list), while letting genuine errors propagate. Stale keystore entries are now removed automatically. On each run the role lists the keystore, subtracts the declared custom entries and the role-managed reserved keys, and removes whatever is left. This keeps the keystore in sync with declared state and makes removal as simple as deleting the entry from elasticsearch_keystore_entries. The whole custom keystore section is wrapped in a block with shared vars so the reserved keys list is defined once. Added molecule test coverage in the es_kibana scenario for both new features: elasticsearch_keystore_entries sets a test entry and verify checks it exists with the right value, kibana_system_password sets a custom password and verify confirms kibana_system can authenticate with it via the ES security API.
The verify assertion was delegating to elasticsearch_ca which is not set during the verify context (only during role execution). Also running the auth check on all ES nodes was redundant. Now it runs directly on the first elasticsearch group member only.
The password change block required inventory_hostname == elasticstack_ca_host, but the Kibana role only runs on Kibana group hosts — never on the CA host. The API call now targets elasticstack_ca_host directly and uses run_once so it executes once regardless of how many Kibana nodes exist.
Oddly
force-pushed
the
feat/custom-passwords-and-keystore-entries
branch
from
0e50e3f to
554acfa
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Implements two new user-facing variables for managing secrets in the Elastic Stack.
kibana_system_password(closes #102) lets you set a known password for the kibana_system Elasticsearch user. When set, the role changes it via the/_security/user/kibana_system/_passwordAPI on each run and uses that value for Kibana's ES connection. When empty, the auto-generated password from initial setup is used as before.elasticsearch_keystore_entries(closes #103) is a dict of custom secrets to add to the Elasticsearch keystore — Watcher credentials, LDAP bind passwords, plugin secrets, etc. Values are passed via stdin so they never appear in process listings. The role validates that none of the keys overlap with the eight internally-managed keystore entries (bootstrap password, SSL passwords). If there's a conflict, the playbook fails with an error listing every reserved key and telling you to use the dedicated variable instead. Entries are only written when their value has actually changed, so ES isn't restarted unnecessarily.