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


Chronological Thread 
  • From: Cassiano Leal < >
  • To:
  • Subject: [chef] Re: Re: Re: Re: Deploying User Private Keys
  • Date: Tue, 4 Feb 2014 10:11:01 +0000

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.


-- 
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 Mon, 3 Feb 2014 21:06:54 +0000 Curtis Stewart
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






Archive powered by MHonArc 2.6.16.

§