9

How would you securely commit you TLS/SSL keys for your HTTP into source control so they could be consumed by Puppet? What tools and practices do you use to encrypt/decrypt these files? Particularly, which tools make this easy to automate as much as possible.

Ricardo Gladwell
  • 3,770
  • 4
  • 38
  • 59

3 Answers3

4

You can store your certificates in any SCM, including Git, without concerns. Storing private key in SCM is not best practice; you'll need to find a way to restrict access to only those who need access to private keys (and that should be a small number of folks). You have two basic options:

  1. securely store private keys; or,
  2. regenerate key-pairs on each client.

It's is not considered best practice, but you can store private keys encrypted in a PKCS-12 archive (protected with a strong password known only to those who need access to private keys) before placing them in storage, like SCM or FS, etc. When a new service is built, the final step in the build process is for a system administrator to manually decrypt the key store.

It is better practice to regenerate keys for new service instances but that requires submitting your CSR for the new service to your CA after the build is complete.

Both scenarios requires manual work to finish the setup process. In an attempt to automate this process, some encode the PKCS-12 password in the setup script - this is not considered best-practice.

Here's Puppet plugin that can help with the process:

https://github.com/puppetlabs/puppetlabs-java_ks

Jan Nielsen
  • 10,892
  • 14
  • 65
  • 119
4

Not speaking from personal experience, but as I understand, it is common practice to

  1. store data such as keys and passwords in hiera and
  2. secure them using eyaml with the hiera-eyaml backend

It supports editing the decrypted values with the editor of your choice, assuming you have access to the private key.

The Puppet master also needs key access, so that it can forward the sensitive information to the agents.

As far as the security is concerned, this makes you loose all your secrets if the master machine is fully compromised (but realistically, if that happens to you, you have to consider all your machines and their data to be compromised as well, anyway).

Yogesh Umesh Vaity
  • 41,009
  • 21
  • 145
  • 105
Felix Frank
  • 8,125
  • 1
  • 23
  • 30
0

Private keys are not suitable for automatic distribution. Because to make them safe for distribution they have to be strongly encrypted, which requires manual intervention for decryption. That does negate the automatic bit.

Nor should they be stored in a repository, because that might be more accessible than you think. If you are not careful, your secret keys could end up on github. It probably happens more often than you would think.

Roland Smith
  • 42,427
  • 3
  • 64
  • 94
  • Encrypting sensitive data in GitHub repos seems like a common pattern. Travis uses a mechanism like this so if you share your repo the code is encrypted. And tools like hiera-eyaml exist that do automate a lot of the encryption. – Ricardo Gladwell Aug 04 '14 at 20:54
  • Even if it is common, that doesn't necessarily make it a good idea. Especially since it is *very easy* to do it wrong. Many things can make the added security of encryption an illusion. Like simple user mistakes such as using weak passwords, encrypting multiple keys with one password or re-using passwords. But also programming errors like using weak algorithms, modes or initialization vectors. – Roland Smith Aug 04 '14 at 21:47