[chef] Re: Re: Re: Re: Chef Vault Writeup

[Maciej Pasternacki < >]

This discussion focuses mostly on distributing secrets to nodes; chef-vault also allows to share secrets between *users*, encrypted by their private Chef API key. This can be quite convenient means to store secrets such as access keys to other APIs, confidential source data or shared secrets for plain old encrypted data bags, and so on - data that should be accessible to admins rather than directly to nodes. Chef-vault since version 2.0 supports key rotation - exchanging the secret - which lets us securely *remove* a user or node from the access list, and prevent them from seeing updated content.

Shameless Plug: I've just written a usable backend for git-annex (http://git-annex.branchable.com/) that stores files in a chef-vault data bag, encrypted for all the users with admin=true - it would also be possible to support various access levels for various items, for now it's just a simple secret sharing mechanism. This way, once a teammate is registered with chef-server, they can just `git annex get` all the keys they need straight into the chef-repo, which is quite convenient. Project is at https://github.com/3ofcoins/knife-annex

-- M

On 17 September 2013 01:09, Seth Falcon < " target="_blank"> > wrote:

Hey there,

A few comments on Chef Vault, inline...

"> writes:
> When I was evaluating Vault recently, I had concerns about how much real
> security it provides. In reading the implementation, it appears that this
> is only security by obfuscation and not truly more secure than regular
> encrypted data bags as you still must use the encrypted_data_bag_secret to
> unlock the key for the node you're operating on... you still have access to
> all of the secrets for all of the nodes, just not in a direct way.

Chef Vault helps you to solve the key distribution problem by taking
advantage of the RSA key pair assigned to each user and client on a Chef
Server. Encrypted data bags are used to implement it.

Here's (my understanding of) what happens when you create a Chef Vault
item (encrypt a data bag item using Chef Vault):

1. You tell Chef Vault:

   - the name of a vault (maps to a data bag)
   - the name of an item (maps to a data bag item)
   - secret item data
   - the clients and users that should be able to access the secret

2. Chef Vault generates a random shared key and uses the encrypted data
   bag support in Chef to encrypt the item data with this key.

3. Chef Vault uses the Chef API to obtain the public RSA keys of the
   users and clients that should have access to item. It then encrypts
   the shared key generated in #1 for each of the public keys. It stores
   the user/client name to encrypted shared key in an $ITEM_keys data
   bag item in the $VAULT data bag.

Here's what I think this gives you:

1. Compared to vanilla encrypted data bags, you don't have to arrange
   for a shared seceret to be distributed to clients (nodes) and users
   in your infrastructure.

2. If an attacker gains root access to a node, the attacker can decrypt
   items that have been encrypted for that nodes client public
   key. So an attacker would not have access to all of the secrets for
   all of the nodes.

And some things it does not give you:

1. Nodes store the client private key on disk. Using this key to decrypt
   secrets means compromise of the node will compromise any secrets
   which can be accessed via that key. So no torpedo launch key
   feature. In most cases, the secret data is used on a node in such a
   way that root access to the node would mean compromise of that secret
   regardless of how it was originally obtained. Avoiding that is hard.

2. If a node is compromised, you will need to do more than remove the
   vault entry that encrypts the shared secret for the compromised key
   pair. In fact, if an attacker is able to obtain old copies of the
   encrypted data bag, changing the shared secret is not enough. You
   will need to change your underlying secret data -- e.g. if the item
   stored db passwords, you'll need to change the db password.

> Having to leave the key on the node (as we do currently) means that once a
> single node is compromised, the entirety of things encrypted with
> /etc/chef/encrypted_data_bag_secret are easily compromised.

Encrypted data bags in general do not have to use that file and
different items can use different shared secrets. For chef vault, only
those items that the node had access to will be compromised.

> Currently, encrypted data bags only give security if your chef server
> itself is compromised but they make people _feel_ like they are being more
> secure by using them... the general attack vector, however, is through
> nodes exposed to the public internet that have flawed applications running,
> not through the Chef server which is probably internal network access only.
>  All of these nodes contain the encrypted_data_bag_secret.
>
> As a result: encrypted data bags are not often any more secure than regular
> data bags for the general case and may inadvertently harm security due to
> the aforementioned feeling of security that encrypting data bags gives and
> so some active secret storage system would be very valuable... just
> something more substantial than Vault.

I see where you're coming from, but I disagree a bit. Protecting secrets
stored in the Chef Server has value. Even without something like chef
vault, it is possible to use different secrets for different items and
thus limit the impact of an attack.

+ seth

--
Seth Falcon | Development Lead | Opscode | @sfalcon