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

["Kemp, Joseph A. (JKEMP)" < >]

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:
 
 
Sent: Thursday, November 07, 2013 6:40 PM
To: 

 
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 
<
 >
 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 
> 
 
>
> Sent: Wednesday, November 06, 2013 5:45 PM
> To: 
> 
 
> 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) 
> <
 >
> 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 
<
 >
          * 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       ]