2015-04-10 19:07:24 +00:00
|
|
|
---
|
|
|
|
layout: "intro"
|
|
|
|
page_title: "Vault vs. Chef, Puppet, etc."
|
|
|
|
sidebar_current: "vs-other-chef"
|
|
|
|
description: |-
|
|
|
|
Comparison between Vault and configuration management solutions such as Chef, Puppet, etc.
|
|
|
|
---
|
|
|
|
|
|
|
|
# Vault vs. Chef, Puppet, etc.
|
2015-04-11 02:39:17 +00:00
|
|
|
|
|
|
|
A big part of configuring software is setting up secrets: configuring a
|
|
|
|
web application to talk to a service, configuring the credentials of a
|
|
|
|
database, etc. Because of this, configuration management systems all face
|
|
|
|
a problem of safely storing these secrets.
|
|
|
|
|
|
|
|
Chef, Puppet, etc. all solve this in a similar way: single-key
|
|
|
|
encrypted storage. Chef has encrypted data bags, Puppet has encrypted
|
2015-05-14 01:07:50 +00:00
|
|
|
Hiera, and so on. The encrypted data is always one secret (a password,
|
2015-04-11 02:39:17 +00:00
|
|
|
a key, etc.) away from being decrypted, and this secret is generally
|
|
|
|
not well protected since in an elastic environment, every server needs
|
|
|
|
to somehow get this secret to decrypt the data. Additionally, access to
|
|
|
|
the encrypted data isn't always logged, so if there is an intrusion, it
|
|
|
|
isn't clear what data has been accessed and by who.
|
|
|
|
|
|
|
|
Vault is not tied to any specific configuration management system. You can
|
|
|
|
read secrets from configuration management, but you can also use the API
|
|
|
|
directly to read secrets from applications. This means that configuration
|
|
|
|
management requires less secrets, and in many cases doesn't ever have to
|
|
|
|
persist them to disk.
|
|
|
|
|
|
|
|
Vault encrypts the data onto physical storage and requires multiple
|
|
|
|
keys to even read it. If an attacker were to gain access to the physical
|
|
|
|
encrypted storage, it couldn't be read without multiple keys which are generally
|
|
|
|
distributed to multiple individuals. This is known as _unsealing_, and happens
|
|
|
|
once whenever Vault starts.
|
|
|
|
|
|
|
|
For an unsealed Vault, every interaction is logged in via the audit backends.
|
|
|
|
Even erroneous requests (invalid access tokens, for example) are logged.
|
|
|
|
To access any data, an access token is required. This token is usually
|
|
|
|
associated with an identity coming from a system such as GitHub, LDAP, etc.
|
|
|
|
This identity is also written to the audit log.
|
|
|
|
|
|
|
|
Access tokens can be given fine-grained control over what secrets can be
|
|
|
|
accessed. It is rare to have a single key that can access all secrets. This
|
|
|
|
makes it easier to have fine-grained access for consumers of Vault.
|