[chef] Re: Re: Re: Re: Re: RE: Running chef in multiple environments

[Sean OMeara < >]

This is at the heart of the "immutable infrastructure" vs "managing
configuration drift" models of infrastructure management.

It really depends on the application.

Okay lets throw out security as a concern, because that invokes
irrationality and sacred "best practices".

Lets focus on stability...
control loops re-start services that have crashed.
control loops allow for dynamic reconfiguration of static
configuration files (LB, metrics, monitoring).
control loops enforce policy on user-interactive machines like
workstations or laptops

Not saying its for you, feel free to crank your control loop down to
zero. Trigger it if thats better.

I'm only pointing out that the in lizard brain of convergent
configuration management tools lies self healing via the
re-application of policy over time.

Now back to your regularly scheduled thread.

-s


On Fri, Aug 1, 2014 at 4:51 AM, James Le Cuirot 
<
 >
 wrote:
> On Thu, 31 Jul 2014 19:48:19 -0400
> Sean OMeara 
> <
 >
>  wrote:
>
>> I'd like to chime in here...
>>
>> As Lamont said... Chef's lineage definitely derives from CFEngine. The
>> whole idea is that recipes represent state policy that your machines
>> are supposed to be in. Running on a control loop ensure that they're
>> really that way.
>>
>> Running chef-client on a control loop interval ensures that anything
>> that perturbs the system (broken code, malicious code, h4x0rs, junior
>> sysadmins, cowboy developers) will be repaired.
>>
>> Think about if this way: if your application has a security
>> vulnerability that allows an attacker to chmod 777 /etc/shadow... do
>> you want to wait until your next production change window to repair
>> it? Or do you want to fix it as quickly as possible?
>
> I don't really agree with this. If someone has broken in, you should
> take time to work out exactly what has been changed and how they
> managed to do it. You should also take that box offline immediately
> instead of relying on Chef to patch it up in the short term.
>
> While Chef's enforcement of permissions is a nice side effect, I don't
> think it should be used primarily as a security feature. My cookbooks
> use /etc/shadow but given that this file was already present with the
> correct permissions before installing Chef, I don't think Chef should
> attempt to enforce this. You could write a cookbook to enforce the
> permissions of every vaguely important file on the system but this
> would be tedious and probably not very effective. Watching for
> unexpected file system changes is really a job for AIDE and the like.
>
> Regards,
> James