[chef] Re: Re: Deploying User Private Keys

[Lamont Granquist < >]

yeah, be real careful about deploying private keys widely and creating 
'full mesh' of passwordless ssh logins on a user.  this problem is 
actually much worse on the non-fleshy users where you might not have any 
password encryption on the key.

a company that i worked at previously had a set of perl scripts which 
did log collection and was engineered so that the individual hosts 
needed to be able to ssh into the centralized log collection 
infrastructure (bad enough) and then the centralized servers needed to 
be able to ssh back out (making the problem worse), and this was 
implemented across the same user id with the same keys creating a 
complete full mesh (horrible).  as a result of that, having access to 
any server and the ability to change to the log scraping user meant 
having ssh access to all 30,000 servers in the company.  and a few 
members of the developer community had figured this out and were using 
it to be able to access servers belonging to other dev teams in order to 
debug across systems (arguably they should have just been granted 
access, but they were technically using it to circumvent access controls...)

anyway, for github deploy users you do tend to wind up with the deploy 
private key blasted out to a lot of your hosts, but you should at least 
make sure that the user is read-only.

if you're using private enterprise chef or the open source server that 
you host yourself you should consider about the amount of trouble that 
you want to go to in order to protect the key. similarly, if most of 
your servers are going to have access to the key, the benefit of 
chef-vault becomes much lower.  going through all the trouble to setup 
chef-vault and then blowing the key out to every single server you have 
does not accomplish very much. similarly, trying to protect that key 
against your chef server getting compromised doesn't accomplish too much 
when it can be used to push arbitrary code to your entire environment as 
root already.

an encrypted databag is most useful when you're on hosted enterprise 
chef.  it can also, though, protect the key against leaking out of 
developer checkouts of your git repo on laptops, so may be useful anyway 
even on PEC and OSS (although if you just saved the key into a databag 
that you didn't store in git that would mitigate a big chunk of that 
problem as well).  chef-vault is going to be most useful the smaller the 
subset of your environment you are pushing the key to, i'm not sure i'd 
use that for a github deploy key unless i had some kind of regulatory 
necessity to do so.

On 2/3/14 1:59 PM, Curtis Stewart wrote:
> Thanks for the response, Arnold, I agree with your comments below about the 
> ‘fleshy’ users.
>
> In regard to the other users, like a deploy user with access to a private git 
> repo, do you store those keys in your repository as plain text?
>
> Curtis
>
> On Feb 3, 2014, at 3:32 PM, Arnold Krille 
> <
>  <mailto:
>  >>
>  wrote:
>
> On Mon, 3 Feb 2014 21:06:54 +0000 Curtis Stewart
> <
>  <mailto:
>  >>
>  wrote:
> I’m currently using the opscode-cookbooks/users cookbook to deploy
> system users.
>
> The users_manage resource uses data bags to deploy users, and this
> does allow you to set an ‘ssh_private_key’ attribute, however, I
> don’t want to store our private keys as plain text in our repository.
>
> My plan is to use ChefVault to deploy users private keys (encrypted
> data bags and a template/file resource), after the users have been
> created with the users_manage resource.
>
> Does anyone have suggestions for a better method, or best practice
> for this case?
>
> Why should your users hand their private keys to you as the admin to
> feed it into some automated system???
>
> The users (the fleshy ones) will give you their public keys to include
> on machines so they don't need passwords when ssh-ing.
>
> The private keys you store in chef is for automated things like
> deployments getting source-code from a ssh-accessible git. Or for
> jenkins-server logging into machines (but even that I did do with a
> jenkins-cookbook creating the public/private keys and storing just the
> public keys in chef).
>
> - Arnold