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

["John E. Vincent (lusis)" < >]

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
>>
>>
>>
>