Repository navigation
[Encryption] Add encryption password to auto-configuration and gradle run - #151522
Conversation
ddd2a7b to
f10e810
Compare
f10e810 to
81be5df
Compare
🔍 Preview links for changed docs⏳ Building and deploying preview... View progress This comment will be updated with preview links when the build is complete. |
ℹ️ Important: Docs version tagging👋 Thanks for updating the docs! Just a friendly reminder that our docs are now cumulative. This means all 9.x versions are documented on the same page and published off of the main branch, instead of creating separate pages for each minor version. We use applies_to tags to mark version-specific features and changes. Expand for a quick overviewWhen to use applies_to tags:✅ At the page level to indicate which products/deployments the content applies to (mandatory) What NOT to do:❌ Don't remove or replace information that applies to an older version 🤔 Need help?
|
eef5ec0 to
8e91405
Compare
997d1f3 to
7952edb
Compare
|
Pinging @elastic/es-security (Team:Security) |
|
Hi @jfreden, I've created a changelog YAML for you. |
… run (#151522) * [Encryption] Add encryption pw to gradle run and auto config security
… run (elastic#151522) * [Encryption] Add encryption pw to gradle run and auto config security
This PR makes two improvements to reduce friction when working with cluster state encryption.
Auto-configuration of the encryption password
AutoConfigureNodenow generates a unique random encryption password for each node during first-boot security auto-configuration and writes it to the keystore undercluster.state.encryption.password.autoconfigured, withcluster.state.encryption.active_password_idset toautoconfigured. The same happens when a node enrolls into an existing cluster. If either setting is already present (user-managed keys), auto-configuration is skipped.When a node is reconfigured to join a different cluster, the autoconfigured keys are replaced with fresh ones as part of the reconfiguration. Any datasource credentials from the old cluster live in cluster state, which is overwritten once the node joins the new cluster - this is inherent to the operation itself, not a consequence of the key replacement. For multi-node clusters, other nodes retain their copies.
A banner line is added to the startup console output alongside the existing security auto-configuration messages when the password has been auto-configured.
Each node intentionally gets its own distinct password. This is safe because the PEK travels in plaintext over TLS-protected transport between nodes; password wrapping and unwrapping happen only during on-disk serialization and deserialization. Each node reads and writes its own local cluster state, so there is no requirement for nodes to share a keystore or agree on a password. This also means no changes to the enrollment API are needed to propagate the password to joining nodes.
Gradle run task
The runTask cluster in elasticsearch.run.gradle is wired with a static encryption password and active id so that
./gradlewrun works out of the box without any manual keystore setup.