BT

Secrets Management with Chef-Vault

| by João Miranda Follow 2 Followers on Jan 31, 2016. Estimated reading time: 2 minutes |

Chef-vault is a Chef tool built on top of encrypted data bags that eliminates the need to share the decryption key with all users and nodes of an infrastructure.

Encrypted data bag items are a common way to store secrets - such as passwords or API keys - in a Chef infrastructure. The problem is that data bags are symmetrically encrypted, so the encryption key (shared secret) has to be distributed to all parties that need to use the encrypted data bags.

Chef-vault solves that problem by encrypting the shared secret with the public keys of each user and node that needs access to an encrypted data bag. Every node managed by Chef Server, as well as every user account, has a RSA key pair. Chef Server stores the public key. Chef nodes and users' workstations store the private key.

Chef-vault manages vaults. Each vault has a list of administrators (Chef users) and clients (Chef nodes). Only these administrators and clients can see the vault's contents. A vault is a data bag with two data bag items. One stores the encrypted item with the shared secret (e.g.: a database password). The other stores the list of administrators and clients, as well as the asymmetrically encrypted shared secret for each of them.

Whenever chef-vault creates a new encrypted data bag, it first generates a random 32-byte string with SecureRandom.random_bytes that will act as the shared secret. It then retrieves the public key of each administrator and client and encrypts the shared secret with it. This workflow eliminates the need to distribute the shared secret and provides an easier way to manage access to a given encrypted data bag item. Chef-vault also offers a rotate_keys operation that, as the name implies, creates a new shared secret and encrypts it with the public keys of all administrators and clients.

Chef-vault has some limitations. For once, it doesn't play nicely with auto scaling, as it requires human intervention to add or remove clients (i.e. nodes); or else resort to a "privileged node that has access to the keys to the kingdom", as Peter Burkholder put it in an article about chef-vault. It's also impossible to replace the provided keying mechanism, although the future chef-vault 3.x.x will solve this issue with a plugin architecture.

Secret management is a difficult problem in a distributed and scalable environment. Chef-vault is specific to Chef, which brings with it both advantages and disadvantages. There are several solutions for secrets management. Some are open source, such as Hashicorp's Vault or Square's Keywhiz, and some are commercial, such as Amazon KMS or Conjur.

Nordstrom was Chef-vault's original developer. It was transferred to Chef itself last November so that its development could continue with adequate resources.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT