a3dfde5cec
* conversion stage 1 * correct image paths * add sidebar title to frontmatter * docs/concepts and docs/internals * configuration docs and multi-level nav corrections * commands docs, index file corrections, small item nav correction * secrets converted * auth * add enterprise and agent docs * add extra dividers * secret section, wip * correct sidebar nav title in front matter for apu section, start working on api items * auth and backend, a couple directory structure fixes * remove old docs * intro side nav converted * reset sidebar styles, add hashi-global-styles * basic styling for nav sidebar * folder collapse functionality * patch up border length on last list item * wip restructure for content component * taking middleman hacking to the extreme, but its working * small css fix * add new mega nav * fix a small mistake from the rebase * fix a content resolution issue with middleman * title a couple missing docs pages * update deps, remove temporary markup * community page * footer to layout, community page css adjustments * wip downloads page * deps updated, downloads page ready * fix community page * homepage progress * add components, adjust spacing * docs and api landing pages * a bunch of fixes, add docs and api landing pages * update deps, add deploy scripts * add readme note * update deploy command * overview page, index title * Update doc fields Note this still requires the link fields to be populated -- this is solely related to copy on the description fields * Update api_basic_categories.yml Updated API category descriptions. Like the document descriptions you'll still need to update the link headers to the proper target pages. * Add bottom hero, adjust CSS, responsive friendly * Add mega nav title * homepage adjustments, asset boosts * small fixes * docs page styling fixes * meganav title * some category link corrections * Update API categories page updated to reflect the second level headings for api categories * Update docs_detailed_categories.yml Updated to represent the existing docs structure * Update docs_detailed_categories.yml * docs page data fix, extra operator page remove * api data fix * fix makefile * update deps, add product subnav to docs and api landing pages * Rearrange non-hands-on guides to _docs_ Since there is no place for these on learn.hashicorp, we'll put them under _docs_. * WIP Redirects for guides to docs * content and component updates * font weight hotfix, redirects * fix guides and intro sidenavs * fix some redirects * small style tweaks * Redirects to learn and internally to docs * Remove redirect to `/vault` * Remove `.html` from destination on redirects * fix incorrect index redirect * final touchups * address feedback from michell for makefile and product downloads
52 lines
2.5 KiB
Markdown
52 lines
2.5 KiB
Markdown
---
|
|
layout: "docs"
|
|
page_title: "Vault vs. Chef, Puppet, etc."
|
|
sidebar_title: "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.
|
|
|
|
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
|
|
Hiera, and so on. The encrypted data is always one secret (a password,
|
|
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 fewer 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 devices.
|
|
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.
|
|
|
|
For tips on how to integrate Vault using configuration management, please see
|
|
[Using HashiCorp's Vault with Chef](https://www.hashicorp.com/blog/using-hashicorp-vault-with-chef.html).
|
|
Although this post is about Chef, the principles can be broadly applied to many
|
|
of the tools listed here.
|