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 [lamont@opscode.com]
Sent: Saturday, November 09, 2013 2:19 PM
To: chef@lists.opscode.com
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) <JKEMP@arinc.commailto:JKEMP@arinc.com> 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.
-
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.
-
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.
-
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.
-
Just thought of another angle. All of this "security" is built on top of openssl. Looking at the man page (/docs/manmaster/man1/openssl.html) 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:jdunn@aquezada.commailto:jdunn@aquezada.com]
Sent: Thursday, November 07, 2013 6:40 PM
To: chef@lists.opscode.commailto:chef@lists.opscode.com
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.
On Thu, Nov 7, 2013 at 7:33 AM, Kadel-Garcia, Nico <NKadelGarcia-consultant@scholastic.commailto:NKadelGarcia-consultant@scholastic.com> 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 [miketheman@gmail.commailto:miketheman@gmail.com]
Sent: Wednesday, November 06, 2013 5:45 PM
To: chef@lists.opscode.commailto:chef@lists.opscode.com
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)
<JKEMP@arinc.commailto:JKEMP@arinc.com>
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 <jdunn@aquezada.commailto:jdunn@aquezada.com> * Sorry, I'm ]
[ WWW: http://www.aquezada.com/staff/julian * only Web 1.0 ]
[ gopher://<UrlBlockedError.aspx>sdf.org/1/users/keymaker/http://sdf.org/1/users/keymaker/ * compliant! ]
[ PGP: 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9 ]