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
-M
On Wed, Nov 6, 2013 at 5:40 PM, Kemp, Joseph A. (JKEMP)
<
" target="_blank">
> wrote:
|
Archive powered by MHonArc 2.6.16.