[chef] Re: Re: Re: Re: RE: Distribute private ssh keys via users cookbook

[Cassiano Leal < >]

Thanks for all the replies and links.

lusis, thanks for shedding some light on the fact that each approach carries its own set of risks. I was beginning to get the impression that my approach was fundamentally wrong and there was some other way to do this without carrying security risks. Also thanks for letting me know that I'm not the only one facing this situation!

I thought about having a monitoring process who would periodically poll the Chef server for new nodes, grab the pub key (beer, anyone?) from an attribute and use the Bitbucket API to authorise the node. Then, it would tell the node that it was ready for work (via attributes again). On the next Chef run, the node would deploy whatever it needed to.

Ups:

- one private key per node, never copied outside of it

- API credentials stored in one place, where they can be better secured and monitored for attacks, and revoked/changed if needed

Downs:

- added complexity (handling state via attributes -- has this approach been used in the wild? --, and the process itself)

- asynchronicity (the node would take at least a second chef run to have the apps deployed -- defeats auto-scaling IMO)

I guess for now I'll either create an AMI with the decryption key pre-stored (and trust Amazon that the AMI won't get leaked), or use lusis' approach of storing the key elsewhere with restricted access. And not use the users cookbook for that.

- cassiano

On Thursday, January 10, 2013 at 12:11, John E. Vincent (lusis) wrote:

We should probably be realistic here. Whether it's the SSH key for

read-only access to your repo or your bitbucket API key, you still

have sensitive information you want to distribute. You just have to

decide which one, if any, you want to risk getting compromised. I'd

argue that the ssh-key is probably the better route to go since

they're easily revoked and already have some manner of ACL in place

(read-only access to repo X vs being the API that let's you grant

yourself access to any repo you want).

Quite honestly, encrypted databags are probably the best way to go

here. However the way we've normally taken to handling this has been

different every time. A few examples:

- At the previous company when we were running all on S3, we created

limited use aws credentials that only had access to specific buckets

for specific tasks using IAM. Those credentials were stored in

encrypted databags (my original implementation not the official one).

The decryption key was stored in Noah and pulled from there. We were

using Hosted Chef.

- At the current gig, we have our own Chef server. We store our ssh

keys, ssl certs and other minutia on a restricted internal

distribution host over HTTP. As access to the Chef server is fairly

restricted and everything is private traffic, we don't bother with any

credentials to the distribution point but if we did, we'd store those

credentials in an encrypted databag.

You can skin this cat a bunch of different ways and none of them are

ideal. The question you have to ask yourself and be realistic are:

- What are the risks if my bitbucket API key is compromised?

- What are the risks if a single private key is compromised?

- Who has access to see either of those things and what is the

mitigation strategy if that person leaves the company or whatever?

i.e. what's easier to change after they leave?

- If someone manages to get access to an internal server, what can

they discover or access.

The last one is really the tricky one. Regardless of which solution

you choose, the attacker will have access to everything (encrypted

databag secret, private ssh key, internal distribution point).

FWIW, the official encrypted databag stuff supports pulling the

databag secret from a url so you can do that as well.

On Thu, Jan 10, 2013 at 8:06 AM, Andrea Campi

< "> > wrote:

You keep saying you would need to upload public keys to bitbucket, but what

if that was automated?

https://confluence.atlassian.com/display/BITBUCKET/deploy-keys+Resource

https://github.com/vongrippen/bitbucket

Write a cookbook to search for public keys and sync them to bitbucket--that

doesn't sound like a lot of work, and it would potentially be useful to

other people.

On Thu, Jan 10, 2013 at 1:23 PM, Cassiano Leal < "> >

wrote:

Hi Kevin,

Thanks for sharing your thoughts. Let me describe my scenario and what I'm

trying to accomplish.

I have VMs that spin up automatically on AWS. These VMs host several

applications, most written in PHP and RoR. The source code for all the apps

resides on bitbucket Git repos.

I'm setting up application deployment via the deploy resource [0]. For

that, I have created a "deploy" user through the users cookbook, but I need

this user to have read-only access to the repos. For that, I have a

bitbucket user with read-only access and I need to configure this user with

the public keys, and that's done on bitbucket website.

If I create a new key pair on each VM, I'll have to manually authorise the

new key on the bitbucket website so that the application can be deployed.

That would completely defeat auto-scaling and would make my life a bit

worse, specially on peak times. :)

I understand the security implications of this approach, but I still find

it all that much better than having to manage potentially infinite key pairs

on a website. This key would have read only access to our repos, and if I

find out that it has been compromised all I need to do is revoke it on

bitbucket, create a new key pair and redistribute it.

I can do that on a recipe manually, but it would be just a bit easier and

more concise if it was possible via the users cookbook.

Also, it beats me why the cookbook allows me to distribute private keys

via an unencrypted data bag [1], and has no secure-ish solution for that.

Again, I'm open for hearing other solutions to this problem. If they're

more secure, all the better, as long as it doesn't make me go to

bitbucket.org and insert a new pubkey each time I spin up a new server. :)

[0] http://docs.opscode.com/resource_deploy.html

[1]

https://github.com/opscode-cookbooks/users/blob/master/providers/manage.rb#L112-L122

- cassiano

On Thursday, January 10, 2013 at 09:51, Kevin Keane (subscriptions) wrote:

It seems to me that there might be a problem with what you are trying to

accomplish in the first place. When you distribute private SSH keys through

*any* means, you have a security problem. Doesn't matter if you are using

encrypted databags, or even manually copy the keys over. Unless they are

your own personal keys, it defeats the very concept behind public key

encryption - and if they *are* your personal keys, you should only manually

copy them, not put them in an automated distribution system.

Once generated, private SSH keys should never leave that user's control.

You can use chef to distribute the corresponding public keys - and you don't

even need an encrypted databag. Public keys are not sensitive; you can leave

them unencrypted.

If your users are humans, have them generated their SSH key pairs, and

create a databag with all the public keys that you want to distribute. Hint:

the users cookbook already has a mechanism built in to do that.

If you need SSH key pairs for some automated tasks (say, a cron script

doing a nightly rsync), generate a *new* key pair, and store only the public

key in a node attribute. You can use an execute or script resource to

generate the key pair; just make sure to check if the key may already exist

(you don't want to clobber an already-existing key pair).

On the SSH client side, you'd extract all the relevant public keys from

your databag or node attributes, and add them to the authorized_keys file as

needed.

-----Original message-----

From: Cassiano Leal < "> >

Sent: Wed 01-09-2013 11:40 am

Subject: [chef] Distribute private ssh keys via users cookbook

To: "> ;

Hi!

Is there a way to securely distribute private ssh keys through the users

community cookbook?

In my setup I have a user deploy that will fetch from git, and I need that

user to have a SSH key that's authorized on the git repo. I saw that the

users cookbook will use "ssh_private_key" and "ssh_public_key" data bag

items, but those would be unencrypted, so not secure.

If people are using a different approach, I'd like to hear about that too.

Thanks!

--

Cassiano Leal