Overwrite Puppet Class Variables in Manifest

Question

I'm currently using hiera to set all my class parameters for the Puppet forge Gitlab module.

cat hieradata/nodes/example.yaml
---
gitlab::backup_cron_enable: true
gitlab::gitlab_rails:
  backup_keep_time: 604800
  backup_path: /opt/gitlab_backup
  gitlab_default_can_create_group: false
  initial_root_password: foobar
...

cat site/profiles/manifests/gitlab.rb
class profile::gitlab {
  include gitlab
}

This code works as intended but I'd like to redact the password values in the log output and reports. I tried to use hiera_options to convert the sensitive values but Puppet still displays the unredacted values.

cat hieradata/nodes/example.yaml
---
lookup_options:
gitlab::gitlab_rails::initial_root_password:
  convert_to: "Sensitive"

gitlab::backup_cron_enable: true
gitlab::gitlab_rails:
  backup_keep_time: 604800
  backup_path: /opt/gitlab_backup
  gitlab_default_can_create_group: false
  initial_root_password: foobar
...

What is the best way to redact all sensitive values whilst using hiera to define the class parameters?

Answer 1

You need to have the password as a separate key in order for the auto conversion to take effect. The key that is looked up is bound to a hash, and it is not possible to address individual values in a hash with lookup_options (it is the entire hash that is looked up).

You can make an individual value Sensitive by using an alias and binding the password in clear text to a separate key - like this:

cat hieradata/nodes/example.yaml
---
lookup_options:
gitlab::gitlab_rails::initial_root_password:
  convert_to: "Sensitive"

gitlab::backup_cron_enable: true
gitlab::gitlab_rails:
  backup_keep_time: 604800
  backup_path: /opt/gitlab_backup
  gitlab_default_can_create_group: false
  initial_root_password: '%{alias("gitlab::gitlab_rails::initial_root_password")}'
gitlab::gitlab_rails::initial_root_password: 'foobar'
...

With this approach you could also use EYAML or some other secure hiera backend to store the password in encrypted form. Such a backend may already return decrypted values wrapped in Sensitive - this is for example done by the Vault backend.

However, even if you get past the first hurdle, the result depends on what the gitlab module does with the hash now containing a Sensitive value. If it just passes the value for initial_root_password on it may work, but if it is doing any operation on this value (like checking if it is an empty string for example) it may fail. If you are unlucky it may seem to work but you may end up with the password "redacted" :-). Contact the maintainers of the module if it does not work and request that they support having the password as a Sensitive value instead of a String.