When adding settings to the Elasticsearch keystore, there is currently no validation of the values, or even that the setting is a valid name. This is painful in a similar way to typos in elasticsearch.yml: a user does not find out until the next time Elasticsearch is started.
We should add validation to the keystore when settings are added. At a bare minimum, we should ensure setting names correlate with a known secure setting, and give an appropriate error if eg a user tries to add a known but non secure setting.
The implementation of this feature is tricky. One idea is to have Elasticsearch pull all registered settings after we have isolated plugins in their own classloaders. Doing so inside the keystore is problematic since we do not want to do a full blown Elasticsearch startup. We need to decouple settings registration from the rest of plugins, allowing them to only load a very small part (still in an isolated classloader) to find which settings are being added by a plugin.
When adding settings to the Elasticsearch keystore, there is currently no validation of the values, or even that the setting is a valid name. This is painful in a similar way to typos in elasticsearch.yml: a user does not find out until the next time Elasticsearch is started.
We should add validation to the keystore when settings are added. At a bare minimum, we should ensure setting names correlate with a known secure setting, and give an appropriate error if eg a user tries to add a known but non secure setting.
The implementation of this feature is tricky. One idea is to have Elasticsearch pull all registered settings after we have isolated plugins in their own classloaders. Doing so inside the keystore is problematic since we do not want to do a full blown Elasticsearch startup. We need to decouple settings registration from the rest of plugins, allowing them to only load a very small part (still in an isolated classloader) to find which settings are being added by a plugin.