[chef] Re: Re: Re: Re: Deploying User Private Keys

[Cassiano Leal < >]

Thanks!

Yes, that's correct. It first queries the deploy key API to check if the key is already there. If it is, it will skip and no Chef resources will have been updated. If it's not, then it gets added and the resource is updated.

It should be compatible with whyrun, although I regret to say that I haven't tested this feature. :-/

-- 
Cassiano Leal

Sent with Sparrow

On Tuesday, February 4, 2014 at 2:12, Rudi wrote:

Hi Cassiano,

Nice plug! I'm just checking out the cookbook and my first impressions are that this is pretty cool.

I have one question, as the recipe is idempotent it's meant to run on every deploy right?

So at the start of every chef run it would check the git provider and add the configured ssh key or do nothing .. correct?

Thanks

On Tue, Feb 4, 2014 at 6:24 AM, Cassiano Leal < " target="_blank"> > wrote:

Forgive the shameless plug, but if you’re deploying via Github, Bitbucket or Gitlab, there’s the deploy_key cookbook [0][1] that can help you manage those.

The cookbook will automate the creation of an SSH key and registering it in the repository as a deploy key (read-only). The LWRP also supports unregistering the key from the repo and deleting from disk if you feel like cleaning up.

The idea is to somehow enforce the creating of local private keys per application that never leave the machine where they will be used, reducing the chance of MITM and other attacks. If you feel like any of your keys have been compromised, it’s easy enough to get rid of all of them and create new ones as needed.

The Gitlab provider was recently contributed by dwradcliffe and pull requests for other providers are welcome.

[0] http://community.opscode.com/cookbooks/deploy_key

[1] https://github.com/cassianoleal/cookbook-deploy_key

-- 

Cassiano Leal

Sent with Sparrow

On Monday, February 3, 2014 at 21:59, 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 < " target="_blank"> < " target="_blank">mailto: >> wrote:

On Mon, 3 Feb 2014 21:06:54 +0000 Curtis Stewart

< " target="_blank"> < " target="_blank">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