You might be interested in this thread:
https://groups.google.com/forum/#!topic/puppet-users/nmVQQA6G-f8
On Thu, Apr 02, 2015 at 12:23:19PM -0700, Scott Jaffa wrote:
> Hi,
> I'm working in an environment where certain parameters need to be enforced
> per security requirements..
>
> The ways we've identified to do this are:
>
> 1) Put the specific settings in the profile:
> Advantages: Utilize stock roles and profiles pattern, plenty of
> documentation and guides online.
> Disadvantage: The settings are part of the profile and thus two groups
> need to share ownership of the same module. Reduces flexibility or speed
> due to additional enforcement needed by shared ownership.
> 2) Modify the modules themselves.
> Advantages: Configuration is part of the module.
> Disadvantages: We are now maintaining all custom modules.
> 3) Extend roles and profiles to add an additional layer between existing
> profiles and the modules.
> The workflow would be:
> Role (business layer) > Profile (technology layer) > Security (security
> layer) > Module.
> Advantages: Engineering configuration and security configuration are
> seperated, with security configuration enforced.
> Disadvantages: Need a way to present most options up to the profiles
> layer for parameterization, while enforcing a few options.
> We'd prefer to go with option 3. Does this make sense?
> If so, some tips on how to go about this would be appreciated. Does it
> make sense for the security module to inherit the base module in this
> case? It would look something like this (but actually work :) )
> class sec_profile::ssh inherits ::ssh {
>
> $server_options = {
> 'Protocol' => '2',
> 'Ciphers' => 'aes128-ctr,aes192-ctr,aes256-ctr',
> 'PermitRootLogin' => 'no',
> 'ClientAliveInterval' => '900',
> 'PermitEmptyPasswords' => 'no',
> 'PasswordAuthentication' => 'no',
> 'Port' => [22],
> }
> }
> If not, can you suggest a good approach to present the base module options
> to the profile? We'd like to to allow parameterization / hiera lookups at
> the profile layer, preferrably without having to reimplement each option
> in the security layer.
> Thanks!
>
> Scott
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [1][email protected].
> To view this discussion on the web visit
>
> [2]https://groups.google.com/d/msgid/puppet-users/a0e99a07-261c-4327-8d0e-a8379f3f23e9%40googlegroups.com.
> For more options, visit [3]https://groups.google.com/d/optout.
>
> References
>
> Visible links
> 1. mailto:[email protected]
> 2.
> https://groups.google.com/d/msgid/puppet-users/a0e99a07-261c-4327-8d0e-a8379f3f23e9%40googlegroups.com?utm_medium=email&utm_source=footer
> 3. https://groups.google.com/d/optout
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/20150402233720.GA19510%40iniquitous.heresiarch.ca.
For more options, visit https://groups.google.com/d/optout.
