Distribute private ssh keys via users cookbook

Cassiano_Leal · January 9, 2013, 7:40pm

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

pmocek · January 9, 2013, 8:59pm

On Wed, Jan 09, 2013 at 05:40:25PM -0200, Cassiano Leal wrote:

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

Yes.

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.

That is not the case when you use encrypted data bags.

References:

--
Phil Mocek
http://mocek.org/

Cassiano_Leal · January 9, 2013, 9:08pm

On Wednesday, January 9, 2013 at 18:59, Phil Mocek wrote:

On Wed, Jan 09, 2013 at 05:40:25PM -0200, Cassiano Leal wrote:

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.

That is not the case when you use [encrypted data bags][1].
Thanks for the reference. but I can use encrypted data bags just fine.

As previously stated, what I want to do is to use the community users cookbook [0] to distribute those keys. That cookbook already has a resource provider to deploy the keys for each user, but I couldn't find a way to make it read an encrypted data bag. If it's possible, I'd like to know.

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

Cheers,

Cassiano Leal

AJ_Christensen · January 9, 2013, 9:10pm

Change the code in the cookbook to load the encrypted data-bag items
instead of doing a search, I guess?

--AJ

On 10 January 2013 10:08, Cassiano Leal cassianoleal@gmail.com wrote:

On Wednesday, January 9, 2013 at 18:59, Phil Mocek wrote:

On Wed, Jan 09, 2013 at 05:40:25PM -0200, Cassiano Leal wrote:

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.

That is not the case when you use [encrypted data bags][1].

Thanks for the reference. but I can use encrypted data bags just fine.

As previously stated, what I want to do is to use the community users
cookbook [0] to distribute those keys. That cookbook already has a resource
provider to deploy the keys for each user, but I couldn't find a way to
make it read an encrypted data bag. If it's possible, I'd like to know.

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

Cheers,

Cassiano Leal

Sean_OMeara · January 9, 2013, 9:10pm

This depends on your application and needs, but....

It should be worth noting that encrypted databags in this case are
just shifting the problem around.
You still have to drop a secret on the node, out of band of
chef-client, to decrypt a secret.

There are examples of generating a secret where it belongs and
exporting the public half via the node object. I know the Jenkins
cookbook on the community site does this with SSH keys. Ohai exposes
host_dsa_public and host_rsa_public attributes by default in a node
object.

Check out the PKI cookbook for a (kinda ghetto) example of how to do
this with SSL certs.
-s

On Wed, Jan 9, 2013 at 3:59 PM, Phil Mocek phil-lists@mocek.org wrote:

On Wed, Jan 09, 2013 at 05:40:25PM -0200, Cassiano Leal wrote:

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

Yes.

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.

That is not the case when you use encrypted data bags.

References:

--
Phil Mocek
http://mocek.org/

Cassiano_Leal · January 9, 2013, 9:18pm

On Wednesday, January 9, 2013 at 19:10, Sean OMeara wrote:

This depends on your application and needs, but....

It should be worth noting that encrypted databags in this case are
just shifting the problem around.
You still have to drop a secret on the node, out of band of
chef-client, to decrypt a secret.

I understand that, but that's always the case with encrypted data bags, and I already will have to deal with it.

There are examples of generating a secret where it belongs and
exporting the public half via the node object. I know the Jenkins
cookbook on the community site does this with SSH keys. Ohai exposes
host_dsa_public and host_rsa_public attributes by default in a node
object.

That would be great if it was feasible. The problem is that after that I would need to have the public key installed on the git repo (in this specific case, on bitbucket). That could work for a couple of nodes, but once I need to deploy to a cluster, I will have to manually add each nodes's key to the repository, and that would very quickly escalate into a problem (too much manual work, keys for nodes that have already been decommissioned still hanging around, …)

Check out the PKI cookbook for a (kinda ghetto) example of how to do
this with SSL certs.
-s

Will do.

cassiano

On Wed, Jan 9, 2013 at 3:59 PM, Phil Mocek <phil-lists@mocek.org (mailto:phil-lists@mocek.org)> wrote:

On Wed, Jan 09, 2013 at 05:40:25PM -0200, Cassiano Leal wrote:

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

Yes.

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.

That is not the case when you use encrypted data bags.

References:

--
Phil Mocek
http://mocek.org/

Cassiano_Leal · January 9, 2013, 9:20pm

On Wednesday, January 9, 2013 at 19:10, AJ Christensen wrote:

Change the code in the cookbook to load the encrypted data-bag items instead of doing a search, I guess?

--AJ

I might have a go at adding that option to the cookbook when I have the time.

I wonder how are people dealing with this problem, though. I'm studying the possibility to use the deploy resource, but I stumbled on this "little" detail. Any thoughts?

--
Cassiano Leal

On 10 January 2013 10:08, Cassiano Leal <cassianoleal@gmail.com (mailto:cassianoleal@gmail.com)> wrote:

On Wednesday, January 9, 2013 at 18:59, Phil Mocek wrote:

On Wed, Jan 09, 2013 at 05:40:25PM -0200, Cassiano Leal wrote:

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.

That is not the case when you use [encrypted data bags][1].
Thanks for the reference. but I can use encrypted data bags just fine.

As previously stated, what I want to do is to use the community users cookbook [0] to distribute those keys. That cookbook already has a resource provider to deploy the keys for each user, but I couldn't find a way to make it read an encrypted data bag. If it's possible, I'd like to know.

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

Cheers,

Cassiano Leal

kkeane · January 10, 2013, 11:51am

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 cassianoleal@gmail.com
Sent:Wed 01-09-2013 11:40 am
Subject:[chef] Distribute private ssh keys via users cookbook
To:chef@lists.opscode.com;

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

Cassiano_Leal · January 10, 2013, 12:23pm

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:

RE: [chef] Distribute private ssh keys via users cookbook
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 <cassianoleal@gmail.com (mailto:cassianoleal@gmail.com)>
Sent: Wed 01-09-2013 11:40 am
Subject: [chef] Distribute private ssh keys via users cookbook
To: chef@lists.opscode.com (mailto:chef@lists.opscode.com);
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

Andrea_Campi · January 10, 2013, 1:06pm

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

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 cassianoleal@gmail.comwrote:

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 cassianoleal@gmail.com
Sent: Wed 01-09-2013 11:40 am
Subject: [chef] Distribute private ssh keys via users cookbook
To: chef@lists.opscode.com;
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

John_E_Vincent_lusis · January 10, 2013, 2:11pm

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
andrea.campi@zephirworks.com wrote:

You keep saying you would need to upload public keys to bitbucket, but what
if that was automated?

Latest updates
GitHub - bitbucket-rest-api/bitbucket: BitBucket API gem - bitbucket_rest_api

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 cassianoleal@gmail.com
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 cassianoleal@gmail.com
Sent: Wed 01-09-2013 11:40 am
Subject: [chef] Distribute private ssh keys via users cookbook
To: chef@lists.opscode.com;
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

Cassiano_Leal · January 10, 2013, 4:43pm

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
<andrea.campi@zephirworks.com (mailto:andrea.campi@zephirworks.com)> wrote:

You keep saying you would need to upload public keys to bitbucket, but what
if that was automated?

Latest updates
GitHub - bitbucket-rest-api/bitbucket: BitBucket API gem - bitbucket_rest_api

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 <cassianoleal@gmail.com (mailto:cassianoleal@gmail.com)>
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 (http://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 <cassianoleal@gmail.com (mailto:cassianoleal@gmail.com)>
Sent: Wed 01-09-2013 11:40 am
Subject: [chef] Distribute private ssh keys via users cookbook
To: chef@lists.opscode.com (mailto:chef@lists.opscode.com);
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

kkeane · January 11, 2013, 4:18am

I see where you are coming from! In this type of scenario, I would probably step outside the Chef setup.

The security problem in Chef ultimately arises because you allow the clients to pull the private keys. As a result, a hacker can potentially simply use HTTP to download your databag, or even sniff the data going over the wire. Databag encryption, client.pem and validation.pem are all protections, but they can’t compete (and aren’t designed to compete) with established security mechanisms such as SSH, PGP, …

So maybe Chef isn’t the best tool for this particular job?

I would instead use SCP to copy your private key from a single secure server to wherever they need to go. The big advantage is that because it is a push-based system, you have full control over which machines do the SSH keys get copied to.

-----Original message-----
From:Cassiano Leal cassianoleal@gmail.com
Sent:Thu 01-10-2013 04:23 am
Subject:[chef] Re: RE: Distribute private ssh keys via users cookbook
To:chef@lists.opscode.com;

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 cassianoleal@gmail.com
Sent:Wed 01-09-2013 11:40 am
Subject:[chef] Distribute private ssh keys via users cookbook
To:chef@lists.opscode.com;

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

Cassiano_Leal · January 11, 2013, 12:18pm

All perfectly good points. How do I deal with auto-scaling, though? I don't really want to be woken up in the middle of the night just because site traffic has peaked and more servers are spinning up so that I can SCP a private key to each new server.

cassiano

On Friday, January 11, 2013 at 02:18, Kevin Keane (subscriptions) wrote:

[chef] Re: RE: Distribute private ssh keys via users cookbook
I see where you are coming from! In this type of scenario, I would probably step outside the Chef setup.

The security problem in Chef ultimately arises because you allow the clients to pull the private keys. As a result, a hacker can potentially simply use HTTP to download your databag, or even sniff the data going over the wire. Databag encryption, client.pem and validation.pem are all protections, but they can't compete (and aren't designed to compete) with established security mechanisms such as SSH, PGP, ...

So maybe Chef isn't the best tool for this particular job?

I would instead use SCP to copy your private key from a single secure server to wherever they need to go. The big advantage is that because it is a push-based system, you have full control over which machines do the SSH keys get copied to.

-----Original message-----
From: Cassiano Leal <cassianoleal@gmail.com (mailto:cassianoleal@gmail.com)>
Sent: Thu 01-10-2013 04:23 am
Subject: [chef] Re: RE: Distribute private ssh keys via users cookbook
To: chef@lists.opscode.com (mailto:chef@lists.opscode.com);
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 (http://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 <cassianoleal@gmail.com (mailto:cassianoleal@gmail.com)>
Sent: Wed 01-09-2013 11:40 am
Subject: [chef] Distribute private ssh keys via users cookbook
To: chef@lists.opscode.com (mailto:chef@lists.opscode.com);
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

kkeane · January 12, 2013, 12:31am

I see two options for that:

Upload the SSH key at the same time you bootstrap the new instance. You could even add that to a custom bootstrap script, to copy it along with the validation.pem
Regularly, say, every 30 minutes, run a knife search and upload the SSH key to each server it finds.

-----Original message-----
From:Cassiano Leal cassianoleal@gmail.com
Sent:Fri 01-11-2013 04:18 am
Subject:[chef] Re: Re: RE: Distribute private ssh keys via users cookbook
To:chef@lists.opscode.com;

All perfectly good points. How do I deal with auto-scaling, though? I don’t really want to be woken up in the middle of the night just because site traffic has peaked and more servers are spinning up so that I can SCP a private key to each new server.

cassiano

On Friday, January 11, 2013 at 02:18, Kevin Keane (subscriptions) wrote:

I see where you are coming from! In this type of scenario, I would probably step outside the Chef setup.

The security problem in Chef ultimately arises because you allow the clients to pull the private keys. As a result, a hacker can potentially simply use HTTP to download your databag, or even sniff the data going over the wire. Databag encryption, client.pem and validation.pem are all protections, but they can’t compete (and aren’t designed to compete) with established security mechanisms such as SSH, PGP, …

So maybe Chef isn’t the best tool for this particular job?

I would instead use SCP to copy your private key from a single secure server to wherever they need to go. The big advantage is that because it is a push-based system, you have full control over which machines do the SSH keys get copied to.

-----Original message-----
From:Cassiano Leal cassianoleal@gmail.com
Sent:Thu 01-10-2013 04:23 am
Subject:[chef] Re: RE: Distribute private ssh keys via users cookbook
To:chef@lists.opscode.com;

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 cassianoleal@gmail.com
Sent:Wed 01-09-2013 11:40 am
Subject:[chef] Distribute private ssh keys via users cookbook
To:chef@lists.opscode.com;

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

Dan_Razzell · January 12, 2013, 12:38am

+1

As Kevin pointed out yesterday, there's something essentially
upside-down about your PKI if you're copying private keys around.

On 13-01-11 04:31 PM, Kevin Keane (subscriptions) wrote:

I see two options for that:

Upload the SSH key at the same time you bootstrap the new instance.
You could even add that to a custom bootstrap script, to copy it along
with the validation.pem
Regularly, say, every 30 minutes, run a knife search and upload the
SSH key to each server it finds.

-----Original message-----
From: Cassiano Leal cassianoleal@gmail.com
Sent: Fri 01-11-2013 04:18 am
Subject: [chef] Re: Re: RE: Distribute private ssh keys via
users cookbook
To: chef@lists.opscode.com;
All perfectly good points. How do I deal with auto-scaling,
though? I don't really want to be woken up in the middle of the
night just because site traffic has peaked and more servers are
spinning up so that I can SCP a private key to each new server.
- cassiano
On Friday, January 11, 2013 at 02:18, Kevin Keane (subscriptions)
wrote:

I see where you are coming from! In this type of scenario, I
would probably step outside the Chef setup.

The security problem in Chef ultimately arises because you allow
the clients to *pull* the private keys. As a result, a hacker can
potentially simply use HTTP to download your databag, or even
sniff the data going over the wire. Databag encryption,
client.pem and validation.pem are all protections, but they can't
compete (and aren't designed to compete) with established
security mechanisms such as SSH, PGP, ...

So maybe Chef isn't the best tool for this particular job?

I would instead use SCP to copy your private key from a single
secure server to wherever they need to go. The big advantage is
that because it is a push-based system, you have full control
over which machines do the SSH keys get copied to.

    -----Original message-----
    *From:* Cassiano Leal <cassianoleal@gmail.com
    <mailto:cassianoleal@gmail.com>>
    *Sent:* Thu 01-10-2013 04:23 am
    *Subject:* [chef] Re: RE: Distribute private ssh keys via
    users cookbook
    *To:* chef@lists.opscode.com <mailto:chef@lists.opscode.com>;
    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 <http://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 <cassianoleal@gmail.com
        <mailto:cassianoleal@gmail.com>>
        *Sent:* Wed 01-09-2013 11:40 am
        *Subject:* [chef] Distribute private ssh keys via users
        cookbook
        *To:* chef@lists.opscode.com
        <mailto:chef@lists.opscode.com>;
        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

Cassiano_Leal · January 14, 2013, 10:02am

Since I want to auto-scale these nodes, I'll have to keep the validation.pem in the AMI that will be used to boot up. That's one of the solutions that I though -- store the SSH key in the AMI.

I understand the security implications of copying SSH keys around or leaving them in an image on the Amazon cloud, but I still fail to see a better solution. The fact that no alternative covering my requirements have appeared in this thread makes me all the more confident that I'm not doing something too crazy.

Recapitulating requirements:

Auto-scaling -- this is the key point
New nodes automatically register themselves on the chef server and converge
Newly auto-scaled nodes are able to clone/update from git repos:
- on the first chef run
- no manual copy of SSH keys to the node
- no manual authorisation of a new key on bitbucket

I guess the better question would be: how are people auto-scaling chef nodes?

On 11 January 2013 22:38, Dan Razzell <danr@activestate.com (javascript:_e({}, 'cvml', 'danr@activestate.com');)> wrote:

+1

As Kevin pointed out yesterday, there's something essentially upside-down about your PKI if you're copying private keys around.

On 13-01-11 04:31 PM, Kevin Keane (subscriptions) wrote:

I see two options for that:

Upload the SSH key at the same time you bootstrap the new instance. You could even add that to a custom bootstrap script, to copy it along with the validation.pem

Regularly, say, every 30 minutes, run a knife search and upload the SSH key to each server it finds.

-----Original message-----
From: Cassiano Leal cassianoleal@gmail.com (javascript:_e({}, 'cvml', 'cassianoleal@gmail.com')
Sent: Fri 01-11-2013 04:18 am
Subject: [chef] Re: Re: RE: Distribute private ssh keys via users cookbook
To: chef@lists.opscode.com (javascript:_e({}, 'cvml', 'chef@lists.opscode.com'););
All perfectly good points. How do I deal with auto-scaling, though? I don't really want to be woken up in the middle of the night just because site traffic has peaked and more servers are spinning up so that I can SCP a private key to each new server.

cassiano

On Friday, January 11, 2013 at 02:18, Kevin Keane (subscriptions) wrote:

I see where you are coming from! In this type of scenario, I would probably step outside the Chef setup.

The security problem in Chef ultimately arises because you allow the clients to pull the private keys. As a result, a hacker can potentially simply use HTTP to download your databag, or even sniff the data going over the wire. Databag encryption, client.pem and validation.pem are all protections, but they can't compete (and aren't designed to compete) with established security mechanisms such as SSH, PGP, ...

So maybe Chef isn't the best tool for this particular job?

I would instead use SCP to copy your private key from a single secure server to wherever they need to go. The big advantage is that because it is a push-based system, you have full control over which machines do the SSH keys get copied to.

-----Original message-----
From: Cassiano Leal <cassianoleal@gmail.com (javascript:_e({}, 'cvml', 'cassianoleal@gmail.com');)>
Sent: Thu 01-10-2013 04:23 am
Subject: [chef] Re: RE: Distribute private ssh keys via users cookbook
To: chef@lists.opscode.com (javascript:_e({}, 'cvml', 'chef@lists.opscode.com'););
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 (http://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 <cassianoleal@gmail.com (javascript:_e({}, 'cvml', 'cassianoleal@gmail.com');)>
Sent: Wed 01-09-2013 11:40 am
Subject: [chef] Distribute private ssh keys via users cookbook
To: chef@lists.opscode.com (javascript:_e({}, 'cvml', 'chef@lists.opscode.com'););
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

Mike · January 14, 2013, 1:41pm

Late to the game.
Have you explored using the instance launch user-data to write out your certs?

i.e.

#!/bin/bash -e
exec > >(tee /var/log/user-data.log|logger -t user-data -s 2>/dev/console) 2>&1
echo BEGIN
date '+%Y-%m-%d %H:%M:%S'

mkdir -p /etc/chef

cat <<- EOF

EOF

/etc/chef/client.rb

cat <<- EOF

EOF

/etc/chef/validation.pem

cat <<- EOF

EOF

/path/to/private/ssh/key

(if your AMI doesn't have chef installed, install it via omnibus:)
curl -L https://www.opscode.com/chef/install.sh | bash

/etc/init.d/chef-client start

echo END

This is effectively the knife bootstrap process, executed by your
EC2 AutoScaler. This works with most "vetted" AMI images that do the
fun 'cloud-init' and all that jazz.

On Mon, Jan 14, 2013 at 5:02 AM, Cassiano Leal cassianoleal@gmail.com wrote:

Since I want to auto-scale these nodes, I'll have to keep the validation.pem
in the AMI that will be used to boot up. That's one of the solutions that I
though -- store the SSH key in the AMI.

I understand the security implications of copying SSH keys around or leaving
them in an image on the Amazon cloud, but I still fail to see a better
solution. The fact that no alternative covering my requirements have
appeared in this thread makes me all the more confident that I'm not doing
something too crazy.

Recapitulating requirements:

Auto-scaling -- this is the key point

New nodes automatically register themselves on the chef server and
converge

Newly auto-scaled nodes are able to clone/update from git repos:

on the first chef run

no manual copy of SSH keys to the node

no manual authorisation of a new key on bitbucket

I guess the better question would be: how are people auto-scaling chef
nodes?

On 11 January 2013 22:38, Dan Razzell danr@activestate.com wrote:

+1

As Kevin pointed out yesterday, there's something essentially upside-down
about your PKI if you're copying private keys around.

On 13-01-11 04:31 PM, Kevin Keane (subscriptions) wrote:

I see two options for that:

Upload the SSH key at the same time you bootstrap the new instance. You
could even add that to a custom bootstrap script, to copy it along with the
validation.pem

Regularly, say, every 30 minutes, run a knife search and upload the SSH
key to each server it finds.

-----Original message-----
From: Cassiano Leal cassianoleal@gmail.com
Sent: Fri 01-11-2013 04:18 am
Subject: [chef] Re: Re: RE: Distribute private ssh keys via users cookbook
To: chef@lists.opscode.com;
All perfectly good points. How do I deal with auto-scaling, though? I don't
really want to be woken up in the middle of the night just because site
traffic has peaked and more servers are spinning up so that I can SCP a
private key to each new server.

cassiano

On Friday, January 11, 2013 at 02:18, Kevin Keane (subscriptions) wrote:

I see where you are coming from! In this type of scenario, I would probably
step outside the Chef setup.

The security problem in Chef ultimately arises because you allow the clients
to pull the private keys. As a result, a hacker can potentially simply use
HTTP to download your databag, or even sniff the data going over the wire.
Databag encryption, client.pem and validation.pem are all protections, but
they can't compete (and aren't designed to compete) with established
security mechanisms such as SSH, PGP, ...

So maybe Chef isn't the best tool for this particular job?

I would instead use SCP to copy your private key from a single secure server
to wherever they need to go. The big advantage is that because it is a
push-based system, you have full control over which machines do the SSH keys
get copied to.

-----Original message-----
From: Cassiano Leal cassianoleal@gmail.com
Sent: Thu 01-10-2013 04:23 am
Subject: [chef] Re: RE: Distribute private ssh keys via users cookbook
To: chef@lists.opscode.com;
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 cassianoleal@gmail.com
Sent: Wed 01-09-2013 11:40 am
Subject: [chef] Distribute private ssh keys via users cookbook
To: chef@lists.opscode.com;
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

mark · January 14, 2013, 11:47pm

lusis and kevin keane have interesting suggestions/observations. I
tend to agree that this is outside the scope of Chef though some
elements of the following can be Chefified (Cooked?). Mike suggestions
are related but the data can be read by anyone in the instance with
access to http://169.254.169.254/latest/user-data

I think Shlomo Swidler has covered this issue best[0]. TLDR:
The Autoscaling requirement adds a wrinkle to the use of two signed
(short expiry) s3 urls (one the encrypted credentials and the other
containing the decryption key); the autoscaling launch config would
need to be constantly updated with current URLs, some may be happy to
script this periodic change but it has risks that an AMI fires up with
an expired URL in its userdata.

My suggestion would be to create an EBS with the encrypted private key
on it, and mount this at startup[1]. This is a superior approach to
burning the encrypted key into an AMI. There are several options re
handling the decryption key:

passed in via signed URL (AS launch config needs to be updated, see
above caveat re expiry)
create a public s3 url that is unguessable (cf signed url with no
expiry) and periodically update the AS launch config (now no instance
should AS launch without access to the decryption key), deleting the
old decryption key 'url' once AS launch config is changed. This URL
should also only be readable by an aws user whose sole permission+role
is to authenticate(via url)+decrypt private key. This user should be
able to be managed by IAM , previously you'd create an AWS user with
no permissions to incur charges (i.e. no credit card provided)

Of course your instance start-up script must clean up after itself to
remove traces of what it has done. The only remnant will be the
unguessable/signed (changed/expired) decrypt key URL in the user data.

HTH?

Regards
Mark

[0] http://shlomoswidler.com/2009/08/how-to-keep-your-aws-credentials-on-ec2.html
[1] http://shlomoswidler.com/2010/07/storing-aws-credentials-on-an-ebs-snapshot-securely.html

On Tue, Jan 15, 2013 at 12:41 AM, Mike miketheman@gmail.com wrote:

Late to the game.
Have you explored using the instance launch user-data to write out your certs?

i.e.

#!/bin/bash -e
exec > >(tee /var/log/user-data.log|logger -t user-data -s 2>/dev/console) 2>&1
echo BEGIN
date '+%Y-%m-%d %H:%M:%S'

mkdir -p /etc/chef

cat <<- EOF

EOF

/etc/chef/client.rb

cat <<- EOF

EOF

/etc/chef/validation.pem

cat <<- EOF

EOF

/path/to/private/ssh/key

(if your AMI doesn't have chef installed, install it via omnibus:)
curl -L https://www.opscode.com/chef/install.sh | bash

/etc/init.d/chef-client start

echo END

This is effectively the knife bootstrap process, executed by your
EC2 AutoScaler. This works with most "vetted" AMI images that do the
fun 'cloud-init' and all that jazz.

On Mon, Jan 14, 2013 at 5:02 AM, Cassiano Leal cassianoleal@gmail.com wrote:

Since I want to auto-scale these nodes, I'll have to keep the validation.pem
in the AMI that will be used to boot up. That's one of the solutions that I
though -- store the SSH key in the AMI.

I understand the security implications of copying SSH keys around or leaving
them in an image on the Amazon cloud, but I still fail to see a better
solution. The fact that no alternative covering my requirements have
appeared in this thread makes me all the more confident that I'm not doing
something too crazy.

Recapitulating requirements:

Auto-scaling -- this is the key point

New nodes automatically register themselves on the chef server and
converge

Newly auto-scaled nodes are able to clone/update from git repos:

on the first chef run

no manual copy of SSH keys to the node

no manual authorisation of a new key on bitbucket

I guess the better question would be: how are people auto-scaling chef
nodes?

On 11 January 2013 22:38, Dan Razzell danr@activestate.com wrote:

+1

As Kevin pointed out yesterday, there's something essentially upside-down
about your PKI if you're copying private keys around.

On 13-01-11 04:31 PM, Kevin Keane (subscriptions) wrote:

I see two options for that:

Upload the SSH key at the same time you bootstrap the new instance. You
could even add that to a custom bootstrap script, to copy it along with the
validation.pem

Regularly, say, every 30 minutes, run a knife search and upload the SSH
key to each server it finds.

-----Original message-----
From: Cassiano Leal cassianoleal@gmail.com
Sent: Fri 01-11-2013 04:18 am
Subject: [chef] Re: Re: RE: Distribute private ssh keys via users cookbook
To: chef@lists.opscode.com;
All perfectly good points. How do I deal with auto-scaling, though? I don't
really want to be woken up in the middle of the night just because site
traffic has peaked and more servers are spinning up so that I can SCP a
private key to each new server.

cassiano

On Friday, January 11, 2013 at 02:18, Kevin Keane (subscriptions) wrote:

I see where you are coming from! In this type of scenario, I would probably
step outside the Chef setup.

The security problem in Chef ultimately arises because you allow the clients
to pull the private keys. As a result, a hacker can potentially simply use
HTTP to download your databag, or even sniff the data going over the wire.
Databag encryption, client.pem and validation.pem are all protections, but
they can't compete (and aren't designed to compete) with established
security mechanisms such as SSH, PGP, ...

So maybe Chef isn't the best tool for this particular job?

I would instead use SCP to copy your private key from a single secure server
to wherever they need to go. The big advantage is that because it is a
push-based system, you have full control over which machines do the SSH keys
get copied to.

-----Original message-----
From: Cassiano Leal cassianoleal@gmail.com
Sent: Thu 01-10-2013 04:23 am
Subject: [chef] Re: RE: Distribute private ssh keys via users cookbook
To: chef@lists.opscode.com;
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 cassianoleal@gmail.com
Sent: Wed 01-09-2013 11:40 am
Subject: [chef] Distribute private ssh keys via users cookbook
To: chef@lists.opscode.com;
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

mark · January 14, 2013, 11:59pm

On Tue, Jan 15, 2013 at 10:47 AM, Mark Van De Vyver mark@taqtiqa.com wrote:

lusis and kevin keane have interesting suggestions/observations. I
tend to agree that this is outside the scope of Chef though some
elements of the following can be Chefified (Cooked?). Mike suggestions
are related but the data can be read by anyone in the instance with
access to http://169.254.169.254/latest/user-data

I think Shlomo Swidler has covered this issue best[0]. TLDR:
The Autoscaling requirement adds a wrinkle to the use of two signed
(short expiry) s3 urls (one the encrypted credentials and the other
containing the decryption key); the autoscaling launch config would
need to be constantly updated with current URLs, some may be happy to
script this periodic change but it has risks that an AMI fires up with
an expired URL in its userdata.

My suggestion would be to create an EBS with the encrypted private key
on it, and mount this at startup[1]. This is a superior approach to
burning the encrypted key into an AMI. There are several options re
handling the decryption key:

passed in via signed URL (AS launch config needs to be updated, see
above caveat re expiry)

create a public s3 url that is unguessable (cf signed url with no
expiry) and periodically update the AS launch config (now no instance
should AS launch without access to the decryption key), deleting the
old decryption key 'url' once AS launch config is changed. This URL
should also only be readable by an aws user whose sole permission+role
is to authenticate(via url)+decrypt private key. This user should be
able to be managed by IAM , previously you'd create an AWS user with
no permissions to incur charges (i.e. no credit card provided)

Of course your instance start-up script must clean up after itself to
remove traces of what it has done. The only remnant will be the
unguessable/signed (changed/expired) decrypt key URL in the user data.

HTH?

PS I should have added that ideally the decrypted ssh key is stored in
some ramdisk area so that it does not survive an instance reboot.

Regards
Mark

[0] http://shlomoswidler.com/2009/08/how-to-keep-your-aws-credentials-on-ec2.html
[1] http://shlomoswidler.com/2010/07/storing-aws-credentials-on-an-ebs-snapshot-securely.html

On Tue, Jan 15, 2013 at 12:41 AM, Mike miketheman@gmail.com wrote:

Late to the game.
Have you explored using the instance launch user-data to write out your certs?

i.e.

#!/bin/bash -e
exec > >(tee /var/log/user-data.log|logger -t user-data -s 2>/dev/console) 2>&1
echo BEGIN
date '+%Y-%m-%d %H:%M:%S'

mkdir -p /etc/chef

cat <<- EOF

EOF

/etc/chef/client.rb

cat <<- EOF

EOF

/etc/chef/validation.pem

cat <<- EOF

EOF

/path/to/private/ssh/key

(if your AMI doesn't have chef installed, install it via omnibus:)
curl -L https://www.opscode.com/chef/install.sh | bash

/etc/init.d/chef-client start

echo END

This is effectively the knife bootstrap process, executed by your
EC2 AutoScaler. This works with most "vetted" AMI images that do the
fun 'cloud-init' and all that jazz.

On Mon, Jan 14, 2013 at 5:02 AM, Cassiano Leal cassianoleal@gmail.com wrote:

Since I want to auto-scale these nodes, I'll have to keep the validation.pem
in the AMI that will be used to boot up. That's one of the solutions that I
though -- store the SSH key in the AMI.

I understand the security implications of copying SSH keys around or leaving
them in an image on the Amazon cloud, but I still fail to see a better
solution. The fact that no alternative covering my requirements have
appeared in this thread makes me all the more confident that I'm not doing
something too crazy.

Recapitulating requirements:

Auto-scaling -- this is the key point

New nodes automatically register themselves on the chef server and
converge

Newly auto-scaled nodes are able to clone/update from git repos:

on the first chef run

no manual copy of SSH keys to the node

no manual authorisation of a new key on bitbucket

I guess the better question would be: how are people auto-scaling chef
nodes?

On 11 January 2013 22:38, Dan Razzell danr@activestate.com wrote:

+1

As Kevin pointed out yesterday, there's something essentially upside-down
about your PKI if you're copying private keys around.

On 13-01-11 04:31 PM, Kevin Keane (subscriptions) wrote:

I see two options for that:

Upload the SSH key at the same time you bootstrap the new instance. You
could even add that to a custom bootstrap script, to copy it along with the
validation.pem

Regularly, say, every 30 minutes, run a knife search and upload the SSH
key to each server it finds.

-----Original message-----
From: Cassiano Leal cassianoleal@gmail.com
Sent: Fri 01-11-2013 04:18 am
Subject: [chef] Re: Re: RE: Distribute private ssh keys via users cookbook
To: chef@lists.opscode.com;
All perfectly good points. How do I deal with auto-scaling, though? I don't
really want to be woken up in the middle of the night just because site
traffic has peaked and more servers are spinning up so that I can SCP a
private key to each new server.

cassiano

On Friday, January 11, 2013 at 02:18, Kevin Keane (subscriptions) wrote:

I see where you are coming from! In this type of scenario, I would probably
step outside the Chef setup.

The security problem in Chef ultimately arises because you allow the clients
to pull the private keys. As a result, a hacker can potentially simply use
HTTP to download your databag, or even sniff the data going over the wire.
Databag encryption, client.pem and validation.pem are all protections, but
they can't compete (and aren't designed to compete) with established
security mechanisms such as SSH, PGP, ...

So maybe Chef isn't the best tool for this particular job?

I would instead use SCP to copy your private key from a single secure server
to wherever they need to go. The big advantage is that because it is a
push-based system, you have full control over which machines do the SSH keys
get copied to.

-----Original message-----
From: Cassiano Leal cassianoleal@gmail.com
Sent: Thu 01-10-2013 04:23 am
Subject: [chef] Re: RE: Distribute private ssh keys via users cookbook
To: chef@lists.opscode.com;
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 cassianoleal@gmail.com
Sent: Wed 01-09-2013 11:40 am
Subject: [chef] Distribute private ssh keys via users cookbook
To: chef@lists.opscode.com;
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

Topic		Replies	Views
Deploying User Private Keys Chef Infra (archive)	12	914	February 6, 2014
RE: Re: Re: Re: RE: private keys Chef Infra (archive)	0	271	September 4, 2015
Sensitive Data w/ Solo Chef Infra (archive)	10	395	June 20, 2010
Databags not been used on node Chef Infra (archive)	2	503	April 9, 2018
RE: RE: Re: Using chef solo to aws distribute keys Chef Infra (archive)	0	262	February 14, 2015

Distribute private ssh keys via users cookbook

Thanks!

Cheers,

Cheers,

Cheers,

Thanks!

Thanks!

Thanks!

Thanks!

Thanks!

Thanks!

Thanks!

Thanks!

Thanks!

Related Topics