Implement the configuration persistence logic

[AlexRuiz7]

Description

This issue continues the research performed in #86 to investigate the different configuration persistence methods available within the development of Indexer plugins.

The Command Manager plugin sends data to the Management API in the server, so it needs to know the endpoint of its HTTP Rest API and its credentials in order to establish the communication.

This information is dynamic and needs to be provided to the Command Manager during runtime, The plugin will read this information from the configuration persisted in the file system during its initialization.

The configuration might change over time. In order to avoid a restart of the Wazuh Indexer node to refresh the information, the plugin should be able to receive the new information when the configuration changes. In order to do that, our plugin needs to extend the ReloadablePlugin interface. We can follow the research in #86 (comment) as a guide.

Following the conclusion of the research, we are going to use a key store as our configuration persistence method. The key store must be unique and should be created automatically if it does not exist. In this case, the plugin will raise a custom exception that requires the key store to be initialized by the user.

Note

The key store can be mocked using Gradle.

• sql/plugin/build.gradle
• sql/plugin/src/test/resources/datasources.json

Functional requirements

• The key store is loaded on plugin's initialization.
• The plugin reacts properly if the required information is missing (custom exception).
• The plugin reloads changes to the configuration on runtime.

Implementation restrictions

• The plugin must implement the ReloadblePlugin interface to receive changes to the configuration.
• The configuration is represented by a singleton object, which can be accessed within the plugin.

[mcasas993]

Opensearch solution

We ask for help to OpenSearch for managing the Settings in the Keystore, and they give us a simple solution:

The plugins can declare "secure" settings and then they will have access to the decrypted value directly. They only have access to their own declared secure settings, but not secure settings declared by other plugins

They can be declared like this and they can be accessed like any other setting.

The different between secureSetting vs normal setting is that secureSetting is stored in the keystore.

So we are going to refactor the code to simplify the solution.