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]puppet-users+unsubscr...@googlegroups.com.
> 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:puppet-users+unsubscr...@googlegroups.com
> 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 puppet-users+unsubscr...@googlegroups.com.
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.
