[jollojou]

We configure our production servers and push new releases there with Puppet. I like Puppet: its fail-safe and reliable.

There is, however, one thing I don't fancy in it. Puppet does not support insecure client–master communication. Requiring SSL communication is OK, but one should be able to switch it off if it brings no value.

We are running our our servers on AWS, and we rely solely on AWS security groups to grant and deny accesses. Puppet's SSL traffic brings no additional security to us; it only complicates matters. For example: we would like to shut down the Puppet master EC2 instances when they are not needed. However, this is not possible, since after start-up the EC2 instances have new IPs, and this breaks the Puppet-signed SSL certificates.

[legooolas]

> after startup the EC2 instances have new IPs

They have static ("Elastic") IP addresses:

http://aws.amazon.com/articles/1346?_encoding=UTF8&jiveR...

..don't these let you keep the same IP for your Puppet master instance?

[jollojou]

That's correct. The problem is that the EC2 internal IPs change even though the instance would have an Elastic IP. EC2 instances use internal IPs when communicating with other EC2 instances (this is a feature of AWS DNS). As a consequence, Puppet clients cannot access the master by using the master's Elastic IP.

[legooolas]

That sounds rather inconvenient. Are the external elastic IPs non-routable internally? I mean, if you add the IPs explicitly to hosts files then will traffic to those IPs not work?