Keystore values cannot be printed by the list keystore sub-command (they are intentionally hidden). Also, there is no other metadata that can be associated with keystore entries. Hence, there is no way for the administrator, or automation scripts, to tell which version of the secure setting value is currently stored, only that it exists. In some scenario this implies restarting the node only to reread the same identical keystore setting.
The "last modified timestamp" attribute is easier to implement and would probably cover most cases, but general metadata for each keystore entry might be preferable. I propose we first implement the "last modified timestamp" attribute and only on further needs proceed with adding user-defined associated metadata.
Keystore values cannot be printed by the
list
keystore sub-command (they are intentionally hidden). Also, there is no other metadata that can be associated with keystore entries. Hence, there is no way for the administrator, or automation scripts, to tell which version of the secure setting value is currently stored, only that it exists. In some scenario this implies restarting the node only to reread the same identical keystore setting.The "last modified timestamp" attribute is easier to implement and would probably cover most cases, but general metadata for each keystore entry might be preferable. I propose we first implement the "last modified timestamp" attribute and only on further needs proceed with adding user-defined associated metadata.
Suggested in https://discuss.elastic.co/t/verify-if-elasticsearch-keystore-value-changed/199041