Add elastic_stack_keystore resource to handle keystore files for both elasticsearch and kibana

[lcharreau]

Hello,

I needed to install Elasticsearch version 8 (with Kibana).
I had several problems configuring the keystore files (elasticsearch and kibana) using the puppet-elasticsearch and puppet-kibana modules.

Here are the problems encountered:

• execution of the elasticsearch_keystore resource is not indempotent. It recreates the keystore file each time it is run, whether or not there has been a change. It does not parse the contents to ensure that the file is synchronized;
• if the keystore file already exists, it tries to create it again, which generates an error;
• there is no possibility of protecting the keystore file with a password;
• diff does not allow changes to be viewed;
• the kibana module does not manage keystore files.

I thought it simpler to implement a single resource type to manage the keystore in the puppet-elastic_stack module (to be used by both the elasticsearch and kibana modules). This avoids duplicate code.
I used the elasticsearch_keystore resource to correct the problems encountered and added keystore management for Kibana. I didn't keep the notion of instances, which weren't necessarily of interest in my case.

Example of the elastic_stack_keystore resource declaration for Elasticsearch:

elastic_stack_keystore { 'elasticsearch_secrets':
  service     => 'elasticsearch',
  purge       => false,
  password => Sensitive($password),
  settings    => { .. },
}

To manage the keystore password, there are 2 modes:

• If the keystore file is not password-protected and the password parameter is set and not empty, when the resource is executed, the keystore will be password-protected. However, it will not be possible to re-modify it by changing the password parameter (this will have to be done manually on the target).
• Possibility of managing a file containing the password on the target, enabling the password parameter to be changed without having to do so manually. To do this, declare a resource file containing the (with the backup parameter set to true).
  I haven't included all the code in the elasticsearch module, just an example to illustrate.

    unless $elasticsearch::elasticsearch_keystore_password =~ Undef {
      file { $elasticsearch::elasticsearch_keystore_password_path:
        ensure  => 'file',
        group   => $elasticsearch::elasticsearch_group,
        owner   => $elasticsearch::elasticsearch_user,
        mode    => '0660',
        content => $_elasticsearch_keystore_password,
        backup  => true,
      }
    }
  
    unless $elasticsearch::secrets =~ Undef {
      file { "${elasticsearch::configdir}/elasticsearch.keystore":
        owner => $elasticsearch::elasticsearch_user,
      }
      elastic_stack_keystore { 'elasticsearch_secrets':
        service     => 'elasticsearch',
        purge       => $elasticsearch::purge_secrets,
        settings    => $elasticsearch::secrets,
        password => $_elasticsearch_keystore_password,
        notify        => $elasticsearch::_notify_service,
        require      => File["${elasticsearch::configdir}/elasticsearch.keystore"],
      }
   }
  

Example of the elastic_stack_keystore resource declaration for Kibana (kibana-keystore does not support password):

elastic_stack_keystore { 'kibana_secrets':
  service     => 'kibana',
  purge       => false,
  settings    => { .. },

The service parameter is the namevar and can take 2 values: elasticsearch or kibana.

[bastelfreak]

please don't use the legacy fact osfamily, that's deprecated. Please use the nested os.family.

[lcharreau]

Yes of course. It's fixed.

[lcharreau]

Finally, I wonder if it wouldn't be more appropriate to implement the elastic_stack_keystore resource directly in the elasticsearch and kibana module rather than mutualizing the resource in elastic_stack (?).

This would simplify the code and would be justified by the fact that there are differences in keystore management between kibana (no password protection, no 'show' option to get the value of an entry) and elasticsearch.

[couloum]

Hello. Is there any news on this PR? The change suggested by @lcharreau seems interesting.