I want the puppetmaster can sign the manifest. avoid some guys publish
dangerous manifest to agent. like exec{"foo": command=>"rm / -rf";}
there is a software named samhain. it's a integrity checker and host
intrusion detection system . when compile the source code of the software,
you can configure a cert with it.
when the software running. it's only read the cert signed configure file.
any way, agent use https connect master . the ssl connect just let the
connecting is safe, but not the manifest code .
在 2013年9月16日星期一UTC+8下午11时24分23秒，jcbollinger写道：
>
>
>
> On Monday, September 16, 2013 2:20:21 AM UTC-5, [email protected] wrote:
>>
>> hi,guys
>>
>> when you use the puppet manage all you production server.
>> the security of the puppet master is very very very very import.
>> because if the hacker control the puppet master server. the can control
>> you all servers. and can do anythings he want.
>>
>
>
> True.
>
>
>
>>
>> I think most company use a VPN network connect the puppet
>> agent and the puppet master. but , I think it's not enough safe.
>> if some one's work PC control by a hacker ,the hacker can into the vpn
>> network. or the hacker is some one that not allowed use the puppet master.
>> vpn is safe ,but not enough .
>>
>
>
> Not exactly. VPN is only really relevant for remote clients. It is
> fairly common -- I would even say typical -- for the master and all managed
> servers to reside on the same physical network within the organization.
> Nevertheless, the fact remains that if an attacker compromises a machine
> belonging to the target organization, then he might be able to access the
> network on which the Puppet master resides, whether via VPN or otherwise.
>
> Even so, that is quite different from compromising the master itself. It
> would be unusual for access to a client machine to enable an assailant to
> modify anything about the master. For that, an assailant would need to
> compromise the credentials of a user having login access to the master. In
> a secure setup, there might be NO such users defined outside the master
> itself, so that an attacker would need to compromise the master by other
> means than analyzing data found on the compromised client.
>
> I think you are overstating the risk.
>
>
>
>>
>> so, the puppet master need 3A. Authentication, Authorization, Accounting.
>> every body push the puppet manifest need 3A. and use cert to sign the
>> code.
>>
>
>
> Puppet uses SSL certificates both to securely identify the master to
> agents and to securely identify agents to the master. Unless bypassed,
> that same system provides for one-time manual authentication of each
> agent. This allows the master to avoid serving sensitive configuration
> information to machines that are not authorized to have it, and allows
> clients to confirm that they are receiving their configs from the correct,
> trusted source.
>
>
>
>>
>> the puppet master only allow signed manifest code.
>>
>>
>
> Of course there is the question of security of the master's manifests,
> separate from the issue of securely serving compiled catalogs to clients.
> That is not managed directly by Puppet, but shops that care about security
> -- i.e. most of them -- have procedures in place to mitigate the
> associated security risks to their satisfaction.
>
>
>
>>
>> In my environment, I not use puppet master. and the puppet agent
>> download the signed manifest from a rsync server. verify the manifest and
>> run it. I think it's safe than puppet master publish the code.
>> because I use a networkless pc to sign the code .then copy the code to
>> the rsync server.
>>
>>
>
> I'm glad you are satisfied with that solution. Please refer to my above
> comments about security risk mitigation.
>
>
>
>> so , the security risk move to all puppet agent. not the puppet master
>> or rsync server.
>>
>>
>
> Are you asking for comments about your approach? Well, then, it is more
> secure than a default master / agent setup with respect to the integrity
> and validity of the information served to clients, because the
> configuration authority cannot be compromised over the network. Security
> risk does not ALL move to the agents, however: the rsync server still
> constitutes a single point of failure that could be targeted for denial of
> service.
>
> Additionally, your approach does not appear to provide for limiting
> configuration information to the clients that need it. That is, I don't
> see how you can avoid serving the complete manifest set to every client,
> thus if the manifests contain any sensitive information then you expose it
> to anyone who compromises *any* client. At minimum, you provide a map of
> your entire managed infrastructure to assailants. That could be a greater
> risk than those you avoid.
>
> Information security is a complex subject, filled with trade-offs. There
> is no solution that is right for everyone. I think Puppet's built-in
> security mechanisms are fairly good, and I rely on them, but nothing can
> satisfy everyone.
>
>
> 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 post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
