Closed lschierer closed 3 years ago
Hey @lschierer, that should already be possible. As far as I am aware, everything, that is specified as a parameter in init.pp
, will be taken from hiera. So your issue comes down to merging arrays in hiera, that is also possible.
For a list of parameters see: https://github.com/dev-sec/puppet-os-hardening/blob/ee1851a31e5ed32f81d340d7b3b329711996aa38/manifests/init.pp#L80-L81
I have tried both wanted_packages:
and os_hardening::wanted_packages:
in data/Ubuntu/18.04.yaml in my environment, but neither package is getting installed.
I can confirm that I use os_hardening in combination with hiera:
### os_hardening
os_hardening::password_max_age: 90
os_hardening::password_min_age: 0
os_hardening::password_warn_age: 14
os_hardening::unwanted_packages: ['telnet']
os_hardening::ignore_users: ['git','githook','ansible','apache','puppetboard']
## Some files point to nowhere, which cause errors. The following are such a dead links
os_hardening::ignore_files_in_folder_to_restrict: ['policytool','miniterm-3.6.py','postgresql-96-setup']
Also confirmed here
Is your feature request related to a problem? Please describe. os hardening is something that you will want to customize for different types of servers, and yet each will have more overlap than not. Since you cannot declare the class more than once, this is hard to do. Ideally I can declare os hardening as part of a base profile that all nodes get, but declare use variables in different other classes to override the base values.
The most obvious example is that as I move through an inheritance tree, I start with a base set of packages in the wanted_packages and unwanted_packages arrays, then I have a webserver node group that adds a couple of packages that did not fit cleanly anywhere else, but then I have a specific webserver that needs one extra package that isn't worth an entire class, and I want to extend wanted_packages yet again.
With hiera and a merge type of deep or deeper, this would happen fairly easily, because each level of inheritance would cause it to look at additional hiera data sources, which could define additional parameters that would then get merged to gether to form the final array of wanted and unwanted packages.
Describe the solution you'd like
Describe alternatives you've considered The alternative is to only declare the os_hardening class at leaf nodes of the inheritance tree, with the risk that if I need to update a parameter that is common to a large set of nodes, I have to change the class definition in a large number of files.