On Thursday, April 2, 2015 at 4:02:30 PM UTC-5, 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?
>
I'm having trouble understanding how you propose to factor out security
considerations from the technology to which they apply. Is this just about
ownership of data, or do there need to be *bona fide* security-specific
resources? If the former, then what do you need that you cannot achieve
via a security-specific level in your Hiera hierarchy? If the latter, then
how would making the security classes responsible for declaring
component-level classes (per option 3) achieve the separation of concerns
you claim as an advantage?
>
> 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 you are contemplating class inheritance for the purpose of greater
freedom in applying resource property overrides, then maybe they would be
useful to you. If you have an idea that they would do anything else for
you, then put it out of your mind -- class inheritance doesn't work that
way (whatever way that happens to be). Note, however, that often you can
perform resource overrides without class inheritance, that often it is
better to modify the external data from which modules draw property values
than to override property values after the fact, and that class inheritance
creates a very tight coupling that is probably better avoided if it crosses
module boundaries.
> 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.
>
>
It would help if you presented a representative example of what you're
trying to configure, and explained the challenge you face with respect to
that. What you've presented so far is too abstract for me to offer any
specific advice.
John
--
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/154e63fa-3b93-4171-b506-fe4ecfb581eb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
