[chef] RE: Re: Re: RE: Re: RE: Re: Securing Knife

["Kadel-Garcia, Nico" < >]

> If you're worried about keyloggers or remote control tools on admin's workstations, then you've lost the war already.

I'm afraid that approach is how the non-passphrased PEM files in $HOME/.chef or in NFS shares happened in the first place.

> the signup process becomes "paste in your public ssh key" which people should be trained to do from interacting with AWS and other cloud services.

I'd actually discourage this, given a choice. Many people tend to re-use the same, unsigned key for many  distinct applications, and this would permit multiple chef admin accounts to use the same private and public keys, which could get..... odd to clean up after and verify. If I had preferences, I'd use Kerberos credentials and avoid the whole "storing private keys" problem. But that rewrite might be even more painful than adding pass-phrased key support.

                        Nico Kadel-Garcia

---

From: Lamont Granquist
Sent: Saturday, November 09, 2013 2:19 PM
To:
Subject: [chef] Re: Re: RE: Re: RE: Re: Securing Knife

If you're worried about keyloggers or remote control tools on admin's workstations, then you've lost the war already.

There is a clear risk vector in stolen laptops and in drive-by hacks of laptops snarfing unencrypted credentials.

Making knife encrypt the existing user.pem file would be fairly easy.

Making knife, and the chef-server, use ssh identities and integrate with ssh-agent would be very cool, but obviously more work.  Since Dan is doing work that will eliminate the need for validation keys and leverage the user creds for provisioning servers, if we could pick up existing ssh keys then that would make chef a lot easier to use -- the signup process becomes "paste in your public ssh key" which people should be trained to do from interacting with AWS and other cloud services.  That key starts to be a lot of eggs in one basket, but for admins with root access, compromise of their ssh credentials is usually enough to own the entire shop anyway -- admin laptops should have encrypted drives and use ssh-agent at that point.

On 11/7/13 9:43 PM, Ranjib Dey wrote:

i like the idea. i dont think it will be lot of work to implement this. though i find the whole password/ssh-agent/gnome bit strange (keyloggers? each tool will add 1+ vector), but this will help in general 2 factor auth/ ldap backed etc.

On Thu, Nov 7, 2013 at 5:29 PM, Kemp, Joseph A. (JKEMP) < " target="_blank"> > wrote:

Julian,

My understanding of the Chef infrastructure is that if someone gets a copy of the physical pem file and has access to your chef server they have the keys to your kingdom.  This would be complete control over every managed device.  It's just like keeping all of the root passwords in a text file on your laptop drive.  I know I can use disk encryption to protect the pem but that seems like a pretty significant requirement to be able to use chef securely.

There are a handful of spots that load the key with a call like this: OpenSSL::PKey::RSA.new(rest.signing_key).  Right now the code relies on the underlying openssl library to ask for the password but it can be easily passed in as a second parameter to this existing call.  So in a sense knife already supports encrypted pems but it just isn't implemented very well.

1.  So the first option would be to allow the password to be passed on the command line to knife.  Better would be to get the password from stdin.  There are some significant risks to allowing the password on the command line but it is better than nothing.

2.  The second option is for knife to check to see if the pem is encrypted, if so ask for the password once and then pass it into all subsequent openssl calls for the user.

3. Finally, ssh-agent has addressed this same type of issue for many years.  It's a good balance between security and usability. Figuring out how to build on that model would most likely be the most elegant solution.

4. Just thought of another angle.  All of this "security" is built on top of openssl.  Looking at the man page (http://www.openssl.org/docs/apps/openssl.html#PASS_PHRASE_ARGUMENTS) it lists 5 different techniques to get the password into the openssl process.  These look to be good options also.


-Joe


-----Original Message-----
From: Julian C. Dunn [mailto: " target="_blank"> ]
Sent: Thursday, November 07, 2013 6:40 PM
To: " target="_blank">
Subject: [chef] Re: RE: Re: Securing Knife

Joe,

It's the first time I've heard this raised as a concern, but that doesn't mean it's not valid. I think the use case so far has been that each Chef admin has the PEM on their local workstations as opposed to a shared workstation/jumpbox.

However, one has to balance usability versus security. Even if Knife only prompted once per command for the user's passphrase, that still seems like a PITA. Doesn't that get in the way of operations?

Again, I think it's a feature request that we would consider if you can define how you see PEM passphrases would work without being too intrusive.

- Julian

On Thu, Nov 7, 2013 at 7:33 AM, Kadel-Garcia, Nico < " target="_blank"> > wrote:
> Such a private pem file is still stored locally, effectively in
> plain-text, with no password protection. For home directories on
> poorly secured NFS mounts it's even worse because any host connected
> to the relevant network can NFS mount the directory, "sudo" to the
> relevant uid, and gain access to the unencrypted keys. NFSv4 with
> Kerberized authentication can help with that, as can proper CIFS
> configurations for Windows based fileshares, but the key is still available on all backup media in plaintext.
>
> I'd recommend using a highly secured local disk area, such as an
> encrypted partition, and a symlink from the relevant workspace to the
> locally encrypted partition. And I'd suggest running chef server
> operations only from that secured workspace, especially for sensitive
> environments and source code manipulation. Since the source code for
> the cookbooks can often be used to manipulate or ruin deployed
> systems, similar precautions should be used for SSH keys for any central source repository.
>
> And as mentioned, don't forget to passphrase protect SSH keys? The old
> "keychain" perl script works well for managing personal SSH keys in
> command-line environments, and many modern window manager environments
> like Gnome and KDE have built-in tools for SSH key management.
>
> ________________________________
> From: Mike [ " target="_blank"> ]
>
> Sent: Wednesday, November 06, 2013 5:45 PM
> To: " target="_blank">
> Subject: [chef] Re: Securing Knife
>
> Have individual/personal admin-level pem files - don't share a
> centralized one.
>
>   knife client create new_person --admin
>
> Ref: http://docs.opscode.com/chef/knife.html#create
>
> -M
>
>
> On Wed, Nov 6, 2013 at 5:40 PM, Kemp, Joseph A. (JKEMP)
> < " target="_blank"> >
> wrote:
>>
>> I am puzzled how to secure the use of knife in open source chef.  If
>> I add a password to the user PEM I am forced to enter the password
>> multiple times for each knife command.  So that's not a very user
>> friendly option.  Someone else suggested storing the pem on an
>> encrypted file system/device/etc.  What is the best practice to provide controlled admin access to the chef server?
>> It's a little unnerving that someone with a copy of any admin PEM
>> file gains complete control over your infrastructure.  I feel like I
>> must be missing something.
>>
>>
>>
>> Thanks,
>>
>> -Joe
>
>



--
[ Julian C. Dunn < " target="_blank"> >          * Sorry, I'm    ]
[ WWW: http://www.aquezada.com/staff/julian    * only Web 1.0  ]
[ gopher://sdf.org/1/users/keymaker/           * compliant!    ]
[ PGP: 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9       ]