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.
