|
In an organization that has security compliance issues there is the need to show that parameters set in a module are final.
This means that regular use of hiera data in a sensitive module can not be used because all of the parameters defined that way can be overridden in the environment and global layers.
The author of a module would however like to use hierarchical data and integration with hiera backends and construct the logic with APL.
Since this is not possible, the current work around is to write custom functions that read data files in yaml, and/or call custom functions to get data from external sources. These do not work with APL. Alternatively the user is stuck with params.pp and defining the values in code.
The features we have proposed for partial ordering of layers etc. do not help as they all allow for overrides to be made outside of the control of the module.
We have a similar use case in MEEP where a completely private hierarchy is needed.
I can imagine that part of the solution is to support private defines and classes and to specify that those may not have their parameters bound in higher layers (i.e their bindings in hiera are private and final in the module). To make them configurable they would need to have public wrappers that define the API for the public (and variable) subset the module supports.
Such a solution seems more appealing than trying to come up with a mechanism for a private layer or by trying to work in specification of "final" declarations in keys in the hiera data.
More user research is needed to see if that is a workable solution. It seems reasonable to assume that it should not be possible to provide arguments to private defines and classes as they are indeed private and can only be instantiated by the module they are private too.
(In addition, work is needed to prevent overrides to take place using collections).
|
