Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I'm pretty new to vagrant, would someone who knows more about it (and puppet) be able to explain how vagrant deals with the ssl certs needed when making vagrant testing machines that are processing the same node definition as the real production machines ?

I run puppet in master / client mode, and I wish to spin up a vagrant version of my puppet production nodes, primarily to test new puppet code against.

If my production machine is, say, sql.domain.com I spin up a vagrant machine of, say, sql.vagrant.domain.com. In the vagrant file I then use the puppet_server provisioner, and give a puppet.puppet_node entry of “sql.domain.com” to it gets the same puppet node definition.

On the puppet server I use a regex of something like /*.sql.domain.com/ on that node entry so that both the vagrant machine and the real one get that node entry on the puppet server.

Finally, I enable auto-signing for *.vagrant.domain.com in puppet's autosign.conf, so the vagrant machine gets signed.

So far, so good...

However: If one machine on my network gets rooted, say, unimportant.domain.com, what's to stop the attacker changing the hostname on that machine to sql.vagrant.domain.com, deleting the old puppet ssl cert off of it and then re-run puppet with a given node name of sql.domain.com ? The new ssl cert would be autosigned by puppet, match the node name regex, and then this hacked node would get all the juicy information intended for the sql machine ?!

One solution I can think of is to avoid autosigning, and put the known puppet ssl cert for the real production machine into the vagrant shared directory, and then have a vagrant ssh job move it into place. The downside of this is I end up with all my ssl certs for each production machine sitting in one git repo (my vagrant repo) and thereby on each developer's machine – which may or may not be an issue, but it dosen't sound like the right way of doing this.

tl;dr: How do other people deal with vagrant & puppet ssl certificates for development or testing clones of production machines ?

share|improve this question
    
I am not sure I understand your question completely. But it seems you use one puppet server for both Dev and Prod? Why not use separate, network isolated servers for Prod and Dev? The Dev server can have the same puppet manifest code(perhaps rsyned or git'ed over), but the certs will be signed by a completely different CA. Also, there are few ways to mitigate, but not completely avoid the autosign problem. theforeman.org for example can insert a single hostname in autosign.conf when you provision, and remove it when the cert is signed. This reduces the window which an attacker can use. –  Not Now Nov 30 '12 at 23:59
    
I'll look into theforeman. But yea, I figured i was looking at having to split into two puppetmasters, but I wanted to check this is actually what people do, rather than "this sounds like a good idea" –  Sirex Dec 1 '12 at 5:59
    
I agree with @not-now - each environment should have it's own puppetmaster for all the aforementioned reasons. I'll only note that security architecture is what eventually caused us to prefer Chef Server, which doesn't have a built-in CA and doesn't evaluate templates on the server side. I mostly agree with this post on the matter. –  platforms Dec 1 '12 at 21:27
    
@platforms Doesn't Chef push all available recipes to the client, regardless of weather the client actually uses all recipes or not? Doesn't this make it less secure? –  Not Now Dec 1 '12 at 22:16
    
No - when using chef-client with chef-server, the client figures out exactly which cookbooks are needed based on the current runlist for that node, and it downloads just those recipes to /var/chef/cache/cookbooks (configurable). Even then, it's just a cache and these files can be deleted at any time (they will be restored without error on the next chef-client run). –  platforms Dec 1 '12 at 22:53

1 Answer 1

up vote 1 down vote accepted

To put an answer here for others who may be experiencing a similar query. I ended up using vagrant in a host-only network arrangement using postrouting masquerade (nat) on the host to enable the host-only network to also contact the outside world.

There's a vagrant puppetmaster, which uses autosigning - given that it's on it's own host-only (vboxnet0) network with whatever vagrant puppet client i'm writing code for, it removes most of the security issues i had.

For production, the real (non vagrant) puppetmaster only has the production branch of git, and does not allow any autosigning.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.