website: homepage, intro
This commit is contained in:
Mitchell Hashimoto
parent
a8d4319ad5
commit
a08664a8c0
|
|
@ -2,7 +2,7 @@
|
|||
# Configure Middleman
|
||||
#-------------------------------------------------------------------------
|
||||
|
||||
set :base_url, "https://www.vault.io/"
|
||||
set :base_url, "https://www.vaultproject.io/"
|
||||
|
||||
activate :hashicorp do |h|
|
||||
h.version = ENV['VAULT_VERSION']
|
||||
|
|
|
|||
|
|
@ -18,12 +18,13 @@
|
|||
<span></span>
|
||||
</div>
|
||||
</div>
|
||||
<h2 id="tag-line">A tool for storing and retrieving secrets.</h2>
|
||||
<h2 id="tag-line">A tool for managing secrets.</h2>
|
||||
<div>
|
||||
<a class="v-btn blue lrg" href="/intro">Get Started</a>
|
||||
</div>
|
||||
<div id="diagram"></div>
|
||||
<p><span class="strong">Vault</span> secures, stores and tightly controls access to tokens, passwords, certificates and other secrets in modern computing. Vault presents a unified access in front of multiple backends, with logical support for HSMs, IAM, Postgres and more.</p>
|
||||
<p><span class="strong">Vault</span> secures, stores, and tightly controls access to tokens, passwords, certificates, API keys, and other secrets in modern computing. Vault handles leasing, key revocation, key rolling, and auditing. Vault presents a unified API to access multiple backends: HSMs, AWS IAM, SQL databases, raw key/value, and more.
|
||||
</p>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
|
@ -39,9 +40,9 @@
|
|||
|
||||
<div id="crud" class="feature">
|
||||
<div class="graphic"></div>
|
||||
<h3 class="">CRUD</h2>
|
||||
<h3 class="">Secret Storage</h3>
|
||||
<p>
|
||||
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Maecenas et purus at orci cursus mattis. Maecenas ullamcorper dictum elit. Vivamus sit amet nisi eu lacus lacinia iaculis. Nulla non massa ultricies, placerat lectus vel, mattis mauris. Nullam urna risus, volutpat quis viverra in, convallis at magna.
|
||||
Vault encrypts and provides access to any secrets. Leases can be associated with secrets, and Vault will automatically revoke secrets after the lease period ends. Access control policies provide strict control over who can access what secrets.
|
||||
</p>
|
||||
<div class="feature-footer">
|
||||
<a class="v-btn black sml" href="/intro">Learn more</a>
|
||||
|
|
@ -50,9 +51,9 @@
|
|||
|
||||
<div id="key" class="feature">
|
||||
<div class="graphic"></div>
|
||||
<h3 class="">Key Rolling</h2>
|
||||
<h3 class="">Key Rolling</h3>
|
||||
<p>
|
||||
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Maecenas et purus at orci cursus mattis. Maecenas ullamcorper dictum elit. Vivamus sit amet nisi eu lacus lacinia iaculis. Nulla non massa ultricies, placerat lectus vel, mattis mauris. Nullam urna risus, volutpat quis viverra in, convallis at magna.
|
||||
Every secret in Vault is associated with a lease. Clients must renew their secret within the lease period, or request a new secret. Key rolling is as simple as storing a new secret and revoking existing secrets or waiting for the lease period to expire.
|
||||
<div class="feature-footer">
|
||||
<a class="v-btn black sml" href="/intro">Learn more</a>
|
||||
<a class="v-btn black sml terminal" href="/#/demo/crud">Launch Interactive Terminal</a>
|
||||
|
|
@ -62,9 +63,9 @@
|
|||
|
||||
<div id="audit" class="feature">
|
||||
<div class="graphic"></div>
|
||||
<h3 class="">Audit Logs</h2>
|
||||
<h3 class="">Audit Logs</h3>
|
||||
<p>
|
||||
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Maecenas et purus at orci cursus mattis. Maecenas ullamcorper dictum elit. Vivamus sit amet nisi eu lacus lacinia iaculis. Nulla non massa ultricies, placerat lectus vel, mattis mauris. Nullam urna risus, volutpat quis viverra in, convallis at magna.
|
||||
Vault stores a detailed audit log of every interaction: authentication, token creation, secret access, secret revocation, and more. Audit logs can be sent to multiple backends to ensure redundant copies. Paired with Vault's strict leasing policies, operators can easily trace back to the source of any secret.
|
||||
<div class="feature-footer">
|
||||
<a class="v-btn black sml" href="/intro">Learn more</a>
|
||||
</div>
|
||||
|
|
@ -77,9 +78,9 @@
|
|||
<div class="row">
|
||||
<div class="col-sm-offset-1 col-sm-10 col-xs-12">
|
||||
<div id="cta">
|
||||
<a class="v-btn black sml" href="/intro/index.html">Try Vault Free</a>
|
||||
<p class="cta-black">Maecenas ullamcorper dictum elit.</p>
|
||||
<p class="cta-gray">Vivamus venenatis augue.</p>
|
||||
<a class="v-btn black sml" href="/intro/index.html">Get Started with Vault</a>
|
||||
<p class="cta-black">Completely free and open source.</p>
|
||||
<!--<p class="cta-gray">Vivamus venenatis augue.</p>-->
|
||||
</div><!-- #cta -->
|
||||
</div> <!-- .col -->
|
||||
</div> <!-- .row -->
|
||||
|
|
|
|||
|
|
@ -19,49 +19,46 @@ guide for all available features as well as internals.
|
|||
|
||||
## What is Vault?
|
||||
|
||||
Vault is a tool for building, changing, and versioning infrastructure
|
||||
safely and efficiently. Vault can manage existing and popular service
|
||||
providers as well as custom in-house solutions.
|
||||
Vault is a tool for securely accessing _secrets_. A secret is anything
|
||||
that you want to tightly control access to, such as API keys, passwords,
|
||||
certificates, and more. Vault provides a unified interface to any
|
||||
secret, while providing tight access control and recording a detailed
|
||||
audit log.
|
||||
|
||||
Configuration files describe to Vault the components needed to
|
||||
run a single application or your entire datacenter.
|
||||
Vault generates an execution plan describing
|
||||
what it will do to reach the desired state, and then executes it to build the
|
||||
described infrastructure. As the configuration changes, Vault is able
|
||||
to determine what changed and create incremental execution plans which
|
||||
can be applied.
|
||||
|
||||
The infrastructure Vault can manage includes
|
||||
low-level components such as
|
||||
compute instances, storage, and networking, as well as high-level
|
||||
components such as DNS entries, SaaS features, etc.
|
||||
A modern system requires access to a multitude of secrets: database
|
||||
credentials, API keys for external services, credentials for
|
||||
service-oriented architecture communication, etc. Understanding who is
|
||||
accessing what secrets is already very difficult and platform-specific.
|
||||
Adding on key rolling, secure storage, and detailed audit logs is almost
|
||||
impossible without a custom solution. This is where Vault steps in.
|
||||
|
||||
Examples work best to showcase Vault. Please see the
|
||||
[use cases](/intro/use-cases.html).
|
||||
|
||||
The key features of Vault are:
|
||||
|
||||
* **Infrastructure as Code**: Infrastructure is described using a high-level
|
||||
configuration syntax. This allows a blueprint of your datacenter to be
|
||||
versioned and treated as you would any other code. Additionally,
|
||||
infrastructure can be shared and re-used.
|
||||
* **Secure Secret Storage**: Arbitrary key/value secrets can be stored
|
||||
in Vault. Vault encrypts these secrets prior to writing them to persistent
|
||||
storage, so gaining access to the raw storage isn't enough to access
|
||||
your secrets. Vault can write to disk, [Consul](http://www.consul.io),
|
||||
and more.
|
||||
|
||||
* **Execution Plans**: Vault has a "planning" step where it generates
|
||||
an _execution plan_. The execution plan shows what Vault will do when
|
||||
you call apply. This lets you avoid any surprises when Vault
|
||||
manipulates infrastructure.
|
||||
* **Dynamic Secrets**: Vault can generate secrets on-demand for some
|
||||
systems, such as AWS or SQL databases. For example, when an application
|
||||
needs to access an S3 bucket, it asks Vault for credentials, and Vault
|
||||
will generate an AWS keypair with valid permissions on demand. After
|
||||
creating these dynamic secrets, Vault will also automatically revoke them
|
||||
after the lease is up.
|
||||
|
||||
* **Resource Graph**: Vault builds a graph of all your resources,
|
||||
and parallelizes the creation and modification of any non-dependent
|
||||
resources. Because of this, Vault builds infrastructure as efficiently
|
||||
as possible, and operators get insight into dependencies in their
|
||||
infrastructure.
|
||||
* **Leasing and Renewal**: All secrets in Vault have a _lease_ associated
|
||||
with it. At the end of the lease, Vault will automatically revoke that
|
||||
secret. Clients are able to renew leases via built-in renew APIs.
|
||||
|
||||
* **Change Automation**: Complex changesets can be applied to
|
||||
your infrastructure with minimal human interaction.
|
||||
With the previously mentioned execution
|
||||
plan and resource graph, you know exactly what Vault will change
|
||||
and in what order, avoiding many possible human errors.
|
||||
* **Revocation**: Vault has built-in support for secret revocation. Vault
|
||||
can revoke not only single secrets, but a tree of secrets, for example
|
||||
all secrets read by a specific user, or all secrets of a particular type.
|
||||
Revocation assists in key rolling as well as locking down systems in the
|
||||
case of an intrusion.
|
||||
|
||||
## Next Steps
|
||||
|
||||
|
|
@ -70,4 +67,4 @@ multiple ways Vault can be used. Then see
|
|||
[how Vault compares to other software](/intro/vs/index.html)
|
||||
to see how it fits into your existing infrastructure. Finally, continue onwards with
|
||||
the [getting started guide](/intro/getting-started/install.html) to use
|
||||
Vault to manage real infrastructure and to see how it works.
|
||||
Vault to read, write, and create real secrets and see how it works in practice.
|
||||
|
|
|
|||
|
|
@ -3,119 +3,41 @@ layout: "intro"
|
|||
page_title: "Use Cases"
|
||||
sidebar_current: "use-cases"
|
||||
description: |-
|
||||
Before understanding use cases, it's useful to know what Vault is. This page lists some concrete use cases for Vault, but the possible use cases are much broader than what we cover. Due to its extensible nature, providers and provisioners can be added to further extend Vault's ability to manipulate resources.
|
||||
This page lists some concrete use cases for Vault, but the possible use cases are much broader than what we cover.
|
||||
---
|
||||
|
||||
# Use Cases
|
||||
|
||||
Before understanding use cases, it's useful to know [what Vault is](/intro/index.html).
|
||||
This page lists some concrete use cases for Vault, but the possible use cases are
|
||||
much broader than what we cover. Due to its extensible nature, providers and provisioners
|
||||
can be added to further extend Vault's ability to manipulate resources.
|
||||
much broader than what we cover.
|
||||
|
||||
#### Heroku App Setup
|
||||
#### General Secret Storage
|
||||
|
||||
Heroku is a popular PaaS for hosting web apps. Developers create an app, and then
|
||||
attach add-ons, such as a database, or email provider. One of the best features is
|
||||
the ability to elastically scale the number of dynos or workers. However, most
|
||||
non-trivial applications quickly need many add-ons and external services.
|
||||
At a bare minimum, Vault can be used for the storage of any secrets. For
|
||||
example, Vault would be a fantastic way to store sensitive environment variables,
|
||||
database credentials, API keys, etc.
|
||||
|
||||
Vault can be used to codify the setup required for a Heroku application, ensuring
|
||||
that all the required add-ons are available, but it can go even further: configuring
|
||||
DNSimple to set a CNAME, or setting up CloudFlare as a CDN for the
|
||||
app. Best of all, Vault can do all of this in under 30 seconds without
|
||||
using a web interface.
|
||||
Compare this with the current way to store these which might be
|
||||
plaintext in files, configuration management, a database, etc. It would be
|
||||
much safer to query these using `vault read` or the API. This protects
|
||||
the plaintext version of these secrets as well as records access in the Vault
|
||||
audit log.
|
||||
|
||||
#### Multi-Tier Applications
|
||||
#### Employee Credential Storage
|
||||
|
||||
A very common pattern is the N-tier architecture. The most common 2-tier architecture is
|
||||
a pool of web servers that use a database tier. Additional tiers get added for API servers,
|
||||
caching servers, routing meshes, etc. This pattern is used because the tiers can be scaled
|
||||
independently and provide a separation of concerns.
|
||||
While this overlaps with "General Secret Storage", Vault is a good mechanism
|
||||
for storing credentials that employees share to access web services. The
|
||||
audit log mechanism lets you know what secrets an employee accessed and
|
||||
when an employee leaves, it is easier to roll keys and understand which keys
|
||||
have and haven't been rolled.
|
||||
|
||||
Vault is an ideal tool for building and managing these infrastructures. Each tier can
|
||||
be described as a collection of resources, and the dependencies between each tier are handled
|
||||
automatically; Vault will ensure the database tier is available before the web servers
|
||||
are started and that the load balancers are aware of the web nodes. Each tier can then be
|
||||
scaled easily using Vault by modifying a single `count` configuration value. Because
|
||||
the creation and provisioning of a resource is codified and automated, elastically scaling
|
||||
with load becomes trivial.
|
||||
#### API Key Generation for Scripts
|
||||
|
||||
#### Self-Service Clusters
|
||||
|
||||
At a certain organizational size, it becomes very challenging for a centralized
|
||||
operations team to manage a large and growing infrastructure. Instead it becomes
|
||||
more attractive to make "self-serve" infrastructure, allowing product teams to
|
||||
manage their own infrastructure using tooling provided by the central operations team.
|
||||
|
||||
Using Vault, the knowledge of how to build and scale a service can be codified
|
||||
in a configuration. Vault configurations can be shared within an organization
|
||||
enabling customer teams to use the configuration as a black box and use Vault as
|
||||
a tool to manage their services.
|
||||
|
||||
#### Software Demos
|
||||
|
||||
Modern software is increasingly networked and distributed. Although tools like
|
||||
[Vagrant](https://www.vagrantup.com/) exist to build virtualized environments
|
||||
for demos, it is still very challenging to demo software on real infrastructure
|
||||
which more closely matches production environments.
|
||||
|
||||
Software writers can provide a Vault configuration to create, provision and
|
||||
bootstrap a demo on cloud providers like AWS. This allows end users to easily demo
|
||||
the software on their own infrastructure, and even enables tweaking parameters like
|
||||
cluster size to more rigorously test tools at any scale.
|
||||
|
||||
#### Disposable Environments
|
||||
|
||||
It is common practice to have both a production and staging or QA environment.
|
||||
These environments are smaller clones of their production counterpart, but are
|
||||
used to test new applications before releasing in production. As the production
|
||||
environment grows larger and more complex, it becomes increasingly onerous to
|
||||
maintain an up-to-date staging environment.
|
||||
|
||||
Using Vault, the production environment can be codified and then shared with
|
||||
staging, QA or dev. These configurations can be used to rapidly spin up new
|
||||
environments to test in, and then be easily disposed of. Vault can help tame
|
||||
the difficulty of maintaining parallel environments, and makes it practical
|
||||
to elastically create and destroy them.
|
||||
|
||||
#### Software Defined Networking
|
||||
|
||||
Software Defined Networking (SDN) is becoming increasingly prevalent in the
|
||||
datacenter, as it provides more control to operators and developers and
|
||||
allows the network to better support the applications running on top. Most SDN
|
||||
implementations have a control layer and infrastructure layer.
|
||||
|
||||
Vault can be used to codify the configuration for software defined networks.
|
||||
This configuration can then be used by Vault to automatically setup and modify
|
||||
settings by interfacing with the control layer. This allows configuration to be
|
||||
versioned and changes to be automated. As an example, [AWS VPC](http://aws.amazon.com/vpc/)
|
||||
is one of the most commonly used SDN implementations, and [can be configured by
|
||||
Vault](/docs/providers/aws/r/vpc.html).
|
||||
|
||||
#### Resource Schedulers
|
||||
|
||||
In large-scale infrastructures, static assignment of applications to machines
|
||||
becomes increasingly challenging. To solve that problem, there are a number
|
||||
of schedulers like Borg, Mesos, YARN, and Kubernetes. These can be used to
|
||||
dynamically schedule Docker containers, Hadoop, Spark, and many other software
|
||||
tools.
|
||||
|
||||
Vault is not limited to physical providers like AWS. Resource schedulers
|
||||
can be treated as a provider, enabling Vault to request resources from them.
|
||||
This allows Vault to be used in layers: to setup the physical infrastructure
|
||||
running the schedulers as well as provisioning onto the scheduled grid.
|
||||
|
||||
#### Multi-Cloud Deployment
|
||||
|
||||
It's often attractive to spread infrastructure across multiple clouds to increase
|
||||
fault-tolerance. By using only a single region or cloud provider, fault tolerance
|
||||
is limited by the availability of that provider. Having a multi-cloud deployment
|
||||
allows for more graceful recovery of the loss of a region or entire provider.
|
||||
|
||||
Realizing multi-cloud deployments can be very challenging as many existing tools
|
||||
for infrastructure management are cloud-specific. Vault is cloud-agnostic
|
||||
and allows a single configuration to be used to manage multiple providers, and
|
||||
to even handle cross-cloud dependencies. This simplifies management and orchestration,
|
||||
helping operators build large-scale multi-cloud infrastructures.
|
||||
The "dynamic secrets" feature of Vault is ideal for scripts: an AWS
|
||||
access key can be generated for the duration of a script, then revoked.
|
||||
The keypair will not exist before or after the script runs, and the
|
||||
creation of the keys are completely logged.
|
||||
|
||||
This is an improvement over using something like Amazon IAM but still
|
||||
effectively hardcoding limited-access access tokens in various places.
|
||||
|
|
|
|||
|
|
@ -75,27 +75,6 @@
|
|||
</li>
|
||||
</ul>
|
||||
</li>
|
||||
|
||||
<li<%= sidebar_current("examples") %>>
|
||||
<a href="/intro/examples/index.html">Example Configurations</a>
|
||||
<ul class="nav">
|
||||
<li<%= sidebar_current("examples-aws") %>>
|
||||
<a href="/intro/examples/aws.html">Basic Two-Tier AWS Architecture</a>
|
||||
</li>
|
||||
|
||||
<li<%= sidebar_current("examples-cross-provider") %>>
|
||||
<a href="/intro/examples/cross-provider.html">Cross Provider</a>
|
||||
</li>
|
||||
|
||||
<li<%= sidebar_current("examples-count") %>>
|
||||
<a href="/intro/examples/count.html">Count Parameter</a>
|
||||
</li>
|
||||
|
||||
<li<%= sidebar_current("examples-consul") %>>
|
||||
<a href="/intro/examples/consul.html">Consul</a>
|
||||
</li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<% end %>
|
||||
|
|
|
|||
Loading…
Reference in a new issue