luxolus
/
open-vault
2
0
Fork 0
Code Issues 1 Pull Requests Releases Activity

Resolve the most painful merge conflict known on earth

This commit is contained in:
Seth Vargo 2017-09-20 15:05:00 -05:00
parent 578f9a4872
commit 51a27b758b
No known key found for this signature in database
GPG Key ID: C921994F9C27E0FF
84 changed files with 1762 additions and 2316 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

389
cli/commands.go
View File

@ -1,389 +0,0 @@
package cli
import (
"os"
auditFile "github.com/hashicorp/vault/builtin/audit/file"
auditSocket "github.com/hashicorp/vault/builtin/audit/socket"
auditSyslog "github.com/hashicorp/vault/builtin/audit/syslog"
"github.com/hashicorp/vault/physical"
"github.com/hashicorp/vault/version"
credGcp "github.com/hashicorp/vault-plugin-auth-gcp/plugin"
credKube "github.com/hashicorp/vault-plugin-auth-kubernetes"
credAppId "github.com/hashicorp/vault/builtin/credential/app-id"
credAppRole "github.com/hashicorp/vault/builtin/credential/approle"
credAws "github.com/hashicorp/vault/builtin/credential/aws"
credCert "github.com/hashicorp/vault/builtin/credential/cert"
credGitHub "github.com/hashicorp/vault/builtin/credential/github"
credLdap "github.com/hashicorp/vault/builtin/credential/ldap"
credOkta "github.com/hashicorp/vault/builtin/credential/okta"
credRadius "github.com/hashicorp/vault/builtin/credential/radius"
credUserpass "github.com/hashicorp/vault/builtin/credential/userpass"
physAzure "github.com/hashicorp/vault/physical/azure"
physCassandra "github.com/hashicorp/vault/physical/cassandra"
physCockroachDB "github.com/hashicorp/vault/physical/cockroachdb"
physConsul "github.com/hashicorp/vault/physical/consul"
physCouchDB "github.com/hashicorp/vault/physical/couchdb"
physDynamoDB "github.com/hashicorp/vault/physical/dynamodb"
physEtcd "github.com/hashicorp/vault/physical/etcd"
physFile "github.com/hashicorp/vault/physical/file"
physGCS "github.com/hashicorp/vault/physical/gcs"
physInmem "github.com/hashicorp/vault/physical/inmem"
physMSSQL "github.com/hashicorp/vault/physical/mssql"
physMySQL "github.com/hashicorp/vault/physical/mysql"
physPostgreSQL "github.com/hashicorp/vault/physical/postgresql"
physS3 "github.com/hashicorp/vault/physical/s3"
physSwift "github.com/hashicorp/vault/physical/swift"
physZooKeeper "github.com/hashicorp/vault/physical/zookeeper"
"github.com/hashicorp/vault/builtin/logical/aws"
"github.com/hashicorp/vault/builtin/logical/cassandra"
"github.com/hashicorp/vault/builtin/logical/consul"
"github.com/hashicorp/vault/builtin/logical/database"
"github.com/hashicorp/vault/builtin/logical/mongodb"
"github.com/hashicorp/vault/builtin/logical/mssql"
"github.com/hashicorp/vault/builtin/logical/mysql"
"github.com/hashicorp/vault/builtin/logical/pki"
"github.com/hashicorp/vault/builtin/logical/postgresql"
"github.com/hashicorp/vault/builtin/logical/rabbitmq"
"github.com/hashicorp/vault/builtin/logical/ssh"
"github.com/hashicorp/vault/builtin/logical/totp"
"github.com/hashicorp/vault/builtin/logical/transit"
"github.com/hashicorp/vault/builtin/plugin"
"github.com/hashicorp/vault/audit"
"github.com/hashicorp/vault/command"
"github.com/hashicorp/vault/logical"
"github.com/hashicorp/vault/meta"
"github.com/mitchellh/cli"
)
// Commands returns the mapping of CLI commands for Vault. The meta
// parameter lets you set meta options for all commands.
func Commands(metaPtr *meta.Meta) map[string]cli.CommandFactory {
if metaPtr == nil {
metaPtr = &meta.Meta{
TokenHelper: command.DefaultTokenHelper,
}
}
if metaPtr.Ui == nil {
metaPtr.Ui = &cli.BasicUi{
Writer: os.Stdout,
ErrorWriter: os.Stderr,
}
}
return map[string]cli.CommandFactory{
"init": func() (cli.Command, error) {
return &command.InitCommand{
Meta: *metaPtr,
}, nil
},
"server": func() (cli.Command, error) {
c := &command.ServerCommand{
Meta: *metaPtr,
AuditBackends: map[string]audit.Factory{
"file": auditFile.Factory,
"syslog": auditSyslog.Factory,
"socket": auditSocket.Factory,
},
CredentialBackends: map[string]logical.Factory{
"approle": credAppRole.Factory,
"cert": credCert.Factory,
"aws": credAws.Factory,
"app-id": credAppId.Factory,
"gcp": credGcp.Factory,
"github": credGitHub.Factory,
"userpass": credUserpass.Factory,
"ldap": credLdap.Factory,
"okta": credOkta.Factory,
"radius": credRadius.Factory,
"kubernetes": credKube.Factory,
"plugin": plugin.Factory,
},
LogicalBackends: map[string]logical.Factory{
"aws": aws.Factory,
"consul": consul.Factory,
"postgresql": postgresql.Factory,
"cassandra": cassandra.Factory,
"pki": pki.Factory,
"transit": transit.Factory,
"mongodb": mongodb.Factory,
"mssql": mssql.Factory,
"mysql": mysql.Factory,
"ssh": ssh.Factory,
"rabbitmq": rabbitmq.Factory,
"database": database.Factory,
"totp": totp.Factory,
"plugin": plugin.Factory,
},
ShutdownCh: command.MakeShutdownCh(),
SighupCh: command.MakeSighupCh(),
}
c.PhysicalBackends = map[string]physical.Factory{
"azure": physAzure.NewAzureBackend,
"cassandra": physCassandra.NewCassandraBackend,
"cockroachdb": physCockroachDB.NewCockroachDBBackend,
"consul": physConsul.NewConsulBackend,
"couchdb": physCouchDB.NewCouchDBBackend,
"couchdb_transactional": physCouchDB.NewTransactionalCouchDBBackend,
"dynamodb": physDynamoDB.NewDynamoDBBackend,
"etcd": physEtcd.NewEtcdBackend,
"file": physFile.NewFileBackend,
"file_transactional": physFile.NewTransactionalFileBackend,
"gcs": physGCS.NewGCSBackend,
"inmem": physInmem.NewInmem,
"inmem_ha": physInmem.NewInmemHA,
"inmem_transactional": physInmem.NewTransactionalInmem,
"inmem_transactional_ha": physInmem.NewTransactionalInmemHA,
"mssql": physMSSQL.NewMSSQLBackend,
"mysql": physMySQL.NewMySQLBackend,
"postgresql": physPostgreSQL.NewPostgreSQLBackend,
"s3": physS3.NewS3Backend,
"swift": physSwift.NewSwiftBackend,
"zookeeper": physZooKeeper.NewZooKeeperBackend,
}
return c, nil
},
"ssh": func() (cli.Command, error) {
return &command.SSHCommand{
Meta: *metaPtr,
}, nil
},
"path-help": func() (cli.Command, error) {
return &command.PathHelpCommand{
Meta: *metaPtr,
}, nil
},
"auth": func() (cli.Command, error) {
return &command.AuthCommand{
Meta: *metaPtr,
Handlers: map[string]command.AuthHandler{
"github": &credGitHub.CLIHandler{},
"userpass": &credUserpass.CLIHandler{DefaultMount: "userpass"},
"ldap": &credLdap.CLIHandler{},
"okta": &credOkta.CLIHandler{},
"cert": &credCert.CLIHandler{},
"aws": &credAws.CLIHandler{},
"radius": &credUserpass.CLIHandler{DefaultMount: "radius"},
},
}, nil
},
"auth-enable": func() (cli.Command, error) {
return &command.AuthEnableCommand{
Meta: *metaPtr,
}, nil
},
"auth-disable": func() (cli.Command, error) {
return &command.AuthDisableCommand{
Meta: *metaPtr,
}, nil
},
"audit-list": func() (cli.Command, error) {
return &command.AuditListCommand{
Meta: *metaPtr,
}, nil
},
"audit-disable": func() (cli.Command, error) {
return &command.AuditDisableCommand{
Meta: *metaPtr,
}, nil
},
"audit-enable": func() (cli.Command, error) {
return &command.AuditEnableCommand{
Meta: *metaPtr,
}, nil
},
"key-status": func() (cli.Command, error) {
return &command.KeyStatusCommand{
Meta: *metaPtr,
}, nil
},
"policies": func() (cli.Command, error) {
return &command.PolicyListCommand{
Meta: *metaPtr,
}, nil
},
"policy-delete": func() (cli.Command, error) {
return &command.PolicyDeleteCommand{
Meta: *metaPtr,
}, nil
},
"policy-write": func() (cli.Command, error) {
return &command.PolicyWriteCommand{
Meta: *metaPtr,
}, nil
},
"read": func() (cli.Command, error) {
return &command.ReadCommand{
Meta: *metaPtr,
}, nil
},
"unwrap": func() (cli.Command, error) {
return &command.UnwrapCommand{
Meta: *metaPtr,
}, nil
},
"list": func() (cli.Command, error) {
return &command.ListCommand{
Meta: *metaPtr,
}, nil
},
"write": func() (cli.Command, error) {
return &command.WriteCommand{
Meta: *metaPtr,
}, nil
},
"delete": func() (cli.Command, error) {
return &command.DeleteCommand{
Meta: *metaPtr,
}, nil
},
"rekey": func() (cli.Command, error) {
return &command.RekeyCommand{
Meta: *metaPtr,
}, nil
},
"generate-root": func() (cli.Command, error) {
return &command.GenerateRootCommand{
Meta: *metaPtr,
}, nil
},
"renew": func() (cli.Command, error) {
return &command.RenewCommand{
Meta: *metaPtr,
}, nil
},
"revoke": func() (cli.Command, error) {
return &command.RevokeCommand{
Meta: *metaPtr,
}, nil
},
"seal": func() (cli.Command, error) {
return &command.SealCommand{
Meta: *metaPtr,
}, nil
},
"status": func() (cli.Command, error) {
return &command.StatusCommand{
Meta: *metaPtr,
}, nil
},
"unseal": func() (cli.Command, error) {
return &command.UnsealCommand{
Meta: *metaPtr,
}, nil
},
"step-down": func() (cli.Command, error) {
return &command.StepDownCommand{
Meta: *metaPtr,
}, nil
},
"mount": func() (cli.Command, error) {
return &command.MountCommand{
Meta: *metaPtr,
}, nil
},
"mounts": func() (cli.Command, error) {
return &command.MountsCommand{
Meta: *metaPtr,
}, nil
},
"mount-tune": func() (cli.Command, error) {
return &command.MountTuneCommand{
Meta: *metaPtr,
}, nil
},
"remount": func() (cli.Command, error) {
return &command.RemountCommand{
Meta: *metaPtr,
}, nil
},
"rotate": func() (cli.Command, error) {
return &command.RotateCommand{
Meta: *metaPtr,
}, nil
},
"unmount": func() (cli.Command, error) {
return &command.UnmountCommand{
Meta: *metaPtr,
}, nil
},
"token-create": func() (cli.Command, error) {
return &command.TokenCreateCommand{
Meta: *metaPtr,
}, nil
},
"token-lookup": func() (cli.Command, error) {
return &command.TokenLookupCommand{
Meta: *metaPtr,
}, nil
},
"token-renew": func() (cli.Command, error) {
return &command.TokenRenewCommand{
Meta: *metaPtr,
}, nil
},
"token-revoke": func() (cli.Command, error) {
return &command.TokenRevokeCommand{
Meta: *metaPtr,
}, nil
},
"capabilities": func() (cli.Command, error) {
return &command.CapabilitiesCommand{
Meta: *metaPtr,
}, nil
},
"version": func() (cli.Command, error) {
versionInfo := version.GetVersion()
return &command.VersionCommand{
VersionInfo: versionInfo,
Ui: metaPtr.Ui,
}, nil
},
}
}

24
command/commands.go
View File

@ -32,6 +32,7 @@ import (
auditSyslog "github.com/hashicorp/vault/builtin/audit/syslog"
credGcp "github.com/hashicorp/vault-plugin-auth-gcp/plugin"
credKube "github.com/hashicorp/vault-plugin-auth-kubernetes"
credAppId "github.com/hashicorp/vault/builtin/credential/app-id"
credAppRole "github.com/hashicorp/vault/builtin/credential/approle"
credAws "github.com/hashicorp/vault/builtin/credential/aws"
@ -410,17 +411,18 @@ func init() {
"syslog": auditSyslog.Factory,
},
CredentialBackends: map[string]logical.Factory{
"app-id": credAppId.Factory,
"approle": credAppRole.Factory,
"aws": credAws.Factory,
"cert": credCert.Factory,
"gcp": credGcp.Factory,
"github": credGitHub.Factory,
"ldap": credLdap.Factory,
"okta": credOkta.Factory,
"plugin": plugin.Factory,
"radius": credRadius.Factory,
"userpass": credUserpass.Factory,
"app-id": credAppId.Factory,
"approle": credAppRole.Factory,
"aws": credAws.Factory,
"cert": credCert.Factory,
"gcp": credGcp.Factory,
"github": credGitHub.Factory,
"kubernetes": credKube.Factory,
"ldap": credLdap.Factory,
"okta": credOkta.Factory,
"plugin": plugin.Factory,
"radius": credRadius.Factory,
"userpass": credUserpass.Factory,
},
LogicalBackends: map[string]logical.Factory{
"aws": aws.Factory,

116
command/remount.go
View File

@ -1,116 +0,0 @@
package command
import (
"fmt"
"strings"
"github.com/hashicorp/vault-enterprise/meta"
"github.com/mitchellh/cli"
"github.com/posener/complete"
)
// Ensure we are implementing the right interfaces.
var _ cli.Command = (*RemountCommand)(nil)
var _ cli.CommandAutocomplete = (*RemountCommand)(nil)
// RemountCommand is a Command that remounts a mounted secret backend
// to a new endpoint.
type RemountCommand struct {
*BaseCommand
}
func (c *RemountCommand) Synopsis() string {
return "Remounts a secret backend to a new path"
}
func (c *RemountCommand) Help() string {
helpText := `
Usage: vault remount [options] SOURCE DESTINATION
Remounts an existing secret backend to a new path. Any leases from the old
backend are revoked, but the data associated with the backend (such as
configuration), is preserved.
Move the existing mount at secret/ to generic/:
$ vault remount secret/ generic/
For a full list of examples, please see the documentation.
` + c.Flags().Help()
return strings.TrimSpace(helpText)
}
func (c *RemountCommand) Flags() *FlagSets {
return c.flagSet(FlagSetHTTP)
}
func (c *RemountCommand) AutocompleteArgs() complete.Predictor {
return c.PredictVaultMounts()
}
func (c *RemountCommand) AutocompleteFlags() complete.Flags {
return c.Flags().Completions()
}
func (c *RemountCommand) Run(args []string) int {
f := c.Flags()
if err := f.Parse(args); err != nil {
c.UI.Error(err.Error())
return 1
}
args = f.Args()
switch len(args) {
case 0, 1:
c.UI.Error(fmt.Sprintf("Not enough arguments (expected 2, got %d)", len(args)))
return 1
case 2:
default:
c.UI.Error(fmt.Sprintf("Too many arguments (expected 2, got %d)", len(args)))
return 1
}
// Grab the source and destination
source := ensureTrailingSlash(args[0])
destination := ensureTrailingSlash(args[1])
client, err := c.Client()
if err != nil {
c.UI.Error(err.Error())
return 2
}
if err := client.Sys().Remount(source, destination); err != nil {
c.UI.Error(fmt.Sprintf("Error remounting %s to %s: %s", source, destination, err))
return 2
}
c.UI.Output(fmt.Sprintf("Success! Remounted %s to: %s", source, destination))
return 0
}
func (c *RemountCommand) Synopsis() string {
return "Remount a secret backend to a new path"
}
func (c *RemountCommand) Help() string {
helpText := `
Usage: vault remount [options] from to
Remount a mounted secret backend to a new path.
This command remounts a secret backend that is already mounted to
a new path. All the secrets from the old path will be revoked, but
the data associated with the backend (such as configuration), will
be preserved.
Example: vault remount secret/ kv/
General Options:
` + meta.GeneralOptionsUsage()
return strings.TrimSpace(helpText)
}

64
command/server.go
View File

@ -8,14 +8,12 @@ import (
"net/http"
"net/url"
"os"
"os/signal"
"path/filepath"
"runtime"
"sort"
"strconv"
"strings"
"sync"
"syscall"
"time"
"golang.org/x/net/http2"
@ -84,6 +82,8 @@ type ServerCommand struct {
flagDevPluginDir string
flagDevHA bool
flagDevLatency int
flagDevLatencyJitter int
flagDevTransactional bool
flagDevLeasedKV bool
flagDevThreeNode bool
@ -204,8 +204,20 @@ func (c *ServerCommand) Flags() *FlagSets {
Hidden: true,
})
f.IntVar(&IntVar{
Name: "dev-latency",
Target: &c.flagDevLatency,
Hidden: true,
})
f.IntVar(&IntVar{
Name: "dev-latency-jitter",
Target: &c.flagDevLatencyJitter,
Hidden: true,
})
f.BoolVar(&BoolVar{
Name: "dev-leased-generic",
Name: "dev-leased-kv",
Target: &c.flagDevLeasedKV,
Default: false,
Hidden: true,
@ -442,12 +454,12 @@ func (c *ServerCommand) Run(args []string) int {
if devPluginDir != "" {
coreConfig.PluginDirectory = devPluginDir
}
if devLatency > 0 {
injectLatency := time.Duration(devLatency) * time.Millisecond
if c.flagDevLatency > 0 {
injectLatency := time.Duration(c.flagDevLatency) * time.Millisecond
if _, txnOK := backend.(physical.Transactional); txnOK {
coreConfig.Physical = physical.NewTransactionalLatencyInjector(backend, injectLatency, devLatencyJitter, c.logger)
coreConfig.Physical = physical.NewTransactionalLatencyInjector(backend, injectLatency, c.flagDevLatencyJitter, c.logger)
} else {
coreConfig.Physical = physical.NewLatencyInjector(backend, injectLatency, devLatencyJitter, c.logger)
coreConfig.Physical = physical.NewLatencyInjector(backend, injectLatency, c.flagDevLatencyJitter, c.logger)
}
}
}
@ -859,13 +871,13 @@ CLUSTER_SYNTHESIS_COMPLETE:
// Write out the PID to the file now that server has successfully started
if err := c.storePidFile(config.PidFile); err != nil {
c.Ui.Output(fmt.Sprintf("Error storing PID: %v", err))
c.UI.Error(fmt.Sprintf("Error storing PID: %s", err))
return 1
}
defer func() {
if err := c.removePidFile(config.PidFile); err != nil {
c.Ui.Output(fmt.Sprintf("Error deleting the PID file: %v", err))
c.UI.Error(fmt.Sprintf("Error deleting the PID file: %s", err))
}
}()
@ -1456,6 +1468,8 @@ func (c *ServerCommand) AutocompleteFlags() complete.Flags {
"-dev-listen-address": complete.PredictNothing,
"-log-level": complete.PredictSet("trace", "debug", "info", "warn", "err"),
}
return reloadErrors.ErrorOrNil()
}
// storePidFile is used to write out our PID to a file if necessary
@ -1489,38 +1503,6 @@ func (c *ServerCommand) removePidFile(pidPath string) error {
return os.Remove(pidPath)
}
// MakeShutdownCh returns a channel that can be used for shutdown
// notifications for commands. This channel will send a message for every
// SIGINT or SIGTERM received.
func MakeShutdownCh() chan struct{} {
resultCh := make(chan struct{})
shutdownCh := make(chan os.Signal, 4)
signal.Notify(shutdownCh, os.Interrupt, syscall.SIGTERM)
go func() {
<-shutdownCh
close(resultCh)
}()
return resultCh
}
// MakeSighupCh returns a channel that can be used for SIGHUP
// reloading. This channel will send a message for every
// SIGHUP received.
func MakeSighupCh() chan struct{} {
resultCh := make(chan struct{})
signalCh := make(chan os.Signal, 4)
signal.Notify(signalCh, syscall.SIGHUP)
go func() {
for {
<-signalCh
resultCh <- struct{}{}
}
}()
return resultCh
}
type grpclogFaker struct {
logger log.Logger
log bool

2
website/source/_ember_steps.html.erb
View File

@ -95,7 +95,7 @@
<script type="text/x-handlebars" data-template-name="secrets">
<p>
Now that Vault has been set-up, we can start reading and writing secrets
with the default mounted secret backend. Secrets written to Vault
with the default enabled secrets engine. Secrets written to Vault
are encrypted and then written to the backend storage.
The backend storage mechanism never sees the unencrypted
value and doesn't have the means necessary to decrypt

22
website/source/api/secret/aws/index.html.md
View File

@ -1,19 +1,19 @@
---
layout: "api"
page_title: "AWS Secret Backend - HTTP API"
page_title: "AWS - Secrets Engines - HTTP API"
sidebar_current: "docs-http-secret-aws"
description: |-
This is the API documentation for the Vault AWS secret backend.
This is the API documentation for the Vault AWS secrets engine.
---
# AWS Secret Backend HTTP API
# AWS Secrets Engine (API)
This is the API documentation for the Vault AWS secret backend. For general
information about the usage and operation of the AWS backend, please see the
[Vault AWS backend documentation](/docs/secrets/aws/index.html).
This is the API documentation for the Vault AWS secrets engine. For general
information about the usage and operation of the AWS secrets engine, please see
the [Vault AWS documentation](/docs/secrets/aws/index.html).
This documentation assumes the AWS backend is mounted at the `/aws` path in
Vault. Since it is possible to mount secret backends at any location, please
This documentation assumes the AWS secrets engine is enabled at the `/aws` path
in Vault. Since it is possible to enable secrets engines at any location, please
update your API calls accordingly.
## Configure Root IAM Credentials
@ -74,7 +74,7 @@ $ curl \
## Configure Lease
This endpoint configures lease settings for the AWS secret backend. It is
This endpoint configures lease settings for the AWS secrets engine. It is
optional, as there are default values for `lease` and `lease_max`.
| Method | Path | Produces |
@ -111,7 +111,7 @@ $ curl \
## Read Lease
This endpoint returns the current lease settings for the AWS secret backend.
This endpoint returns the current lease settings for the AWS secrets engine.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
@ -231,7 +231,7 @@ For an ARN:
## List Roles
This endpoint lists all existing roles in the backend.
This endpoint lists all existing roles in the secrets engine.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |

12
website/source/api/secret/cassandra/index.html.md
View File

@ -1,25 +1,25 @@
---
layout: "api"
page_title: "Cassandra Secret Backend - HTTP API"
page_title: "Cassandra - Secrets Engines - HTTP API"
sidebar_current: "docs-http-secret-cassandra"
description: |-
This is the API documentation for the Vault Cassandra secret backend.
This is the API documentation for the Vault Cassandra secrets engine.
---
# Cassandra Secret Backend HTTP API
# Cassandra Secrets Engine (API)
~> **Deprecation Note:** This backend is deprecated in favor of the
combined databases backend added in v0.7.1. See the API documentation for
the new implementation of this backend at
[Cassandra Database Plugin HTTP API](/api/secret/databases/cassandra.html).
[Cassandra database plugin HTTP API](/api/secret/databases/cassandra.html).
This is the API documentation for the Vault Cassandra secret backend. For
This is the API documentation for the Vault Cassandra secrets engine. For
general information about the usage and operation of the Cassandra backend,
please see the
[Vault Cassandra backend documentation](/docs/secrets/cassandra/index.html).
This documentation assumes the Cassandra backend is mounted at the `/cassandra`
path in Vault. Since it is possible to mount secret backends at any location,
path in Vault. Since it is possible to mount secrets engines at any location,
please update your API calls accordingly.
## Configure Connection

20
website/source/api/secret/consul/index.html.md
View File

@ -1,20 +1,20 @@
---
layout: "api"
page_title: "Consul Secret Backend - HTTP API"
page_title: "Consul - Secrets Engines - HTTP API"
sidebar_current: "docs-http-secret-consul"
description: |-
This is the API documentation for the Vault Consul secret backend.
This is the API documentation for the Vault Consul secrets engine.
---
# Consul Secret Backend HTTP API
# Consul Secrets Engine (API)
This is the API documentation for the Vault Consul secret backend. For general
information about the usage and operation of the Consul backend, please see the
[Vault Consul backend documentation](/docs/secrets/consul/index.html).
This is the API documentation for the Vault Consul secrets engine. For general
information about the usage and operation of the Consul secrets engine, please
see the [Vault Consul documentation](/docs/secrets/consul/index.html).
This documentation assumes the Consul backend is mounted at the `/consul` path
in Vault. Since it is possible to mount secret backends at any location, please
update your API calls accordingly.
This documentation assumes the Consul secrets engine is enabled at the `/consul`
path in Vault. Since it is possible to enable secrets engines at any location,
please update your API calls accordingly.
## Configure Access
@ -147,7 +147,7 @@ $ curl \
## List Roles
This endpoint lists all existing roles in the backend.
This endpoint lists all existing roles in the secrets engine.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |

20
website/source/api/secret/cubbyhole/index.html.md
View File

@ -1,21 +1,21 @@
---
layout: "api"
page_title: "Cubbyhole Secret Backend - HTTP API"
page_title: "Cubbyhole - Secrets Engines - HTTP API"
sidebar_current: "docs-http-secret-cubbyhole"
description: |-
This is the API documentation for the Vault Cubbyhole secret backend.
This is the API documentation for the Vault Cubbyhole secrets engine.
---
# Cubbyhole Secret Backend HTTP API
# Cubbyhole Secrets Engine (API)
This is the API documentation for the Vault Cubbyhole secret backend. For
general information about the usage and operation of the Cubbyhole backend,
please see the
[Vault Cubbyhole backend documentation](/docs/secrets/cubbyhole/index.html).
This is the API documentation for the Vault Cubbyhole secrets engine. For
general information about the usage and operation of the Cubbyhole secrets
engine, please see the
[Vault Cubbyhole documentation](/docs/secrets/cubbyhole/index.html).
This documentation assumes the Cubbyhole backend is mounted at the `/cubbyhole`
path in Vault. Since it is possible to mount secret backends at any location,
please update your API calls accordingly.
This documentation assumes the Cubbyhole secrets engine is enabled at the
`/cubbyhole` path in Vault. Since it is possible to enable secrets engines at
any location, please update your API calls accordingly.
## Read Secret

18
website/source/api/secret/databases/cassandra.html.md
View File

@ -1,21 +1,21 @@
---
layout: "api"
page_title: "Cassandra Database Plugin - HTTP API"
page_title: "Cassandra - Database - Secrets Engines - HTTP API"
sidebar_current: "docs-http-secret-databases-cassandra"
description: |-
The Cassandra plugin for Vault's Database backend generates database credentials to access Cassandra servers.
The Cassandra plugin for Vault's database secrets engine generates database credentials to access Cassandra servers.
---
# Cassandra Database Plugin HTTP API
The Cassandra Database Plugin is one of the supported plugins for the Database
backend. This plugin generates database credentials dynamically based on
The Cassandra database plugin is one of the supported plugins for the database
secrets engine. This plugin generates database credentials dynamically based on
configured roles for the Cassandra database.
## Configure Connection
In addition to the parameters defined by the [Database
Backend](/api/secret/databases/index.html#configure-connection), this plugin
Secrets Engine](/api/secret/databases/index.html#configure-connection), this plugin
has a number of parameters to further configure a connection.
| Method | Path | Produces |
@ -48,7 +48,7 @@ has a number of parameters to further configure a connection.
- `pem_json` `(string: "")` – Specifies JSON containing a certificate and
private key; a certificate, private key, and issuing CA certificate; or just a
CA certificate. For convenience format is the same as the output of the
`issue` command from the `pki` backend; see
`issue` command from the `pki` secrets engine; see
[the pki documentation](/docs/secrets/pki/index.html).
- `protocol_version` `(int: 2)` – Specifies the CQL protocol version to use.
@ -74,7 +74,7 @@ TLS works as follows:
`pem_bundle` should be a PEM-concatenated bundle of a private key + client
certificate, an issuing CA certificate, or both. `pem_json` should contain the
same information; for convenience, the JSON format is the same as that output by
the issue command from the PKI backend.
the issue command from the PKI secrets engine.
### Sample Payload
@ -103,7 +103,7 @@ $ curl \
Statements are configured during role creation and are used by the plugin to
determine what is sent to the datatabse on user creation, renewing, and
revocation. For more information on configuring roles see the [Role
API](/api/secret/databases/index.html#create-role) in the Database Backend docs.
API](/api/secret/databases/index.html#create-role) in the database secrets engine docs.
### Parameters
@ -129,4 +129,4 @@ list the plugin does not support that statement type.
semicolon-separated string, a base64-encoded semicolon-separated string, a
serialized JSON string array, or a base64-encoded serialized JSON string
array. The '{{name}}' value will be substituted. If not provided, defaults to
a generic drop user statement
a generic drop user statement

14
website/source/api/secret/databases/hanadb.html.md
View File

@ -1,21 +1,21 @@
---
layout: "api"
page_title: "HANA Database Plugin - HTTP API"
page_title: "HANA - Database - Secrets Engines - HTTP API"
sidebar_current: "docs-http-secret-databases-hana"
description: |-
The HANA plugin for Vault's Database backend generates database credentials to access HANA servers.
The HANA plugin for Vault's database secrets engine generates database credentials to access HANA servers.
---
# HANA Database Plugin HTTP API
The HANA Database Plugin is one of the supported plugins for the Database
backend. This plugin generates database credentials dynamically based on
The HANA database plugin is one of the supported plugins for the database
secrets engine. This plugin generates database credentials dynamically based on
configured roles for the HANA database.
## Configure Connection
In addition to the parameters defined by the [Database
Backend](/api/secret/databases/index.html#configure-connection), this plugin
In addition to the parameters defined by the [database
secrets engine](/api/secret/databases/index.html#configure-connection), this plugin
has a number of parameters to further configure a connection.
| Method | Path | Produces |
@ -63,7 +63,7 @@ $ curl \
Statements are configured during role creation and are used by the plugin to
determine what is sent to the datatabse on user creation, renewing, and
revocation. For more information on configuring roles see the [Role
API](/api/secret/databases/index.html#create-role) in the Database Backend docs.
API](/api/secret/databases/index.html#create-role) in the database secrets engine docs.
### Parameters

22
website/source/api/secret/databases/index.html.md
View File

@ -1,21 +1,21 @@
---
layout: "api"
page_title: "Databases - HTTP API"
page_title: "Database - Secrets Engines - HTTP API"
sidebar_current: "docs-http-secret-databases"
description: |-
Top page for database secret backend information
Top page for database secrets engine information
---
# Database Secret Backend HTTP API
# Database Secrets Engine (API)
This is the API documentation for the Vault Database secret backend. For
general information about the usage and operation of the Database backend,
This is the API documentation for the Vault Database secrets engine. For
general information about the usage and operation of the database secrets engine,
please see the
[Vault Database backend documentation](/docs/secrets/databases/index.html).
[Vault database secrets engine documentation](/docs/secrets/databases/index.html).
This documentation assumes the Database backend is mounted at the
`/database` path in Vault. Since it is possible to mount secret backends at
any location, please update your API calls accordingly.
This documentation assumes the database secrets engine is enabled at the
`/database` path in Vault. Since it is possible to enable secrets engines at any
location, please update your API calls accordingly.
## Configure Connection
@ -164,11 +164,11 @@ This endpoint creates or updates a role definition.
- `default_ttl` `(string/int: 0)` - Specifies the TTL for the leases
associated with this role. Accepts time suffixed strings ("1h") or an integer
number of seconds. Defaults to system/backend default TTL time.
number of seconds. Defaults to system/engine default TTL time.
- `max_ttl` `(string/int: 0)` - Specifies the maximum TTL for the leases
associated with this role. Accepts time suffixed strings ("1h") or an integer
number of seconds. Defaults to system/backend default TTL time.
number of seconds. Defaults to system/engine default TTL time.
- `creation_statements` `(string: <required>)` – Specifies the database
statements executed to create and configure a user. See the plugin's API page

16
website/source/api/secret/databases/mongodb.html.md
View File

@ -1,15 +1,15 @@
---
layout: "api"
page_title: "MongoDB Database Plugin - HTTP API"
page_title: "MongoDB - Database - Secrets Engines - HTTP API"
sidebar_current: "docs-http-secret-databases-mongodb"
description: |-
The MongoDB plugin for Vault's Database backend generates database credentials to access MongoDB servers.
The MongoDB plugin for Vault's database secrets engine generates database credentials to access MongoDB servers.
---
# MongoDB Database Plugin HTTP API
The MongoDB Database Plugin is one of the supported plugins for the Database
backend. This plugin generates database credentials dynamically based on
The MongoDB database plugin is one of the supported plugins for the database
secrets engine. This plugin generates database credentials dynamically based on
configured roles for the MongoDB database.
## Configure Connection
@ -50,7 +50,7 @@ $ curl \
Statements are configured during role creation and are used by the plugin to
determine what is sent to the datatabse on user creation, renewing, and
revocation. For more information on configuring roles see the [Role
API](/api/secret/databases/index.html#create-role) in the Database Backend docs.
API](/api/secret/databases/index.html#create-role) in the database secrets engine docs.
### Parameters
@ -59,7 +59,7 @@ list the plugin does not support that statement type.
- `creation_statements` `(string: <required>)` – Specifies the database
statements executed to create and configure a user. Must be a
serialized JSON object, or a base64-encoded serialized JSON object.
serialized JSON object, or a base64-encoded serialized JSON object.
The object can optionally contain a "db" string for session connection,
and must contain a "roles" array. This array contains objects that holds
a "role", and an optional "db" value, and is similar to the BSON document that
@ -68,7 +68,7 @@ list the plugin does not support that statement type.
[MongoDB's documentation](https://docs.mongodb.com/manual/reference/method/db.createUser/).
- `revocation_statements` `(string: "")` – Specifies the database statements to
be executed to revoke a user. Must be a serialized JSON object, or a base64-encoded
be executed to revoke a user. Must be a serialized JSON object, or a base64-encoded
serialized JSON object. The object can optionally contain a "db" string. If no
"db" value is provided, it defaults to the "admin" database.
@ -84,4 +84,4 @@ list the plugin does not support that statement type.
}
]
}
```
```

10
website/source/api/secret/databases/mssql.html.md
View File

@ -1,15 +1,15 @@
---
layout: "api"
page_title: "MSSQL Database Plugin - HTTP API"
page_title: "MSSQL - Database - Secrets Engines - HTTP API"
sidebar_current: "docs-http-secret-databases-mssql"
description: |-
The MSSQL plugin for Vault's Database backend generates database credentials to access MSSQL servers.
The MSSQL plugin for Vault's database secrets engine generates database credentials to access MSSQL servers.
---
# MSSQL Database Plugin HTTP API
The MSSQL Database Plugin is one of the supported plugins for the Database
backend. This plugin generates database credentials dynamically based on
The MSSQL database plugin is one of the supported plugins for the database
secrets engine. This plugin generates database credentials dynamically based on
configured roles for the MSSQL database.
## Configure Connection
@ -63,7 +63,7 @@ $ curl \
Statements are configured during role creation and are used by the plugin to
determine what is sent to the datatabse on user creation, renewing, and
revocation. For more information on configuring roles see the [Role
API](/api/secret/databases/index.html#create-role) in the Database Backend docs.
API](/api/secret/databases/index.html#create-role) in the database secrets engine docs.
### Parameters

10
website/source/api/secret/databases/mysql-maria.html.md
View File

@ -1,15 +1,15 @@
---
layout: "api"
page_title: "MySQL/MariaDB Database Plugin - HTTP API"
page_title: "MySQL/MariaDB - Database - Secrets Engines - HTTP API"
sidebar_current: "docs-http-secret-databases-mysql-maria"
description: |-
The MySQL/MariaDB plugin for Vault's Database backend generates database credentials to access MySQL and MariaDB servers.
The MySQL/MariaDB plugin for Vault's database secrets engine generates database credentials to access MySQL and MariaDB servers.
---
# MySQL/MariaDB Database Plugin HTTP API
The MySQL Database Plugin is one of the supported plugins for the Database
backend. This plugin generates database credentials dynamically based on
The MySQL database plugin is one of the supported plugins for the database
secrets engine. This plugin generates database credentials dynamically based on
configured roles for the MySQL database.
## Configure Connection
@ -63,7 +63,7 @@ $ curl \
Statements are configured during role creation and are used by the plugin to
determine what is sent to the datatabse on user creation, renewing, and
revocation. For more information on configuring roles see the [Role
API](/api/secret/databases/index.html#create-role) in the Database Backend docs.
API](/api/secret/databases/index.html#create-role) in the database secrets engine docs.
### Parameters

10
website/source/api/secret/databases/oracle.html.md
View File

@ -1,15 +1,15 @@
---
layout: "api"
page_title: "Oracle Database Plugin - HTTP API"
page_title: "Oracle - Database - Secrets Engines - HTTP API"
sidebar_current: "docs-http-secret-databases-oracle-maria"
description: |-
The Oracle plugin for Vault's Database backend generates database credentials to access Oracle servers.
The Oracle plugin for Vault's database secrets engine generates database credentials to access Oracle servers.
---
# Oracle Database Plugin HTTP API
The Oracle Database Plugin is one of the supported plugins for the Database
backend. This plugin generates database credentials dynamically based on
The Oracle database plugin is one of the supported plugins for the database
secrets engine. This plugin generates database credentials dynamically based on
configured roles for the Oracle database.
## Configure Connection
@ -63,7 +63,7 @@ $ curl \
Statements are configured during role creation and are used by the plugin to
determine what is sent to the datatabse on user creation, renewing, and
revocation. For more information on configuring roles see the [Role
API](/api/secret/databases/index.html#create-role) in the Database Backend docs.
API](/api/secret/databases/index.html#create-role) in the database secrets engine docs.
### Parameters

10
website/source/api/secret/databases/postgresql.html.md
View File

@ -1,15 +1,15 @@
---
layout: "api"
page_title: "PostgreSQL Database Plugin - HTTP API"
page_title: "PostgreSQL - Database - Secrets Engines - HTTP API"
sidebar_current: "docs-http-secret-databases-postgresql"
description: |-
The PostgreSQL plugin for Vault's Database backend generates database credentials to access PostgreSQL servers.
The PostgreSQL plugin for Vault's database secrets engine generates database credentials to access PostgreSQL servers.
---
# PostgreSQL Database Plugin HTTP API
The PostgreSQL Database Plugin is one of the supported plugins for the Database
backend. This plugin generates database credentials dynamically based on
The PostgreSQL database plugin is one of the supported plugins for the database
secrets engine. This plugin generates database credentials dynamically based on
configured roles for the PostgreSQL database.
## Configure Connection
@ -63,7 +63,7 @@ $ curl \
Statements are configured during role creation and are used by the plugin to
determine what is sent to the datatabse on user creation, renewing, and
revocation. For more information on configuring roles see the [Role
API](/api/secret/databases/index.html#create-role) in the Database Backend docs.
API](/api/secret/databases/index.html#create-role) in the database secrets engine docs.
### Parameters

27
website/source/api/secret/identity/index.html.md
View File

@ -1,17 +1,16 @@
---
layout: "api"
page_title: "Identity Secret Backend - HTTP API"
page_title: "Identity - Secrets Engines - HTTP API"
sidebar_current: "docs-http-secret-identity"
description: |-
This is the API documentation for the Vault Identity secret backend.
This is the API documentation for the Vault Identity secrets engine.
---
# Identity Secret Backend HTTP API
# Identity Secrets Engine (API)
This is the API documentation for the Vault Identity secret backend. For
general information about the usage and operation of the Identity backend,
please see the
[Vault Identity backend documentation](/docs/secrets/identity/index.html).
This is the API documentation for the Vault Identity secrets engine. For general
information about the usage and operation of the Identity secrets engine, please
see the [Vault Identity documentation](/docs/secrets/identity/index.html).
## Register Entity
@ -219,11 +218,11 @@ given identifier.
### Parameters
- `name` (string: Required) - Name of the persona. Name should be the
identifier of the client in the authentication source. For example, if the
persona belongs to userpass backend, the name should be a valid username
within userpass backend. If persona belongs to GitHub, it should be the
GitHub username.
- `name` (string: Required) - Name of the persona. Name should be the identifier
of the client in the authentication source. For example, if the persona
belongs to userpass auth method, the name should be a valid username within
userpass auth method. If persona belongs to GitHub, it should be the GitHub
username.
- `entity_id` (string: required) - Entity ID to which this persona belongs to.
@ -319,8 +318,8 @@ This endpoint is used to update an existing persona.
- `name` (string: Required) - Name of the persona. Name should be the
identifier of the client in the authentication source. For example, if the
persona belongs to userpass backend, the name should be a valid username
within userpass backend. If persona belongs to GitHub, it should be the
persona belongs to userpass auth method, the name should be a valid username
within userpass auth method. If persona belongs to GitHub, it should be the
GitHub username.
- `entity_id` (string: required) - Entity ID to which this persona belongs to.

19
website/source/api/secret/index.html.md
View File

@ -1,19 +1,18 @@
---
layout: "api"
page_title: "HTTP API"
page_title: "Secrets Engines - HTTP API"
sidebar_current: "docs-http-secret"
description: |-
Each secret backend publishes its own set of API paths and methods. These
Each secrets engine publishes its own set of API paths and methods. These
endpoints are documented in this section.
---
# Secret Backends
# Secrets Engines
Each secret backend publishes its own set of API paths and methods. These
endpoints are documented in this section. Secret backends are mounted at a path,
but the documentation will assume the default mount points for simplicity. If
you are mounting at a different path, you should adjust your API calls
accordingly.
Each secrets engine publishes its own set of API paths and methods. These
endpoints are documented in this section. secrets engines are enabled at a path,
but the documentation will assume the default paths for simplicity. If you are
enabled at a different path, you should adjust your API calls accordingly.
For the API documentation for a specific secret backend, please choose a secret
backend from the navigation.
For the API documentation for a specific secrets engine, please choose a secrets
engine from the navigation.

26
website/source/api/secret/kv/index.html.md
View File

@ -1,20 +1,20 @@
---
layout: "api"
page_title: "Key/Value Secret Backend - HTTP API"
page_title: "KV - Secrets Engines - HTTP API"
sidebar_current: "docs-http-secret-kv"
description: |-
This is the API documentation for the Vault Key/Value secret backend.
This is the API documentation for the Vault KV secrets engine.
---
# Key/Value Secret Backend HTTP API
# KV Secrets Engine (API)
This is the API documentation for the Vault Key/Value secret backend. For general
information about the usage and operation of the Key/Value backend, please see
the [Vault Key/Value backend documentation](/docs/secrets/kv/index.html).
This is the API documentation for the Vault KV secrets engine. For general
information about the usage and operation of the kv secrets engine, please
see the [Vault kv documentation](/docs/secrets/kv/index.html).
This documentation assumes the Key/Value backend is mounted at the `/secret`
path in Vault. Since it is possible to mount secret backends at any location,
please update your API calls accordingly.
This documentation assumes the kv secrets engine is enabled at the
`/secret` path in Vault. Since it is possible to enable secrets engines at any
location, please update your API calls accordingly.
## Read Secret
@ -53,9 +53,9 @@ $ curl \
_Note_: the `lease_duration` field (which on the CLI shows as
`refresh_interval`) is advisory. No lease is created. This is a way for writers
to indicate how often a given value shold be re-read by the client. See the
[Vault Key/Value backend documentation](/docs/secrets/kv/index.html) for
more details.
to indicate how often a given value should be re-read by the client. See the
[Vault KV secrets engine documentation](/docs/secrets/kv/index.html)
for more details.
## List Secrets
@ -121,7 +121,7 @@ policy granting the `update` capability.
- `:key` `(string: "")` – Specifies a key, paired with an associated value, to
be held at the given location. Multiple key/value pairs can be specified, and
all will be returned on a read operation. A key called `ttl` will trigger
some special behavior; see the [Vault Key/Value backend
some special behavior. See the [Vault KV secrets engine
documentation](/docs/secrets/kv/index.html) for details.
### Sample Payload

29
website/source/api/secret/mongodb/index.html.md
View File

@ -1,25 +1,26 @@
---
layout: "api"
page_title: "MongoDB Secret Backend - HTTP API"
page_title: "MongoDB - Secrets Engines - HTTP API"
sidebar_current: "docs-http-secret-mongodb"
description: |-
This is the API documentation for the Vault MongoDB secret backend.
This is the API documentation for the Vault MongoDB secrets engine.
---
# MongoDB Secret Backend HTTP API
# MongoDB Secrets Engine (API)
~> **Deprecation Note:** This backend is deprecated in favor of the
combined databases backend added in v0.7.1. See the API documentation for
the new implementation of this backend at
[MongoDB Database Plugin HTTP API](/api/secret/databases/mongodb.html).
~> **Deprecation Note:** This secrets engine is deprecated in favor of the
combined databases secrets engine added in v0.7.1. See the API documentation for
the new implementation of this secrets engine at
[MongoDB database plugin HTTP API](/api/secret/databases/mongodb.html).
This is the API documentation for the Vault MongoDB secret backend. For general
information about the usage and operation of the MongoDB backend, please see
the [Vault MongoDB backend documentation](/docs/secrets/mongodb/index.html).
This is the API documentation for the Vault MongoDB secrets engine. For general
information about the usage and operation of the MongoDB secrets engine, please
see the
[Vault MongoDB secrets engine documentation](/docs/secrets/mongodb/index.html).
This documentation assumes the MongoDB backend is mounted at the `/mongodb`
path in Vault. Since it is possible to mount secret backends at any location,
please update your API calls accordingly.
This documentation assumes the MongoDB secrets engine is enabled at the
`/mongodb` path in Vault. Since it is possible to enable secrets engines at any
location, please update your API calls accordingly.
## Configure Connection
@ -109,7 +110,7 @@ $ curl \
## Configure Lease
This endpoint configures the default lease TTL settings for credentials
generated by the mongodb backend.
generated by the mongodb secrets engine.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |

24
website/source/api/secret/mssql/index.html.md
View File

@ -1,24 +1,24 @@
---
layout: "api"
page_title: "MSSQL Secret Backend - HTTP API"
page_title: "MSSQL - Secrets Engines - HTTP API"
sidebar_current: "docs-http-secret-mssql"
description: |-
This is the API documentation for the Vault MSSQL secret backend.
This is the API documentation for the Vault MSSQL secrets engine.
---
# MSSQL Secret Backend HTTP API
# MSSQL Secrets Engine (API)
~> **Deprecation Note:** This backend is deprecated in favor of the
combined databases backend added in v0.7.1. See the API documentation for
the new implementation of this backend at
[MSSQL Database Plugin HTTP API](/api/secret/databases/mssql.html).
~> **Deprecation Note:** This secrets engine is deprecated in favor of the
combined databases secrets engine added in v0.7.1. See the API documentation for
the new implementation of this secrets engine at
[MSSQL database plugin HTTP API](/api/secret/databases/mssql.html).
This is the API documentation for the Vault MSSQL secret backend. For general
information about the usage and operation of the MSSQL backend, please see
the [Vault MSSQL backend documentation](/docs/secrets/mssql/index.html).
This is the API documentation for the Vault MSSQL secrets engine. For general
information about the usage and operation of the MSSQL secrets engine, please
see the [Vault MSSQL documentation](/docs/secrets/mssql/index.html).
This documentation assumes the MSSQL backend is mounted at the `/mssql`
path in Vault. Since it is possible to mount secret backends at any location,
This documentation assumes the MSSQL secrets engine is enabled at the `/mssql`
path in Vault. Since it is possible to enable secrets engines at any location,
please update your API calls accordingly.
## Configure Connection

24
website/source/api/secret/mysql/index.html.md
View File

@ -1,24 +1,24 @@
---
layout: "api"
page_title: "MySQL Secret Backend - HTTP API"
page_title: "MySQL - Secrets Engines - HTTP API"
sidebar_current: "docs-http-secret-mysql"
description: |-
This is the API documentation for the Vault MySQL secret backend.
This is the API documentation for the Vault MySQL secrets engine.
---
# MySQL Secret Backend HTTP API
# MySQL Secrets Engine (API)
~> **Deprecation Note:** This backend is deprecated in favor of the
combined databases backend added in v0.7.1. See the API documentation for
the new implementation of this backend at
[MySQL/MariaDB Database Plugin HTTP API](/api/secret/databases/mysql-maria.html).
~> **Deprecation Note:** This secrets engine is deprecated in favor of the
combined databases secrets engine added in v0.7.1. See the API documentation for
the new implementation of this secrets engine at
[MySQL/MariaDB database plugin HTTP API](/api/secret/databases/mysql-maria.html).
This is the API documentation for the Vault MySQL secret backend. For general
information about the usage and operation of the MySQL backend, please see
the [Vault MySQL backend documentation](/docs/secrets/mysql/index.html).
This is the API documentation for the Vault MySQL secrets engine. For general
information about the usage and operation of the MySQL secrets engine, please
see the [Vault MySQL documentation](/docs/secrets/mysql/index.html).
This documentation assumes the MySQL backend is mounted at the `/mysql`
path in Vault. Since it is possible to mount secret backends at any location,
This documentation assumes the MySQL secrets engine is enabled at the `/mysql`
path in Vault. Since it is possible to enable secrets engines at any location,
please update your API calls accordingly.
## Configure Connection

42
website/source/api/secret/pki/index.html.md
View File

@ -1,19 +1,19 @@
---
layout: "api"
page_title: "PKI Secret Backend - HTTP API"
page_title: "PKI - Secrets Engines - HTTP API"
sidebar_current: "docs-http-secret-pki"
description: |-
This is the API documentation for the Vault PKI secret backend.
This is the API documentation for the Vault PKI secrets engine.
---
# PKI Secret Backend HTTP API
# PKI Secrets Engine (API)
This is the API documentation for the Vault PKI secret backend. For general
information about the usage and operation of the PKI backend, please see the
[Vault PKI backend documentation](/docs/secrets/pki/index.html).
This is the API documentation for the Vault PKI secrets engine. For general
information about the usage and operation of the PKI secrets engine, please see
the [PKI documentation](/docs/secrets/pki/index.html).
This documentation assumes the PKI backend is mounted at the `/pki` path in
Vault. Since it is possible to mount secret backends at any location, please
This documentation assumes the PKI secrets engine is enabled at the `/pki` path
in Vault. Since it is possible to enable secrets engines at any location, please
update your API calls accordingly.
## Table of Contents
@ -172,10 +172,10 @@ $ curl \
## Submit CA Information
This endpoint allows submitting the CA information for the backend via a PEM
file containing the CA certificate and its private key, concatenated. Not needed
if you are generating a self-signed root certificate, and not used if you have a
signed intermediate CA certificate with a generated key (use the
This endpoint allows submitting the CA information for the secrets engine via a
PEM file containing the CA certificate and its private key, concatenated. Not
needed if you are generating a self-signed root certificate, and not used if you
have a signed intermediate CA certificate with a generated key (use the
`/pki/intermediate/set-signed` endpoint for that). _If you have already set a
certificate and key, they will be overridden._
@ -893,9 +893,9 @@ As with other issued certificates, Vault will automatically revoke the
generated root at the end of its lease period; the CA certificate will sign its
own CRL.
As of Vault 0.8.1, if a CA cert/key already exists within the backend, this
function will return a 204 and will not overwrite it. Previous versions of
Vault would overwrite the existing cert/key with new values.
As of Vault 0.8.1, if a CA cert/key already exists, this function will return a
204 and will not overwrite it. Previous versions of Vault would overwrite the
existing cert/key with new values.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
@ -920,8 +920,8 @@ Vault would overwrite the existing cert/key with new values.
Names, in a comma-delimited list.
- `ttl` `(string: "")` – Specifies the requested Time To Live (after which the
certificate will be expired). This cannot be larger than the mount max (or, if
not set, the system max).
certificate will be expired). This cannot be larger than the engine's max (or,
if not set, the system max).
- `format` `(string: "pem")` – Specifies the format for returned data. Can be
`pem`, `der`, or `pem_bundle`. If `der`, the output is base64 encoded. If
@ -1033,8 +1033,8 @@ verbatim.
Names, in a comma-delimited list.
- `ttl` `(string: "")` – Specifies the requested Time To Live (after which the
certificate will be expired). This cannot be larger than the mount max (or, if
not set, the system max). However, this can be after the expiration of the
certificate will be expired). This cannot be larger than the engine's max (or,
if not set, the system max). However, this can be after the expiration of the
signing CA.
- `format` `(string: "pem")` – Specifies the format for returned data. Can be
@ -1255,7 +1255,7 @@ have access.**
- `csr` `(string: <required>)` – Specifies the PEM-encoded CSR.
- `ttl` `(string: "")` – Specifies the requested Time To Live. Cannot be greater
than the mount's `max_ttl` value. If not provided, the mount's `ttl` value
than the engine's `max_ttl` value. If not provided, the engine's `ttl` value
will be used, which defaults to system values if not explicitly set.
- `format` `(string: "pem")` – Specifies the format for returned data. Can be
@ -1301,7 +1301,7 @@ $ curl \
## Tidy
This endpoint allows tidying up the backend storage and/or CRL by removing
This endpoint allows tidying up the storage backend and/or CRL by removing
certificates that have expired and are past a certain buffer period beyond their
expiration time.

26
website/source/api/secret/postgresql/index.html.md
View File

@ -1,25 +1,25 @@
---
layout: "api"
page_title: "PostgreSQL Secret Backend - HTTP API"
page_title: "PostgreSQL - Secrets Engines - HTTP API"
sidebar_current: "docs-http-secret-postgresql"
description: |-
This is the API documentation for the Vault PostgreSQL secret backend.
This is the API documentation for the Vault PostgreSQL secrets engine.
---
# PostgreSQL Secret Backend HTTP API
# PostgreSQL Secrets Engine (API)
~> **Deprecation Note:** This backend is deprecated in favor of the
combined databases backend added in v0.7.1. See the API documentation for
the new implementation of this backend at
[PostgreSQL Database Plugin HTTP API](/api/secret/databases/postgresql.html).
~> **Deprecation Note:** This secrets engine is deprecated in favor of the
combined databases secrets engine added in v0.7.1. See the API documentation for
the new implementation of this secrets engine at
[PostgreSQL database plugin HTTP API](/api/secret/databases/postgresql.html).
This is the API documentation for the Vault PostgreSQL secret backend. For
general information about the usage and operation of the PostgreSQL backend,
please see the
[Vault PostgreSQL backend documentation](/docs/secrets/postgresql/index.html).
This is the API documentation for the Vault PostgreSQL secrets engine. For
general information about the usage and operation of the PostgreSQL secrets
engine, please see the [PostgreSQL
documentation](/docs/secrets/postgresql/index.html).
This documentation assumes the PostgreSQL backend is mounted at the
`/postgresql` path in Vault. Since it is possible to mount secret backends at
This documentation assumes the PostgreSQL secrets engine is enabled at the
`/postgresql` path in Vault. Since it is possible to enable secrets engines at
any location, please update your API calls accordingly.
## Configure Connection

18
website/source/api/secret/rabbitmq/index.html.md
View File

@ -1,20 +1,20 @@
---
layout: "api"
page_title: "RabbitMQ Secret Backend - HTTP API"
page_title: "RabbitMQ - Secrets Engines - HTTP API"
sidebar_current: "docs-http-secret-rabbitmq"
description: |-
This is the API documentation for the Vault RabbitMQ secret backend.
This is the API documentation for the Vault RabbitMQ secrets engine.
---
# RabbitMQ Secret Backend HTTP API
# RabbitMQ Secrets Engine (API)
This is the API documentation for the Vault RabbitMQ secret backend. For general
information about the usage and operation of the RabbitMQ backend, please see
the [Vault RabbitMQ backend documentation](/docs/secrets/rabbitmq/index.html).
This is the API documentation for the Vault RabbitMQ secrets engine. For general
information about the usage and operation of the RabbitMQ secrets engine, please
see the [RabbitMQ documentation](/docs/secrets/rabbitmq/index.html).
This documentation assumes the RabbitMQ backend is mounted at the `/rabbitmq`
path in Vault. Since it is possible to mount secret backends at any location,
please update your API calls accordingly.
This documentation assumes the RabbitMQ secrets engine is enabled at the
`/rabbitmq` path in Vault. Since it is possible to enable secrets engines at any
location, please update your API calls accordingly.
## Configure Connection

20
website/source/api/secret/ssh/index.html.md
View File

@ -1,19 +1,19 @@
---
layout: "api"
page_title: "SSH Secret Backend - HTTP API"
page_title: "SSH - Secrets Engines - HTTP API"
sidebar_current: "docs-http-secret-ssh"
description: |-
This is the API documentation for the Vault SSH secret backend.
This is the API documentation for the Vault SSH secrets engine.
---
# SSH Secret Backend HTTP API
# SSH Secrets Engine (API)
This is the API documentation for the Vault SSH secret backend. For general
information about the usage and operation of the SSH backend, please see the
[Vault SSH backend documentation](/docs/secrets/ssh/index.html).
This is the API documentation for the Vault SSH secrets engine. For general
information about the usage and operation of the SSH secrets engine, please see
the [SSH documentation](/docs/secrets/ssh/index.html).
This documentation assumes the SSH backend is mounted at the `/ssh` path in
Vault. Since it is possible to mount secret backends at any location, please
This documentation assumes the SSH secrets engine is enabled at the `/ssh` path
in Vault. Since it is possible to enable secrets engines at any location, please
update your API calls accordingly.
## Create/Update Key
@ -115,7 +115,7 @@ This endpoint creates or updates a named role.
and certain parts need to be kept out.
- `port` `(int: 22)` – Specifies the port number for SSH connection. Port number
does not play any role in OTP generation. For the `otp` backend type, this is
does not play any role in OTP generation. For the `otp` secrets engine type, this is
just a way to inform the client about the port number to use. The port number
will be returned to the client by Vault along with the OTP.
@ -603,7 +603,7 @@ $ curl \
## Submit CA Information
This endpoint allows submitting the CA information for the backend via an SSH
This endpoint allows submitting the CA information for the secrets engine via an SSH
key pair. _If you have already set a certificate and key, they will be
overridden._

19
website/source/api/secret/totp/index.html.md
View File

@ -1,21 +1,20 @@
---
layout: "api"
page_title: "TOTP Secret Backend - HTTP API"
page_title: "TOTP - Secrets Engines - HTTP API"
sidebar_current: "docs-http-secret-totp"
description: |-
This is the API documentation for the Vault TOTP secret backend.
This is the API documentation for the Vault TOTP secrets engine.
---
# TOTP Secret Backend HTTP API
# TOTP Secrets Engine (API)
This is the API documentation for the Vault TOTP secret backend. For
general information about the usage and operation of the TOTP backend,
please see the
[Vault TOTP backend documentation](/docs/secrets/totp/index.html).
This is the API documentation for the Vault TOTP secrets engine. For general
information about the usage and operation of the TOTP secrets engine, please see
the [TOTP documentation](/docs/secrets/totp/index.html).
This documentation assumes the TOTP backend is mounted at the
`/totp` path in Vault. Since it is possible to mount secret backends at
any location, please update your API calls accordingly.
This documentation assumes the TOTP secrets engine is enabled at the `/totp`
path in Vault. Since it is possible to enable secrets engines at any location,
please update your API calls accordingly.
## Create Key

18
website/source/api/secret/transit/index.html.md
View File

@ -1,20 +1,20 @@
---
layout: "api"
page_title: "Transit Secret Backend - HTTP API"
page_title: "Transit - Secrets Engines - HTTP API"
sidebar_current: "docs-http-secret-transit"
description: |-
This is the API documentation for the Vault Transit secret backend.
This is the API documentation for the Vault Transit secrets engine.
---
# Transit Secret Backend HTTP API
# Transit Secrets Engine (API)
This is the API documentation for the Vault Transit secret backend. For general
information about the usage and operation of the Transit backend, please see the
[Vault Transit backend documentation](/docs/secrets/transit/index.html).
This is the API documentation for the Vault Transit secrets engine. For general
information about the usage and operation of the Transit secrets engine, please
see the [transit documentation](/docs/secrets/transit/index.html).
This documentation assumes the Transit backend is mounted at the `/transit`
path in Vault. Since it is possible to mount secret backends at any location,
please update your API calls accordingly.
This documentation assumes the transit secrets engine is enabled at the
`/transit` path in Vault. Since it is possible to enable secrets engines at any
location, please update your API calls accordingly.
## Create Key

18
website/source/api/system/mounts.html.md
View File

@ -3,16 +3,16 @@ layout: "api"
page_title: "/sys/mounts - HTTP API"
sidebar_current: "docs-http-system-mounts"
description: |-
The `/sys/mounts` endpoint is used manage secret backends in Vault.
The `/sys/mounts` endpoint is used manage secrets engines in Vault.
---
# `/sys/mounts`
The `/sys/mounts` endpoint is used manage secret backends in Vault.
The `/sys/mounts` endpoint is used manage secrets engines in Vault.
## List Mounted Secret Backends
## List Mounted Secrets Engines
This endpoints lists all the mounted secret backends.
This endpoints lists all the mounted secrets engines.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
@ -54,9 +54,9 @@ $ curl \
`default_lease_ttl` or `max_lease_ttl` values of 0 mean that the system defaults
are used by this backend.
## Mount Secret Backend
## Mount Secrets Engine
This endpoint mounts a new secret backend at the given path.
This endpoint mounts a new secrets engine at the given path.
| Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- |
@ -64,7 +64,7 @@ This endpoint mounts a new secret backend at the given path.
### Parameters
- `path` `(string: <required>)` – Specifies the path where the secret backend
- `path` `(string: <required>)` – Specifies the path where the secrets engine
will be mounted. This is specified as part of the URL.
- `type` `(string: <required>)` – Specifies the type of the backend, such as
@ -100,7 +100,7 @@ This endpoint mounts a new secret backend at the given path.
Additionally, the following options are allowed in Vault open-source, but
relevant functionality is only supported in Vault Enterprise:
- `local` `(bool: false)` – Specifies if the secret backend is a local mount
- `local` `(bool: false)` – Specifies if the secrets engine is a local mount
only. Local mounts are not replicated nor (if a secondary) removed by
replication.
@ -125,7 +125,7 @@ $ curl \
https://vault.rocks/v1/sys/mounts/my-mount
```
## Unmount Secret Backend
## Unmount Secrets Engine
This endpoint un-mounts the mount point specified in the URL.

2
website/source/docs/auth/aws.html.md
View File

@ -231,7 +231,7 @@ comparison of the two auth methods.
to handle EC2 instances, such as restricting access to EC2 instances from
a particular AMI, EC2 instances in a particular instance profile, or EC2
instances with a specialized tag value (via the role_tag feature).
* The iam auth method authenticates generic AWS IAM principals. This can
* The iam auth method authenticates AWS IAM principals. This can
include IAM users, IAM roles assumed from other accounts, AWS Lambdas that
are launched in an IAM role, or even EC2 instances that are launched in an
IAM instance profile. However, because it authenticates more generalized IAM

2
website/source/docs/commands/delete.html.md
View File

@ -16,7 +16,7 @@ given path.
## Examples
Remove data in the status secret backend:
Remove data in the status secrets engine:
```text
$ vault delete secret/my-secret

2
website/source/docs/commands/lease/revoke.html.md
View File

@ -35,7 +35,7 @@ flags](/docs/commands/index.html) included on all commands.
- `-force` `(bool: false)` - Delete the lease from Vault even if the secret
engine revocation fails. This is meant for recovery situations where the
secret in the target secret engine was manually removed. If this flag is
secret in the target secrets engine was manually removed. If this flag is
specified, -prefix is also required. This is aliased as "-f". The default is
false.

6
website/source/docs/commands/list.html.md
View File

@ -4,17 +4,17 @@ page_title: "list - Command"
sidebar_current: "docs-commands-list"
description: |-
The "list" command lists data from Vault at the given path. This can be used
to list keys in a, given secret engine.
to list keys in a, given secrets engine.
---
# list
The `list` command lists data from Vault at the given path. This can be used to
list keys in a, given secret engine.
list keys in a, given secrets engine.
## Examples
List values under the "my-app" folder of the generic secret engine:
List values under the "my-app" folder of the KV secrets engine:
```text
$ vault list secret/my-app/

4
website/source/docs/commands/path-help.html.md
View File

@ -31,13 +31,13 @@ exact.
## Examples
Get help output for the generic secrets engine:
Get help output for the KV secrets engine:
```text
$ vault path-help secret
## DESCRIPTION
The generic backend reads and writes arbitrary secrets to the backend.
The KV backend reads and writes arbitrary secrets to the backend.
The secrets are encrypted/decrypted by Vault: they are never stored
unencrypted in the backend and the backend never has an opportunity to
see the unencrypted value.

6
website/source/docs/commands/secrets.html.md
View File

@ -10,7 +10,7 @@ description: |-
# secrets
The `secrets` command groups subcommands for interacting with Vault's secrets
engines. Each secret engine behaves differently. Please see the documentation
engines. Each secrets engine behaves differently. Please see the documentation
for more information.
Some secrets engines persist data, some act as data pass-through, and some
@ -36,7 +36,7 @@ Path Type Description
---- ---- -----------
cubbyhole/ cubbyhole per-token private secret storage
database/ database n/a
secret/ generic generic secret storage
secret/ kv key/value secret storage
sys/ system system endpoints used for control, policy and debugging
```
@ -69,7 +69,7 @@ Usage: vault secrets <subcommand> [options] [args]
# ...
Subcommands:
disable Disable a secret engine
disable Disable a secrets engine
enable Enable a secrets engine
list List enabled secrets engines
move Move a secrets engine to a new path

8
website/source/docs/commands/secrets/list.html.md
View File

@ -3,7 +3,7 @@ layout: "docs"
page_title: "secrets list - Command"
sidebar_current: "docs-commands-secrets-list"
description: |-
The "secrets list" command lists the enabled secret engines on the Vault
The "secrets list" command lists the enabled secrets engines on the Vault
server. This command also outputs information about the enabled path including
configured TTLs and human-friendly descriptions. A TTL of "system" indicates
that the system default is in use.
@ -11,7 +11,7 @@ description: |-
# secrets list
The `secrets list` command lists the enabled secret engines on the Vault server.
The `secrets list` command lists the enabled secrets engines on the Vault server.
This command also outputs information about the enabled path including
configured TTLs and human-friendly descriptions. A TTL of "system" indicates
that the system default is in use.
@ -25,7 +25,7 @@ $ vault secrets list
Path Type Description
---- ---- -----------
cubbyhole/ cubbyhole per-token private secret storage
secret/ generic generic secret storage
secret/ kv key/value secret storage
sys/ system system endpoints used for control, policy and debugging
```
@ -36,7 +36,7 @@ $ vault secrets list -detailed
Path Type Accessor Plugin Default TTL Max TTL Force No Cache Replication Description
---- ---- -------- ------ ----------- ------- -------------- ----------- -----------
cubbyhole/ cubbyhole cubbyhole_10fbb584 n/a n/a n/a false local per-token private secret storage
secret/ generic generic_167ce199 n/a system system false replicated generic secret storage
secret/ kv kv_167ce199 n/a system system false replicated key/value secret storage
sys/ system system_a9fd745d n/a n/a n/a false replicated system endpoints used for control, policy and debugging
```

4
website/source/docs/commands/secrets/move.html.md
View File

@ -19,10 +19,10 @@ engine.**
## Examples
Move the existing secrets engine at secret/ to generic/:
Move the existing secrets engine at secret/ to kv/:
```text
$ vault secrets move secret/ generic/
$ vault secrets move secret/ kv/
```
## Usage

4
website/source/docs/commands/write.html.md
View File

@ -19,11 +19,11 @@ is loaded from a file. If the value is "-", Vault will read the value from
stdin.
For a full list of examples and paths, please see the documentation that
corresponds to the secret engines in use.
corresponds to the secrets engines in use.
## Examples
Persist data in the generic secrets engine:
Persist data in the KV secrets engine:
```text
$ vault write secret/my-secret foo=bar

2
website/source/docs/concepts/dev-server.html.md
View File

@ -44,7 +44,7 @@ The properties of the dev server:
## Use Case
The dev server should be used for experimentation with Vault features, such
as different auth methods, secret backends, audit backends, etc.
as different auth methods, secrets engines, audit backends, etc.
If you're new to Vault, you may want to pick up with [Your First
Secret](/intro/getting-started/first-secret.html) in
our getting started guide.

2
website/source/docs/concepts/lease.html.md
View File

@ -26,7 +26,7 @@ to check in routinely.
In addition to renewals, a lease can be _revoked_. When a lease is revoked, it
invalidates that secret immediately and prevents any further renewals. For
example, with the [AWS secret backend](/docs/secrets/aws/index.html), the
example, with the [AWS secrets engine](/docs/secrets/aws/index.html), the
access keys will be deleted from AWS the moment a secret is revoked. This
renders the access keys invalid from that point forward.

4
website/source/docs/enterprise/replication/index.html.md
View File

@ -50,7 +50,7 @@ encryption keys for `transit`, etc).
If a user action would modify underlying shared state, the secondary forwards the request
to the primary to be handled; this is transparent to the client. In practice, most
high-volume workloads (reads in the `generic` backend, encryption/decryption operations
high-volume workloads (reads in the `kv` backend, encryption/decryption operations
in `transit`, etc.) can be satisfied by the local secondary, allowing Vault to scale
relatively horizontally with the number of secondaries rather than vertically as
in the past.
@ -68,7 +68,7 @@ They do not forward service read or write requests until they are elected and be
| Capability | Disaster Recovery | Performance |
|-------------------------------------------------------------------------------------------------------------------------- |------------------- |-------------------------------------------------------------------------- |
| Mirrors the secrets infrastructure of a primary cluster | Yes | Yes |
| Mirrors the configuration of a primary cluster’s backends (i.e.: auth methods, storage backends, secret backends, etc.) | Yes | Yes |
| Mirrors the configuration of a primary cluster’s backends (i.e.: auth methods, storage backends, secrets engines, etc.) | Yes | Yes |
| Contains a local replica of secrets on the secondary and allows the secondary to forward writes | No | Yes |
| Mirrors the token auth infrastructure for applications or users interacting with the primary cluster | Yes | No. Upon promotion, applications must re-auth tokens with a new primary. |

4
website/source/docs/internals/architecture.html.md
View File

@ -33,7 +33,7 @@ clarify what is being discussed:
that only encrypted data is written out, and that data is verified and decrypted on the way
in. Much like a bank vault, the barrier must be "unsealed" before anything inside can be accessed.
* **Secret Backend** - A secret backend is responsible for managing secrets. Simple secret backends
* **Secrets Engine** - A secrets engine is responsible for managing secrets. Simple secrets engines
like the "kv" backend simply return the same secret when queried. Some backends support
using policies to dynamically generate a secret each time they are queried. This allows for
unique secrets to be used which allows Vault to do fine-grained revocation and policy updates.
@ -136,7 +136,7 @@ may need to be periodically renewed to avoid invalidation.
Once authenticated, requests are made providing the client token. The token is used
to verify the client is authorized and to load the relevant policies. The policies
are used to authorize the client request. The request is then routed to the secret backend,
are used to authorize the client request. The request is then routed to the secrets engine,
which is processed depending on the type of backend. If the backend returns a secret,
the core registers it with the expiration manager and attaches a lease ID.
The lease ID is used by clients to renew or revoke their secret. If a client allows the

4
website/source/docs/internals/telemetry.html.md
View File

@ -128,12 +128,12 @@ These metrics relate to supported auth methods.
| `vault.rollback.attempt.auth-token-` | This measures the number of rollback operations attempted for authentication tokens backend | Number of operations | Summary |
| `vault.rollback.attempt.auth-ldap-` | This measures the number of rollback operations attempted for the LDAP auth method | Number of operations | Summary |
| `vault.rollback.attempt.cubbyhole-` | This measures the number of rollback operations attempted for the cubbyhole auth method | Number of operations | Summary |
| `vault.rollback.attempt.secret-` | This measures the number of rollback operations attempted for the kv secret backend | Number of operations | Summary |
| `vault.rollback.attempt.secret-` | This measures the number of rollback operations attempted for the kv secrets engine | Number of operations | Summary |
| `vault.rollback.attempt.sys-` | This measures the number of rollback operations attempted for the sys backend | Number of operations | Summary |
| `vault.route.rollback.auth-ldap-` | This measures the number of rollback operations for the LDAP auth method | Number of operations | Summary |
| `vault.route.rollback.auth-token-` | This measures the number of rollback operations for the authentication tokens backend | Number of operations | Summary |
| `vault.route.rollback.cubbyhole-` | This measures the number of rollback operations for the cubbyhole auth method | Number of operations | Summary |
| `vault.route.rollback.secret-` | This measures the number of rollback operations for the kv secret backend | Number of operations | Summary |
| `vault.route.rollback.secret-` | This measures the number of rollback operations for the kv secrets engine | Number of operations | Summary |
| `vault.route.rollback.sys-` | This measures the number of rollback operations for the sys backend | Number of operations | Summary |
### Storage Backend Metrics

2
website/source/docs/plugin/index.html.md
View File

@ -9,7 +9,7 @@ description: |-
# Custom Plugin Backends
Plugin backends are the components in Vault that can be implemented separately from Vault's
builtin backends. These backends can be either authentication or secret backends.
builtin backends. These backends can be either authentication or secrets engines.
Detailed information regarding the plugin system can be found in the
[internals documentation](https://www.vaultproject.io/docs/internals/plugins.html).

223
website/source/docs/secrets/aws/index.html.md
View File

@ -1,148 +1,129 @@
---
layout: "docs"
page_title: "AWS Secret Backend"
page_title: "AWS - Secrets Engines"
sidebar_current: "docs-secrets-aws"
description: |-
The AWS secret backend for Vault generates access keys dynamically based on IAM policies.
The AWS secrets engine for Vault generates access keys dynamically based on
IAM policies.
---
# AWS Secret Backend
# AWS Secrets Engine
Name: `aws`
The AWS secrets engine generates AWS access credentials dynamically based on IAM
policies. This generally makes working with AWS IAM easier, since it does not
involve clicking in the web UI. Additionally, the process is codified and mapped
to internal auth methods (such as LDAP). The AWS IAM credentials are time-based
and are automatically revoked when the Vault lease expires.
The AWS secret backend for Vault generates AWS access credentials dynamically
based on IAM policies. This makes IAM much easier to use: credentials could
be generated on the fly, and are automatically revoked when the Vault
lease is expired.
## Setup
This page will show a quick start for this backend. For detailed documentation
on every path, use `vault path-help` after mounting the backend.
Most secrets engines must be configured in advance before they can perform their
functions. These steps are usually completed by an operator or configuration
management tool.
## Quick Start
1. Enable the AWS secrets engine:
The first step to using the aws backend is to mount it.
Unlike the `kv` backend, the `aws` backend is not mounted by default.
```text
$ vault secrets enable aws
Success! Enabled the aws secrets engine at: aws/
```
```text
$ vault mount aws
Successfully mounted 'aws' at 'aws'!
```
By default, the secrets engine will mount at the name of the engine. To
enable the secrets engine at a different path, use the `-path` argument.
Next, we must configure the credentials that Vault uses to manage the IAM credentials generated by this secret backend:
1. Configure the credentials that Vault uses to communicate with AWS to generate
the IAM credentials:
```text
$ vault write aws/config/root \
access_key=AKIAJWVN5Z4FOFT7NLNA \
secret_key=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 \
region=us-east-1
```
```text
$ vault write aws/config/root \
access_key=AKIAJWVN5Z4FOFT7NLNA \
secret_key=R4nm063hgMVo4BTT5xOs5nHLeLXA6lar7ZJ3Nt0i \
region=us-east-1
```
*Note that `root` does not mean it needs to be your AWS account's root credentials, and it
probably should not be. It is also unnecessary in many cases as Vault will use normal AWS credential mechanisms (instance profile, env vars, etc.) when possible. If you need to use static credentials, create an IAM user with permissions to manage IAM and STS.
See below for the specific actions required.*
Internally, Vault will connect to AWS using these credentials. As such,
these credentials must be a superset of any policies which might be granted
on IAM credentials. Since Vault uses the official AWS SDK, it will use the
specified credentials. You can also specify the credentials via the standard
AWS environment credentials, shared file credentials, or IAM role/ECS task
credentials.
The following parameters are required:
~> **Notice:** Even though the path above is `aws/config/root`, do not use
your AWS root account credentials. Instead generate a dedicated user or
role.
- `access_key` - the AWS access key that has permission to manage IAM
credentials.
- `secret_key` - the AWS secret key that has permission to manage IAM
credentials.
1. Configure a role that maps a name in Vault to a policy or policy file in AWS.
When users generate credentials, they are generated against this role:
The following parameter is optional:
- `region` the AWS region for API calls. If not provided, the `AWS_REGION` and
`AWS_DEFAULT_REGION` env vars will be used, in that order. If there is still
no region, `us-east-1` will be used as a fallback.
Note: the client uses the official AWS SDK and will use the specified
credentials, environment credentials, shared file credentials, or IAM role/ECS
task credentials in that order.
The next step is to configure a role. A role is a logical name that maps
to a policy used to generated those credentials.
You can either supply a user inline policy (via the policy argument), or
provide a reference to an existing AWS policy by supplying the full ARN
reference (via the arn argument).
For example, lets first create a "deploy" role using an user inline policy as an example:
```text
$ vault write aws/roles/deploy \
policy=@policy.json
```
This path will create a named role along with the IAM policy used
to restrict permissions for it. This is used to dynamically create
a new pair of IAM credentials when needed.
The `@` tells Vault to load the policy from the file named `policy.json`. Here
is an example IAM policy to get started:
```javascript
{
"Version": "2012-10-17",
"Statement": [
```text
$ vault write aws/roles/my-role \
policy=-<<EOF
{
"Effect": "Allow",
"Action": "iam:*",
"Resource": "*"
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:*",
"Resource": "*"
}
]
}
]
}
```
EOF
```
As a second example, lets create a "readonly" role using an existing AWS policy as an example:
This creates a role named "my-role". When users generate credentials against
this role, the resulting IAM credential will have the permissions specified
in the policy provided as the argument.
```text
$ vault write aws/roles/readonly arn=arn:aws:iam::aws:policy/AmazonEC2ReadOnlyAccess
```
You can either supply a user inline policy or provide a reference to an
existing AWS policy's full ARN:
This path will create a named role pointing to an existing IAM policy used
to restrict permissions for it. This is used to dynamically create
a new pair of IAM credentials when needed.
```text
$ vault write aws/roles/my-other-role \
arn=arn:aws:iam::aws:policy/AmazonEC2ReadOnlyAccess
```
For more information on IAM policies, please see the
[AWS IAM policy documentation](https://docs.aws.amazon.com/IAM/latest/UserGuide/PoliciesOverview.html).
For more information on IAM policies, please see the
[AWS IAM policy documentation](https://docs.aws.amazon.com/IAM/latest/UserGuide/PoliciesOverview.html).
## Usage
To generate a new set of IAM credentials, we simply read from that role:
After the secrets engine is configured and a user/machine has a Vault token with
the proper permission, it can generate credentials.
```text
$ vault read aws/creds/deploy
Key Value
lease_id aws/creds/deploy/7cb8df71-782f-3de1-79dd-251778e49f58
lease_duration 3600
access_key AKIAIOMYUTSLGJOGLHTQ
secret_key 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
security_token <nil>
```
1. Generate a new credential by reading from the `/creds` endpoint with the name
of the role:
If you run the command again, you will get a new set of credentials:
```text
$ vault read aws/creds/my-role
Key Value
--- -----
lease_id aws/creds/my-role/f3e92392-7d9c-09c8-c921-575d62fe80d8
lease_duration 768h
lease_renewable true
access_key AKIAIOWQXTLW36DV7IEA
secret_key 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
security_token <nil>
```
```text
$ vault read aws/creds/deploy
Key Value
lease_id aws/creds/deploy/82d89562-ff19-382e-6be9-cb45c8f6a42d
lease_duration 3600
access_key AKIAJZ5YRPHFH3QHRRRQ
secret_key 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
security_token <nil>
```
Each invocation of the command will generate a new credential.
## Dynamic IAM users
Unfortunately, IAM credentials are eventually consistent with respect to
other Amazon services. If you are planning on using these credential in a
pipeline, you may need to add a delay of 5-10 seconds (or more) after
fetching credentials before they can be used successfully.
The `aws/creds` endpoint will dynamically create a new IAM user and respond
with an IAM access key for the newly created user.
If you want to be able to use credentials without the wait, consider using
the STS method of fetching keys. IAM credentials supported by an STS token
are available for use as soon as they are generated.
The [Quick Start](#quick-start) describes how to setup the `aws/creds` endpoint.
## Example IAM Policy for Vault
## Root Credentials for Dynamic IAM users
The `aws/config/root` credentials need permission to manage dynamic IAM users.
Here is an example AWS IAM policy that grants the most commonly required
permissions Vault needs:
The `aws/config/root` credentials need permission to manage dynamic IAM users.
This does not mean it needs to be your AWS account's root credentials, and we would not suggest using them.
Here is an example IAM policy that would grant these permissions:
```javascript
```json
{
"Version": "2012-10-17",
"Statement": [
@ -171,22 +152,6 @@ Here is an example IAM policy that would grant these permissions:
}
```
Note that this policy example is unrelated to the policy you wrote to `aws/roles/deploy`.
This policy example should be applied to the IAM user (or role) associated with
the root credentials that you wrote to `aws/config/root`. You have to apply it
yourself in IAM. The policy you wrote to `aws/roles/deploy` is the policy you
want the AWS secret backend to apply to the temporary credentials it returns
from `aws/creds/deploy`.
Unfortunately, IAM credentials are eventually consistent with respect to other
Amazon services. If you are planning on using these credential in a pipeline,
you may need to add a delay of 5-10 seconds (or more) after fetching
credentials before they can be used successfully.
If you want to be able to use credentials without the wait, consider using the STS
method of fetching keys. IAM credentials supported by an STS token are available for use
as soon as they are generated.
## STS credentials
Vault also supports an STS credentials instead of creating a new IAM user.
@ -374,6 +339,6 @@ errors for exceeding the AWS limit of 32 characters on STS token names.
## API
The AWS secret backend has a full HTTP API. Please see the
[AWS secret backend API](/api/secret/aws/index.html) for more
The AWS secrets engine has a full HTTP API. Please see the
[AWS secrets engine API](/api/secret/aws/index.html) for more
details.

49
website/source/docs/secrets/cassandra/index.html.md
View File

@ -1,21 +1,19 @@
---
layout: "docs"
page_title: "Cassandra Secret Backend"
page_title: "Cassandra - Secrets Engines"
sidebar_current: "docs-secrets-cassandra"
description: |-
The Cassandra secret backend for Vault generates database credentials to access Cassandra.
The Cassandra secrets engine for Vault generates database credentials to access Cassandra.
---
# Cassandra Secret Backend
# Cassandra Secrets Engine
Name: `cassandra`
~> **Deprecation Note:** This secrets engine is deprecated in favor of the
combined databases secrets engine added in v0.7.1. See the documentation for
the new implementation of this secrets engine at
[Cassandra database plugin](/docs/secrets/databases/cassandra.html).
~> **Deprecation Note:** This backend is deprecated in favor of the
combined databases backend added in v0.7.1. See the documentation for
the new implementation of this backend at
[Cassandra Database Plugin](/docs/secrets/databases/cassandra.html).
The Cassandra secret backend for Vault generates database credentials
The Cassandra secrets engine for Vault generates database credentials
dynamically based on configured roles. This means that services that need
to access a database no longer need to hardcode credentials: they can request
them from Vault, and use Vault's leasing mechanism to more easily roll keys.
@ -25,17 +23,17 @@ the database with unique credentials, it makes auditing much easier when
questionable data access is discovered: you can track it down to the specific
instance of a service based on the Cassandra username.
This page will show a quick start for this backend. For detailed documentation
on every path, use `vault path-help` after mounting the backend.
This page will show a quick start for this secrets engine. For detailed documentation
on every path, use `vault path-help` after mounting the secrets engine.
## Quick Start
The first step to using the Cassandra backend is to mount it.
Unlike the `kv` backend, the `cassandra` backend is not mounted by default.
The first step to using the Cassandra secrets engine is to mount it. Unlike the
`kv` secrets engine, the `cassandra` secrets engine is not mounted by default.
```text
$ vault mount cassandra
Successfully mounted 'cassandra' at 'cassandra'!
$ vault secrets enable cassandra
Success! Enabled the cassandra secrets engine at: cassandra/
```
Next, Vault must be configured to connect to Cassandra. This is done by
@ -76,12 +74,13 @@ Vault is now configured to create and manage credentials for Cassandra!
```text
$ vault read cassandra/creds/readonly
Key Value
lease_id cassandra/creds/test/7a23e890-3a26-531d-529b-92d18d1fa63f
lease_duration 3600
lease_renewable true
password dfa80eea-ccbe-b228-ebf7-e2f62b245e71
username vault-root-1434647667-9313
Key Value
--- -----
lease_id cassandra/creds/test/7a23e890-3a26-531d-529b-92d18d1fa63f
lease_duration 3600
lease_renewable true
password dfa80eea-ccbe-b228-ebf7-e2f62b245e71
username vault-root-1434647667-9313
```
By reading from the `creds/readonly` path, Vault has generated a new
@ -89,7 +88,7 @@ set of credentials using the `readonly` role configuration. Here we
see the dynamically generated username and password, along with a one
hour lease.
Using ACLs, it is possible to restrict using the `cassandra` backend such
Using ACLs, it is possible to restrict using the `cassandra` secrets engine such
that trusted operators can manage the role definitions, and both
users and applications are restricted in the credentials they are
allowed to read.
@ -99,6 +98,6 @@ subpath for interactive help output.
## API
The Cassandra secret backend has a full HTTP API. Please see the
[Cassandra secret backend API](/api/secret/cassandra/index.html) for more
The Cassandra secrets engine has a full HTTP API. Please see the
[Cassandra secrets engine API](/api/secret/cassandra/index.html) for more
details.

138
website/source/docs/secrets/consul/index.html.md
View File

@ -1,103 +1,95 @@
---
layout: "docs"
page_title: "Consul Secret Backend"
page_title: "Consul - Secrets Engines"
sidebar_current: "docs-secrets-consul"
description: |-
The Consul secret backend for Vault generates tokens for Consul dynamically.
The Consul secrets engine for Vault generates tokens for Consul dynamically.
---
# Consul Secret Backend
# Consul Secrets Engine
Name: `consul`
The Consul secrets engine generates [Consul](https://www.consul.io) API tokens
dynamically based on Consul ACL policies.
The Consul secret backend for Vault generates
[Consul](https://www.consul.io)
API tokens dynamically based on Consul ACL policies.
## Setup
This page will show a quick start for this backend. For detailed documentation
on every path, use `vault path-help` after mounting the backend.
Most secrets engines must be configured in advance before they can perform their
functions. These steps are usually completed by an operator or configuration
management tool.
## Quick Start
1. Enable the Consul secrets engine:
The first step to using the consul backend is to mount it.
Unlike the `kv` backend, the `consul` backend is not mounted by default.
```text
$ vault secrets enable consul
Success! Enabled the consul secrets engine at: consul/
```
```
$ vault mount consul
Successfully mounted 'consul' at 'consul'!
```
By default, the secrets engine will mount at the name of the engine. To
enable the secrets engine at a different path, use the `-path` argument.
[Acquire a management token from
Consul](https://www.consul.io/docs/agent/http/acl.html#acl_create), using the
`acl_master_token` from your Consul configuration file or any other management
1. Acquire a [management token][consul-mgmt-token] from Consul, using the
`acl_master_token` from your Consul configuration file or another management
token:
```shell
$ curl \
-H "X-Consul-Token: secret" \
-X PUT \
-d '{"Name": "sample", "Type": "management"}' \
http://127.0.0.1:8500/v1/acl/create
```
```javascript
{
"ID": "adf4238a-882b-9ddc-4a9d-5b6758e4159e"
}
```
```sh
$ curl \
--header "X-Consul-Token: my-management-token" \
--request PUT \
--data '{"Name": "sample", "Type": "management"}' \
https://consul.rocks/v1/acl/create
```
Next, we must configure Vault to know how to contact Consul.
This is done by writing the access information:
Vault must have a management type token so that it can create and revoke ACL
tokens. The response will return a new token:
```
$ vault write consul/config/access \
address=127.0.0.1:8500 \
token=adf4238a-882b-9ddc-4a9d-5b6758e4159e
Success! Data written to: consul/config/access
```
```json
{
"ID": "7652ba4c-0f6e-8e75-5724-5e083d72cfe4"
}
```
In this case, we've configured Vault to connect to Consul
on the default port with the loopback address. We've also provided
an ACL token to use with the `token` parameter. Vault must have a management
type token so that it can create and revoke ACL tokens.
1. Configure Vault to connect and authenticate to Consul:
The next step is to configure a role. A role is a logical name that maps
to a role used to generate those credentials. For example, lets create
a "readonly" role:
```text
$ vault write consul/config/access \
address=127.0.0.1:8500 \
token=7652ba4c-0f6e-8e75-5724-5e083d72cfe4
Success! Data written to: consul/config/access
```
```
POLICY='key "" { policy = "read" }'
$ echo $POLICY | base64 | vault write consul/roles/readonly policy=-
Success! Data written to: consul/roles/readonly
```
1. Configure a role that maps a name in Vault to a Consul ACL policy.
When users generate credentials, they are generated against this role:
The backend expects the policy to be base64 encoded, so we need to encode it
properly before writing. The policy language is [documented by
Consul](https://www.consul.io/docs/internals/acl.html), but we've defined a
read-only policy.
```text
$ vault write consul/roles/my-role policy=$(base64 <<< 'key "" { policy = "read" }')
Success! Data written to: consul/roles/my-role
```
To generate a new set Consul ACL token, we simply read from that role:
The policy must be base64-encoded. The policy language is [documented by
Consul](https://www.consul.io/docs/internals/acl.html).
```
$ vault read consul/creds/readonly
Key Value
lease_id consul/creds/readonly/c7a3bd77-e9af-cfc4-9cba-377f0ef10e6c
lease_duration 3600
token 973a31ea-1ec4-c2de-0f63-623f477c2510
```
## Usage
Here we can see that Vault has generated a new Consul ACL token for us.
We can test this token out, and verify that it is read-only:
After the secrets engine is configured and a user/machine has a Vault token with
the proper permission, it can generate credentials.
```
$ curl 127.0.0.1:8500/v1/kv/foo?token=973a31ea-1ec4-c2de-0f63-623f477c2510
[{"CreateIndex":12,"ModifyIndex":53,"LockIndex":4,"Key":"foo","Flags":3304740253564472344,"Value":"YmF6"}]
1. Generate a new credential by reading from the `/creds` endpoint with the name
of the role:
$ curl -X PUT -d 'test' 127.0.0.1:8500/v1/kv/foo?token=973a31ea-1ec4-c2de-0f63-623f477c2510
Permission denied
```
```text
$ vault read consul/creds/readonly
Key Value
--- -----
lease_id consul/creds/my-role/b2469121-f55f-53c5-89af-a3ba52b1d6d8
lease_duration 768h
lease_renewable true
token 642783bf-1540-526f-d4de-fe1ac1aed6f0
```
## API
The Consul secret backend has a full HTTP API. Please see the
[Consul secret backend API](/api/secret/consul/index.html) for more
The Consul secrets engine has a full HTTP API. Please see the
[Consul secrets engine API](/api/secret/consul/index.html) for more
details.
[consul-mgmt-token]: https://www.consul.io/docs/agent/http/acl.html#acl_create

72
website/source/docs/secrets/cubbyhole/index.html.md
View File

@ -1,58 +1,58 @@
---
layout: "docs"
page_title: "Cubbyhole Secret Backend"
page_title: "Cubbyhole - Secrets Engines"
sidebar_current: "docs-secrets-cubbyhole"
description: |-
The cubbyhole secret backend can store arbitrary secrets scoped to a single token.
The cubbyhole secrets engine can store arbitrary secrets scoped to a single token.
---
# Cubbyhole Secret Backend
# Cubbyhole Secrets Engine
Name: `cubbyhole`
The `cubbyhole` secrets engine is used to store arbitrary secrets within the
configured physical storage for Vault namespaced to a token. In `cubbyhole`,
paths are scoped per token. No token can access another token's cubbyhole. When
the token expires, its cubbyhole is destroyed.
The `cubbyhole` secret backend is used to store arbitrary secrets within
the configured physical storage for Vault. It is mounted at the `cubbyhole/`
prefix by default and cannot be mounted elsewhere or removed.
Also unlike the `kv` secrets engine, because the cubbyhole's lifetime is
linked to that of an authentication token, there is no concept of a TTL or
refresh interval for values contained in the token's cubbyhole.
This backend differs from the `kv` backend in that the `kv` backend's
values are accessible to any token with read privileges on that path. In
`cubbyhole`, paths are scoped per token; no token can access another token's
cubbyhole, whether to read, write, list, or for any other operation. When the
token expires, its cubbyhole is destroyed.
Writing to a key in the `cubbyhole` secrets engine will completely replace the
old value.
Also unlike the `kv` backend, because the cubbyhole's lifetime is linked
to that of an authentication token, there is no concept of a TTL or refresh
interval for values contained in the token's cubbyhole.
## Setup
Writing to a key in the `cubbyhole` backend will replace the old value;
the sub-fields are not merged together.
Most secrets engines must be configured in advance before they can perform their
functions. These steps are usually completed by an operator or configuration
management tool.
## Quick Start
The `cubbyhole` secrets engine is enabled by default. It cannot be disabled,
moved, or enabled multiple times.
The `cubbyhole` backend allows for writing keys with arbitrary values.
## Usage
As an example, we can write a new key "foo" to the `cubbyhole` backend, which
is mounted at `cubbyhole/`:
After the secrets engine is configured and a user/machine has a Vault token with
the proper permission, it can generate credentials. The `cubbyhole` secrets
engine allows for writing keys with arbitrary values.
```
$ vault write cubbyhole/foo \
zip=zap
Success! Data written to: cubbyhole/foo
```
1. Write arbitrary data:
This writes the key with the "zip" field set to "zap". We can test this by doing
a read:
```text
$ vault write cubbyhole/my-secret my-value=s3cr3t
Success! Data written to: cubbyhole/my-secret
```
```
$ vault read cubbyhole/foo
Key Value
zip zap
```
1. Read arbitrary data:
As expected, the value previously set is returned to us.
```text
$ vault read cubbyhole/my-secret
Key Value
--- -----
my-value s3cr3t
```
## API
The Cubbyhole secret backend has a full HTTP API. Please see the
[Cubbyhole secret backend API](/api/secret/cubbyhole/index.html) for more
The Cubbyhole secrets engine has a full HTTP API. Please see the
[Cubbyhole secrets engine API](/api/secret/cubbyhole/index.html) for more
details.

95
website/source/docs/secrets/databases/cassandra.html.md
View File

@ -1,61 +1,82 @@
---
layout: "docs"
page_title: "Cassandra Database Plugin - Database Secret Backend"
page_title: "Cassandra - Database - Secrets Engines"
sidebar_current: "docs-secrets-databases-cassandra"
description: |-
The Cassandra plugin for Vault's Database backend generates database credentials to access Cassandra.
Cassandra is one of the supported plugins for the database secrets engine.
This plugin generates database credentials dynamically based on configured
roles for the Cassandra database.
---
# Cassandra Database Plugin
# Cassandra Database Secrets Engine
Name: `cassandra-database-plugin`
Cassandra is one of the supported plugins for the database secrets engine. This
plugin generates database credentials dynamically based on configured roles for
the Cassandra database.
The Cassandra Database Plugin is one of the supported plugins for the Database
backend. This plugin generates database credentials dynamically based on
configured roles for the Cassandra database.
See the [database secrets engine](/docs/secrets/databases/index.html) docs for
more information about setting up the database secrets engine.
See the [Database Backend](/docs/secrets/databases/index.html) docs for more
information about setting up the Database Backend.
## Setup
## Quick Start
1. Enable the database secrets engine if it is not already enabled:
After the Database Backend is mounted you can configure a cassandra connection
by specifying this plugin as the `"plugin_name"` argument. Here is an example
cassandra configuration:
```text
$ vault secrets enable database
Success! Enabled the database secrets engine at: database/
```
```
$ vault write database/config/cassandra \
plugin_name=cassandra-database-plugin \
allowed_roles="readonly" \
hosts=localhost \
username=cassandra \
password=cassandra
By default, the secrets engine will enable at the name of the engine. To
enable the secrets engine at a different path, use the `-path` argument.
The following warnings were returned from the Vault server:
* Read access to this endpoint should be controlled via ACLs as it will return the connection details as is, including passwords, if any.
```
1. Configure Vault with the proper plugin and connection information:
Once the cassandra connection is configured we can add a role:
```text
$ vault write database/config/my-cassandra-database \
plugin_name="cassandra-database-plugin" \
hosts=127.0.0.1 \
protocol_version=4 \
username=cassandra \
password=cassandra \
allowed_roles=my-role
```
```
$ vault write database/roles/readonly \
db_name=cassandra \
creation_statements="CREATE USER '{{username}}' WITH PASSWORD '{{password}}' NOSUPERUSER; \
GRANT SELECT ON ALL KEYSPACES TO {{username}};" \
default_ttl="1h" \
max_ttl="24h"
1. Configure a role that maps a name in Vault to an SQL statement to execute to
create the database credential:
```text
$ vault write database/roles/my-role \
db_name=my-cassandra-database \
creation_statements="CREATE USER '{{username}}' WITH PASSWORD '{{password}}' NOSUPERUSER; \
GRANT SELECT ON ALL KEYSPACES TO {{username}};" \
default_ttl="1h" \
max_ttl="24h"
Success! Data written to: database/roles/my-role
```
Success! Data written to: database/roles/readonly
```
## Usage
This role can be used to retrieve a new set of credentials by querying the
"database/creds/readonly" endpoint.
After the secrets engine is configured and a user/machine has a Vault token with
the proper permission, it can generate credentials.
1. Generate a new credential by reading from the `/creds` endpoint with the name
of the role:
```text
$ vault read database/creds/my-role
Key Value
--- -----
lease_id database/creds/my-role/2f6a614c-4aa2-7b19-24b9-ad944a8d4de6
lease_duration 1h
lease_renewable true
password 8cab931c-d62e-a73d-60d3-5ee85139cd66
username v-root-e2978cd0-
```
## API
The full list of configurable options can be seen in the [Cassandra database
plugin API](/api/secret/databases/cassandra.html) page.
For more information on the Database secret backend's HTTP API please see the [Database secret
backend API](/api/secret/databases/index.html) page.
For more information on the database secrets engine's HTTP API please see the [Database secret
secrets engine API](/api/secret/databases/index.html) page.

42
website/source/docs/secrets/databases/custom.html.md
View File

@ -1,23 +1,26 @@
---
layout: "docs"
page_title: "Custom Database Plugins - Database Secret Backend"
page_title: "Custom - Database - Secrets Engines"
sidebar_current: "docs-secrets-databases-custom"
description: |-
Creating custom database plugins for Vault's Database backend to generate credentials for a database.
The database secrets engine allows new functionality to be added through a
plugin interface without needing to modify vault's core code. This allows you
write your own code to generate credentials in any database you wish. It also
allows databases that require dynamically linked libraries to be used as
plugins while keeping Vault itself statically linked.
---
# Custom Database Plugins
# Custom Database Secrets Engines
The Database backend allows new functionality to be added through a plugin
interface without needing to modify vault's core code. This allows you write
your own code to generate credentials in any database you wish. It also allows
databases that require dynamically linked libraries to be used as plugins while
keeping Vault itself statically linked.
The database secrets engine allows new functionality to be added through a
plugin interface without needing to modify vault's core code. This allows you
write your own code to generate credentials in any database you wish. It also
allows databases that require dynamically linked libraries to be used as plugins
while keeping Vault itself statically linked.
~> **Advanced topic!** Plugin development is a highly advanced
topic in Vault, and is not required knowledge for day-to-day usage.
If you don't plan on writing any plugins, we recommend not reading
this section of the documentation.
~> **Advanced topic!** Plugin development is a highly advanced topic in Vault,
and is not required knowledge for day-to-day usage. If you don't plan on writing
any plugins, we recommend not reading this section of the documentation.
Please read the [Plugins internals](/docs/internals/plugins.html) docs for more
information about the plugin system before getting started building your
@ -25,7 +28,7 @@ Database plugin.
## Plugin Interface
All plugins for the Database backend must implement the same simple interface.
All plugins for the database secrets engine must implement the same simple interface.
```go
type Database interface {
@ -91,27 +94,24 @@ The above main package, once built, will supply you with a binary of your
plugin. We also recommend if you are planning on distributing your plugin to
build with [gox](https://github.com/mitchellh/gox) for cross platform builds.
To use your plugin with the Database backend you need to place the binary in the
To use your plugin with the database secrets engine you need to place the binary in the
plugin directory as specified in the [plugin internals](/docs/internals/plugins.html) docs.
You should now be able to register your plugin into the vault catalog. To do
this your token will need sudo permissions.
```
```text
$ vault write sys/plugins/catalog/myplugin-database-plugin \
sha_256=<expected SHA256 Hex value of the plugin binary> \
sha_256="..." \
command="myplugin"
Success! Data written to: sys/plugins/catalog/myplugin-database-plugin
```
Now you should be able to configure your plugin like any other:
```
```text
$ vault write database/config/myplugin \
plugin_name=myplugin-database-plugin \
allowed_roles="readonly" \
myplugins_connection_details=....
The following warnings were returned from the Vault server:
* Read access to this endpoint should be controlled via ACLs as it will return the connection details as is, including passwords, if any.
myplugins_connection_details="..."
```

138
website/source/docs/secrets/databases/hanadb.html.md
View File

@ -1,59 +1,79 @@
---
layout: "docs"
page_title: "HANA Database Plugin - Database Secret Backend"
sidebar_current: "docs-secrets-databases-HANA"
description: |-
The HANA plugin for Vault's Database backend generates database credentials to access SAP HANA Database.
---
# HANA Database Plugin
Name: `hana-database-plugin`
The HANA Database Plugin is one of the supported plugins for the Database
backend. This plugin generates database credentials dynamically based on
configured roles for the HANA database.
See the [Database Backend](/docs/secrets/databases/index.html) docs for more
information about setting up the Database Backend.
## Quick Start
After the Database Backend is mounted you can configure a HANA connection
by specifying this plugin as the `"plugin_name"` argument. Here is an example
configuration:
```
$ vault write database/config/hana \
plugin_name=hana-database-plugin \
connection_url="hdb://username:password@localhost:1433" \
allowed_roles="readonly"
The following warnings were returned from the Vault server:
* Read access to this endpoint should be controlled via ACLs as it will
return the connection details as is, including passwords, if any.
```
Once the HANA connection is configured we can add a role:
```
$ vault write database/roles/readonly \
db_name=hana \
creation_statements="CREATE USER {{name}} PASSWORD {{password}} VALID UNTIL '{{expiration}}';\
CALL GRANT_ACTIVATED_ROLE ( 'sap.hana.admin.roles::Monitoring', '{{name}}' );" \
default_ttl="12h" \
max_ttl="24h"
Success! Data written to: database/roles/readonly
```
This role can now be used to retrieve a new set of credentials by querying the
"database/creds/readonly" endpoint.
## API
The full list of configurable options can be seen in the [HANA database
plugin API](/api/secret/databases/hanadb.html) page.
For more information on the Database secret backend's HTTP API please see the [Database secret
backend API](/api/secret/databases/index.html) page.
---
layout: "docs"
page_title: "HANA - Database - Secrets Engines"
sidebar_current: "docs-secrets-databases-hanadb"
description: |-
HANA is one of the supported plugins for the database secrets engine. This
plugin generates database credentials dynamically based on configured roles
for the HANA database.
---
# HANA Database Secrets Engine
HANA is one of the supported plugins for the database secrets engine. This
plugin generates database credentials dynamically based on configured roles for
the HANA database.
See the [database secrets engine](/docs/secrets/databases/index.html) docs for
more information about setting up the database secrets engine.
## Setup
1. Enable the database secrets engine if it is not already enabled:
```text
$ vault secrets enable database
Success! Enabled the database secrets engine at: database/
```
By default, the secrets engine will enable at the name of the engine. To
enable the secrets engine at a different path, use the `-path` argument.
1. Configure Vault with the proper plugin and connection information:
```text
$ vault write database/config/my-hana-database \
plugin_name=hana-database-plugin \
connection_url="hdb://username:password@localhost:1433" \
allowed_roles="my-role"
```
1. Configure a role that maps a name in Vault to an SQL statement to execute to
create the database credential:
```text
$ vault write database/roles/my-role \
db_name=my-hana-database \
creation_statements="CREATE USER {{name}} PASSWORD {{password}} VALID UNTIL '{{expiration}}';\
CALL GRANT_ACTIVATED_ROLE ( 'sap.hana.admin.roles::Monitoring', '{{name}}' );" \
default_ttl="12h" \
max_ttl="24h"
Success! Data written to: database/roles/my-role
```
## Usage
After the secrets engine is configured and a user/machine has a Vault token with
the proper permission, it can generate credentials.
1. Generate a new credential by reading from the `/creds` endpoint with the name
of the role:
```text
$ vault read database/creds/my-role
Key Value
--- -----
lease_id database/creds/my-role/2f6a614c-4aa2-7b19-24b9-ad944a8d4de6
lease_duration 1h
lease_renewable true
password 8cab931c-d62e-a73d-60d3-5ee85139cd66
username v-root-e2978cd0-
```
## API
The full list of configurable options can be seen in the [HANA database
plugin API](/api/secret/databases/hanadb.html) page.
For more information on the database secrets engine's HTTP API please see the
[Database secrets engine API](/api/secret/databases/index.html) page.

143
website/source/docs/secrets/databases/index.html.md
View File

@ -1,102 +1,101 @@
---
layout: "docs"
page_title: "Database Secret Backend"
page_title: "Database - Secrets Engines"
sidebar_current: "docs-secrets-databases"
description: |-
Top page for database secret backend information
The database secrets engine generates database credentials dynamically based
on configured roles. It works with a number of different databases through a
plugin interface. There are a number of builtin database types and an exposed
framework for running custom database types for extendability.
---
# Databases
Name: `Database`
The database secrets engine generates database credentials dynamically based on
configured roles. It works with a number of different databases through a plugin
interface. There are a number of builtin database types and an exposed framework
for running custom database types for extendability. This means that services
that need to access a database no longer need to hardcode credentials: they can
request them from Vault, and use Vault's leasing mechanism to more easily roll
keys.
The Database secret backend for Vault generates database credentials dynamically
based on configured roles. It works with a number of different databases through
a plugin interface. There are a number of builtin database types and an exposed
framework for running custom database types for extendability. This means that
services that need to access a database no longer need to hardcode credentials:
they can request them from Vault, and use Vault's leasing mechanism to more
easily roll keys.
Additionally, it introduces a new ability: with every service accessing the
database with unique credentials, it makes auditing much easier when
questionable data access is discovered: you can track it down to the specific
instance of a service based on the SQL username.
Since every service accessing the database with unique credentials, it makes
auditing much easier when questionable data access is discovered. You can track
it down to the specific instance of a service based on the SQL username.
Vault makes use of its own internal revocation system to ensure that users
become invalid within a reasonable time of the lease expiring.
This page will show a quick start for this backend. For detailed documentation
on every path, use vault path-help after mounting the backend.
## Setup
## Quick Start
Most secrets engines must be configured in advance before they can perform their
functions. These steps are usually completed by an operator or configuration
management tool.
The first step in using the Database backend is mounting it.
1. Enable the database secrets engine:
```text
$ vault mount database
Successfully mounted 'database' at 'database'!
```
```text
$ vault secrets enable database
Success! Enabled the database secrets engine at: database/
```
Next, we must configure this backend to connect to a database. In this example
we will connect to a MySQL database, but the configuration details needed for
other plugin types can be found in their docs pages. This backend can configure
multiple database connections, therefore a name for the connection must be
provided; we'll call this one simply "mysql".
By default, the secrets engine will enable at the name of the engine. To
enable the secrets engine at a different path, use the `-path` argument.
```
$ vault write database/config/mysql \
plugin_name=mysql-database-plugin \
connection_url="root:mysql@tcp(127.0.0.1:3306)/" \
allowed_roles="readonly"
1. Configure Vault with the proper plugin and connection information:
The following warnings were returned from the Vault server:
* Read access to this endpoint should be controlled via ACLs as it will return the connection details as is, including passwords, if any.
```
```text
$ vault write database/config/my-database \
plugin_name="..." \
connection_url="..." \
allowed_roles="..."
```
The next step is to configure a role. A role is a logical name that maps to a
policy used to generate those credentials. A role needs to be configured with
the database name we created above, and the default/max TTLs. For example, lets
create a "readonly" role:
This secrets engine can configure multiple database connections. For details
on the specific configuration options, please see the database-specific
documentation.
```
$ vault write database/roles/readonly \
db_name=mysql \
creation_statements="CREATE USER '{{name}}'@'%' IDENTIFIED BY '{{password}}';GRANT SELECT ON *.* TO '{{name}}'@'%';" \
default_ttl="1h" \
max_ttl="24h"
Success! Data written to: database/roles/readonly
```
By writing to the roles/readonly path we are defining the readonly role. This
role will be created by evaluating the given creation statements. By default,
the {{name}} and {{password}} fields will be populated by the plugin with
dynamically generated values. In other plugins the {{expiration}} field could
also be supported. This SQL statement is creating the named user, and then
granting it SELECT or read-only privileges to tables in the database. More
complex GRANT queries can be used to customize the privileges of the role.
Custom revocation statements could be passed too, but this plugin has a default
statement we can use.
1. Configure a role that maps a name in Vault to an SQL statement to execute to create the database credential:
To generate a new set of credentials, we simply read from that role:
```text
$ vault write database/roles/my-role \
db_name=my-database \
creation_statements="..." \
default_ttl="1h" \
max_ttl="24h"
Success! Data written to: database/roles/my-role
```
```
$ vault read database/creds/readonly
Key Value
--- -----
lease_id database/creds/readonly/2f6a614c-4aa2-7b19-24b9-ad944a8d4de6
lease_duration 1h0m0s
lease_renewable true
password 8cab931c-d62e-a73d-60d3-5ee85139cd66
username v-root-e2978cd0-
```
The `{{name}}` and `{{password}}` fields will be populated by the plugin
with dynamically generated values. In some plugins the `{{expiration}}`
field is also be supported.
## Usage
After the secrets engine is configured and a user/machine has a Vault token with
the proper permission, it can generate credentials.
1. Generate a new credential by reading from the `/creds` endpoint with the name
of the role:
```text
$ vault read database/creds/my-role
Key Value
--- -----
lease_id database/creds/my-role/2f6a614c-4aa2-7b19-24b9-ad944a8d4de6
lease_duration 1h
lease_renewable true
password 8cab931c-d62e-a73d-60d3-5ee85139cd66
username v-root-e2978cd0-
```
## Custom Plugins
This backend allows custom database types to be run through the exposed plugin
interface. Please see the [Custom database
This secrets engine allows custom database types to be run through the exposed
plugin interface. Please see the [custom database
plugin](/docs/secrets/databases/custom.html) for more information.
## API
The Database secret backend has a full HTTP API. Please see the [Database secret
backend API](/api/secret/databases/index.html) for more details.
The database secrets engine has a full HTTP API. Please see the [Database secret
secrets engine API](/api/secret/databases/index.html) for more details.

89
website/source/docs/secrets/databases/mongodb.html.md
View File

@ -1,57 +1,78 @@
---
layout: "docs"
page_title: "MongoDB Database Plugin - Database Secret Backend"
page_title: "MongoDB - Database - Secrets Engines"
sidebar_current: "docs-secrets-databases-mongodb"
description: |-
The MongoDB plugin for Vault's Database backend generates database credentials to access MongoDB.
MongoDB is one of the supported plugins for the database secrets engine. This
plugin generates database credentials dynamically based on configured roles
for the MongoDB database.
---
# MongoDB Database Plugin
# MongoDB Database Secrets Engine
Name: `mongodb-database-plugin`
MongoDB is one of the supported plugins for the database secrets engine. This
plugin generates database credentials dynamically based on configured roles for
the MongoDB database.
The MongoDB Database Plugin is one of the supported plugins for the Database
backend. This plugin generates database credentials dynamically based on
configured roles for the MongoDB database.
See the [database secrets engine](/docs/secrets/databases/index.html) docs for
more information about setting up the database secrets engine.
See the [Database Backend](/docs/secrets/databases/index.html) docs for more
information about setting up the Database Backend.
## Setup
## Quick Start
1. Enable the database secrets engine if it is not already enabled:
After the Database Backend is mounted you can configure a MongoDB connection
by specifying this plugin as the `"plugin_name"` argument. Here is an example
MongoDB configuration:
```text
$ vault secrets enable database
Success! Enabled the database secrets engine at: database/
```
```
$ vault write database/config/mongodb \
plugin_name=mongodb-database-plugin \
allowed_roles="readonly" \
connection_url="mongodb://admin:Password!@mongodb.acme.com:27017/admin?ssl=true"
By default, the secrets engine will enable at the name of the engine. To
enable the secrets engine at a different path, use the `-path` argument.
The following warnings were returned from the Vault server:
* Read access to this endpoint should be controlled via ACLs as it will return the connection details as is, including passwords, if any.
```
1. Configure Vault with the proper plugin and connection information:
Once the MongoDB connection is configured we can add a role:
```text
$ vault write database/config/my-mongodb-database \
plugin_name=mongodb-database-plugin \
allowed_roles="my-role" \
connection_url="mongodb://admin:Password!@mongodb.acme.com:27017/admin?ssl=true"
```
```
$ vault write database/roles/readonly \
db_name=mongodb \
creation_statements='{ "db": "admin", "roles": [{ "role": "readWrite" }, {"role": "read", "db": "foo"}] }' \
default_ttl="1h" \
max_ttl="24h"
1. Configure a role that maps a name in Vault to an SQL statement to execute to
create the database credential:
Success! Data written to: database/roles/readonly
```
```text
$ vault write database/roles/my-role \
db_name=my-mongodb-database \
creation_statements='{ "db": "admin", "roles": [{ "role": "readWrite" }, {"role": "read", "db": "foo"}] }' \
default_ttl="1h" \
max_ttl="24h"
Success! Data written to: database/roles/my-role
```
This role can be used to retrieve a new set of credentials by querying the
"database/creds/readonly" endpoint.
## Usage
After the secrets engine is configured and a user/machine has a Vault token with
the proper permission, it can generate credentials.
1. Generate a new credential by reading from the `/creds` endpoint with the name
of the role:
```text
$ vault read database/creds/my-role
Key Value
--- -----
lease_id database/creds/my-role/2f6a614c-4aa2-7b19-24b9-ad944a8d4de6
lease_duration 1h
lease_renewable true
password 8cab931c-d62e-a73d-60d3-5ee85139cd66
username v-root-e2978cd0-
```
## API
The full list of configurable options can be seen in the [MongoDB database
plugin API](/api/secret/databases/mongodb.html) page.
For more information on the Database secret backend's HTTP API please see the [Database secret
backend API](/api/secret/databases/index.html) page.
For more information on the database secrets engine's HTTP API please see the
[Database secrets engine API](/api/secret/databases/index.html) page.

110
website/source/docs/secrets/databases/mssql.html.md
View File

@ -1,69 +1,91 @@
---
layout: "docs"
page_title: "MSSQL Database Plugin - Database Secret Backend"
page_title: "MSSQL - Database - Secrets Engines"
sidebar_current: "docs-secrets-databases-mssql"
description: |-
The MSSQL plugin for Vault's Database backend generates database credentials to access Microsoft SQL Server.
MSSQL is one of the supported plugins for the database secrets engine. This
plugin generates database credentials dynamically based on configured roles
for the MSSQL database.
---
# MSSQL Database Plugin
# MSSQL Database Secrets Engine
Name: `mssql-database-plugin`
MSSQL is one of the supported plugins for the database secrets engine. This
plugin generates database credentials dynamically based on configured roles for
the MSSQL database.
The MSSQL Database Plugin is one of the supported plugins for the Database
backend. This plugin generates database credentials dynamically based on
configured roles for the MSSQL database.
See the [database secrets engine](/docs/secrets/databases/index.html) docs for
more information about setting up the database secrets engine.
See the [Database Backend](/docs/secrets/databases/index.html) docs for more
information about setting up the Database Backend.
## Setup
## Quick Start
1. Enable the database secrets engine if it is not already enabled:
After the Database Backend is mounted you can configure a MSSQL connection
by specifying this plugin as the `"plugin_name"` argument. Here is an example
configuration:
```text
$ vault secrets enable database
Success! Enabled the database secrets engine at: database/
```
```
$ vault write database/config/mssql \
plugin_name=mssql-database-plugin \
connection_url='server=localhost;port=1433;user id=sa;password=Password!;database=AdventureWorks;app name=vault;' \
allowed_roles="readonly"
By default, the secrets engine will enable at the name of the engine. To
enable the secrets engine at a different path, use the `-path` argument.
The following warnings were returned from the Vault server:
* Read access to this endpoint should be controlled via ACLs as it will return the connection details as is, including passwords, if any.
```
1. Configure Vault with the proper plugin and connection information:
In this case, we've configured Vault with the user "sa" and password "Password!",
connecting to an instance at "localhost" on port 1433. It is not necessary
that Vault has the sa login, but the user must have privileges to create
logins and manage processes. The fixed server roles `securityadmin` and
`processadmin` are examples of built-in roles that grant these permissions. The
user also must have privileges to create database users and grant permissions in
the databases that Vault manages. The fixed database roles `db_accessadmin` and
`db_securityadmin` are examples or built-in roles that grant these permissions.
```text
$ vault write database/config/my-mssql-database \
plugin_name=mssql-database-plugin \
connection_url='sqlserver://sa:yourStrong(!)Password@localhost:1433' \
allowed_roles="my-role"
```
In this case, we've configured Vault with the user "sa" and password
"Password!", connecting to an instance at "localhost" on port 1433. It is
not necessary that Vault has the sa login, but the user must have privileges
to create logins and manage processes. The fixed server roles
`securityadmin` and `processadmin` are examples of built-in roles that grant
these permissions. The user also must have privileges to create database
users and grant permissions in the databases that Vault manages. The fixed
database roles `db_accessadmin` and `db_securityadmin` are examples or
built-in roles that grant these permissions.
Once the MSSQL connection is configured we can add a role:
1. Configure a role that maps a name in Vault to an SQL statement to execute to
create the database credential:
```
$ vault write database/roles/readonly \
db_name=mssql \
creation_statements="CREATE LOGIN [{{name}}] WITH PASSWORD = '{{password}}';\
CREATE USER [{{name}}] FOR LOGIN [{{name}}];\
GRANT SELECT ON SCHEMA::dbo TO [{{name}}];" \
default_ttl="1h" \
max_ttl="24h"
```text
$ vault write database/roles/my-role \
db_name=my-mssql-database \
creation_statements="CREATE LOGIN [{{name}}] WITH PASSWORD = '{{password}}';\
CREATE USER [{{name}}] FOR LOGIN [{{name}}];\
GRANT SELECT ON SCHEMA::dbo TO [{{name}}];" \
default_ttl="1h" \
max_ttl="24h"
Success! Data written to: database/roles/my-role
```
Success! Data written to: database/roles/readonly
```
## Usage
This role can now be used to retrieve a new set of credentials by querying the
"database/creds/readonly" endpoint.
After the secrets engine is configured and a user/machine has a Vault token with
the proper permission, it can generate credentials.
1. Generate a new credential by reading from the `/creds` endpoint with the name
of the role:
```text
$ vault read database/creds/my-role
Key Value
--- -----
lease_id database/creds/my-role/2f6a614c-4aa2-7b19-24b9-ad944a8d4de6
lease_duration 1h
lease_renewable true
password 8cab931c-d62e-a73d-60d3-5ee85139cd66
username v-root-e2978cd0-
```
## API
The full list of configurable options can be seen in the [MSSQL database
plugin API](/api/secret/databases/mssql.html) page.
For more information on the Database secret backend's HTTP API please see the [Database secret
backend API](/api/secret/databases/index.html) page.
For more information on the database secrets engine's HTTP API please see the
[Database secrets engine API](/api/secret/databases/index.html) page.

104
website/source/docs/secrets/databases/mysql-maria.html.md
View File

@ -1,19 +1,18 @@
---
layout: "docs"
page_title: "MySQL/MariaDB Database Plugin - Database Secret Backend"
page_title: "MySQL/MariaDB - Database - Secrets Engines"
sidebar_current: "docs-secrets-databases-mysql-maria"
description: |-
The MySQL/MariaDB plugin for Vault's Database backend generates database credentials to access MySQL and MariaDB servers.
MySQL is one of the supported plugins for the database secrets engine. This
plugin generates database credentials dynamically based on configured roles
for the MySQL database.
---
# MySQL/MariaDB Database Plugin
# MySQL/MariaDB Database Secrets Engine
Name: `mysql-database-plugin`, `mysql-aurora-database-plugin`, `mysql-rds-database-plugin`,
`mysql-legacy-database-plugin`
The MySQL Database Plugin is one of the supported plugins for the Database
backend. This plugin generates database credentials dynamically based on
configured roles for the MySQL database.
MySQL is one of the supported plugins for the database secrets engine. This
plugin generates database credentials dynamically based on configured roles for
the MySQL database.
This plugin has a few different instances built into vault, each instance is for
a slightly different MySQL driver. The only difference between these plugins is
@ -25,47 +24,60 @@ accept different lengths. The available plugins are:
- mysql-rds-database-plugin
- mysql-legacy-database-plugin
See the [Database Backend](/docs/secrets/databases/index.html) docs for more
information about setting up the Database Backend.
See the [database secrets engine](/docs/secrets/databases/index.html) docs for
more information about setting up the database secrets engine.
## Quick Start
## Setup
After the Database Backend is mounted you can configure a MySQL connection
by specifying this plugin as the `"plugin_name"` argument. Here is an example
configuration:
1. Enable the database secrets engine if it is not already enabled:
```
$ vault write database/config/mysql \
plugin_name=mysql-database-plugin \
connection_url="root:mysql@tcp(127.0.0.1:3306)/" \
allowed_roles="readonly"
```text
$ vault secrets enable database
Success! Enabled the database secrets engine at: database/
```
The following warnings were returned from the Vault server:
* Read access to this endpoint should be controlled via ACLs as it will return the connection details as is, including passwords, if any.
```
By default, the secrets engine will enable at the name of the engine. To
enable the secrets engine at a different path, use the `-path` argument.
Once the MySQL connection is configured we can add a role:
1. Configure Vault with the proper plugin and connection information:
```
$ vault write database/roles/readonly \
db_name=mysql \
creation_statements="CREATE USER '{{name}}'@'%' IDENTIFIED BY '{{password}}';GRANT SELECT ON *.* TO '{{name}}'@'%';" \
default_ttl="1h" \
max_ttl="24h"
```text
$ vault write database/config/my-mysql-database \
plugin_name=mysql-database-plugin \
connection_url="root:mysql@tcp(127.0.0.1:3306)/" \
allowed_roles="my-role"
```
Success! Data written to: database/roles/readonly
```
1. Configure a role that maps a name in Vault to an SQL statement to execute to
create the database credential:
This role can now be used to retrieve a new set of credentials by querying the
"database/creds/readonly" endpoint.
```text
$ vault write database/roles/my-role \
db_name=my-mysql-database \
creation_statements="CREATE USER '{{name}}'@'%' IDENTIFIED BY '{{password}}';GRANT SELECT ON *.* TO '{{name}}'@'%';" \
default_ttl="1h" \
max_ttl="24h"
Success! Data written to: database/roles/my-role
```
## API
## Usage
The full list of configurable options can be seen in the [MySQL database
plugin API](/api/secret/databases/mysql-maria.html) page.
After the secrets engine is configured and a user/machine has a Vault token with
the proper permission, it can generate credentials.
For more information on the Database secret backend's HTTP API please see the [Database secret
backend API](/api/secret/databases/index.html) page.
1. Generate a new credential by reading from the `/creds` endpoint with the name
of the role:
```text
$ vault read database/creds/my-role
Key Value
--- -----
lease_id database/creds/my-role/2f6a614c-4aa2-7b19-24b9-ad944a8d4de6
lease_duration 1h
lease_renewable true
password 8cab931c-d62e-a73d-60d3-5ee85139cd66
username v-root-e2978cd0-
```
## Examples
@ -77,7 +89,7 @@ This can be realized by using a wildcard in the grant statement. For example if
you want the user created by Vault to have access to all databases starting with
`fooapp_` you could use the following creation statement:
```
```text
CREATE USER '{{name}}'@'%' IDENTIFIED BY '{{password}}'; GRANT SELECT ON `fooapp\_%`.* TO '{{name}}'@'%';
```
@ -88,10 +100,18 @@ text between the backticks as something that must be executed. The easiest way t
get around this is to encode the creation statement as Base64 and feed this to Vault.
For example:
```
$ vault write database/roles/readonly \
```text
$ vault write database/roles/my-role \
db_name=mysql \
creation_statements="Q1JFQVRFIFVTRVIgJ3t7bmFtZX19J0AnJScgSURFTlRJRklFRCBCWSAne3twYXNzd29yZH19JzsgR1JBTlQgU0VMRUNUIE9OIGBmb29hcHBcXyVgLiogVE8gJ3t7bmFtZX19J0AnJSc7" \
default_ttl="1h" \
max_ttl="24h"
```
## API
The full list of configurable options can be seen in the [MySQL database plugin
API](/api/secret/databases/mysql-maria.html) page.
For more information on the database secrets engine's HTTP API please see the
[Database secrets engine API](/api/secret/databases/index.html) page.

108
website/source/docs/secrets/databases/oracle.html.md
View File

@ -1,23 +1,27 @@
---
layout: "docs"
page_title: "Oracle Database Plugin"
page_title: "Oracle - Database - Secrets Engines"
sidebar_current: "docs-secrets-databases-oracle"
description: |-
The Oracle Database plugin for Vault's Database backend generates database credentials to access Oracle Database severs.
Oracle is one of the supported plugins for the database secrets engine. This
plugin generates database credentials dynamically based on configured roles
for the Oracle database.
---
# Oracle Database Plugin
# Oracle Database Secrets Engine
Name: `vault-plugin-database-oracle`
Oracle is one of the supported plugins for the database secrets engine. This
plugin generates database credentials dynamically based on configured roles for
the Oracle database.
The Oracle Database Plugin is an external plugin for the Database
backend. This plugin generates database credentials dynamically based on
configured roles for the Oracle database.
The Oracle database plugin is not bundled in the core Vault code tree and can be
found at its own git repository here:
[hashicorp/vault-plugin-database-oracle](https://github.com/hashicorp/vault-plugin-database-oracle)
See the [Database Backend](/docs/secrets/databases/index.html) docs for more
information about setting up the Database Backend.
## Installation
## Setup
The Oracle Database Plugin does not live in the core Vault code tree and can be found
at its own git repository here: [hashicorp/vault-plugin-database-oracle](https://github.com/hashicorp/vault-plugin-database-oracle)
@ -27,54 +31,68 @@ library installed. These can be downloaded from Oracle. The libraries will need
be placed in the default library search path or somewhere defined in the
`LD_LIBRARY_PATH` environment variable.
## Quick Start
1. Enable the database secrets engine if it is not already enabled:
After the Database Backend is mounted you can run the plugin and configure a
connection to the Oracle Database.
```text
$ vault secrets enable database
Success! Enabled the database secrets engine at: database/
```
First the plugin must be built and registered to Vault's plugin catalog. To
build the plugin see the plugin's code repository. Once the plugin is built and
the binary is placed in Vault's plugin directory the catalog should be updated:
By default, the secrets engine will enable at the name of the engine. To
enable the secrets engine at a different path, use the `-path` argument.
```
$ vault write sys/plugins/catalog/vault-plugin-database-oracle \
sha_256=<expected SHA256 value> \
command=vault-plugin-database-oracle
```
1. Download and register the plugin:
Once the plugin exists in the plugin catalog the Database backend can configure
a connection for the Oracle Database:
```text
$ vault write sys/plugins/catalog/oracle-database-plugin \
sha_256="..." \
command=oracle-database-plugin
```
```
$ vault write database/config/oracle \
plugin_name=vault-plugin-database-oracle \
connection_url="system/Oracle@localhost:1521/OraDoc.localhost" \
allowed_roles="readonly"
1. Configure Vault with the proper plugin and connection information:
The following warnings were returned from the Vault server:
* Read access to this endpoint should be controlled via ACLs as it will return the connection details as is, including passwords, if any.
```
```text
$ vault write database/config/my-oracle-database \
plugin_name=oracle-database-plugin \
connection_url="system/Oracle@localhost:1521/OraDoc.localhost" \
allowed_roles="my-role"
```
Once the Oracle connection is configured we can add a role:
1. Configure a role that maps a name in Vault to an SQL statement to execute to
create the database credential:
```
$ vault write database/roles/readonly \
db_name=oracle \
creation_statements="CREATE USER {{name}} IDENTIFIED BY {{password}}; GRANT CONNECT TO {{name}}; GRANT CREATE SESSION TO {{name}};" \
default_ttl="1h" \
max_ttl="24h"
```text
$ vault write database/roles/my-role \
db_name=my-oracle-database \
creation_statements="CREATE USER {{name}} IDENTIFIED BY {{password}}; GRANT CONNECT TO {{name}}; GRANT CREATE SESSION TO {{name}};" \
default_ttl="1h" \
max_ttl="24h"
Success! Data written to: database/roles/my-role
```
Success! Data written to: database/roles/readonly
```
## Usage
This role can now be used to retrieve a new set of credentials by querying the
"database/creds/readonly" endpoint.
After the secrets engine is configured and a user/machine has a Vault token with
the proper permission, it can generate credentials.
1. Generate a new credential by reading from the `/creds` endpoint with the name
of the role:
```text
$ vault read database/creds/my-role
Key Value
--- -----
lease_id database/creds/my-role/2f6a614c-4aa2-7b19-24b9-ad944a8d4de6
lease_duration 1h
lease_renewable true
password 8cab931c-d62e-a73d-60d3-5ee85139cd66
username v-root-e2978cd0-
```
## API
The full list of configurable options can be seen in the [Oracle database
plugin API](/api/secret/databases/oracle.html) page.
For more information on the Database secret backend's HTTP API please see the [Database secret
backend API](/api/secret/databases/index.html) page.
The full list of configurable options can be seen in the [Oracle database plugin
API](/api/secret/databases/oracle.html) page.
For more information on the database secrets engine's HTTP API please see the
[Database secrets engine API](/api/secret/databases/index.html) page.

92
website/source/docs/secrets/databases/postgresql.html.md
View File

@ -1,59 +1,79 @@
---
layout: "docs"
page_title: "PostgreSQL Database Plugin - Database Secret Backend"
page_title: "PostgreSQL - Database - Secrets Engines"
sidebar_current: "docs-secrets-databases-postgresql"
description: |-
The PostgreSQL plugin for Vault's Database backend generates database credentials to access PostgreSQL.
PostgreSQL is one of the supported plugins for the database secrets engine.
This plugin generates database credentials dynamically based on configured
roles for the PostgreSQL database.
---
# PostgreSQL Database Plugin
# PostgreSQL Database Secrets Engine
Name: `postgresql-database-plugin`
PostgreSQL is one of the supported plugins for the database secrets engine. This
plugin generates database credentials dynamically based on configured roles for
the PostgreSQL database.
The PostgreSQL Database Plugin is one of the supported plugins for the Database
backend. This plugin generates database credentials dynamically based on
configured roles for the PostgreSQL database.
See the [database secrets engine](/docs/secrets/databases/index.html) docs for
more information about setting up the database secrets engine.
See the [Database Backend](/docs/secrets/databases/index.html) docs for more
information about setting up the Database Backend.
## Setup
## Quick Start
1. Enable the database secrets engine if it is not already enabled:
After the Database Backend is mounted you can configure a PostgreSQL connection
by specifying this plugin as the `"plugin_name"` argument. Here is an example
configuration:
```text
$ vault secrets enable database
Success! Enabled the database secrets engine at: database/
```
```
$ vault write database/config/postgresql \
plugin_name=postgresql-database-plugin \
allowed_roles="readonly" \
connection_url="postgresql://root:root@localhost:5432/"
By default, the secrets engine will enable at the name of the engine. To
enable the secrets engine at a different path, use the `-path` argument.
The following warnings were returned from the Vault server:
* Read access to this endpoint should be controlled via ACLs as it will return the connection details as is, including passwords, if any.
```
1. Configure Vault with the proper plugin and connection information:
Once the PostgreSQL connection is configured we can add a role. The PostgreSQL
plugin replaces `{{expiration}}` in statements with a formated timestamp:
```text
$ vault write database/config/my-postgresql-database \
plugin_name=postgresql-database-plugin \
allowed_roles="my-role" \
connection_url="postgresql://root:root@localhost:5432/"
```
```
$ vault write database/roles/readonly \
db_name=postgresql \
creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; \
GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
default_ttl="1h" \
max_ttl="24h"
1. Configure a role that maps a name in Vault to an SQL statement to execute to
create the database credential:
Success! Data written to: database/roles/readonly
```
```text
$ vault write database/roles/my-role \
db_name=my-postgresql-database \
creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; \
GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
default_ttl="1h" \
max_ttl="24h"
Success! Data written to: database/roles/my-role
```
This role can be used to retrieve a new set of credentials by querying the
"database/creds/readonly" endpoint.
## Usage
After the secrets engine is configured and a user/machine has a Vault token with
the proper permission, it can generate credentials.
1. Generate a new credential by reading from the `/creds` endpoint with the name
of the role:
```text
$ vault read database/creds/my-role
Key Value
--- -----
lease_id database/creds/my-role/2f6a614c-4aa2-7b19-24b9-ad944a8d4de6
lease_duration 1h
lease_renewable true
password 8cab931c-d62e-a73d-60d3-5ee85139cd66
username v-root-e2978cd0-
```
## API
The full list of configurable options can be seen in the [PostgreSQL database
plugin API](/api/secret/databases/postgresql.html) page.
For more information on the Database secret backend's HTTP API please see the [Database secret
backend API](/api/secret/databases/index.html) page.
For more information on the database secrets engine's HTTP API please see the
[Database secrets engine API](/api/secret/databases/index.html) page.

16
website/source/docs/secrets/identity/index.html.md
View File

@ -1,16 +1,16 @@
---
layout: "docs"
page_title: "Identity Secret Backend"
page_title: "Identity - Secrets Engines"
sidebar_current: "docs-secrets-identity"
description: |-
The Identity secret backend for Vault manages client identities.
The Identity secrets engine for Vault manages client identities.
---
# Identity Secret Backend
# Identity Secrets Engine
Name: `identity`
The Identity secret backend is the identity management solution for Vault. It
The Identity secrets engine is the identity management solution for Vault. It
internally maintains the clients who are recognized by Vault. Each client is
internally termed as an `Entity`. An entity can have multiple `Personas`. For
example, a single user who has accounts in both Github and LDAP, can be mapped
@ -30,11 +30,11 @@ entities are **an addition** to the existing capabilities of the token and
get inherited from entities are computed at request time. This provides
flexibility in controlling the access of tokens that are already issued.
This backend will be mounted by default. This backend cannot be unmounted or
remounted.
This secrets engine will be mounted by default. This secrets engine cannot be
unmounted or remounted.
## API
The Identity secret backend has a full HTTP API. Please see the
[Identity secret backend API](/api/secret/identity/index.html) for more
The Identity secrets engine has a full HTTP API. Please see the
[Identity secrets engine API](/api/secret/identity/index.html) for more
details.

99
website/source/docs/secrets/index.html.md
View File

@ -1,75 +1,66 @@
---
layout: "docs"
page_title: "Secret Backends"
page_title: "Secrets Engines"
sidebar_current: "docs-secrets"
description: |-
Secret backends are mountable backends that store or generate secrets in Vault.
Secrets engines are mountable engines that store or generate secrets in Vault.
---
# Secret Backends
# Secrets Engines
Secret backends are the components in Vault which store and generate
secrets.
Secrets engines are components which store, generate, or encrypt data. Secrets
engines are incredibly flexible, so it is easiest to think about them in terms
of their function. Secrets engines are provided some set of data, they take some
action on that data, and they return a result.
Some secret backends, such as "kv", simply store and read
secrets verbatim. Other secret backends, such as "aws", create _dynamic
secrets_: secrets that are made on demand.
Some secrets engines simply store and read data - like encrypted
Redis/Memcached. Other secrets engines connect to other services and generate
dynamic credentials on demand. Other secrets engines provide encryption as a
service, totp generation, certificates, and much more.
Secret backends are part of the
[mount system](#)
in Vault. They behave very similarly to a virtual filesystem:
any read/write/delete is sent to the secret backend, and the secret
backend can choose to react to that operation however it sees fit.
Secrets engines are enabled at a "path" in Vault. When a request comes to Vault,
the router automatically routes anything with the route prefix to the secrets
engine. In this way, each secrets engine defines its own paths and properties.
To the user, secrets engines behave similar to a virtual filesystem, supporting
operations like read, write, and delete.
For example, the "kv" backend passes through any operation back
to the configured storage backend for Vault. A "read" turns into a
"read" of the storage backend at the same path, a "write" turns into
a write, etc. This is a lot like a normal filesystem.
## Secrets Engines Lifecycle
The "aws" backend, on the other hand, behaves differently. When you
write to `aws/config/root`, it expects a certain format and stores that
information as configuration. You can't read from this path. When you
read from `aws/<name>`, it looks up an IAM policy named `<name>` and
generates AWS access credentials on demand and returns them. It doesn't
behave at all like a typical filesystem: you're not simply storing and
retrieving values, you're interacting with an API.
Most secrets engines can be enabled, disabled, tuned, and moved via the CLI or
API. Previous versions of Vault called these "mounts", but that term was
overloaded.
## Mounting/Unmounting Secret Backends
- **Enable** - This enables a secrets engine at a given path. With few
exceptions, secrets engines can be enabled at multiple paths. Each secrets
engine is isolated to its path. By default, they are enabled at their "type"
(e.g. "aws" enables at "aws/").
Secret backends can be mounted/unmounted using the CLI or the API.
There are three operations that can be performed with a secret backend
with regards to mounting:
- **Disable** - This disables an existing secrets engine. When a secrets engine
is disabled, all of its secrets are revoked (if they support it), and all of
the data stored for that engine in the physical storage layer is deleted.
* **Mount** - This mounts a new secret backend. Multiple secret
backends of the same type can be mounted at the same time by
specifying different mount points. By default, secret backends are
mounted to the same path as their name. This is what you want most
of the time.
- **Move** - This moves the path for an existing secrets engine. This process
revokes all secrets, since secret leases are tied to the path they were
created at. The configuration data stored for the engine persists through the
move.
* **Unmount** - This unmounts an existing secret backend. When a secret
backend is unmounted, all of its secrets are revoked (if they support
it), and all of the data stored for that backend in the physical storage
layer is deleted.
- **Tune** - This tunes global configuration for the secrets engine such as the
TTLs.
* **Remount** - This moves the mount point for an existing secret backend.
This revokes all secrets, since secret leases are tied to the path they
were created at. The data stored for the backend won't be deleted.
Once a secret backend is mounted, you can interact with it directly
at its mount point according to its own API. You can use the `vault path-help`
system to determine the paths it responds to.
Once a secrets engine is enabled, you can interact with it directly at its path
according to its own API. Use `vault path-help` to determine the paths it
responds to.
## Barrier View
An important concept around secret backends is that they receive a
_barrier view_ to the configured Vault physical storage. This is a lot
like a [chroot](https://en.wikipedia.org/wiki/Chroot).
Secrets engines receive a _barrier view_ to the configured Vault physical
storage. This is a lot like a [chroot](https://en.wikipedia.org/wiki/Chroot).
Whenever a secret backend is mounted, a random UUID is generated. This
becomes the data root for that backend. Whenever that backend writes to
the physical storage layer, it is prefixed with that UUID folder. Since
the Vault storage layer doesn't support relative access (such as `..`),
this makes it impossible for a mounted backend to access any other data.
When a secrets engine is enabled, a random UUID is generated. This becomes the
data root for that engine. Whenever that engine writes to the physical storage
layer, it is prefixed with that UUID folder. Since the Vault storage layer
doesn't support relative access (such as `../`), this makes it impossible for a
enabled secrets engine to access other data.
This is an important security feature in Vault: even a malicious backend
can't access the data from any other backend.
This is an important security feature in Vault - even a malicious engine
cannot access the data from any other engine.

116
website/source/docs/secrets/kv/index.html.md
View File

@ -1,77 +1,91 @@
---
layout: "docs"
page_title: "Key/Value Secret Backend"
page_title: "KV - Secrets Engines"
sidebar_current: "docs-secrets-kv"
description: |-
The key/value secret backend can store arbitrary secrets.
The KV secrets engine can store arbitrary secrets.
---
# Key/Value Secret Backend
# KV Secrets Engine
Name: `kv`
The `kv` secrets engine is used to store arbitrary secrets within the
configured physical storage for Vault.
The key/value secret backend is used to store arbitrary secrets within
the configured physical storage for Vault. If you followed along with
the getting started guide, you interacted with a key/value secret backend
via the `secret/` prefix that Vault mounts by default. You can mount as many
of these backends at different mount points as you like.
Writing to a key in the `kv` secrets engine will completely replace the old
value.
Writing to a key in the `kv` backend will replace the old value;
sub-fields are not merged together.
This backend honors the distinction between the `create` and `update`
This secrets engine honors the distinction between the `create` and `update`
capabilities inside ACL policies.
**Note**: Path and key names are _not_ obfuscated or encrypted; only the values
set on keys are. You should not store sensitive information as part of a
~> **Note**: Path and key names are _not_ obfuscated or encrypted; only the
values set on keys are. You should not store sensitive information as part of a
secret's path.
## Quick Start
## Setup
The kv backend allows for writing keys with arbitrary values. When data is
returned, the `lease_duration` field (in the API JSON) or `refresh_interval`
field (on the CLI) gives a hint as to how often a reader should look for a new
value. This comes from the value of the `default_lease_ttl` set on the mount,
or the system value.
Most secrets engines must be configured in advance before they can perform their
functions. These steps are usually completed by an operator or configuration
management tool.
There is one piece of special data handling: if a `ttl` key is provided, it
will be treated as normal data, but on read the backend will attempt to parse
it as a duration (either as a string like `1h` or an integer number of seconds
like `3600`). If successful, the backend will use this value in place of the
normal `lease_duration`. However, the given value will also still be returned
exactly as specified, so you are free to use that key in any way that you like
if it fits your input data.
The `kv` secrets engine is enabled by default at the path `secret/`. It can
be disabled, moved, or enabled multiple times at different paths. Each instance
of the KV secrets engine is isolated and unique.
The backend _never_ removes data on its own; the `ttl` key is merely advisory.
## Usage
As an example, we can write a new key "foo" to the kv backend mounted at
"secret/" by default:
After the secrets engine is configured and a user/machine has a Vault token with
the proper permission, it can generate credentials. The `kv` secrets engine
allows for writing keys with arbitrary values.
```
$ vault write secret/foo \
zip=zap \
ttl=1h
Success! Data written to: secret/foo
1. Write arbitrary data:
```text
$ vault write secret/my-secret my-value=s3cr3t
Success! Data written to: secret/my-secret
```
1. Read arbitrary data:
```text
$ vault read secret/my-secret
Key Value
--- -----
refresh_interval 768h
my-value s3cr3t
```
## TTLs
Unlike other secrets engines, the KV secrets engine does not enforce TTLs
for expiration. Instead, the `lease_duration` is a hint for how often consumers
should check back for a new value. This is commonly displayed as
`refresh_interval` instead of `lease_duration` to clarify this in output.
If provided a key of `ttl`, the KV secrets engine will utilize this value
as the lease duration:
```text
$ vault write secret/my-secret ttl=30m my-value=s3cr3t
Success! Data written to: secret/my-secret
```
This writes the key with the "zip" field set to "zap" and a one hour TTL.
We can test this by doing a read:
Even will a `ttl` set, the secrets engine _never_ removes data on its own. The
`ttl` key is merely advisory.
```
$ vault read secret/foo
Key Value
--- -----
refresh_interval 3600
ttl 1h
zip zap
```
When reading a value with a `ttl`, both the `ttl` key _and_ the refresh interval
will reflect the value:
As expected, we get the values previously set back as well as our custom TTL
both as specified and translated to seconds. The duration has been set to 3600
seconds (one hour) as specified.
```text
$ vault read secret/my-secret
Key Value
--- -----
refresh_interval 30m
my-value s3cr3t
ttl 30m
```
## API
The Key/Value secret backend has a full HTTP API. Please see the
[Key/Value secret backend API](/api/secret/kv/index.html) for more
The KV secrets engine has a full HTTP API. Please see the
[KV secrets engine API](/api/secret/kv/index.html) for more
details.

52
website/source/docs/secrets/mongodb/index.html.md
View File

@ -1,21 +1,19 @@
---
layout: "docs"
page_title: "MongoDB Secret Backend"
page_title: "MongoDB - Secrets Engines"
sidebar_current: "docs-secrets-mongodb"
description: |-
The mongodb secret backend for Vault generates database credentials to access MongoDB.
The mongodb secrets engine for Vault generates database credentials to access MongoDB.
---
# MongoDB Secret Backend
# MongoDB Secrets Engine
Name: `mongodb`
~> **Deprecation Note:** This secrets engine is deprecated in favor of the
combined databases secrets engine added in v0.7.1. See the documentation for
the new implementation of this secrets engine at
[MongoDB database plugin](/docs/secrets/databases/mongodb.html).
~> **Deprecation Note:** This backend is deprecated in favor of the
combined databases backend added in v0.7.1. See the documentation for
the new implementation of this backend at
[MongoDB Database Plugin](/docs/secrets/databases/mongodb.html).
The `mongodb` secret backend for Vault generates MongoDB database credentials
The `mongodb` secrets engine for Vault generates MongoDB database credentials
dynamically based on configured roles. This means that services that need
to access a MongoDB database no longer need to hard-code credentials: they
can request them from Vault and use Vault's leasing mechanism to more easily
@ -29,17 +27,17 @@ instance of a service based on the MongoDB username.
Vault makes use of its own internal revocation system to ensure that users
become invalid within a reasonable time of the lease expiring.
This page will show a quick start for this backend. For detailed documentation
on every path, use `vault path-help` after mounting the backend.
This page will show a quick start for this secrets engine. For detailed documentation
on every path, use `vault path-help` after mounting the secrets engine.
## Quick Start
The first step to using the mongodb backend is to mount it.
Unlike the `kv` backend, the `mongodb` backend is not mounted by default.
The first step to using the mongodb secrets engine is to mount it. Unlike the
`kv` secrets engine, the `mongodb` secrets engine is not mounted by default.
```
$ vault mount mongodb
Successfully mounted 'mongodb' at 'mongodb'!
$ vault secrets enable mongodb
Success! Enabled the mongodb secrets engine at: mongodb/
```
Next, we must tell Vault how to connect to MongoDB. This is done by providing
@ -105,26 +103,26 @@ the credentials path for that role:
```
$ vault read mongodb/creds/readonly
Key Value
--- -----
lease_id mongodb/creds/readonly/91685212-3040-7dde-48b1-df997c5dc8e7
lease_duration 3600
lease_renewable true
db foo
password c3faa86d-0f93-9649-de91-c431765e62dd
username vault-token-48729def-b0ca-2b17-d7b9-3ca7cb86f0ae
Key Value
--- -----
lease_id mongodb/creds/readonly/91685212-3040-7dde-48b1-df997c5dc8e7
lease_duration 3600
lease_renewable true
db foo
password c3faa86d-0f93-9649-de91-c431765e62dd
username vault-token-48729def-b0ca-2b17-d7b9-3ca7cb86f0ae
```
By reading from the `creds/readonly` path, Vault has generated a new set of
credentials using the `readonly` role configuration. Here we see the
dynamically generated username and password, along with a one hour lease.
Using ACLs, it is possible to restrict using the `mongodb` backend such that
Using ACLs, it is possible to restrict using the `mongodb` secrets engine such that
trusted operators can manage the role definitions, and both users and
applications are restricted in the credentials they are allowed to read.
## API
The MongoDB secret backend has a full HTTP API. Please see the
[MongoDB secret backend API](/api/secret/mongodb/index.html) for more
The MongoDB secrets engine has a full HTTP API. Please see the
[MongoDB secrets engine API](/api/secret/mongodb/index.html) for more
details.

47
website/source/docs/secrets/mssql/index.html.md
View File

@ -1,21 +1,19 @@
---
layout: "docs"
page_title: "MSSQL Secret Backend"
page_title: "MSSQL - Secrets Engines"
sidebar_current: "docs-secrets-mssql"
description: |-
The MSSQL secret backend for Vault generates database credentials to access Microsoft Sql Server.
The MSSQL secrets engine for Vault generates database credentials to access Microsoft Sql Server.
---
# MSSQL Secret Backend
# MSSQL Secrets Engine
Name: `mssql`
~> **Deprecation Note:** This secrets engine is deprecated in favor of the
combined databases secrets engine added in v0.7.1. See the documentation for
the new implementation of this secrets engine at
[MSSQL database plugin](/docs/secrets/databases/mssql.html).
~> **Deprecation Note:** This backend is deprecated in favor of the
combined databases backend added in v0.7.1. See the documentation for
the new implementation of this backend at
[MSSQL Database Plugin](/docs/secrets/databases/mssql.html).
The MSSQL secret backend for Vault generates database credentials
The MSSQL secrets engine for Vault generates database credentials
dynamically based on configured roles. This means that services that need
to access a database no longer need to hardcode credentials: they can request
them from Vault, and use Vault's leasing mechanism to more easily roll keys.
@ -28,17 +26,17 @@ instance of a service based on the SQL username.
Vault makes use of its own internal revocation system to ensure that users
become invalid within a reasonable time of the lease expiring.
This page will show a quick start for this backend. For detailed documentation
on every path, use `vault path-help` after mounting the backend.
This page will show a quick start for this secrets engine. For detailed documentation
on every path, use `vault path-help` after mounting the secrets engine.
## Quick Start
The first step to using the mssql backend is to mount it.
Unlike the `kv` backend, the `mssql` backend is not mounted by default.
The first step to using the mssql secrets engine is to mount it. Unlike the `kv`
secrets engine, the `mssql` secrets engine is not mounted by default.
```
$ vault mount mssql
Successfully mounted 'mssql' at 'mssql'!
$ vault secrets enable mssql
Success! Enabled the mssql secrets engine at: mssql/
```
Next, we must configure Vault to know how to connect to the MSSQL
@ -96,11 +94,12 @@ To generate a new set of credentials, we simply read from that role:
```
$ vault read mssql/creds/readonly
Key Value
lease_id mssql/creds/readonly/cdf23ac8-6dbd-4bf9-9919-6acaaa86ba6c
lease_duration 3600
password ee202d0d-e4fd-4410-8d14-2a78c5c8cb76
username root-a147d529-e7d6-4a16-8930-4c3e72170b19
Key Value
--- -----
lease_id mssql/creds/readonly/cdf23ac8-6dbd-4bf9-9919-6acaaa86ba6c
lease_duration 3600
password ee202d0d-e4fd-4410-8d14-2a78c5c8cb76
username root-a147d529-e7d6-4a16-8930-4c3e72170b19
```
By reading from the `creds/readonly` path, Vault has generated a new
@ -108,13 +107,13 @@ set of credentials using the `readonly` role configuration. Here we
see the dynamically generated username and password, along with a one
hour lease.
Using ACLs, it is possible to restrict using the mssql backend such
Using ACLs, it is possible to restrict using the mssql secrets engine such
that trusted operators can manage the role definitions, and both
users and applications are restricted in the credentials they are
allowed to read.
## API
The MSSQL secret backend has a full HTTP API. Please see the
[MSSQL secret backend API](/api/secret/mssql/index.html) for more
The MSSQL secrets engine has a full HTTP API. Please see the
[MSSQL secrets engine API](/api/secret/mssql/index.html) for more
details.

45
website/source/docs/secrets/mysql/index.html.md
View File

@ -1,21 +1,21 @@
---
layout: "docs"
page_title: "MySQL Secret Backend"
page_title: "MySQL - Secrets Engines"
sidebar_current: "docs-secrets-mysql"
description: |-
The MySQL secret backend for Vault generates database credentials to access MySQL.
The MySQL secrets engine for Vault generates database credentials to access MySQL.
---
# MySQL Secret Backend
# MySQL Secrets Engine
Name: `mysql`
~> **Deprecation Note:** This backend is deprecated in favor of the
combined databases backend added in v0.7.1. See the documentation for
the new implementation of this backend at
[MySQL/MariaDB Database Plugin](/docs/secrets/databases/mysql-maria.html).
~> **Deprecation Note:** This secrets engine is deprecated in favor of the
combined databases secrets engine added in v0.7.1. See the documentation for
the new implementation of this secrets engine at
[MySQL/MariaDB database plugin](/docs/secrets/databases/mysql-maria.html).
The MySQL secret backend for Vault generates database credentials
The MySQL secrets engine for Vault generates database credentials
dynamically based on configured roles. This means that services that need
to access a database no longer need to hardcode credentials: they can request
them from Vault, and use Vault's leasing mechanism to more easily roll keys.
@ -28,17 +28,17 @@ instance of a service based on the SQL username.
Vault makes use of its own internal revocation system to ensure that users
become invalid within a reasonable time of the lease expiring.
This page will show a quick start for this backend. For detailed documentation
on every path, use `vault path-help` after mounting the backend.
This page will show a quick start for this secrets engine. For detailed documentation
on every path, use `vault path-help` after mounting the secrets engine.
## Quick Start
The first step to using the mysql backend is to mount it.
Unlike the `kv` backend, the `mysql` backend is not mounted by default.
The first step to using the mysql secrets engine is to mount it. Unlike the `kv`
secrets engine, the `mysql` secrets engine is not mounted by default.
```
$ vault mount mysql
Successfully mounted 'mysql' at 'mysql'!
$ vault secrets enable mysql
Success! Enabled the mysql secrets engine at: mysql/
```
Next, we must configure Vault to know how to connect to the MySQL
@ -95,11 +95,12 @@ To generate a new set of credentials, we simply read from that role:
```
$ vault read mysql/creds/readonly
Key Value
lease_id mysql/creds/readonly/bd404e98-0f35-b378-269a-b7770ef01897
lease_duration 3600
password 132ae3ef-5a64-7499-351e-bfe59f3a2a21
username readonly-aefa635a-18
Key Value
--- -----
lease_id mysql/creds/readonly/bd404e98-0f35-b378-269a-b7770ef01897
lease_duration 3600
password 132ae3ef-5a64-7499-351e-bfe59f3a2a21
username readonly-aefa635a-18
```
By reading from the `creds/readonly` path, Vault has generated a new
@ -107,7 +108,7 @@ set of credentials using the `readonly` role configuration. Here we
see the dynamically generated username and password, along with a one
hour lease.
Using ACLs, it is possible to restrict using the mysql backend such
Using ACLs, it is possible to restrict using the mysql secrets engine such
that trusted operators can manage the role definitions, and both
users and applications are restricted in the credentials they are
allowed to read.
@ -124,6 +125,6 @@ the default on versions prior to that.
## API
The MySQL secret backend has a full HTTP API. Please see the
[MySQL secret backend API](/api/secret/mysql/index.html) for more
The MySQL secrets engine has a full HTTP API. Please see the
[MySQL secrets engine API](/api/secret/mysql/index.html) for more
details.

481
website/source/docs/secrets/pki/index.html.md
View File

@ -1,42 +1,133 @@
---
layout: "docs"
page_title: "PKI Secret Backend"
page_title: "PKI - Secrets Engines"
sidebar_current: "docs-secrets-pki"
description: |-
The PKI secret backend for Vault generates TLS certificates.
The PKI secrets engine for Vault generates TLS certificates.
---
# PKI Secret Backend
# PKI Secrets Engine
Name: `pki`
The PKI secret backend for Vault generates X.509 certificates dynamically based
on configured roles. This means services can get certificates needed for both
client and server authentication without going through the usual manual process
of generating a private key and CSR, submitting to a CA, and waiting for a
verification and signing process to complete. Vault's built-in authentication
The PKI secrets engine generates dynamic X.509 certificates. With this secrets
engine, services can get certificates without going through the usual manual
process of generating a private key and CSR, submitting to a CA, and waiting for
a verification and signing process to complete. Vault's built-in authentication
and authorization mechanisms provide the verification functionality.
By keeping TTLs relatively short, revocations are less likely to be needed,
keeping CRLs short and helping the backend scale to large workloads. This in
turn allows each instance of a running application to have a unique
keeping CRLs short and helping the secrets engine scale to large workloads. This
in turn allows each instance of a running application to have a unique
certificate, eliminating sharing and the accompanying pain of revocation and
rollover.
In addition, by allowing revocation to mostly be forgone, this backend allows
for ephemeral certificates; certificates can be fetched and stored in memory
upon application startup and discarded upon shutdown, without ever being
In addition, by allowing revocation to mostly be forgone, this secrets engine
allows for ephemeral certificates. Certificates can be fetched and stored in
memory upon application startup and discarded upon shutdown, without ever being
written to disk.
This page will show a quick start for this backend. For detailed documentation
on every path, use `vault path-help` after mounting the backend.
## Setup
Most secrets engines must be configured in advance before they can perform their
functions. These steps are usually completed by an operator or configuration
management tool.
1. Enable the PKI secrets engine:
```text
$ vault secrets enable pki
Success! Enabled the pki secrets engine at: pki/
```
By default, the secrets engine will mount at the name of the engine. To
enable the secrets engine at a different path, use the `-path` argument.
1. Increase the TTL by tuning the secrets engine. The default value of 30 days may be too short, so increase it to 1 year:
```text
$ vault secrets tune -max-lease-ttl=8760h pki
Success! Tuned the secrets engine at: pki/
```
Note that individual roles can restrict this value to be shorter on a
per-certificate basis. This just configures the global maximum for this
secrets engine.
1. Configure a CA certificate and private key. Vault can accept an existing key
pair, or it can generate its own self-signed root. In general, we recommend
maintaining your root CA outside of Vault and providing Vault a signed
intermediate CA.
```text
$ vault write pki/root/generate/internal \
common_name=my-website.com \
ttl=8760h
Key Value
--- -----
certificate -----BEGIN CERTIFICATE-----...
expiration 1536807433
issuing_ca -----BEGIN CERTIFICATE-----...
serial_number 7c:f1:fb:2c:6e:4d:99:0e:82:1b:08:0a:81:ed:61:3e:1d:fa:f5:29
```
The returned certificate is purely informative. The private key is safely
stored internally in Vault.
1. Update the CRL location and issuing certificates. These values can be updated
in the future.
```text
$ vault write pki/config/urls \
issuing_certificates="http://127.0.0.1:8200/v1/pki/ca" \
crl_distribution_points="http://127.0.0.1:8200/v1/pki/crl"
Success! Data written to: pki/config/urls
```
1. Configure a role that maps a name in Vault to a procedure for generating a
certificate. When users or machines generate credentials, they are generated
against this role:
```text
$ vault write pki/roles/my-role \
allowed_domains=my-website.com \
allow_subdomains=true \
max_ttl=72h
Success! Data written to: pki/roles/my-role
```
## Usage
After the secrets engine is configured and a user/machine has a Vault token with
the proper permission, it can generate credentials.
1. Generate a new credential by writing to the `/issue` endpoint with the name
of the role:
```text
$ vault write pki/issue/my-role \
common_name=www.my-website.com
Key Value
--- -----
certificate -----BEGIN CERTIFICATE-----...
issuing_ca -----BEGIN CERTIFICATE-----...
private_key -----BEGIN RSA PRIVATE KEY-----...
private_key_type rsa
serial_number 1d:2e:c6:06:45:18:60:0e:23:d6:c5:17:43:c0:fe:46:ed:d1:50:be
```
The output will include a dynamically generated private key and certificate
which corresponds to the given role and expires in 72h (as dictated by our
role definition). The issuing CA and trust chain is also returned for
automation simplicity.
## Considerations
To successfully deploy this backend, there are a number of important
To successfully deploy this secrets engine, there are a number of important
considerations to be aware of, as well as some preparatory steps that should be
undertaken. You should read all of these *before* using this backend or
generating the CA to use with this backend.
undertaken. You should read all of these *before* using this secrets engine or
generating the CA to use with this secrets engine.
### Be Careful with Root CAs
@ -46,342 +137,86 @@ Vault, don't put it in Vault as well; instead, issue a shorter-lived
intermediate CA certificate and put this into Vault. This aligns with industry
best practices.
Since 0.4, the backend supports generating self-signed root CAs and creating
and signing CSRs for intermediate CAs. In each instance, for security reasons,
the private key can *only* be exported at generation time, and the ability to
do so is part of the command path (so it can be put into ACL policies).
Since 0.4, the secrets engine supports generating self-signed root CAs and
creating and signing CSRs for intermediate CAs. In each instance, for security
reasons, the private key can *only* be exported at generation time, and the
ability to do so is part of the command path (so it can be put into ACL
policies).
If you plan on using intermediate CAs with Vault, it is suggested that you let
Vault create CSRs and do not export the private key, then sign those with your
root CA (which may be a second mount of the `pki` backend).
root CA (which may be a second mount of the `pki` secrets engine).
### One CA Certificate, One Backend
### One CA Certificate, One Secrets Engine
In order to vastly simplify both the configuration and codebase of the PKI
backend, only one CA certificate is allowed per backend. If you want to issue
certificates from multiple CAs, mount the PKI backend at multiple mount points
with separate CA certificates in each.
secrets engine, only one CA certificate is allowed per secrets engine. If you
want to issue certificates from multiple CAs, mount the PKI secrets engine at
multiple mount points with separate CA certificates in each.
This also provides a convenient method of switching to a new CA certificate
while keeping CRLs valid from the old CA certificate; simply mount a new
backend and issue from there.
while keeping CRLs valid from the old CA certificate; simply mount a new secrets
engine and issue from there.
A common pattern is to have one mount act as your root CA and to use this CA
only to sign intermediate CA CSRs from other PKI mounts.
### Keep certificate lifetimes short, for CRL's sake
This backend aligns with Vault's philosophy of short-lived secrets. As such it
is not expected that CRLs will grow large; the only place a private key is ever
returned is to the requesting client (this backend does *not* store generated
private keys, except for CA certificates). In most cases, if the key is lost,
the certificate can simply be ignored, as it will expire shortly.
This secrets engine aligns with Vault's philosophy of short-lived secrets. As
such it is not expected that CRLs will grow large; the only place a private key
is ever returned is to the requesting client (this secrets engine does *not*
store generated private keys, except for CA certificates). In most cases, if the
key is lost, the certificate can simply be ignored, as it will expire shortly.
If a certificate must truly be revoked, the normal Vault revocation function
can be used; alternately a root token can be used to revoke the certificate
using the certificate's serial number. Any revocation action will cause the CRL
to be regenerated. When the CRL is regenerated, any expired certificates are
removed from the CRL (and any revoked, expired certificate are removed from
backend storage).
If a certificate must truly be revoked, the normal Vault revocation function can
be used; alternately a root token can be used to revoke the certificate using
the certificate's serial number. Any revocation action will cause the CRL to be
regenerated. When the CRL is regenerated, any expired certificates are removed
from the CRL (and any revoked, expired certificate are removed from secrets
engine storage).
This backend does not support multiple CRL endpoints with sliding date windows;
often such mechanisms will have the transition point a few days apart, but this
gets into the expected realm of the actual certificate validity periods issued
from this backend. A good rule of thumb for this backend would be to simply not
issue certificates with a validity period greater than your maximum comfortable
CRL lifetime. Alternately, you can control CRL caching behavior on the client
to ensure that checks happen more often.
This secrets engine does not support multiple CRL endpoints with sliding date
windows; often such mechanisms will have the transition point a few days apart,
but this gets into the expected realm of the actual certificate validity periods
issued from this secrets engine. A good rule of thumb for this secrets engine
would be to simply not issue certificates with a validity period greater than
your maximum comfortable CRL lifetime. Alternately, you can control CRL caching
behavior on the client to ensure that checks happen more often.
Often multiple endpoints are used in case a single CRL endpoint is down so that
clients don't have to figure out what to do with a lack of response. Run Vault
in HA mode, and the CRL endpoint should be available even if a particular node
clients don't have to figure out what to do with a lack of response. Run Vault in HA mode, and the CRL endpoint should be available even if a particular node
is down.
### You must configure issuing/CRL/OCSP information *in advance*
This backend serves CRLs from a predictable location, but it is not possible
for the backend to know where it is running. Therefore, you must configure
desired URLs for the issuing certificate, CRL distribution points, and OCSP
servers manually using the `config/urls` endpoint. It is supported to have more
than one of each of these by passing in the multiple URLs as a comma-separated
string parameter.
This secrets engine serves CRLs from a predictable location, but it is not
possible for the secrets engine to know where it is running. Therefore, you must
configure desired URLs for the issuing certificate, CRL distribution points, and
OCSP servers manually using the `config/urls` endpoint. It is supported to have
more than one of each of these by passing in the multiple URLs as a
comma-separated string parameter.
### Safe Minimums
Since its inception, this backend has enforced SHA256 for signature hashes
rather than SHA1. As of 0.5.1, a minimum of 2048 bits for RSA keys is also
enforced. Software that can handle SHA256 signatures should also be able to
handle 2048-bit keys, and 1024-bit keys are considered unsafe and are
disallowed in the Internet PKI.
Since its inception, this secrets engine has enforced SHA256 for signature
hashes rather than SHA1. As of 0.5.1, a minimum of 2048 bits for RSA keys is
also enforced. Software that can handle SHA256 signatures should also be able to
handle 2048-bit keys, and 1024-bit keys are considered unsafe and are disallowed
in the Internet PKI.
### Token Lifetimes and Revocation
When a token expires, it revokes all leases associated with it. This means that
long-lived CA certs need correspondingly long-lived tokens, something that is
easy to forget. Starting with 0.6, root and intermediate CA certs no longer
have associated leases, to prevent unintended revocation when not using a token
with a long enough lifetime. To revoke these certificates, use the `pki/revoke`
easy to forget. Starting with 0.6, root and intermediate CA certs no longer have
associated leases, to prevent unintended revocation when not using a token with
a long enough lifetime. To revoke these certificates, use the `pki/revoke`
endpoint.
## Quick Start
#### Mount the backend
The first step to using the PKI backend is to mount it. Unlike the `kv`
backend, the `pki` backend is not mounted by default.
```text
$ vault mount pki
Successfully mounted 'pki' at 'pki'!
```
#### Configure a CA certificate
Next, Vault must be configured with a CA certificate and associated private
key. We'll take advantage of the backend's self-signed root generation support,
but Vault also supports generating an intermediate CA (with a CSR for signing)
or setting a PEM-encoded certificate and private key bundle directly into the
backend.
Generally you'll want a root certificate to only be used to sign CA
intermediate certificates, but for this example we'll proceed as if you will
issue certificates directly from the root. As it's a root, we'll want to set a
long maximum life time for the certificate; since it honors the maximum mount
TTL, first we adjust that:
```text
$ vault mount-tune -max-lease-ttl=87600h pki
Successfully tuned mount 'pki'!
```
That sets the maximum TTL for secrets issued from the mount to 10 years. (Note
that roles can further restrict the maximum TTL.)
Now, we generate our root certificate:
```text
$ vault write pki/root/generate/internal common_name=myvault.com ttl=87600h
Key Value
certificate -----BEGIN CERTIFICATE-----
MIIDvTCCAqWgAwIBAgIUAsza+fvOw+Xh9ifYQ0gNN0ruuWcwDQYJKoZIhvcNAQEL
BQAwFjEUMBIGA1UEAxMLbXl2YXVsdC5jb20wHhcNMTUxMTE5MTYwNDU5WhcNMjUx
MTE2MTYwNDU5WjAWMRQwEgYDVQQDEwtteXZhdWx0LmNvbTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMUhH4OLf/sa6GuJONGC/CWLY7nDbfH8jAaCKgqV
eJ81KrmcgP8WPhoFsYHFQEQXQZcrJagwYfm19jYn3CaqrYPbciv9bcWi+ECxZV3x
Hs/YdCFk7KgDGCci37w+cy6fSB943FKJqqVbvPv0odmq6LvgGGgneznvuvkIrOWG
qVDrDdvbEZ01XAyzUQJaaiJXExN+6xm1HcBoypCP8ZjjnXHcFQvw2QBItLRU7iUd
ESFgbrkrSPW3HA6KF0ov2qFMoHTiQ6aM4KaHPmXcFPicugYR9owZfZ4lwWJCqT7j
EkhokaMgHnvyRScuiRZhQm8ppHZoYsqrc3glfEuxGHkS+0cCAwEAAaOCAQEwgf4w
DgYDVR0PAQH/BAQDAgGuMBMGA1UdJQQMMAoGCCsGAQUFBwMJMA8GA1UdEwEB/wQF
MAMBAf8wHQYDVR0OBBYEFLvAbt0eUUOoo7hjKiQM2bRqDKrZMB8GA1UdIwQYMBaA
FLvAbt0eUUOoo7hjKiQM2bRqDKrZMDsGCCsGAQUFBwEBBC8wLTArBggrBgEFBQcw
AoYfaHR0cDovLzEyNy4wLjAuMTo4MjAwL3YxL3BraS9jYTAWBgNVHREEDzANggtt
eXZhdWx0LmNvbTAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vMTI3LjAuMC4xOjgy
MDAvdjEvcGtpL2NybDANBgkqhkiG9w0BAQsFAAOCAQEAVSgIRl6XJs95D7iXGzeQ
Ab8OIei779k0pD7xxS/+knY3TM6733zL/LXs4BEL3wfcQWoDrMtCW0Ook455sAOE
PSnTaZYQSH/F74VawWhSee4ZyiWq+sTUI4IzqYG3IS36mCyb0t6RxEb3aoQ87WHs
BHIB6uWbj6WoGHYM8ESxY89aY9jnX3xSs1HuluVW1uPrpIoa/eudpyV40Y1+9RNM
6fCX5LHGM7vKYxqvudYe+7G1MdKVBQg17h6XuieiUswVt2/HvDlNr+9DHrUla9Ve
Ig43v+grirlG7DrAr6Aiu/MVWKJP6CvNwG/XzrGaqd6KqSsE+8oIGR9tCTuPxI6v
SQ==
-----END CERTIFICATE-----
expiration 1.763309099e+09
issuing_ca -----BEGIN CERTIFICATE-----
MIIDvTCCAqWgAwIBAgIUAsza+fvOw+Xh9ifYQ0gNN0ruuWcwDQYJKoZIhvcNAQEL
BQAwFjEUMBIGA1UEAxMLbXl2YXVsdC5jb20wHhcNMTUxMTE5MTYwNDU5WhcNMjUx
MTE2MTYwNDU5WjAWMRQwEgYDVQQDEwtteXZhdWx0LmNvbTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMUhH4OLf/sa6GuJONGC/CWLY7nDbfH8jAaCKgqV
eJ81KrmcgP8WPhoFsYHFQEQXQZcrJagwYfm19jYn3CaqrYPbciv9bcWi+ECxZV3x
Hs/YdCFk7KgDGCci37w+cy6fSB943FKJqqVbvPv0odmq6LvgGGgneznvuvkIrOWG
qVDrDdvbEZ01XAyzUQJaaiJXExN+6xm1HcBoypCP8ZjjnXHcFQvw2QBItLRU7iUd
ESFgbrkrSPW3HA6KF0ov2qFMoHTiQ6aM4KaHPmXcFPicugYR9owZfZ4lwWJCqT7j
EkhokaMgHnvyRScuiRZhQm8ppHZoYsqrc3glfEuxGHkS+0cCAwEAAaOCAQEwgf4w
DgYDVR0PAQH/BAQDAgGuMBMGA1UdJQQMMAoGCCsGAQUFBwMJMA8GA1UdEwEB/wQF
MAMBAf8wHQYDVR0OBBYEFLvAbt0eUUOoo7hjKiQM2bRqDKrZMB8GA1UdIwQYMBaA
FLvAbt0eUUOoo7hjKiQM2bRqDKrZMDsGCCsGAQUFBwEBBC8wLTArBggrBgEFBQcw
AoYfaHR0cDovLzEyNy4wLjAuMTo4MjAwL3YxL3BraS9jYTAWBgNVHREEDzANggtt
eXZhdWx0LmNvbTAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vMTI3LjAuMC4xOjgy
MDAvdjEvcGtpL2NybDANBgkqhkiG9w0BAQsFAAOCAQEAVSgIRl6XJs95D7iXGzeQ
Ab8OIei779k0pD7xxS/+knY3TM6733zL/LXs4BEL3wfcQWoDrMtCW0Ook455sAOE
PSnTaZYQSH/F74VawWhSee4ZyiWq+sTUI4IzqYG3IS36mCyb0t6RxEb3aoQ87WHs
BHIB6uWbj6WoGHYM8ESxY89aY9jnX3xSs1HuluVW1uPrpIoa/eudpyV40Y1+9RNM
6fCX5LHGM7vKYxqvudYe+7G1MdKVBQg17h6XuieiUswVt2/HvDlNr+9DHrUla9Ve
Ig43v+grirlG7DrAr6Aiu/MVWKJP6CvNwG/XzrGaqd6KqSsE+8oIGR9tCTuPxI6v
SQ==
-----END CERTIFICATE-----
serial_number 02:cc:da:f9:fb:ce:c3:e5:e1:f6:27:d8:43:48:0d:37:4a:ee:b9:67
```
The returned certificate is purely informational; it and its private key are
safely stored in the backend mount.
#### Set URL configuration
Generated certificates can have the CRL location and the location of the
issuing certificate encoded. These values must be set manually, but can be
changed at any time.
```text
$ vault write pki/config/urls issuing_certificates="http://127.0.0.1:8200/v1/pki/ca" crl_distribution_points="http://127.0.0.1:8200/v1/pki/crl"
Success! Data written to: pki/ca/urls
```
#### Configure a role
The next step is to configure a role. A role is a logical name that maps to a
policy used to generate those credentials. For example, let's create an
"example-dot-com" role:
```text
$ vault write pki/roles/example-dot-com \
allowed_domains="example.com" \
allow_subdomains="true" max_ttl="72h"
Success! Data written to: pki/roles/example-dot-com
```
#### Generate credentials
By writing to the `roles/example-dot-com` path we are defining the
`example-dot-com` role. To generate a new set of credentials, we simply write
to the `issue` endpoint with that role name: Vault is now configured to create
and manage certificates!
```text
$ vault write pki/issue/example-dot-com \
common_name=blah.example.com
Key Value
--- -----
lease_id pki/issue/example-dot-com/6d8ab3e2-ce31-8821-81e4-740a498af51d
lease_duration 259199
lease_renewable false
certificate -----BEGIN CERTIFICATE-----
MIIDbDCCAlSgAwIBAgIUPiAyxq+nIE6xlWf7hrzLkPQxtvMwDQYJKoZIhvcNAQEL
BQAwMzExMC8GA1UEAxMoVmF1bHQgVGVzdGluZyBJbnRlcm1lZGlhdGUgU3ViIEF1
dGhvcml0eTAeFw0xNjA5MjcwMDA5MTNaFw0xNjA5MjcwMTA5NDNaMBsxGTAXBgNV
BAMTEGJsYWguZXhhbXBsZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQDJAYB04IVdmSC/TimaA6BbXlvgBTZHL5wBUTmO4iHhenL0eDEXVe2Fd7Yq
75LiBJmcC96hKbqh5rwS8KwN9ElZI52/mSMC+IvoNlYHAf7shwfsjrVx3q7/bTFg
lz6wECn1ugysxynmMvgQD/pliRkxTQ7RMh4Qlh75YG3R9BHy9ZddklZp0aNaitts
0uufHnN1UER/wxBCZdWTUu34KDL9I6yE7Br0slKKHPdEsGlFcMkbZhvjslZ7DGvO
974S0qtOdKiawJZbpNPg0foGZ3AxesDUlkHmmgzUNes/sjknDYTHEfeXM6Uap0j6
XvyhCxqdeahb/Vtibg0z9I0IusJbAgMBAAGjgY8wgYwwDgYDVR0PAQH/BAQDAgOo
MB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAdBgNVHQ4EFgQU/5oy0rL7
TT0wX7KZK7qcXqgayNwwHwYDVR0jBBgwFoAUgM37P8oXmA972ztLfw+b1eIY5now
GwYDVR0RBBQwEoIQYmxhaC5leGFtcGxlLmNvbTANBgkqhkiG9w0BAQsFAAOCAQEA
CT2vI6/taeLTw6ZulUhLXEXYXWZu1gF8n2COjZzbZXmHxQAoZ3GtnSNwacPHAyIj
f3cA9Moo552y39LUtWk+wgFtQokWGK7LXglLaveNUBowOHq/xk0waiIinJcgTG53
Z/qnbJnTjAOG7JwVJplWUIiS1avCksrHt7heE2EGRGJALqyLZ119+PW6ogtCLUv1
X8RCTw/UkIF/LT+sLF0bXWy4Hn38Gjwj1MVv1l76cEGOVSHyrYkN+6AMnAP58L5+
IWE9tN3oac4x7jhbuNpfxazIJ8Q6l/Up5U5Evfbh6N1DI0/gFCP20fMBkHwkuLfZ
2ekZoSeCgFRDlHGkr7Vv9w==
-----END CERTIFICATE-----
issuing_ca -----BEGIN CERTIFICATE-----
MIIDijCCAnKgAwIBAgIUB28DoGwgGFKL7fbOu9S4FalHLn0wDQYJKoZIhvcNAQEL
BQAwLzEtMCsGA1UEAxMkVmF1bHQgVGVzdGluZyBJbnRlcm1lZGlhdGUgQXV0aG9y
aXR5MB4XDTE2MDkyNzAwMDgyMVoXDTI2MDkxNjE2MDg1MVowMzExMC8GA1UEAxMo
VmF1bHQgVGVzdGluZyBJbnRlcm1lZGlhdGUgU3ViIEF1dGhvcml0eTCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBAOSCiSij4wy1wiMwvZt+rtU3IaO6ZTn9
LfIPuGsR5/QSJk37pCZQco1LgoE/rTl+/xu3bDovyHDmgObghC6rzVOX2Tpi7kD+
DOZpqxOsaS8ebYgxB/XJTSxyEJuSAcpSNLqqAiZivuQXdaD0N7H3Or0awwmKE9mD
I0g8CF4fPDmuuOG0ASn9fMqXVVt5tXtEqZ9yJYfNOXx3FOPjRVOZf+kvSc31wCKe
i/KmR0AQOmToKMzq988nLqFPTi9KZB8sEU20cGFeTQFol+m3FTcIru94EPD+nLUn
xtlLELVspYb/PP3VpvRj9b+DY8FGJ5nfSJl7Rkje+CD4VxJpSadin3kCAwEAAaOB
mTCBljAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQU
gM37P8oXmA972ztLfw+b1eIY5nowHwYDVR0jBBgwFoAUj4YAIxRwrBy0QMRKLnD0
kVidIuYwMwYDVR0RBCwwKoIoVmF1bHQgVGVzdGluZyBJbnRlcm1lZGlhdGUgU3Vi
IEF1dGhvcml0eTANBgkqhkiG9w0BAQsFAAOCAQEAA4buJuPNJvA1kiATLw1dVU2J
HPubk2Kp26Mg+GwLn7Vz45Ub133JCYfF3/zXLFZZ5Yub9gWTtjScrvNfQTAbNGdQ
BdnUlMmIRmfB7bfckhryR2R9byumeHATgNKZF7h8liNHI7X8tTzZGs6wPdXOLlzR
TlM3m1RNK8pbSPOkfPb06w9cBRlD8OAbNtJmuypXA6tYyiiMYBhP0QLAO3i4m1ns
aAjAgEjtkB1rQxW5DxoTArZ0asiIdmIcIGmsVxfDQIjFlRxAkafMs74v+5U5gbBX
wsOledU0fLl8KLq8W3OXqJwhGLK65fscrP0/omPAcFgzXf+L4VUADM4XhW6Xyg==
-----END CERTIFICATE-----
ca_chain [-----BEGIN CERTIFICATE-----
MIIDijCCAnKgAwIBAgIUB28DoGwgGFKL7fbOu9S4FalHLn0wDQYJKoZIhvcNAQEL
BQAwLzEtMCsGA1UEAxMkVmF1bHQgVGVzdGluZyBJbnRlcm1lZGlhdGUgQXV0aG9y
aXR5MB4XDTE2MDkyNzAwMDgyMVoXDTI2MDkxNjE2MDg1MVowMzExMC8GA1UEAxMo
VmF1bHQgVGVzdGluZyBJbnRlcm1lZGlhdGUgU3ViIEF1dGhvcml0eTCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBAOSCiSij4wy1wiMwvZt+rtU3IaO6ZTn9
LfIPuGsR5/QSJk37pCZQco1LgoE/rTl+/xu3bDovyHDmgObghC6rzVOX2Tpi7kD+
DOZpqxOsaS8ebYgxB/XJTSxyEJuSAcpSNLqqAiZivuQXdaD0N7H3Or0awwmKE9mD
I0g8CF4fPDmuuOG0ASn9fMqXVVt5tXtEqZ9yJYfNOXx3FOPjRVOZf+kvSc31wCKe
i/KmR0AQOmToKMzq988nLqFPTi9KZB8sEU20cGFeTQFol+m3FTcIru94EPD+nLUn
xtlLELVspYb/PP3VpvRj9b+DY8FGJ5nfSJl7Rkje+CD4VxJpSadin3kCAwEAAaOB
mTCBljAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQU
gM37P8oXmA972ztLfw+b1eIY5nowHwYDVR0jBBgwFoAUj4YAIxRwrBy0QMRKLnD0
kVidIuYwMwYDVR0RBCwwKoIoVmF1bHQgVGVzdGluZyBJbnRlcm1lZGlhdGUgU3Vi
IEF1dGhvcml0eTANBgkqhkiG9w0BAQsFAAOCAQEAA4buJuPNJvA1kiATLw1dVU2J
HPubk2Kp26Mg+GwLn7Vz45Ub133JCYfF3/zXLFZZ5Yub9gWTtjScrvNfQTAbNGdQ
BdnUlMmIRmfB7bfckhryR2R9byumeHATgNKZF7h8liNHI7X8tTzZGs6wPdXOLlzR
TlM3m1RNK8pbSPOkfPb06w9cBRlD8OAbNtJmuypXA6tYyiiMYBhP0QLAO3i4m1ns
aAjAgEjtkB1rQxW5DxoTArZ0asiIdmIcIGmsVxfDQIjFlRxAkafMs74v+5U5gbBX
wsOledU0fLl8KLq8W3OXqJwhGLK65fscrP0/omPAcFgzXf+L4VUADM4XhW6Xyg==
-----END CERTIFICATE----- -----BEGIN CERTIFICATE-----
MIIDejCCAmKgAwIBAgIUDXJyQ1uJPF5ridDOCvGtVF1F8HUwDQYJKoZIhvcNAQEL
BQAwJzElMCMGA1UEAxMcVmF1bHQgVGVzdGluZyBSb290IEF1dGhvcml0eTAeFw0x
NjA5MjcwMDA4MjBaFw0yNjA5MjAyMDA4NTBaMC8xLTArBgNVBAMTJFZhdWx0IFRl
c3RpbmcgSW50ZXJtZWRpYXRlIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEBBQAD
ggEPADCCAQoCggEBAKHsRTw3aShwDTbywK7AeXNvz7IrmdOLAsd+svDdIUn/4kWQ
lAy4uXYncQc/V9bqLjza3tflK7otXT+V5GjbK+WpW5WSp8LkVhKdLRWOnPWJEC+B
nOucmLR0mFQF1W4Bfx0fYYCLdN/YbjSevPmA0UzlIN/pdQQoxUIvraTHPNBar94K
zmlMu06qAvl27LXYUE3nAhQaRGq4M39WbAUtRsNKaTU72qTpMsstpnBB1QBT2m2U
44twFpXZAgfR/hSqcA4NegPWmB5l+E2GhYfihOhVcnFaH2tgXb4MOMUyRH1hNdgZ
28K5G1ILt2+Rp+NSosA0LI3pV490SJfAxuc0tsUCAwEAAaOBlTCBkjAOBgNVHQ8B
Af8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUj4YAIxRwrBy0QMRK
LnD0kVidIuYwHwYDVR0jBBgwFoAULNIU30rP+wMVelJMFNyDtxgtq04wLwYDVR0R
BCgwJoIkVmF1bHQgVGVzdGluZyBJbnRlcm1lZGlhdGUgQXV0aG9yaXR5MA0GCSqG
SIb3DQEBCwUAA4IBAQCOjH2n8H1Q5KpaWTm378FKd2YY1nzI/nCwjAQX96VcJUrZ
W1ofPsTcCASQKwo3HC2ayV46DMiKoJWI+xOux2N+S9uVd+SC4ZloFzSER8cCDRRk
huVra+cAaljnkJVb4Ojv6vHnXljx9NrcW6KzJzwMf1HzewyG+P1EjD4/kcA5r0Gw
vuzGXMXmjMATf0LZlklDOHkNLtvnLS8axbXI05TlHIj9y9Y+aQyFYebwip+ZXYju
pIJFswrsCk5e2G6+UmhV81JH29IvjBi4POgqm2+mrGz5xS/i6flcs/8pn01jlDpC
knj9MxY9j42z2BKkhHayyuOa0BQm0TTu4S2fhajl
-----END CERTIFICATE-----]
private_key -----BEGIN RSA PRIVATE KEY-----
MIIEpgIBAAKCAQEAyQGAdOCFXZkgv04pmgOgW15b4AU2Ry+cAVE5juIh4Xpy9Hgx
F1XthXe2Ku+S4gSZnAveoSm6oea8EvCsDfRJWSOdv5kjAviL6DZWBwH+7IcH7I61
cd6u/20xYJc+sBAp9boMrMcp5jL4EA/6ZYkZMU0O0TIeEJYe+WBt0fQR8vWXXZJW
adGjWorbbNLrnx5zdVBEf8MQQmXVk1Lt+Cgy/SOshOwa9LJSihz3RLBpRXDJG2Yb
47JWewxrzve+EtKrTnSomsCWW6TT4NH6BmdwMXrA1JZB5poM1DXrP7I5Jw2ExxH3
lzOlGqdI+l78oQsanXmoW/1bYm4NM/SNCLrCWwIDAQABAoIBAQCCbHMJY1Wl8eIJ
v5HG2WuHXaaHqVoavo2fXTDXwWryfx1v+zz/Q0YnQBH3shPAi/OQCTOfpw/uVWTb
dUZul3+wUyfcVmUdXGCLgBY53dWna8Z8e+zHwhISsqtDXV/TpelUBDCNO324XIIR
Cg0TLO4nyzQ+ESLo6D+Y2DTp8lBjMEkmKTd8CLXR2ycEoVykN98qPZm8keiLGO91
I8K7aRd8uOyQ6HUfJRlzFHSuwaLReErxGTEPI4t/wVqh2nP2gGBsn3apiJ0ul6Jz
NlYO5PqiwpeDk4ibhQBpicnm1jnEcynH/WtGuKgMNB0M4SBRBsEguO7WoKx3o+qZ
iVIaPWDhAoGBAO05UBvyJpAcz/ZNQlaF0EAOhoxNQ3h6+6ZYUE52PgZ/DHftyJPI
Y+JJNclY91wn91Yk3ROrDi8gqhzA+2Lelxo1kuZDu+m+bpzhVUdJia7tZDNzRIhI
24eP2GdochooOZ0qjvrik4kuX43amBhQ4RHsBjmX5CnUlL5ZULs8v2xnAoGBANjq
VLAwiIIqJZEC6BuBvVYKaRWkBCAXvQ3j/OqxHRYu3P68PZ58Q7HrhrCuyQHTph2v
fzfmEMPbSCrFIrrMRmjUG8wopL7GjZjFl8HOBHFwzFiz+CT5DEC+IJIRkp4HM8F/
PAzjB2wCdRdSjLTD5ph0/xQIg5xfln7D+wqU0QHtAoGBAKkLF0/ivaIiNftw0J3x
WxXag/yErlizYpIGCqvuzII6lLr9YdoViT/eJYrmb9Zm0HS9biCu2zuwDijRSBIL
RieyF40opUaKoi3+0JMtDwTtO2MCd8qaCH3QfkgqAG0tTuj1Q8/6F2JA/myKYamq
MMhhpYny9+7rAlemM8ZJIqtvAoGBAKOI3zpKDNCdd98A4v7B7H2usZUIJ7gOTZDo
XqiNyRENWb2PK6GNq/e6SrxvuclvyKA+zFnXULJoYtsj7tAH69lieGaOCc5uoRgZ
eBU7/euMj/McE6vEO3GgJawaJYCQi3uJMjvA+bp7i81+hehOfU5ZfmmbFaZSBoMh
u+U5Vu3tAoGBANnBIbHfD3E7rqnqdpH1oRRHLA1VdghzEKgyUTPHNDzPJG87RY3c
rRqeXepblud3qFjD60xS9BzcBijOvZ4+KHk6VIMpkyqoeNVFCJbBVCw+JGMp88+v
e9t+2iwryh5+rnq+pg6anmgwHldptJc1XEFZA2UUQ89RP7kOGQF6IkIS
-----END RSA PRIVATE KEY-----
private_key_type rsa
serial_number 3e:20:32:c6:af:a7:20:4e:b1:95:67:fb:86:bc:cb:90:f4:31:b6:f3
```
Vault has now generated a new set of credentials using the `example-dot-com`
role configuration. Here we see the dynamically generated private key and
certificate. The issuing CA certificate and CA trust chain is returned as well.
Using ACLs, it is possible to restrict using the pki backend such that trusted
operators can manage the role definitions, and both users and applications are
restricted in the credentials they are allowed to read.
If you get stuck at any time, simply run `vault path-help pki` or with a
subpath for interactive help output.
## API
The PKI secret backend has a full HTTP API. Please see the
[PKI secret backend API](/api/secret/pki/index.html) for more
The PKI secrets engine has a full HTTP API. Please see the
[PKI secrets engine API](/api/secret/pki/index.html) for more
details.

45
website/source/docs/secrets/postgresql/index.html.md
View File

@ -1,21 +1,21 @@
---
layout: "docs"
page_title: "PostgreSQL Secret Backend"
page_title: "PostgreSQL - Secrets Engines"
sidebar_current: "docs-secrets-postgresql"
description: |-
The PostgreSQL secret backend for Vault generates database credentials to access PostgreSQL.
The PostgreSQL secrets engine for Vault generates database credentials to access PostgreSQL.
---
# PostgreSQL Secret Backend
# PostgreSQL Secrets Engine
Name: `postgresql`
~> **Deprecation Note:** This backend is deprecated in favor of the
combined databases backend added in v0.7.1. See the documentation for
the new implementation of this backend at
[PostgreSQL Database Plugin](/docs/secrets/databases/postgresql.html).
~> **Deprecation Note:** This secrets engine is deprecated in favor of the
combined databases secrets engine added in v0.7.1. See the documentation for
the new implementation of this secrets engine at
[PostgreSQL database plugin](/docs/secrets/databases/postgresql.html).
The PostgreSQL secret backend for Vault generates database credentials
The PostgreSQL secrets engine for Vault generates database credentials
dynamically based on configured roles. This means that services that need
to access a database no longer need to hardcode credentials: they can request
them from Vault, and use Vault's leasing mechanism to more easily roll keys.
@ -29,17 +29,17 @@ Vault makes use both of its own internal revocation system as well as the
`VALID UNTIL` setting when creating PostgreSQL users to ensure that users
become invalid within a reasonable time of the lease expiring.
This page will show a quick start for this backend. For detailed documentation
on every path, use `vault path-help` after mounting the backend.
This page will show a quick start for this secrets engine. For detailed documentation
on every path, use `vault path-help` after mounting the secrets engine.
## Quick Start
The first step to using the PostgreSQL backend is to mount it.
Unlike the `kv` backend, the `postgresql` backend is not mounted by default.
The first step to using the PostgreSQL secrets engine is to mount it. Unlike the
`kv` secrets engine, the `postgresql` secrets engine is not mounted by default.
```text
$ vault mount postgresql
Successfully mounted 'postgresql' at 'postgresql'!
$ vault secrets enable postgresql
Success! Enabled the postgresql secrets engine at: postgresql/
```
Next, Vault must be configured to connect to the PostgreSQL. This is done by
@ -92,11 +92,12 @@ Vault is now configured to create and manage credentials for Postgres!
```text
$ vault read postgresql/creds/readonly
Key Value
lease_id postgresql/creds/readonly/c888a097-b0e2-26a8-b306-fc7c84b98f07
lease_duration 3600
password 34205e88-0de1-68b7-6267-72d8e32c5d3d
username root-1430162075-7887
Key Value
--- -----
lease_id postgresql/creds/readonly/c888a097-b0e2-26a8-b306-fc7c84b98f07
lease_duration 3600
password 34205e88-0de1-68b7-6267-72d8e32c5d3d
username root-1430162075-7887
```
By reading from the `creds/readonly` path, Vault has generated a new
@ -104,7 +105,7 @@ set of credentials using the `readonly` role configuration. Here we
see the dynamically generated username and password, along with a one
hour lease.
Using ACLs, it is possible to restrict using the postgresql backend such
Using ACLs, it is possible to restrict using the postgresql secrets engine such
that trusted operators can manage the role definitions, and both
users and applications are restricted in the credentials they are
allowed to read.
@ -114,6 +115,6 @@ subpath for interactive help output.
## API
The PostgreSQL secret backend has a full HTTP API. Please see the
[PostgreSQL secret backend API](/api/secret/postgresql/index.html) for more
The PostgreSQL secrets engine has a full HTTP API. Please see the
[PostgreSQL secrets engine API](/api/secret/postgresql/index.html) for more
details.

150
website/source/docs/secrets/rabbitmq/index.html.md
View File

@ -1,115 +1,97 @@
---
layout: "docs"
page_title: "RabbitMQ Secret Backend"
page_title: "RabbitMQ - Secrets Engines"
sidebar_current: "docs-secrets-rabbitmq"
description: |-
The RabbitMQ secret backend for Vault generates user credentials to access RabbitMQ.
The RabbitMQ secrets engine for Vault generates user credentials to access RabbitMQ.
---
# RabbitMQ Secret Backend
# RabbitMQ Secrets Engine
Name: `rabbitmq`
The RabbitMQ secrets engine generates user credentials dynamically based on
configured permissions and virtual hosts. This means that services that need to
access a virtual host no longer need to hardcode credentials.
The RabbitMQ secret backend for Vault generates user credentials dynamically
based on configured permissions and virtual hosts. This means that services
that need to access a virtual host no longer need to hardcode credentials:
they can request them from Vault, and use Vault's leasing mechanism to
more easily roll users.
Additionally, it introduces a new ability: with every service accessing the
messaging queue with unique credentials, it makes auditing much easier when
questionable data access is discovered: you can track it down to the specific
instance of a service based on the RabbitMQ username.
With every service accessing the messaging queue with unique credentials,
auditing is much easier when questionable data access is discovered. Easily
track issues down to a specific instance of a service based on the RabbitMQ
username.
Vault makes use both of its own internal revocation system as well as the
deleting RabbitMQ users when creating RabbitMQ users to ensure that users
become invalid within a reasonable time of the lease expiring.
deleting RabbitMQ users when creating RabbitMQ users to ensure that users become
invalid within a reasonable time of the lease expiring.
This page will show a quick start for this backend. For detailed documentation
on every path, use `vault path-help` after mounting the backend.
## Setup
## Quick Start
Most secrets engines must be configured in advance before they can perform their
functions. These steps are usually completed by an operator or configuration
management tool.
The first step to using the RabbitMQ backend is to mount it. Unlike the
`kv` backend, the `rabbitmq` backend is not mounted by default.
1. Enable the RabbitMQ secrets engine:
```text
$ vault mount rabbitmq
Successfully mounted 'rabbitmq' at 'rabbitmq'!
```
```text
$ vault secrets enable rabbitmq
Success! Enabled the rabbitmq secrets engine at: rabbitmq/
```
Next, Vault must be configured to connect to the RabbitMQ. This is done by
writing the RabbitMQ management URI, RabbitMQ management administrator user,
and the user's password.
By default, the secrets engine will mount at the name of the engine. To
enable the secrets engine at a different path, use the `-path` argument.
```text
$ vault write rabbitmq/config/connection \
connection_uri="http://localhost:15672" \
username="admin" \
password="password"
```
1. Configure the credentials that Vault uses to communicate with RabbitMQ to
generate credentials:
In this case, we've configured Vault with the URI "http://localhost:15672",
user "admin", and password "password" connecting to a local RabbitMQ
management instance. It is important that the Vault user have the
administrator privilege to manager users.
```text
$ vault write rabbitmq/config/connection \
connection_uri="http://localhost:15672" \
username="admin" \
password="password"
Success! Data written to: rabbitmq/config/connection
```
Optionally, we can configure the lease settings for credentials generated
by Vault. This is done by writing to the `config/lease` key:
It is important that the Vault user have the administrator privilege to
manager users.
```
$ vault write rabbitmq/config/lease ttl=3600 max_ttl=86400
Success! Data written to: rabbitmq/config/lease
```
This restricts each credential to being valid or leased for 1 hour
at a time, with a maximum use period of 24 hours. This forces an
application to renew their credentials at least hourly, and to recycle
them once per day.
1. Configure a role that maps a name in Vault to virtual host permissions:
The next step is to configure a role. A role is a logical name that maps
to tags and virtual host permissions used to generated those credentials.
For example, lets create a "readwrite" virtual host role:
```text
$ vault write rabbitmq/roles/my-role \
vhosts='{"/":{"write": ".*", "read": ".*"}}'
Success! Data written to: rabbitmq/roles/my-role
```
```text
$ vault write rabbitmq/roles/readwrite \
vhosts='{"/":{"write": ".*", "read": ".*"}}'
Success! Data written to: rabbitmq/roles/readwrite
```
By writing to the `roles/my-role` path we are defining the `my-role` role.
This role will be created by evaluating the given `vhosts` and `tags`
statements. By default, no tags and no virtual hosts are assigned to a role.
You can read more about [RabbitMQ management tags][rmq-perms].
By writing to the `roles/readwrite` path we are defining the `readwrite` role.
This role will be created by evaluating the given `vhosts` and `tags` statements.
By default, no tags and no virtual hosts are assigned to a role. You can read more
about RabbitMQ management tags [here](https://www.rabbitmq.com/management.html#permissions).
Configure, write, and read permissions are granted per virtual host.
## Usage
To generate a new set of credentials, we simply read from that role.
Vault is now configured to create and manage credentials for RabbitMQ!
After the secrets engine is configured and a user/machine has a Vault token with
the proper permission, it can generate credentials.
```text
$ vault read rabbitmq/creds/readwrite
lease_id rabbitmq/creds/readwrite/2740df96-d1c2-7140-c406-77a137fa3ecf
lease_duration 3600
lease_renewable true
password e1b6c159-ca63-4c6a-3886-6639eae06c30
username root-4b95bf47-281d-dcb5-8a60-9594f8056092
```
1. Generate a new credential by reading from the `/creds` endpoint with the name
of the role:
By reading from the `creds/readwrite` path, Vault has generated a new
set of credentials using the `readwrite` role configuration. Here we
see the dynamically generated username and password, along with a one
hour lease.
```text
$ vault read rabbitmq/creds/my-role
Key Value
--- -----
lease_id rabbitmq/creds/my-role/37d70d04-f24d-760a-e06e-b9b21087f0f4
lease_duration 768h
lease_renewable true
password a98af72b-b6c9-b4b1-fe37-c73a572befed
username token-590f1fe2-1094-a4d6-01a7-9d4ff756a085
```
Using ACLs, it is possible to restrict using the rabbitmq backend such
that trusted operators can manage the role definitions, and both
users and applications are restricted in the credentials they are
allowed to read.
If you get stuck at any time, simply run `vault path-help rabbitmq` or with a
subpath for interactive help output.
Using ACLs, it is possible to restrict using the rabbitmq secrets engine
such that trusted operators can manage the role definitions, and both users
and applications are restricted in the credentials they are allowed to read.
## API
The RabbitMQ secret backend has a full HTTP API. Please see the
[RabbitMQ secret backend API](/api/secret/rabbitmq/index.html) for more
The RabbitMQ secrets engine has a full HTTP API. Please see the
[RabbitMQ secrets engine API](/api/secret/rabbitmq/index.html) for more
details.
[rmq-perms]: https://www.rabbitmq.com/management.html#permissions

14
website/source/docs/secrets/ssh/dynamic-ssh-keys.html.md
View File

@ -1,6 +1,6 @@
---
layout: "docs"
page_title: "Dynamic SSH Keys - SSH Secret Backend"
page_title: "Dynamic SSH Keys - SSH - Secrets Engines"
sidebar_current: "docs-secrets-ssh-dynamic-ssh-keys"
description: |-
When using this type, the administrator registers a secret key with
@ -23,7 +23,7 @@ request, Vault creates a new SSH key pair and appends the newly-generated public
key to the `authorized_keys` file for the configured username on the remote
host. Vault uses a configurable install script to achieve this.
The backend does not prompt for `sudo` passwords; the `NOPASSWD` option for
The secrets engine does not prompt for `sudo` passwords; the `NOPASSWD` option for
sudoers should be enabled at all remote hosts for the Vault administrative
user.
@ -35,8 +35,8 @@ audit the SSH session establishments.
When the credential lease expires, Vault removes the secret key from the remote
machine.
This page will show a quick start for this backend. For detailed documentation
on every path, use `vault path-help` after mounting the backend.
This page will show a quick start for this secrets engine. For detailed documentation
on every path, use `vault path-help` after mounting the secrets engine.
### Drawbacks
@ -75,7 +75,7 @@ vaultadmin ALL=(ALL)NOPASSWD: ALL
Next, infrastructure configuration must be registered with Vault via roles.
First, however, the shared secret key must be specified.
### Mount the backend
### Mount the secrets engine
```text
$ vault mount ssh
@ -189,6 +189,6 @@ username@<IP of remote host>:~$
## API
The SSH secret backend has a full HTTP API. Please see the
[SSH secret backend API](/api/secret/ssh/index.html) for more
The SSH secret secrets engine has a full HTTP API. Please see the
[SSH secret secrets engine API](/api/secret/ssh/index.html) for more
details.

22
website/source/docs/secrets/ssh/index.html.md
View File

@ -1,24 +1,24 @@
---
layout: "docs"
page_title: "SSH Secret Backend"
page_title: "SSH - Secrets Engines"
sidebar_current: "docs-secrets-ssh"
description: |-
The Vault SSH secret backend provides secure authentication and authorization
The Vault SSH secrets engine provides secure authentication and authorization
for access to machines via the SSH protocol. There are multiple modes to the
Vault SSH backend including signed SSH certificates, dynamic SSH keys, and
one-time passwords.
Vault SSH secrets engine including signed SSH certificates, dynamic SSH keys,
and one-time passwords.
---
# SSH Secret Backend
# SSH Secrets Engine
Name: `ssh`
The Vault SSH secret backend provides secure authentication and authorization
for access to machines via the SSH protocol. The Vault SSH backend helps manage
access to machine infrastructure, providing several ways to issue SSH
The Vault SSH secrets engine provides secure authentication and authorization
for access to machines via the SSH protocol. The Vault SSH secrets engine helps
manage access to machine infrastructure, providing several ways to issue SSH
credentials.
The Vault SSH secret backend supports the following modes. Each mode is
The Vault SSH secrets engine supports the following modes. Each mode is
individually documented on its own page.
- [Signed SSH Certificates](/docs/secrets/ssh/signed-ssh-certificates.html)
@ -29,6 +29,6 @@ All guides assume a basic familiarity with the SSH protocol.
## API
The SSH secret backend has a full HTTP API. Please see the
[SSH secret backend API](/api/secret/ssh/index.html) for more
The SSH secrets engine has a full HTTP API. Please see the
[SSH secrets engine API](/api/secret/ssh/index.html) for more
details.

29
website/source/docs/secrets/ssh/one-time-ssh-passwords.html.md
View File

@ -1,16 +1,16 @@
---
layout: "docs"
page_title: "One-Time SSH Passwords (OTP) - SSH Secret Backend"
page_title: "One-Time SSH Passwords (OTP) - SSH - Secrets Engines"
sidebar_current: "docs-secrets-ssh-one-time-ssh-passwords"
description: |-
The One-Time SSH Password (OTP) SSH secret backend type allows a Vault server
The One-Time SSH Password (OTP) SSH secrets engine type allows a Vault server
to issue a One-Time Password every time a client wants to SSH into a remote
host using a helper command on the remote host to perform verification.
---
# One-Time SSH Passwords
The One-Time SSH Password (OTP) SSH secret backend type allows a Vault server to
The One-Time SSH Password (OTP) SSH secrets engine type allows a Vault server to
issue a One-Time Password every time a client wants to SSH into a remote host
using a helper command on the remote host to perform verification.
@ -22,23 +22,24 @@ server then deletes this OTP, ensuring that it is only used once.
Since the Vault server is contacted during SSH connection establishment, every
login attempt and the correlating Vault lease information is logged to the audit
backend.
secrets engine.
See [Vault-SSH-Helper](https://github.com/hashicorp/vault-ssh-helper) for
details on the helper.
This page will show a quick start for this backend. For detailed documentation
on every path, use `vault path-help` after mounting the backend.
This page will show a quick start for this secrets engine. For detailed
documentation on every path, use `vault path-help` after mounting the secrets
engine.
### Drawbacks
The main concern with the OTP backend type is the remote host's connection to
Vault; if compromised, an attacker could spoof the Vault server returning a
successful request. This risk can be mitigated by using TLS for the connection
to Vault and checking certificate validity; future enhancements to this backend
may allow for extra security on top of what TLS provides.
The main concern with the OTP secrets engine type is the remote host's
connection to Vault; if compromised, an attacker could spoof the Vault server
returning a successful request. This risk can be mitigated by using TLS for the
connection to Vault and checking certificate validity; future enhancements to
this secrets engine may allow for extra security on top of what TLS provides.
### Mount the backend
### Mount the secrets engine
```text
$ vault mount ssh
@ -109,6 +110,6 @@ disabled by setting `-strict-host-key-checking=no`.
## API
The SSH secret backend has a full HTTP API. Please see the
[SSH secret backend API](/api/secret/ssh/index.html) for more
The SSH secrets engine has a full HTTP API. Please see the
[SSH secrets engine API](/api/secret/ssh/index.html) for more
details.

22
website/source/docs/secrets/ssh/signed-ssh-certificates.html.md
View File

@ -1,11 +1,11 @@
---
layout: "docs"
page_title: "Signed SSH Certificates - SSH Secret Backend"
page_title: "Signed SSH Certificates - SSH - Secrets Engines"
sidebar_current: "docs-secrets-ssh-signed-ssh-certificates"
description: |-
The signed SSH certificates is the simplest and most powerful in terms of
setup complexity and in terms of being platform agnostic. When using this
type, an SSH CA signing key is generated or configured at the backend's mount.
type, an SSH CA signing key is generated or configured at the secrets engine's mount.
This key will be used to sign other SSH keys.
---
@ -20,12 +20,12 @@ In this section, the term "**client**" refers to the person or machine
performing the SSH operation. The "**host**" refers to the target machine. If
this is confusing, substitute "client" with "user".
This page will show a quick start for this backend. For detailed documentation
on every path, use `vault path-help` after mounting the backend.
This page will show a quick start for this secrets engine. For detailed documentation
on every path, use `vault path-help` after mounting the secrets engine.
## Client Key Signing
Before a client can request their SSH key be signed, the Vault SSH backend must
Before a client can request their SSH key be signed, the Vault SSH secrets engine must
be configured. Usually a Vault administrator or security team performs these
steps. It is also possible to automate these actions using a configuration
management tool like Chef, Puppet, Ansible, or Salt.
@ -35,7 +35,7 @@ management tool like Chef, Puppet, Ansible, or Salt.
The following steps are performed in advance by a Vault administrator, security
team, or configuration management tooling.
1. Mount the backend. Like all secret backends in Vault, the SSH secret backend
1. Mount the secrets engine. Like all secrets engines in Vault, the SSH secrets engine
must be mounted before use.
```text
@ -43,8 +43,8 @@ must be mounted before use.
Successfully mounted 'ssh' at 'ssh-client-signer'!
```
This mounts the SSH backend at the path "ssh-client-signer". It is possible
to mount the same secret backend multiple times using different `-path`
This mounts the SSH secrets engine at the path "ssh-client-signer". It is possible
to mount the same secrets engine multiple times using different `-path`
arguments. The name "ssh-client-signer" is not special - it can be any name,
but this documentation will assume "ssh-client-signer".
@ -197,7 +197,7 @@ accidentally SSHing into an unmanaged or malicious machine.
### Signing Key Configuration
1. Mount the backend. For the most security, mount at a different path from the
1. Mount the secrets engine. For the most security, mount at a different path from the
client signer.
```text
@ -480,6 +480,6 @@ forwarding. See [no prompt after login](#no-prompt-after-login) for examples.
## API
The SSH secret backend has a full HTTP API. Please see the
[SSH secret backend API](/api/secret/ssh/index.html) for more
The SSH secrets engine has a full HTTP API. Please see the
[SSH secrets engine API](/api/secret/ssh/index.html) for more
details.

153
website/source/docs/secrets/totp/index.html.md
View File

@ -1,83 +1,126 @@
---
layout: "docs"
page_title: "TOTP Secret Backend"
page_title: "TOTP - Secrets Engines"
sidebar_current: "docs-secrets-totp"
description: |-
The TOTP secret backend for Vault generates time-based one-time use passwords.
The TOTP secrets engine for Vault generates time-based one-time use passwords.
---
# TOTP Secret Backend
# TOTP Secrets Engine
Name: `totp`
The TOTP secrets engine generates time-based credentials according to the TOTP
standard. The secrets engine can also be used to generate a new key and validate
passwords generated by that key.
The TOTP secret backend for Vault will allow Vault users to store their multi-factor
authentication keys in Vault and use the API to retrieve time-based one-time use passwords
on demand. The backend can also be used to generate a new key and validate passwords generated by that key.
The TOTP secrets engine can act as both a generator (like Google Authenticator)
and a provider (like the Google.com sign in service).
This page will show a quick start for this backend. For detailed documentation
on every path, use `vault path-help` after mounting the backend.
## As a Generator
## Quick Start
The TOTP secrets engine can act as a TOTP code generator. In this mode, it can
replace traditional TOTP generators like Google Authenticator. It provides an
added layer of security since the ability to generate codes is guarded by
policies and the entire process is audited.
The first step to using the TOTP backend is to mount it.
Unlike the `kv` backend, the `totp` backend is not mounted by default.
### Setup
```text
$ vault mount totp
Successfully mounted 'totp' at 'totp'!
```
Most secrets engines must be configured in advance before they can perform their
functions. These steps are usually completed by an operator or configuration
management tool.
The next step is to configure a key. For example, lets create
a "test" key by passing in a TOTP key url:
1. Enable the TOTP secrets engine:
```text
$ vault write totp/keys/test \
url="otpauth://totp/Vault:test@gmail.com?secret=Y64VEVMBTSXCYIWRSHRNDZW62MPGVU2G&issuer=Vault"
Success! Data written to: totp/keys/test
```
```text
$ vault secrets enable totp
Success! Enabled the totp secrets engine at: totp/
```
By writing to the `keys/test` path we are defining the `test` key.
By default, the secrets engine will mount at the name of the engine. To
enable the secrets engine at a different path, use the `-path` argument.
To generate a new set of credentials, we simply read from that key using the `code` path:
1. Configure a named key. The name of this key will be a human identifier as to
its purpose.
```text
$ vault read totp/code/test
Key Value
code 135031
```
Vault is now configured to create time-based one-time use passwords!
```text
$ vault write totp/keys/my-key \
url="otpauth://totp/Vault:test@test.com?secret=Y64VEVMBTSXCYIWRSHRNDZW62MPGVU2G&issuer=Vault"
Success! Data written to: totp/keys/my-key
```
By reading from the `code/test` path, Vault has generated a new
time-based one-time use password using the `test` key configuration.
The `url` corresponds to the secret key or value from the barcode provided
by the third-party service.
Using ACLs, it is possible to restrict using the TOTP backend such
that trusted operators can manage the key definitions, and both
users and applications are restricted in the credentials they are
allowed to read.
### Usage
The TOTP backend can also be used to generate new keys and validate passwords generated using those keys.
After the secrets engine is configured and a user/machine has a Vault token with
the proper permission, it can generate credentials.
In order to generate a new key, set the generate flag to true and pass in an issuer and account name.
1. Generate a new time-based OTP by reading from the `/code` endpoint with the
name of the key:
```text
$ vault write totp/keys/test \
generate=true issuer=Vault account_name=test@gmail.com
```
A base64 encoded barcode and url will be returned upon generating a new key. These can be given to client applications that
can generate passwords. You can validate those passwords by writing to the `code/test` path.
```text
$ vault read totp/code/my-key
Key Value
--- -----
code 260610
```
```text
$ vault write totp/code/test \
code=127388
Key Value
valid true
```
Using ACLs, it is possible to restrict using the TOTP secrets engine such
that trusted operators can manage the key definitions, and both users and
applications are restricted in the credentials they are allowed to read.
If you get stuck at any time, simply run `vault path-help totp` or with a
subpath for interactive help output.
## As a Provider
The TOTP secrets engine can also act as a TOTP provider. In this mode, it can be
used to generate new keys and validate passwords generated using those keys.
### Setup
Most secrets engines must be configured in advance before they can perform their
functions. These steps are usually completed by an operator or configuration
management tool.
1. Enable the TOTP secrets engine:
```text
$ vault secrets enable totp
Success! Enabled the totp secrets engine at: totp/
```
By default, the secrets engine will mount at the name of the engine. To
enable the secrets engine at a different path, use the `-path` argument.
1. Create a named key, using the `generate` option. This tells Vault to be the
provider:
```text
$ vault write totp/keys/my-user \
generate=true \
issuer=Vault \
account_name=user@test.com
Key Value
--- -----
barcode iVBORw0KGgoAAAANSUhEUgAAAMgAAADIEAAAAADYoy0BA...
url otpauth://totp/Vault:user@test.com?algorithm=SHA1&digits=6&issuer=Vault&period=30&secret=V7MBSK324I7KF6KVW34NDFH2GYHIF6JY
```
The response includes a base64-encoded barcode and OTP url. Both are
equivalent. Give these to the user who is authenticating with TOTP.
### Usage
1. As a user, validate a TOTP code generated by a third-party app:
```text
$ vault write totp/code/my-user code=886531
Key Value
--- -----
valid true
```
## API
The TOTP secret backend has a full HTTP API. Please see the
[TOTP secret backend API](/api/secret/totp/index.html) for more
The TOTP secrets engine has a full HTTP API. Please see the
[TOTP secrets engine API](/api/secret/totp/index.html) for more
details.

197
website/source/docs/secrets/transit/index.html.md
View File

@ -1,136 +1,143 @@
---
layout: "docs"
page_title: "Transit Secret Backend"
page_title: "Transit - Secrets Engines"
sidebar_current: "docs-secrets-transit"
description: |-
The transit secret backend for Vault encrypts/decrypts data in-transit. It doesn't store any secrets.
The transit secrets engine for Vault encrypts/decrypts data in-transit. It doesn't store any secrets.
---
# Transit Secret Backend
# Transit Secrets Engine
Name: `transit`
The transit secret backend handles cryptographic functions on data in-transit.
Vault doesn't store the data sent to the backend. It can also be viewed as
"cryptography as a service."
The transit secrets engine handles cryptographic functions on data in-transit.
Vault doesn't store the data sent to the secrets engine. It can also be viewed
as "cryptography as a service" or "encryption as a service". The transit secrets
engine can also sign and verify data; generate hashes and HMACs of data; and act
as a source of random bytes.
The primary use case for `transit` is to encrypt data from applications while
still storing that encrypted data in some primary data store. This relieves the
burden of proper encryption/decryption from application developers and pushes
the burden onto the operators of Vault. Operators of Vault generally include
the security team at an organization, which means they can ensure that data is
encrypted/decrypted properly. Additionally, since encrypt/decrypt operations
must enter the audit log, any decryption event is recorded.
`transit` can also sign and verify data; generate hashes and HMACs of data; and
act as a source of random bytes.
Due to Vault's flexible ACLs, other interesting use-cases are possible. For
instance, one set of Internet-facing servers can be given permission to encrypt
with a named key but not decrypt with it; a separate set of servers not
directly connected to the Internet can then perform decryption, reducing the
data's attack surface.
the burden onto the operators of Vault.
Key derivation is supported, which allows the same key to be used for multiple
purposes by deriving a new key based on a user-supplied context value. In this
mode, convergent encryption can optionally be supported, which allows the same
input values to produce the same ciphertext.
The backend also supports key rotation, which allows a new version of the named
key to be generated. All data encrypted with the key will use the newest
version of the key; previously encrypted data can be decrypted using old
versions of the key. Administrators can control which previous versions of a
key are available for decryption, to prevent an attacker gaining an old copy of
ciphertext to be able to successfully decrypt it. At any time, a legitimate
user can "rewrap" the data, providing an old version of the ciphertext and
receiving a new version encrypted with the latest key. Because rewrapping does
not expose the plaintext, using Vault's ACL system, this can even be safely
performed by unprivileged users or cron jobs.
Datakey generation allows processes to request a high-entropy key of a given
bit length be returned to them, encrypted with the named key. Normally this will
also return the key in plaintext to allow for immediate use, but this can be
disabled to accommodate auditing requirements.
N.B.: As part of adding rotation support, the initial version of a named key
produces ciphertext starting with version 1, i.e. containing `:v1:`. Keys from
very old versions of Vault, when rotated, will jump to version 2 despite their
previous ciphertext output containing `:v0:`. Decryption, however, treats
version 0 and version 1 the same, so old ciphertext will still work.
## Setup
This page will show a quick start for this backend. For detailed documentation
on every path, use `vault path-help` after mounting the backend.
Most secrets engines must be configured in advance before they can perform their
functions. These steps are usually completed by an operator or configuration
management tool.
## Quick Start
1. Enable the Transit secrets engine:
The first step to using the transit backend is to mount it. Unlike the `kv`
backend, the `transit` backend is not mounted by default.
```text
$ vault secrets enable transit
Success! Enabled the transit secrets engine at: transit/
```
```
$ vault mount transit
Successfully mounted 'transit' at 'transit'!
```
By default, the secrets engine will mount at the name of the engine. To
enable the secrets engine at a different path, use the `-path` argument.
The next step is to create a named encryption key. A named key is used so that
many different applications can use the transit backend with independent keys.
This is done by doing a write against the backend:
1. Create a named encryption key ring:
```
$ vault write -f transit/keys/foo
Success! Data written to: transit/keys/foo
```
```text
$ vault write -f transit/keys/my-key
Success! Data written to: transit/keys/my-key
```
This will create the "foo" named key in the transit backend. We can inspect
the settings of the "foo" key by reading it:
Usually each application has its own encryption key ring.
```
$ vault read transit/keys/foo
Key Value
deletion_allowed false
derived false
exportable false
keys map[1:1484070923]
latest_version 1
min_decryption_version 1
name foo
supports_decryption true
supports_derivation true
supports_encryption true
supports_signing false
type aes256-gcm96
```
## Usage
Now, if we wanted to encrypt a piece of plain text, we use the encrypt
endpoint using our named key:
After the secrets engine is configured and a user/machine has a Vault token with
the proper permission, it can use this secrets engine.
```
$ echo -n "the quick brown fox" | base64 | vault write transit/encrypt/foo plaintext=-
Key Value
ciphertext vault:v1:czEwyKqGZY/limnuzDCUUe5AK0tbBObWqeZgFqxCuIqq7A84SeiOq3sKD0Y/KUvv
```
1. Encrypt some plaintext data using the `/encrypt` endpoint with a named key:
The encryption endpoint expects the plaintext to be provided as a base64 encoded
strings, so we must first convert it. Vault does not store the plaintext or the
ciphertext, but only handles it _in transit_ for processing. The application
is free to store the ciphertext in a database or file at rest.
```text
$ vault write transit/encrypt/my-key plaintext=$(base64 <<< "my secret data")
To decrypt, we simply use the decrypt endpoint using the same named key:
Key Value
--- -----
ciphertext vault:v1:8SDd3WHDOjf7mq69CyCqYjBXAiQQAVZRkFM13ok481zoCmHnSeDX9vyf7w==
```
```
$ vault write transit/decrypt/foo ciphertext=vault:v1:czEwyKqGZY/limnuzDCUUe5AK0tbBObWqeZgFqxCuIqq7A84SeiOq3sKD0Y/KUvv
Key Value
plaintext dGhlIHF1aWNrIGJyb3duIGZveAo=
All plaintext data **must be base64-encoded**. The reason for this
requirement is that Vault does not require that the plaintext is "text". It
could be a binary file such as a PDF or image. The easiest safe transport
mechanism for this data as part of a JSON payload is to base64-encode it.
$ echo "dGhlIHF1aWNrIGJyb3duIGZveAo=" | base64 -d
the quick brown fox
```
Note that Vault does not _store_ any of this data. The caller is responsible
for storing the encrypted ciphertext. When the caller wants the plaintext,
it must provide the ciphertext back to Vault to decrypt the value.
Using ACLs, it is possible to restrict using the transit backend such
that trusted operators can manage the named keys, and applications can
only encrypt or decrypt using the named keys they need access to.
1. Decrypt a piece of data using the `/decrypt` endpoint with a named key:
```text
$ vault write transit/decrypt/my-key ciphertext=vault:v1:8SDd3WHDOjf7mq69CyCqYjBXAiQQAVZRkFM13ok481zoCmHnSeDX9vyf7w==
Key Value
--- -----
plaintext bXkgc2VjcmV0IGRhdGEK
```
The resulting data is base64-encoded (see the note above for details on
why). Decode it to get the raw plaintext:
```text
$ base64 --decode <<< "bXkgc2VjcmV0IGRhdGEK"
my secret data
```
It is also possible to script this decryption using some clever shell
scripting in one command:
```text
$ vault write -field=plaintext transit/decrypt/my-key ciphertext=... | base64 --decode
my secret data
```
Using ACLs, it is possible to restrict using the transit secrets engine such
that trusted operators can manage the named keys, and applications can only
encrypt or decrypt using the named keys they need access to.
1. Rotate the underlying encryption key. This will generate a new encryption key
and add it to the keyring for the named key:
```text
$ vault write -f transit/keys/my-key/rotate
Success! Data written to: transit/keys/my-key/rotate
```
Future encryptions will use this new key. Old data can still be decrypted
due to the use of a key ring.
1. Upgrade already-encrypted data to a new key. Vault will decrypt the value
using the appropriate key in the keyring and then encrypted the resulting
plaintext with the newest key in the keyring.
```text
$ vault write transit/rewrap/my-key ciphertext=vault:v1:8SDd3WHDOjf7mq69CyCqYjBXAiQQAVZRkFM13ok481zoCmHnSeDX9vyf7w==
Key Value
--- -----
ciphertext vault:v2:0VHTTBb2EyyNYHsa3XiXsvXOQSLKulH+NqS4eRZdtc2TwQCxqJ7PUipvqQ==
```
This process **does not** reveal the plaintext data. As such, a Vault policy
could grant almost an untrusted process the ability to "rewrap" encrypted
data, since the process would not be able to get access to the plaintext
data.
## API
The Transit secret backend has a full HTTP API. Please see the
[Transit secret backend API](/api/secret/transit/index.html) for more
The Transit secrets engine has a full HTTP API. Please see the
[Transit secrets engine API](/api/secret/transit/index.html) for more
details.

8
website/source/guides/plugin-backends.html.md
View File

@ -11,11 +11,11 @@ description: |-
Plugin backends utilize the [plugin system][plugin-system] to enable
third-party secret and auth methods to be mounted.
It is worth noting that even though [database backends][database-backend]
It is worth noting that even though [database secrets engines][database-backend]
operate under the same underlying plugin mechanism, they are slightly different
in design than plugin backends demonstrated in this guide. The database backend
manages multiple plugins under the same backend mount point, whereas plugin
backends are generic backends that function as either secret or auth methods.
in design than plugin backends demonstrated in this guide. The database secrets
engine manages multiple plugins under the same backend mount point, whereas
plugin backends are kv backends that function as either secret or auth methods.
This guide provides steps to build, register, and mount non-database external
plugin backends.

2
website/source/guides/upgrading/upgrade-to-0.5.0.html.md
View File

@ -122,7 +122,7 @@ cannot be less restrictive than the mount's maximum TTL.)
- `userpass` – The renew function now uses the backend's configured maximum TTL,
if set; otherwise the mount maximum TTL is used.
#### Secret Backends
#### Secrets Engines
- `aws` – New IAM roles no longer always have a default TTL of one hour, instead
honoring the configured default if available and the mount default TTL if not

2
website/source/intro/getting-started/authentication.html.md
View File

@ -99,7 +99,7 @@ $ vault auth enable github
Success! Enabled github auth method at: github/
```
Auth methods are mounted, just like secret backends, except auth
Auth methods are mounted, just like secrets engines, except auth
backends are always prefixed with `auth/`. So the GitHub backend we just
mounted can be accessed at `auth/github`. You can use `vault path-help` to
learn more about it.

6
website/source/intro/getting-started/dynamic-secrets.html.md
View File

@ -15,7 +15,7 @@ Vault: _dynamic secrets_.
Dynamic secrets are secrets that are generated when they're accessed,
and aren't statically written like we did in
[Your First Secret](/intro/getting-started/first-secret.html).
On this page, we'll use the built-in AWS secret backend to dynamically
On this page, we'll use the built-in AWS secrets engine to dynamically
generate AWS access keys.
The power of dynamic secrets is that they simply don't exist before
@ -40,7 +40,7 @@ Successfully mounted 'aws' at 'aws'!
```
The AWS backend is now mounted at `aws/`. As we covered in a previous
section: different secret backends allow for different behavior, and in this
section: different secrets engines allow for different behavior, and in this
case the AWS backend is a dynamic backend for generating AWS access credentials.
## Configuring the AWS Backend
@ -59,7 +59,7 @@ $ vault write aws/config/root \
Success! Data written to: aws/config/root
```
Remember that secret backends can behave anyway they want when
Remember that secrets engines can behave anyway they want when
reading/writing a path, so this path stores this configuration for
later. Notice you can't read it back:

2
website/source/intro/getting-started/first-secret.html.md
View File

@ -123,4 +123,4 @@ In this section we learned how to use the powerful CRUD features of
Vault to store arbitrary secrets. On its own this is already a useful
but basic feature.
Next, we'll learn the basics about [secret backends](/intro/getting-started/secret-backends.html).
Next, we'll learn the basics about [secrets engines](/intro/getting-started/secret-backends.html).

2
website/source/intro/getting-started/help.html.md
View File

@ -9,7 +9,7 @@ description: |-
# Built-in Help
You've now worked with `vault write` and `vault read` for multiple
paths: the kv secret backend with `secret/` and dynamic AWS
paths: the kv secrets engine with `secret/` and dynamic AWS
credentials with the AWS backend provider at `aws/`. In both cases, the
structure and usage of each backend differed, for example the AWS
backend has special paths like `aws/config`.

12
website/source/intro/getting-started/secret-backends.html.md
View File

@ -1,12 +1,12 @@
---
layout: "intro"
page_title: "Secret Backends - Getting Started"
page_title: "Secrets Engines - Getting Started"
sidebar_current: "gettingstarted-secretbackends"
description: |-
Secret backends are what create, read, update, and delete secrets.
secrets engines are what create, read, update, and delete secrets.
---
# Secret Backends
# Secrets Engines
Previously, we saw how to read and write arbitrary secrets to Vault. To
do this, we used the `secret/` prefix. This prefix specifies which
@ -87,10 +87,10 @@ backend changes its mount point. This is still a disruptive command: the
stored data is retained, but all secrets are revoked since secrets are
closely tied to their mount paths.
## What is a Secret Backend?
## What is a Secrets Engine?
Now that you've mounted and unmounted a backend, you might wonder:
"what is a secret backend? what is the point of this mounting system?"
"what is a secrets engine? what is the point of this mounting system?"
Vault behaves a lot like a [virtual filesystem](https://en.wikipedia.org/wiki/Virtual_file_system).
The read/write/delete operations are forwarded to the backend, and the
@ -111,7 +111,7 @@ etc. all using the same read/write interface.
## Next
You now know about secret backends and how to operate on the mount table.
You now know about secrets engines and how to operate on the mount table.
This is important knowledge to move forward and learn about other secret
backends.

2
website/source/intro/vs/kms.html.md
View File

@ -23,7 +23,7 @@ capabilities as KMS, allowing for encryption keys to be stored and
cryptographic operations to be performed. However, Vault goes much further than
just key management.
The flexible secret backends allow Vault to handle any type of secret data,
The flexible secrets engines allow Vault to handle any type of secret data,
including database credentials, API keys, PKI keys, and encryption keys. Vault
also supports dynamic secrets, generating credentials on-demand for
fine-grained security controls, auditing, and non-repudiation.

2
website/source/layouts/api.erb
View File

@ -11,7 +11,7 @@
<hr>
<li<%= sidebar_current("docs-http-secret") %>>
<a href="/api/secret/index.html">Secret Backends</a>
<a href="/api/secret/index.html">Secrets Engines</a>
<ul class="nav">
<li<%= sidebar_current("docs-http-secret-aws") %>>
<a href="/api/secret/aws/index.html">AWS</a>

2
website/source/layouts/docs.erb
View File

@ -323,7 +323,7 @@
<hr>
<li<%= sidebar_current("docs-secrets") %>>
<a href="/docs/secrets/index.html">Secret Backends</a>
<a href="/docs/secrets/index.html">Secrets Engines</a>
<ul class="nav">
<li<%= sidebar_current("docs-secrets-aws") %>>
<a href="/docs/secrets/aws/index.html">AWS</a>

2
website/source/layouts/intro.erb
View File

@ -58,7 +58,7 @@
</li>
<li<%= sidebar_current("gettingstarted-secretbackends") %>>
<a href="/intro/getting-started/secret-backends.html">Secret Backends</a>
<a href="/intro/getting-started/secret-backends.html">Secrets Engines</a>
</li>
<li<%= sidebar_current("gettingstarted-dynamicsecrets") %>>