Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Secrets Management with Chef-Vault

Secrets Management with Chef-Vault

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