Spike. Check if custom settings can be added to opensearch.yml

OpenSearch supports adding custom configurations to the opensearch.yml, and it can be done in a friendly way, as we researched in #86, and as we can see from the code of this third-party plugin as reference.

Proof of concept

To validate the implementation is possible, I've generated a custom package with the changes required to read the settings m_api.auth.username, m_api.auth.password & m_api.urifrom the configuration file:

• Convert the settings from SecureSetting.secureString to Setting.simpleString

  public class PluginSettings {
      public static final Setting<String> M_API_AUTH_USERNAME = Setting.simpleString("m_api.auth.username", Setting.Property.NodeScope, Setting.Property.Filtered);
      public static final Setting<String> M_API_AUTH_PASSWORD = Setting.simpleString("m_api.auth.password", Setting.Property.NodeScope, Setting.Property.Filtered);
      public static final Setting<String> M_API_URI = Setting.simpleString("m_api.uri", Setting.Property.NodeScope, Setting.Property.Filtered);
      ...
  }

• On the build.gradle for the integTest section define the values storage to be on setting instead of keystore

  testClusters.integTest {
       ...
       setting 'm_api.auth.username', 'admin'
       setting 'm_api.auth.password', 'test'
       setting 'm_api.uri', 'https://127.0.0.1:55000' 
       ...
  }

• Add some logs to check the values at wazuh-indexer startup

      private PluginSettings(@NonNull final Settings settings) {
          ...
          log.info("[SETTINGS] Username: {}", this.authUsername);
          log.info("[SETTINGS] URI: {}", this.uri);
      }

Functionality validation

1. Install the custom wazuh-indexer package with the POC changes
2. Configure the settings on the opensearch.yml

   m_api:
     auth:
       username: "test_user"
       password: "test_pwd"
     uri: "test_uri"

3. Restart wazuh-indexer and check the logs

   [2024-12-17T10:02:38,276][INFO ][c.w.c.s.PluginSettings   ] [node-1] [SETTINGS] Username: test_user
   [2024-12-17T10:02:38,276][INFO ][c.w.c.s.PluginSettings   ] [node-1] [SETTINGS] URI: test_uri

Identify settings to expose

• command_manager.client.timeout: integer (seconds)
• command_manager.job.schedule: integer (minutes)
• command_manager.job.page_size: integer
• command_manager.job.pit_keep_alive: integer (seconds)
• command_manager.job.index.template: string
• command_manager.api.prefix: string
• command_manager.api.endpoint: string
• command_manager.index.name: string
• command_manager.index.template: string

Based on the previous definitions, we have analyzed a potential structure for the command-manager configuration. Here is a proposed YAML structure:

command_manager:
  client:
    timeout: int           # Default: 20
  job:
    schedule: int         # Default: 1
    page_size: int        # Default: 100
    pit_keep_alive: int   # Default: 30

Further research and testing is required to validate if this approach is possible, for now we only tested for "simple" key values on the yaml. On the POC from the previous comment we have validated this configuration format in a minor scale.

We need to evaluate the possibility of supporting multiple management_api connections. Currently, the configuration supports only one host with a username and password, making it incompatible with multiple connections. To address this, we should consider modifying the configuration to use an array for each API node, which will require additional development on the plugin.

management_api:
  nodes:
    - auth:
        username: secure string
        password: secure string
      host: string

The settings are registered, and the constant usages have been replaced with their corresponding values. These settings will be loaded from the opensearch.yml file. None of the settings are mandatory, as each has a default value registered in the PluginSettings class.

The job.index.name setting is discarded and retained as a constant in PluginSettings because the job's index name value is used in the getJobIndex() getter function of the CommandManagerPlugin class, and this is required for the JobSchedulerExtension interface, which is loaded before the settings.

Generated a documentation proposal that can be found at the main comment of the PR #213