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" auditSyslog "github.com/hashicorp/vault/builtin/audit/syslog"
credGcp "github.com/hashicorp/vault-plugin-auth-gcp/plugin" 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" credAppId "github.com/hashicorp/vault/builtin/credential/app-id"
credAppRole "github.com/hashicorp/vault/builtin/credential/approle" credAppRole "github.com/hashicorp/vault/builtin/credential/approle"
credAws "github.com/hashicorp/vault/builtin/credential/aws" credAws "github.com/hashicorp/vault/builtin/credential/aws"
@ -410,17 +411,18 @@ func init() {
"syslog": auditSyslog.Factory, "syslog": auditSyslog.Factory,
}, },
CredentialBackends: map[string]logical.Factory{ CredentialBackends: map[string]logical.Factory{
"app-id": credAppId.Factory, "app-id": credAppId.Factory,
"approle": credAppRole.Factory, "approle": credAppRole.Factory,
"aws": credAws.Factory, "aws": credAws.Factory,
"cert": credCert.Factory, "cert": credCert.Factory,
"gcp": credGcp.Factory, "gcp": credGcp.Factory,
"github": credGitHub.Factory, "github": credGitHub.Factory,
"ldap": credLdap.Factory, "kubernetes": credKube.Factory,
"okta": credOkta.Factory, "ldap": credLdap.Factory,
"plugin": plugin.Factory, "okta": credOkta.Factory,
"radius": credRadius.Factory, "plugin": plugin.Factory,
"userpass": credUserpass.Factory, "radius": credRadius.Factory,
"userpass": credUserpass.Factory,
}, },
LogicalBackends: map[string]logical.Factory{ LogicalBackends: map[string]logical.Factory{
"aws": aws.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/http"
"net/url" "net/url"
"os" "os"
"os/signal"
"path/filepath" "path/filepath"
"runtime" "runtime"
"sort" "sort"
"strconv" "strconv"
"strings" "strings"
"sync" "sync"
"syscall"
"time" "time"
"golang.org/x/net/http2" "golang.org/x/net/http2"
@ -84,6 +82,8 @@ type ServerCommand struct {
flagDevPluginDir string flagDevPluginDir string
flagDevHA bool flagDevHA bool
flagDevLatency int
flagDevLatencyJitter int
flagDevTransactional bool flagDevTransactional bool
flagDevLeasedKV bool flagDevLeasedKV bool
flagDevThreeNode bool flagDevThreeNode bool
@ -204,8 +204,20 @@ func (c *ServerCommand) Flags() *FlagSets {
Hidden: true, 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{ f.BoolVar(&BoolVar{
Name: "dev-leased-generic", Name: "dev-leased-kv",
Target: &c.flagDevLeasedKV, Target: &c.flagDevLeasedKV,
Default: false, Default: false,
Hidden: true, Hidden: true,
@ -442,12 +454,12 @@ func (c *ServerCommand) Run(args []string) int {
if devPluginDir != "" { if devPluginDir != "" {
coreConfig.PluginDirectory = devPluginDir coreConfig.PluginDirectory = devPluginDir
} }
if devLatency > 0 { if c.flagDevLatency > 0 {
injectLatency := time.Duration(devLatency) * time.Millisecond injectLatency := time.Duration(c.flagDevLatency) * time.Millisecond
if _, txnOK := backend.(physical.Transactional); txnOK { 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 { } 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 // Write out the PID to the file now that server has successfully started
if err := c.storePidFile(config.PidFile); err != nil { 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 return 1
} }
defer func() { defer func() {
if err := c.removePidFile(config.PidFile); err != nil { 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, "-dev-listen-address": complete.PredictNothing,
"-log-level": complete.PredictSet("trace", "debug", "info", "warn", "err"), "-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 // 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) 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 { type grpclogFaker struct {
logger log.Logger logger log.Logger
log bool log bool

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

@ -95,7 +95,7 @@
<script type="text/x-handlebars" data-template-name="secrets"> <script type="text/x-handlebars" data-template-name="secrets">
<p> <p>
Now that Vault has been set-up, we can start reading and writing secrets 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. are encrypted and then written to the backend storage.
The backend storage mechanism never sees the unencrypted The backend storage mechanism never sees the unencrypted
value and doesn't have the means necessary to decrypt 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" layout: "api"
page_title: "AWS Secret Backend - HTTP API" page_title: "AWS - Secrets Engines - HTTP API"
sidebar_current: "docs-http-secret-aws" sidebar_current: "docs-http-secret-aws"
description: |- 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 This is the API documentation for the Vault AWS secrets engine. For general
information about the usage and operation of the AWS backend, please see the information about the usage and operation of the AWS secrets engine, please see
[Vault AWS backend documentation](/docs/secrets/aws/index.html). the [Vault AWS documentation](/docs/secrets/aws/index.html).
This documentation assumes the AWS backend is mounted at the `/aws` path in This documentation assumes the AWS secrets engine is enabled at the `/aws` path
Vault. Since it is possible to mount secret backends at any location, please in Vault. Since it is possible to enable secrets engines at any location, please
update your API calls accordingly. update your API calls accordingly.
## Configure Root IAM Credentials ## Configure Root IAM Credentials
@ -74,7 +74,7 @@ $ curl \
## Configure Lease ## 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`. optional, as there are default values for `lease` and `lease_max`.
| Method | Path | Produces | | Method | Path | Produces |
@ -111,7 +111,7 @@ $ curl \
## Read Lease ## 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 | | Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- | | :------- | :--------------------------- | :--------------------- |
@ -231,7 +231,7 @@ For an ARN:
## List Roles ## List Roles
This endpoint lists all existing roles in the backend. This endpoint lists all existing roles in the secrets engine.
| Method | Path | Produces | | Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- | | :------- | :--------------------------- | :--------------------- |

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

@ -1,25 +1,25 @@
--- ---
layout: "api" layout: "api"
page_title: "Cassandra Secret Backend - HTTP API" page_title: "Cassandra - Secrets Engines - HTTP API"
sidebar_current: "docs-http-secret-cassandra" sidebar_current: "docs-http-secret-cassandra"
description: |- 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 ~> **Deprecation Note:** This backend is deprecated in favor of the
combined databases backend added in v0.7.1. See the API documentation for combined databases backend added in v0.7.1. See the API documentation for
the new implementation of this backend at 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, general information about the usage and operation of the Cassandra backend,
please see the please see the
[Vault Cassandra backend documentation](/docs/secrets/cassandra/index.html). [Vault Cassandra backend documentation](/docs/secrets/cassandra/index.html).
This documentation assumes the Cassandra backend is mounted at the `/cassandra` 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. please update your API calls accordingly.
## Configure Connection ## Configure Connection

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

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

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

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

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

@ -1,21 +1,21 @@
--- ---
layout: "api" layout: "api"
page_title: "Cassandra Database Plugin - HTTP API" page_title: "Cassandra - Database - Secrets Engines - HTTP API"
sidebar_current: "docs-http-secret-databases-cassandra" sidebar_current: "docs-http-secret-databases-cassandra"
description: |- 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 # Cassandra Database Plugin HTTP API
The Cassandra Database Plugin is one of the supported plugins for the Database The Cassandra database plugin is one of the supported plugins for the database
backend. This plugin generates database credentials dynamically based on secrets engine. This plugin generates database credentials dynamically based on
configured roles for the Cassandra database. configured roles for the Cassandra database.
## Configure Connection ## Configure Connection
In addition to the parameters defined by the [Database 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. has a number of parameters to further configure a connection.
| Method | Path | Produces | | 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 - `pem_json` `(string: "")` – Specifies JSON containing a certificate and
private key; a certificate, private key, and issuing CA certificate; or just a 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 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). [the pki documentation](/docs/secrets/pki/index.html).
- `protocol_version` `(int: 2)` – Specifies the CQL protocol version to use. - `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 `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 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 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 ### Sample Payload
@ -103,7 +103,7 @@ $ curl \
Statements are configured during role creation and are used by the plugin to 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 determine what is sent to the datatabse on user creation, renewing, and
revocation. For more information on configuring roles see the [Role 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 ### Parameters
@ -129,4 +129,4 @@ list the plugin does not support that statement type.
semicolon-separated string, a base64-encoded semicolon-separated string, a semicolon-separated string, a base64-encoded semicolon-separated string, a
serialized JSON string array, or a base64-encoded serialized JSON string serialized JSON string array, or a base64-encoded serialized JSON string
array. The '{{name}}' value will be substituted. If not provided, defaults to 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" layout: "api"
page_title: "HANA Database Plugin - HTTP API" page_title: "HANA - Database - Secrets Engines - HTTP API"
sidebar_current: "docs-http-secret-databases-hana" sidebar_current: "docs-http-secret-databases-hana"
description: |- 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 # HANA Database Plugin HTTP API
The HANA Database Plugin is one of the supported plugins for the Database The HANA database plugin is one of the supported plugins for the database
backend. This plugin generates database credentials dynamically based on secrets engine. This plugin generates database credentials dynamically based on
configured roles for the HANA database. configured roles for the HANA database.
## Configure Connection ## Configure Connection
In addition to the parameters defined by the [Database 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. has a number of parameters to further configure a connection.
| Method | Path | Produces | | Method | Path | Produces |
@ -63,7 +63,7 @@ $ curl \
Statements are configured during role creation and are used by the plugin to 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 determine what is sent to the datatabse on user creation, renewing, and
revocation. For more information on configuring roles see the [Role 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 ### Parameters

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

@ -1,21 +1,21 @@
--- ---
layout: "api" layout: "api"
page_title: "Databases - HTTP API" page_title: "Database - Secrets Engines - HTTP API"
sidebar_current: "docs-http-secret-databases" sidebar_current: "docs-http-secret-databases"
description: |- 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 This is the API documentation for the Vault Database secrets engine. For
general information about the usage and operation of the Database backend, general information about the usage and operation of the database secrets engine,
please see the 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 This documentation assumes the database secrets engine is enabled at the
`/database` path in Vault. Since it is possible to mount secret backends at `/database` path in Vault. Since it is possible to enable secrets engines at any
any location, please update your API calls accordingly. location, please update your API calls accordingly.
## Configure Connection ## 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 - `default_ttl` `(string/int: 0)` - Specifies the TTL for the leases
associated with this role. Accepts time suffixed strings ("1h") or an integer 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 - `max_ttl` `(string/int: 0)` - Specifies the maximum TTL for the leases
associated with this role. Accepts time suffixed strings ("1h") or an integer 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 - `creation_statements` `(string: <required>)` – Specifies the database
statements executed to create and configure a user. See the plugin's API page 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" layout: "api"
page_title: "MongoDB Database Plugin - HTTP API" page_title: "MongoDB - Database - Secrets Engines - HTTP API"
sidebar_current: "docs-http-secret-databases-mongodb" sidebar_current: "docs-http-secret-databases-mongodb"
description: |- 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 # MongoDB Database Plugin HTTP API
The MongoDB Database Plugin is one of the supported plugins for the Database The MongoDB database plugin is one of the supported plugins for the database
backend. This plugin generates database credentials dynamically based on secrets engine. This plugin generates database credentials dynamically based on
configured roles for the MongoDB database. configured roles for the MongoDB database.
## Configure Connection ## Configure Connection
@ -50,7 +50,7 @@ $ curl \
Statements are configured during role creation and are used by the plugin to 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 determine what is sent to the datatabse on user creation, renewing, and
revocation. For more information on configuring roles see the [Role 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 ### Parameters
@ -59,7 +59,7 @@ list the plugin does not support that statement type.
- `creation_statements` `(string: <required>)` – Specifies the database - `creation_statements` `(string: <required>)` – Specifies the database
statements executed to create and configure a user. Must be a 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, The object can optionally contain a "db" string for session connection,
and must contain a "roles" array. This array contains objects that holds 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 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/). [MongoDB's documentation](https://docs.mongodb.com/manual/reference/method/db.createUser/).
- `revocation_statements` `(string: "")` – Specifies the database statements to - `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 serialized JSON object. The object can optionally contain a "db" string. If no
"db" value is provided, it defaults to the "admin" database. "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" layout: "api"
page_title: "MSSQL Database Plugin - HTTP API" page_title: "MSSQL - Database - Secrets Engines - HTTP API"
sidebar_current: "docs-http-secret-databases-mssql" sidebar_current: "docs-http-secret-databases-mssql"
description: |- 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 # MSSQL Database Plugin HTTP API
The MSSQL Database Plugin is one of the supported plugins for the Database The MSSQL database plugin is one of the supported plugins for the database
backend. This plugin generates database credentials dynamically based on secrets engine. This plugin generates database credentials dynamically based on
configured roles for the MSSQL database. configured roles for the MSSQL database.
## Configure Connection ## Configure Connection
@ -63,7 +63,7 @@ $ curl \
Statements are configured during role creation and are used by the plugin to 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 determine what is sent to the datatabse on user creation, renewing, and
revocation. For more information on configuring roles see the [Role 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 ### Parameters

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

@ -1,15 +1,15 @@
--- ---
layout: "api" 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" sidebar_current: "docs-http-secret-databases-mysql-maria"
description: |- 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 # MySQL/MariaDB Database Plugin HTTP API
The MySQL Database Plugin is one of the supported plugins for the Database The MySQL database plugin is one of the supported plugins for the database
backend. This plugin generates database credentials dynamically based on secrets engine. This plugin generates database credentials dynamically based on
configured roles for the MySQL database. configured roles for the MySQL database.
## Configure Connection ## Configure Connection
@ -63,7 +63,7 @@ $ curl \
Statements are configured during role creation and are used by the plugin to 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 determine what is sent to the datatabse on user creation, renewing, and
revocation. For more information on configuring roles see the [Role 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 ### Parameters

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

@ -1,15 +1,15 @@
--- ---
layout: "api" 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" sidebar_current: "docs-http-secret-databases-oracle-maria"
description: |- 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 # Oracle Database Plugin HTTP API
The Oracle Database Plugin is one of the supported plugins for the Database The Oracle database plugin is one of the supported plugins for the database
backend. This plugin generates database credentials dynamically based on secrets engine. This plugin generates database credentials dynamically based on
configured roles for the Oracle database. configured roles for the Oracle database.
## Configure Connection ## Configure Connection
@ -63,7 +63,7 @@ $ curl \
Statements are configured during role creation and are used by the plugin to 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 determine what is sent to the datatabse on user creation, renewing, and
revocation. For more information on configuring roles see the [Role 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 ### Parameters

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

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

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

@ -1,17 +1,16 @@
--- ---
layout: "api" layout: "api"
page_title: "Identity Secret Backend - HTTP API" page_title: "Identity - Secrets Engines - HTTP API"
sidebar_current: "docs-http-secret-identity" sidebar_current: "docs-http-secret-identity"
description: |- 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 This is the API documentation for the Vault Identity secrets engine. For general
general information about the usage and operation of the Identity backend, information about the usage and operation of the Identity secrets engine, please
please see the see the [Vault Identity documentation](/docs/secrets/identity/index.html).
[Vault Identity backend documentation](/docs/secrets/identity/index.html).
## Register Entity ## Register Entity
@ -219,11 +218,11 @@ given identifier.
### Parameters ### Parameters
- `name` (string: Required) - Name of the persona. Name should be the - `name` (string: Required) - Name of the persona. Name should be the identifier
identifier of the client in the authentication source. For example, if the of the client in the authentication source. For example, if the persona
persona belongs to userpass backend, the name should be a valid username belongs to userpass auth method, the name should be a valid username within
within userpass backend. If persona belongs to GitHub, it should be the userpass auth method. If persona belongs to GitHub, it should be the GitHub
GitHub username. username.
- `entity_id` (string: required) - Entity ID to which this persona belongs to. - `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 - `name` (string: Required) - Name of the persona. Name should be the
identifier of the client in the authentication source. For example, if 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 persona belongs to userpass auth method, the name should be a valid username
within userpass backend. If persona belongs to GitHub, it should be the within userpass auth method. If persona belongs to GitHub, it should be the
GitHub username. GitHub username.
- `entity_id` (string: required) - Entity ID to which this persona belongs to. - `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" layout: "api"
page_title: "HTTP API" page_title: "Secrets Engines - HTTP API"
sidebar_current: "docs-http-secret" sidebar_current: "docs-http-secret"
description: |- 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. endpoints are documented in this section.
--- ---
# Secret Backends # Secrets Engines
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 are mounted at a path, endpoints are documented in this section. secrets engines are enabled at a path,
but the documentation will assume the default mount points for simplicity. If but the documentation will assume the default paths for simplicity. If you are
you are mounting at a different path, you should adjust your API calls enabled at a different path, you should adjust your API calls accordingly.
accordingly.
For the API documentation for a specific secret backend, please choose a secret For the API documentation for a specific secrets engine, please choose a secrets
backend from the navigation. engine from the navigation.

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

@ -1,20 +1,20 @@
--- ---
layout: "api" layout: "api"
page_title: "Key/Value Secret Backend - HTTP API" page_title: "KV - Secrets Engines - HTTP API"
sidebar_current: "docs-http-secret-kv" sidebar_current: "docs-http-secret-kv"
description: |- 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 This is the API documentation for the Vault KV secrets engine. For general
information about the usage and operation of the Key/Value backend, please see information about the usage and operation of the kv secrets engine, please
the [Vault Key/Value backend documentation](/docs/secrets/kv/index.html). see the [Vault kv documentation](/docs/secrets/kv/index.html).
This documentation assumes the Key/Value backend is mounted at the `/secret` This documentation assumes the kv secrets engine is enabled at the
path in Vault. Since it is possible to mount secret backends at any location, `/secret` path in Vault. Since it is possible to enable secrets engines at any
please update your API calls accordingly. location, please update your API calls accordingly.
## Read Secret ## Read Secret
@ -53,9 +53,9 @@ $ curl \
_Note_: the `lease_duration` field (which on the CLI shows as _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 `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 to indicate how often a given value should be re-read by the client. See the
[Vault Key/Value backend documentation](/docs/secrets/kv/index.html) for [Vault KV secrets engine documentation](/docs/secrets/kv/index.html)
more details. for more details.
## List Secrets ## List Secrets
@ -121,7 +121,7 @@ policy granting the `update` capability.
- `:key` `(string: "")` – Specifies a key, paired with an associated value, to - `: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 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 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. documentation](/docs/secrets/kv/index.html) for details.
### Sample Payload ### Sample Payload

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@ -3,16 +3,16 @@ layout: "api"
page_title: "/sys/mounts - HTTP API" page_title: "/sys/mounts - HTTP API"
sidebar_current: "docs-http-system-mounts" sidebar_current: "docs-http-system-mounts"
description: |- 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` # `/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 | | Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- | | :------- | :--------------------------- | :--------------------- |
@ -54,9 +54,9 @@ $ curl \
`default_lease_ttl` or `max_lease_ttl` values of 0 mean that the system defaults `default_lease_ttl` or `max_lease_ttl` values of 0 mean that the system defaults
are used by this backend. 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 | | Method | Path | Produces |
| :------- | :--------------------------- | :--------------------- | | :------- | :--------------------------- | :--------------------- |
@ -64,7 +64,7 @@ This endpoint mounts a new secret backend at the given path.
### Parameters ### 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. will be mounted. This is specified as part of the URL.
- `type` `(string: <required>)` – Specifies the type of the backend, such as - `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 Additionally, the following options are allowed in Vault open-source, but
relevant functionality is only supported in Vault Enterprise: 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 only. Local mounts are not replicated nor (if a secondary) removed by
replication. replication.
@ -125,7 +125,7 @@ $ curl \
https://vault.rocks/v1/sys/mounts/my-mount 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. 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 to handle EC2 instances, such as restricting access to EC2 instances from
a particular AMI, EC2 instances in a particular instance profile, or EC2 a particular AMI, EC2 instances in a particular instance profile, or EC2
instances with a specialized tag value (via the role_tag feature). 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 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 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 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 ## Examples
Remove data in the status secret backend: Remove data in the status secrets engine:
```text ```text
$ vault delete secret/my-secret $ 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 - `-force` `(bool: false)` - Delete the lease from Vault even if the secret
engine revocation fails. This is meant for recovery situations where the 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 specified, -prefix is also required. This is aliased as "-f". The default is
false. false.

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

@ -4,17 +4,17 @@ page_title: "list - Command"
sidebar_current: "docs-commands-list" sidebar_current: "docs-commands-list"
description: |- description: |-
The "list" command lists data from Vault at the given path. This can be used 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 # list
The `list` command lists data from Vault at the given path. This can be used to 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 ## 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 ```text
$ vault list secret/my-app/ $ vault list secret/my-app/

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

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

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

@ -10,7 +10,7 @@ description: |-
# secrets # secrets
The `secrets` command groups subcommands for interacting with Vault's 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. for more information.
Some secrets engines persist data, some act as data pass-through, and some 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 cubbyhole/ cubbyhole per-token private secret storage
database/ database n/a 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 sys/ system system endpoints used for control, policy and debugging
``` ```
@ -69,7 +69,7 @@ Usage: vault secrets <subcommand> [options] [args]
# ... # ...
Subcommands: Subcommands:
disable Disable a secret engine disable Disable a secrets engine
enable Enable a secrets engine enable Enable a secrets engine
list List enabled secrets engines list List enabled secrets engines
move Move a secrets engine to a new path 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" page_title: "secrets list - Command"
sidebar_current: "docs-commands-secrets-list" sidebar_current: "docs-commands-secrets-list"
description: |- 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 server. This command also outputs information about the enabled path including
configured TTLs and human-friendly descriptions. A TTL of "system" indicates configured TTLs and human-friendly descriptions. A TTL of "system" indicates
that the system default is in use. that the system default is in use.
@ -11,7 +11,7 @@ description: |-
# secrets list # 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 This command also outputs information about the enabled path including
configured TTLs and human-friendly descriptions. A TTL of "system" indicates configured TTLs and human-friendly descriptions. A TTL of "system" indicates
that the system default is in use. that the system default is in use.
@ -25,7 +25,7 @@ $ vault secrets list
Path Type Description Path Type Description
---- ---- ----------- ---- ---- -----------
cubbyhole/ cubbyhole per-token private secret storage 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 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 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 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 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 ## Examples
Move the existing secrets engine at secret/ to generic/: Move the existing secrets engine at secret/ to kv/:
```text ```text
$ vault secrets move secret/ generic/ $ vault secrets move secret/ kv/
``` ```
## Usage ## 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. stdin.
For a full list of examples and paths, please see the documentation that 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 ## Examples
Persist data in the generic secrets engine: Persist data in the KV secrets engine:
```text ```text
$ vault write secret/my-secret foo=bar $ 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 ## Use Case
The dev server should be used for experimentation with Vault features, such 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 If you're new to Vault, you may want to pick up with [Your First
Secret](/intro/getting-started/first-secret.html) in Secret](/intro/getting-started/first-secret.html) in
our getting started guide. 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 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 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 access keys will be deleted from AWS the moment a secret is revoked. This
renders the access keys invalid from that point forward. 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 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 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 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 relatively horizontally with the number of secondaries rather than vertically as
in the past. 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 | | Capability | Disaster Recovery | Performance |
|-------------------------------------------------------------------------------------------------------------------------- |------------------- |-------------------------------------------------------------------------- | |-------------------------------------------------------------------------------------------------------------------------- |------------------- |-------------------------------------------------------------------------- |
| Mirrors the secrets infrastructure of a primary cluster | Yes | Yes | | 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 | | 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. | | 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 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. 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 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 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. 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 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 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, 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 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 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-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.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.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.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-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.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.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 | | `vault.route.rollback.sys-` | This measures the number of rollback operations for the sys backend | Number of operations | Summary |
### Storage Backend Metrics ### Storage Backend Metrics

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

@ -9,7 +9,7 @@ description: |-
# Custom Plugin Backends # Custom Plugin Backends
Plugin backends are the components in Vault that can be implemented separately from Vault's 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 Detailed information regarding the plugin system can be found in the
[internals documentation](https://www.vaultproject.io/docs/internals/plugins.html). [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" layout: "docs"
page_title: "AWS Secret Backend" page_title: "AWS - Secrets Engines"
sidebar_current: "docs-secrets-aws" sidebar_current: "docs-secrets-aws"
description: |- 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 ## Setup
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.
This page will show a quick start for this backend. For detailed documentation Most secrets engines must be configured in advance before they can perform their
on every path, use `vault path-help` after mounting the backend. 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. ```text
Unlike the `kv` backend, the `aws` backend is not mounted by default. $ vault secrets enable aws
Success! Enabled the aws secrets engine at: aws/
```
```text By default, the secrets engine will mount at the name of the engine. To
$ vault mount aws enable the secrets engine at a different path, use the `-path` argument.
Successfully mounted 'aws' at 'aws'!
```
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 ```text
$ vault write aws/config/root \ $ vault write aws/config/root \
access_key=AKIAJWVN5Z4FOFT7NLNA \ access_key=AKIAJWVN5Z4FOFT7NLNA \
secret_key=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 \ secret_key=R4nm063hgMVo4BTT5xOs5nHLeLXA6lar7ZJ3Nt0i \
region=us-east-1 region=us-east-1
``` ```
*Note that `root` does not mean it needs to be your AWS account's root credentials, and it Internally, Vault will connect to AWS using these credentials. As such,
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. these credentials must be a superset of any policies which might be granted
See below for the specific actions required.* 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 1. Configure a role that maps a name in Vault to a policy or policy file in AWS.
credentials. When users generate credentials, they are generated against this role:
- `secret_key` - the AWS secret key that has permission to manage IAM
credentials.
The following parameter is optional: ```text
$ vault write aws/roles/my-role \
- `region` the AWS region for API calls. If not provided, the `AWS_REGION` and policy=-<<EOF
`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": [
{ {
"Effect": "Allow", "Version": "2012-10-17",
"Action": "iam:*", "Statement": [
"Resource": "*" {
"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 You can either supply a user inline policy or provide a reference to an
$ vault write aws/roles/readonly arn=arn:aws:iam::aws:policy/AmazonEC2ReadOnlyAccess existing AWS policy's full ARN:
```
This path will create a named role pointing to an existing IAM policy used ```text
to restrict permissions for it. This is used to dynamically create $ vault write aws/roles/my-other-role \
a new pair of IAM credentials when needed. arn=arn:aws:iam::aws:policy/AmazonEC2ReadOnlyAccess
```
For more information on IAM policies, please see the For more information on IAM policies, please see the
[AWS IAM policy documentation](https://docs.aws.amazon.com/IAM/latest/UserGuide/PoliciesOverview.html). [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 1. Generate a new credential by reading from the `/creds` endpoint with the name
$ vault read aws/creds/deploy of the role:
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>
```
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 Each invocation of the command will generate a new credential.
$ 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>
```
## 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 If you want to be able to use credentials without the wait, consider using
with an IAM access key for the newly created user. 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. ```json
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
{ {
"Version": "2012-10-17", "Version": "2012-10-17",
"Statement": [ "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 ## STS credentials
Vault also supports an STS credentials instead of creating a new IAM user. 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 ## API
The AWS secret backend has a full HTTP API. Please see the The AWS secrets engine has a full HTTP API. Please see the
[AWS secret backend API](/api/secret/aws/index.html) for more [AWS secrets engine API](/api/secret/aws/index.html) for more
details. details.

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

@ -1,21 +1,19 @@
--- ---
layout: "docs" layout: "docs"
page_title: "Cassandra Secret Backend" page_title: "Cassandra - Secrets Engines"
sidebar_current: "docs-secrets-cassandra" sidebar_current: "docs-secrets-cassandra"
description: |- 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 The Cassandra secrets engine for Vault generates database credentials
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
dynamically based on configured roles. This means that services that need dynamically based on configured roles. This means that services that need
to access a database no longer need to hardcode credentials: they can request 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. 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 questionable data access is discovered: you can track it down to the specific
instance of a service based on the Cassandra username. instance of a service based on the Cassandra username.
This page will show a quick start for this backend. For detailed documentation This page will show a quick start for this secrets engine. For detailed documentation
on every path, use `vault path-help` after mounting the backend. on every path, use `vault path-help` after mounting the secrets engine.
## Quick Start ## Quick Start
The first step to using the Cassandra backend is to mount it. The first step to using the Cassandra secrets engine is to mount it. Unlike the
Unlike the `kv` backend, the `cassandra` backend is not mounted by default. `kv` secrets engine, the `cassandra` secrets engine is not mounted by default.
```text ```text
$ vault mount cassandra $ vault secrets enable cassandra
Successfully mounted 'cassandra' at 'cassandra'! Success! Enabled the cassandra secrets engine at: cassandra/
``` ```
Next, Vault must be configured to connect to Cassandra. This is done by 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 ```text
$ vault read cassandra/creds/readonly $ vault read cassandra/creds/readonly
Key Value Key Value
lease_id cassandra/creds/test/7a23e890-3a26-531d-529b-92d18d1fa63f --- -----
lease_duration 3600 lease_id cassandra/creds/test/7a23e890-3a26-531d-529b-92d18d1fa63f
lease_renewable true lease_duration 3600
password dfa80eea-ccbe-b228-ebf7-e2f62b245e71 lease_renewable true
username vault-root-1434647667-9313 password dfa80eea-ccbe-b228-ebf7-e2f62b245e71
username vault-root-1434647667-9313
``` ```
By reading from the `creds/readonly` path, Vault has generated a new 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 see the dynamically generated username and password, along with a one
hour lease. 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 that trusted operators can manage the role definitions, and both
users and applications are restricted in the credentials they are users and applications are restricted in the credentials they are
allowed to read. allowed to read.
@ -99,6 +98,6 @@ subpath for interactive help output.
## API ## API
The Cassandra secret backend has a full HTTP API. Please see the The Cassandra secrets engine has a full HTTP API. Please see the
[Cassandra secret backend API](/api/secret/cassandra/index.html) for more [Cassandra secrets engine API](/api/secret/cassandra/index.html) for more
details. details.

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

@ -1,103 +1,95 @@
--- ---
layout: "docs" layout: "docs"
page_title: "Consul Secret Backend" page_title: "Consul - Secrets Engines"
sidebar_current: "docs-secrets-consul" sidebar_current: "docs-secrets-consul"
description: |- 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 ## Setup
[Consul](https://www.consul.io)
API tokens dynamically based on Consul ACL policies.
This page will show a quick start for this backend. For detailed documentation Most secrets engines must be configured in advance before they can perform their
on every path, use `vault path-help` after mounting the backend. 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. ```text
Unlike the `kv` backend, the `consul` backend is not mounted by default. $ vault secrets enable consul
Success! Enabled the consul secrets engine at: consul/
```
``` By default, the secrets engine will mount at the name of the engine. To
$ vault mount consul enable the secrets engine at a different path, use the `-path` argument.
Successfully mounted 'consul' at 'consul'!
```
[Acquire a management token from 1. Acquire a [management token][consul-mgmt-token] from Consul, using the
Consul](https://www.consul.io/docs/agent/http/acl.html#acl_create), using the `acl_master_token` from your Consul configuration file or another management
`acl_master_token` from your Consul configuration file or any other management
token: token:
```shell ```sh
$ curl \ $ curl \
-H "X-Consul-Token: secret" \ --header "X-Consul-Token: my-management-token" \
-X PUT \ --request PUT \
-d '{"Name": "sample", "Type": "management"}' \ --data '{"Name": "sample", "Type": "management"}' \
http://127.0.0.1:8500/v1/acl/create https://consul.rocks/v1/acl/create
``` ```
```javascript
{
"ID": "adf4238a-882b-9ddc-4a9d-5b6758e4159e"
}
```
Next, we must configure Vault to know how to contact Consul. Vault must have a management type token so that it can create and revoke ACL
This is done by writing the access information: tokens. The response will return a new token:
``` ```json
$ vault write consul/config/access \ {
address=127.0.0.1:8500 \ "ID": "7652ba4c-0f6e-8e75-5724-5e083d72cfe4"
token=adf4238a-882b-9ddc-4a9d-5b6758e4159e }
Success! Data written to: consul/config/access ```
```
In this case, we've configured Vault to connect to Consul 1. Configure Vault to connect and authenticate 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.
The next step is to configure a role. A role is a logical name that maps ```text
to a role used to generate those credentials. For example, lets create $ vault write consul/config/access \
a "readonly" role: address=127.0.0.1:8500 \
token=7652ba4c-0f6e-8e75-5724-5e083d72cfe4
Success! Data written to: consul/config/access
```
``` 1. Configure a role that maps a name in Vault to a Consul ACL policy.
POLICY='key "" { policy = "read" }' When users generate credentials, they are generated against this role:
$ echo $POLICY | base64 | vault write consul/roles/readonly policy=-
Success! Data written to: consul/roles/readonly
```
The backend expects the policy to be base64 encoded, so we need to encode it ```text
properly before writing. The policy language is [documented by $ vault write consul/roles/my-role policy=$(base64 <<< 'key "" { policy = "read" }')
Consul](https://www.consul.io/docs/internals/acl.html), but we've defined a Success! Data written to: consul/roles/my-role
read-only policy. ```
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).
``` ## Usage
$ 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
```
Here we can see that Vault has generated a new Consul ACL token for us. After the secrets engine is configured and a user/machine has a Vault token with
We can test this token out, and verify that it is read-only: the proper permission, it can generate credentials.
``` 1. Generate a new credential by reading from the `/creds` endpoint with the name
$ curl 127.0.0.1:8500/v1/kv/foo?token=973a31ea-1ec4-c2de-0f63-623f477c2510 of the role:
[{"CreateIndex":12,"ModifyIndex":53,"LockIndex":4,"Key":"foo","Flags":3304740253564472344,"Value":"YmF6"}]
$ curl -X PUT -d 'test' 127.0.0.1:8500/v1/kv/foo?token=973a31ea-1ec4-c2de-0f63-623f477c2510 ```text
Permission denied $ 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 ## API
The Consul secret backend has a full HTTP API. Please see the The Consul secrets engine has a full HTTP API. Please see the
[Consul secret backend API](/api/secret/consul/index.html) for more [Consul secrets engine API](/api/secret/consul/index.html) for more
details. 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" layout: "docs"
page_title: "Cubbyhole Secret Backend" page_title: "Cubbyhole - Secrets Engines"
sidebar_current: "docs-secrets-cubbyhole" sidebar_current: "docs-secrets-cubbyhole"
description: |- 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 Also unlike the `kv` secrets engine, because the cubbyhole's lifetime is
the configured physical storage for Vault. It is mounted at the `cubbyhole/` linked to that of an authentication token, there is no concept of a TTL or
prefix by default and cannot be mounted elsewhere or removed. refresh interval for values contained in the token's cubbyhole.
This backend differs from the `kv` backend in that the `kv` backend's Writing to a key in the `cubbyhole` secrets engine will completely replace the
values are accessible to any token with read privileges on that path. In old value.
`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.
Also unlike the `kv` backend, because the cubbyhole's lifetime is linked ## Setup
to that of an authentication token, there is no concept of a TTL or refresh
interval for values contained in the token's cubbyhole.
Writing to a key in the `cubbyhole` backend will replace the old value; Most secrets engines must be configured in advance before they can perform their
the sub-fields are not merged together. 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 After the secrets engine is configured and a user/machine has a Vault token with
is mounted at `cubbyhole/`: the proper permission, it can generate credentials. The `cubbyhole` secrets
engine allows for writing keys with arbitrary values.
``` 1. Write arbitrary data:
$ vault write cubbyhole/foo \
zip=zap
Success! Data written to: cubbyhole/foo
```
This writes the key with the "zip" field set to "zap". We can test this by doing ```text
a read: $ vault write cubbyhole/my-secret my-value=s3cr3t
Success! Data written to: cubbyhole/my-secret
```
``` 1. Read arbitrary data:
$ vault read cubbyhole/foo
Key Value
zip zap
```
As expected, the value previously set is returned to us. ```text
$ vault read cubbyhole/my-secret
Key Value
--- -----
my-value s3cr3t
```
## API ## API
The Cubbyhole secret backend has a full HTTP API. Please see the The Cubbyhole secrets engine has a full HTTP API. Please see the
[Cubbyhole secret backend API](/api/secret/cubbyhole/index.html) for more [Cubbyhole secrets engine API](/api/secret/cubbyhole/index.html) for more
details. details.

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

@ -1,61 +1,82 @@
--- ---
layout: "docs" layout: "docs"
page_title: "Cassandra Database Plugin - Database Secret Backend" page_title: "Cassandra - Database - Secrets Engines"
sidebar_current: "docs-secrets-databases-cassandra" sidebar_current: "docs-secrets-databases-cassandra"
description: |- 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 See the [database secrets engine](/docs/secrets/databases/index.html) docs for
backend. This plugin generates database credentials dynamically based on more information about setting up the database secrets engine.
configured roles for the Cassandra database.
See the [Database Backend](/docs/secrets/databases/index.html) docs for more ## Setup
information about setting up the Database Backend.
## 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 ```text
by specifying this plugin as the `"plugin_name"` argument. Here is an example $ vault secrets enable database
cassandra configuration: Success! Enabled the database secrets engine at: database/
```
``` By default, the secrets engine will enable at the name of the engine. To
$ vault write database/config/cassandra \ enable the secrets engine at a different path, use the `-path` argument.
plugin_name=cassandra-database-plugin \
allowed_roles="readonly" \
hosts=localhost \
username=cassandra \
password=cassandra
The following warnings were returned from the Vault server: 1. Configure Vault with the proper plugin and connection information:
* 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 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
```
``` 1. Configure a role that maps a name in Vault to an SQL statement to execute to
$ vault write database/roles/readonly \ create the database credential:
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"
```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 After the secrets engine is configured and a user/machine has a Vault token with
"database/creds/readonly" endpoint. 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 ## API
The full list of configurable options can be seen in the [Cassandra database The full list of configurable options can be seen in the [Cassandra database
plugin API](/api/secret/databases/cassandra.html) page. plugin API](/api/secret/databases/cassandra.html) page.
For more information on the Database secret backend's HTTP API please see the [Database secret For more information on the database secrets engine's HTTP API please see the [Database secret
backend API](/api/secret/databases/index.html) page. 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" layout: "docs"
page_title: "Custom Database Plugins - Database Secret Backend" page_title: "Custom - Database - Secrets Engines"
sidebar_current: "docs-secrets-databases-custom" sidebar_current: "docs-secrets-databases-custom"
description: |- 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 The database secrets engine allows new functionality to be added through a
interface without needing to modify vault's core code. This allows you write plugin interface without needing to modify vault's core code. This allows you
your own code to generate credentials in any database you wish. It also allows write your own code to generate credentials in any database you wish. It also
databases that require dynamically linked libraries to be used as plugins while allows databases that require dynamically linked libraries to be used as plugins
keeping Vault itself statically linked. while keeping Vault itself statically linked.
~> **Advanced topic!** Plugin development is a highly advanced ~> **Advanced topic!** Plugin development is a highly advanced topic in Vault,
topic in Vault, and is not required knowledge for day-to-day usage. and is not required knowledge for day-to-day usage. If you don't plan on writing
If you don't plan on writing any plugins, we recommend not reading any plugins, we recommend not reading this section of the documentation.
this section of the documentation.
Please read the [Plugins internals](/docs/internals/plugins.html) docs for more Please read the [Plugins internals](/docs/internals/plugins.html) docs for more
information about the plugin system before getting started building your information about the plugin system before getting started building your
@ -25,7 +28,7 @@ Database plugin.
## Plugin Interface ## 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 ```go
type Database interface { 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 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. 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. 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 You should now be able to register your plugin into the vault catalog. To do
this your token will need sudo permissions. this your token will need sudo permissions.
``` ```text
$ vault write sys/plugins/catalog/myplugin-database-plugin \ $ vault write sys/plugins/catalog/myplugin-database-plugin \
sha_256=<expected SHA256 Hex value of the plugin binary> \ sha_256="..." \
command="myplugin" command="myplugin"
Success! Data written to: sys/plugins/catalog/myplugin-database-plugin Success! Data written to: sys/plugins/catalog/myplugin-database-plugin
``` ```
Now you should be able to configure your plugin like any other: Now you should be able to configure your plugin like any other:
``` ```text
$ vault write database/config/myplugin \ $ vault write database/config/myplugin \
plugin_name=myplugin-database-plugin \ plugin_name=myplugin-database-plugin \
allowed_roles="readonly" \ allowed_roles="readonly" \
myplugins_connection_details=.... 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.
``` ```

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

@ -1,59 +1,79 @@
--- ---
layout: "docs" layout: "docs"
page_title: "HANA Database Plugin - Database Secret Backend" page_title: "HANA - Database - Secrets Engines"
sidebar_current: "docs-secrets-databases-HANA" sidebar_current: "docs-secrets-databases-hanadb"
description: |- description: |-
The HANA plugin for Vault's Database backend generates database credentials to access SAP HANA Database. 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 Plugin ---
Name: `hana-database-plugin` # HANA Database Secrets Engine
The HANA Database Plugin is one of the supported plugins for the Database HANA is one of the supported plugins for the database secrets engine. This
backend. This plugin generates database credentials dynamically based on plugin generates database credentials dynamically based on configured roles for
configured roles for the HANA database. the HANA database.
See the [Database Backend](/docs/secrets/databases/index.html) docs for more See the [database secrets engine](/docs/secrets/databases/index.html) docs for
information about setting up the Database Backend. more information about setting up the database secrets engine.
## Quick Start ## Setup
After the Database Backend is mounted you can configure a HANA connection 1. Enable the database secrets engine if it is not already enabled:
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/hana \ ```
plugin_name=hana-database-plugin \
connection_url="hdb://username:password@localhost:1433" \ By default, the secrets engine will enable at the name of the engine. To
allowed_roles="readonly" enable the secrets engine at a different path, use the `-path` argument.
The following warnings were returned from the Vault server: 1. Configure Vault with the proper plugin and connection information:
* 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-hana-database \
plugin_name=hana-database-plugin \
Once the HANA connection is configured we can add a role: connection_url="hdb://username:password@localhost:1433" \
allowed_roles="my-role"
``` ```
$ vault write database/roles/readonly \
db_name=hana \ 1. Configure a role that maps a name in Vault to an SQL statement to execute to
creation_statements="CREATE USER {{name}} PASSWORD {{password}} VALID UNTIL '{{expiration}}';\ create the database credential:
CALL GRANT_ACTIVATED_ROLE ( 'sap.hana.admin.roles::Monitoring', '{{name}}' );" \
default_ttl="12h" \ ```text
max_ttl="24h" $ vault write database/roles/my-role \
db_name=my-hana-database \
Success! Data written to: database/roles/readonly creation_statements="CREATE USER {{name}} PASSWORD {{password}} VALID UNTIL '{{expiration}}';\
``` CALL GRANT_ACTIVATED_ROLE ( 'sap.hana.admin.roles::Monitoring', '{{name}}' );" \
default_ttl="12h" \
This role can now be used to retrieve a new set of credentials by querying the max_ttl="24h"
"database/creds/readonly" endpoint. Success! Data written to: database/roles/my-role
```
## API
## Usage
The full list of configurable options can be seen in the [HANA database
plugin API](/api/secret/databases/hanadb.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-
```
## 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" layout: "docs"
page_title: "Database Secret Backend" page_title: "Database - Secrets Engines"
sidebar_current: "docs-secrets-databases" sidebar_current: "docs-secrets-databases"
description: |- 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 # 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 Since every service accessing the database with unique credentials, it makes
based on configured roles. It works with a number of different databases through auditing much easier when questionable data access is discovered. You can track
a plugin interface. There are a number of builtin database types and an exposed it down to the specific instance of a service based on the SQL username.
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.
Vault makes use of its own internal revocation system to ensure that users Vault makes use of its own internal revocation system to ensure that users
become invalid within a reasonable time of the lease expiring. become invalid within a reasonable time of the lease expiring.
This page will show a quick start for this backend. For detailed documentation ## Setup
on every path, use vault path-help after mounting the backend.
## 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 ```text
$ vault mount database $ vault secrets enable database
Successfully mounted 'database' at 'database'! Success! Enabled the database secrets engine at: database/
``` ```
Next, we must configure this backend to connect to a database. In this example By default, the secrets engine will enable at the name of the engine. To
we will connect to a MySQL database, but the configuration details needed for enable the secrets engine at a different path, use the `-path` argument.
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".
``` 1. Configure Vault with the proper plugin and connection information:
$ vault write database/config/mysql \
plugin_name=mysql-database-plugin \
connection_url="root:mysql@tcp(127.0.0.1:3306)/" \
allowed_roles="readonly"
The following warnings were returned from the Vault server: ```text
* Read access to this endpoint should be controlled via ACLs as it will return the connection details as is, including passwords, if any. $ 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 This secrets engine can configure multiple database connections. For details
policy used to generate those credentials. A role needs to be configured with on the specific configuration options, please see the database-specific
the database name we created above, and the default/max TTLs. For example, lets documentation.
create a "readonly" 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=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.
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
```
``` The `{{name}}` and `{{password}}` fields will be populated by the plugin
$ vault read database/creds/readonly with dynamically generated values. In some plugins the `{{expiration}}`
Key Value field is also be supported.
--- -----
lease_id database/creds/readonly/2f6a614c-4aa2-7b19-24b9-ad944a8d4de6 ## Usage
lease_duration 1h0m0s
lease_renewable true After the secrets engine is configured and a user/machine has a Vault token with
password 8cab931c-d62e-a73d-60d3-5ee85139cd66 the proper permission, it can generate credentials.
username v-root-e2978cd0-
``` 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 ## Custom Plugins
This backend allows custom database types to be run through the exposed plugin This secrets engine allows custom database types to be run through the exposed
interface. Please see the [Custom database plugin interface. Please see the [custom database
plugin](/docs/secrets/databases/custom.html) for more information. plugin](/docs/secrets/databases/custom.html) for more information.
## API ## API
The Database secret backend has a full HTTP API. Please see the [Database secret The database secrets engine has a full HTTP API. Please see the [Database secret
backend API](/api/secret/databases/index.html) for more details. 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" layout: "docs"
page_title: "MongoDB Database Plugin - Database Secret Backend" page_title: "MongoDB - Database - Secrets Engines"
sidebar_current: "docs-secrets-databases-mongodb" sidebar_current: "docs-secrets-databases-mongodb"
description: |- 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 See the [database secrets engine](/docs/secrets/databases/index.html) docs for
backend. This plugin generates database credentials dynamically based on more information about setting up the database secrets engine.
configured roles for the MongoDB database.
See the [Database Backend](/docs/secrets/databases/index.html) docs for more ## Setup
information about setting up the Database Backend.
## 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 ```text
by specifying this plugin as the `"plugin_name"` argument. Here is an example $ vault secrets enable database
MongoDB configuration: Success! Enabled the database secrets engine at: database/
```
``` By default, the secrets engine will enable at the name of the engine. To
$ vault write database/config/mongodb \ enable the secrets engine at a different path, use the `-path` argument.
plugin_name=mongodb-database-plugin \
allowed_roles="readonly" \
connection_url="mongodb://admin:Password!@mongodb.acme.com:27017/admin?ssl=true"
The following warnings were returned from the Vault server: 1. Configure Vault with the proper plugin and connection information:
* 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 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"
```
``` 1. Configure a role that maps a name in Vault to an SQL statement to execute to
$ vault write database/roles/readonly \ create the database credential:
db_name=mongodb \
creation_statements='{ "db": "admin", "roles": [{ "role": "readWrite" }, {"role": "read", "db": "foo"}] }' \
default_ttl="1h" \
max_ttl="24h"
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 ## Usage
"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 ## API
The full list of configurable options can be seen in the [MongoDB database The full list of configurable options can be seen in the [MongoDB database
plugin API](/api/secret/databases/mongodb.html) page. plugin API](/api/secret/databases/mongodb.html) page.
For more information on the Database secret backend's HTTP API please see the [Database secret For more information on the database secrets engine's HTTP API please see the
backend API](/api/secret/databases/index.html) page. [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" layout: "docs"
page_title: "MSSQL Database Plugin - Database Secret Backend" page_title: "MSSQL - Database - Secrets Engines"
sidebar_current: "docs-secrets-databases-mssql" sidebar_current: "docs-secrets-databases-mssql"
description: |- 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 See the [database secrets engine](/docs/secrets/databases/index.html) docs for
backend. This plugin generates database credentials dynamically based on more information about setting up the database secrets engine.
configured roles for the MSSQL database.
See the [Database Backend](/docs/secrets/databases/index.html) docs for more ## Setup
information about setting up the Database Backend.
## 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 ```text
by specifying this plugin as the `"plugin_name"` argument. Here is an example $ vault secrets enable database
configuration: Success! Enabled the database secrets engine at: database/
```
``` By default, the secrets engine will enable at the name of the engine. To
$ vault write database/config/mssql \ enable the secrets engine at a different path, use the `-path` argument.
plugin_name=mssql-database-plugin \
connection_url='server=localhost;port=1433;user id=sa;password=Password!;database=AdventureWorks;app name=vault;' \
allowed_roles="readonly"
The following warnings were returned from the Vault server: 1. Configure Vault with the proper plugin and connection information:
* Read access to this endpoint should be controlled via ACLs as it will return the connection details as is, including passwords, if any.
```
In this case, we've configured Vault with the user "sa" and password "Password!", ```text
connecting to an instance at "localhost" on port 1433. It is not necessary $ vault write database/config/my-mssql-database \
that Vault has the sa login, but the user must have privileges to create plugin_name=mssql-database-plugin \
logins and manage processes. The fixed server roles `securityadmin` and connection_url='sqlserver://sa:yourStrong(!)Password@localhost:1433' \
`processadmin` are examples of built-in roles that grant these permissions. The allowed_roles="my-role"
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.
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:
``` ```text
$ vault write database/roles/readonly \ $ vault write database/roles/my-role \
db_name=mssql \ db_name=my-mssql-database \
creation_statements="CREATE LOGIN [{{name}}] WITH PASSWORD = '{{password}}';\ creation_statements="CREATE LOGIN [{{name}}] WITH PASSWORD = '{{password}}';\
CREATE USER [{{name}}] FOR LOGIN [{{name}}];\ CREATE USER [{{name}}] FOR LOGIN [{{name}}];\
GRANT SELECT ON SCHEMA::dbo TO [{{name}}];" \ GRANT SELECT ON SCHEMA::dbo TO [{{name}}];" \
default_ttl="1h" \ default_ttl="1h" \
max_ttl="24h" 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 After the secrets engine is configured and a user/machine has a Vault token with
"database/creds/readonly" endpoint. 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 ## API
The full list of configurable options can be seen in the [MSSQL database The full list of configurable options can be seen in the [MSSQL database
plugin API](/api/secret/databases/mssql.html) page. plugin API](/api/secret/databases/mssql.html) page.
For more information on the Database secret backend's HTTP API please see the [Database secret For more information on the database secrets engine's HTTP API please see the
backend API](/api/secret/databases/index.html) page. [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" 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" sidebar_current: "docs-secrets-databases-mysql-maria"
description: |- 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 is one of the supported plugins for the database secrets engine. This
`mysql-legacy-database-plugin` plugin generates database credentials dynamically based on configured roles for
the MySQL database.
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.
This plugin has a few different instances built into vault, each instance is for 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 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-rds-database-plugin
- mysql-legacy-database-plugin - mysql-legacy-database-plugin
See the [Database Backend](/docs/secrets/databases/index.html) docs for more See the [database secrets engine](/docs/secrets/databases/index.html) docs for
information about setting up the Database Backend. more information about setting up the database secrets engine.
## Quick Start ## Setup
After the Database Backend is mounted you can configure a MySQL connection 1. Enable the database secrets engine if it is not already enabled:
by specifying this plugin as the `"plugin_name"` argument. Here is an example
configuration:
``` ```text
$ vault write database/config/mysql \ $ vault secrets enable database
plugin_name=mysql-database-plugin \ Success! Enabled the database secrets engine at: database/
connection_url="root:mysql@tcp(127.0.0.1:3306)/" \ ```
allowed_roles="readonly"
The following warnings were returned from the Vault server: By default, the secrets engine will enable at the name of the engine. To
* Read access to this endpoint should be controlled via ACLs as it will return the connection details as is, including passwords, if any. 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:
``` ```text
$ vault write database/roles/readonly \ $ vault write database/config/my-mysql-database \
db_name=mysql \ plugin_name=mysql-database-plugin \
creation_statements="CREATE USER '{{name}}'@'%' IDENTIFIED BY '{{password}}';GRANT SELECT ON *.* TO '{{name}}'@'%';" \ connection_url="root:mysql@tcp(127.0.0.1:3306)/" \
default_ttl="1h" \ allowed_roles="my-role"
max_ttl="24h" ```
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 ```text
"database/creds/readonly" endpoint. $ 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 After the secrets engine is configured and a user/machine has a Vault token with
plugin API](/api/secret/databases/mysql-maria.html) page. the proper permission, it can generate credentials.
For more information on the Database secret backend's HTTP API please see the [Database secret 1. Generate a new credential by reading from the `/creds` endpoint with the name
backend API](/api/secret/databases/index.html) page. 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 ## 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 you want the user created by Vault to have access to all databases starting with
`fooapp_` you could use the following creation statement: `fooapp_` you could use the following creation statement:
``` ```text
CREATE USER '{{name}}'@'%' IDENTIFIED BY '{{password}}'; GRANT SELECT ON `fooapp\_%`.* TO '{{name}}'@'%'; 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. get around this is to encode the creation statement as Base64 and feed this to Vault.
For example: For example:
``` ```text
$ vault write database/roles/readonly \ $ vault write database/roles/my-role \
db_name=mysql \ db_name=mysql \
creation_statements="Q1JFQVRFIFVTRVIgJ3t7bmFtZX19J0AnJScgSURFTlRJRklFRCBCWSAne3twYXNzd29yZH19JzsgR1JBTlQgU0VMRUNUIE9OIGBmb29hcHBcXyVgLiogVE8gJ3t7bmFtZX19J0AnJSc7" \ creation_statements="Q1JFQVRFIFVTRVIgJ3t7bmFtZX19J0AnJScgSURFTlRJRklFRCBCWSAne3twYXNzd29yZH19JzsgR1JBTlQgU0VMRUNUIE9OIGBmb29hcHBcXyVgLiogVE8gJ3t7bmFtZX19J0AnJSc7" \
default_ttl="1h" \ default_ttl="1h" \
max_ttl="24h" 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" layout: "docs"
page_title: "Oracle Database Plugin" page_title: "Oracle - Database - Secrets Engines"
sidebar_current: "docs-secrets-databases-oracle" sidebar_current: "docs-secrets-databases-oracle"
description: |- 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 The Oracle database plugin is not bundled in the core Vault code tree and can be
backend. This plugin generates database credentials dynamically based on found at its own git repository here:
configured roles for the Oracle database. [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 See the [Database Backend](/docs/secrets/databases/index.html) docs for more
information about setting up the Database Backend. 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 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) 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 be placed in the default library search path or somewhere defined in the
`LD_LIBRARY_PATH` environment variable. `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 ```text
connection to the Oracle Database. $ 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 By default, the secrets engine will enable at the name of the engine. To
build the plugin see the plugin's code repository. Once the plugin is built and enable the secrets engine at a different path, use the `-path` argument.
the binary is placed in Vault's plugin directory the catalog should be updated:
``` 1. Download and register the plugin:
$ vault write sys/plugins/catalog/vault-plugin-database-oracle \
sha_256=<expected SHA256 value> \
command=vault-plugin-database-oracle
```
Once the plugin exists in the plugin catalog the Database backend can configure ```text
a connection for the Oracle Database: $ vault write sys/plugins/catalog/oracle-database-plugin \
sha_256="..." \
command=oracle-database-plugin
```
``` 1. Configure Vault with the proper plugin and connection information:
$ vault write database/config/oracle \
plugin_name=vault-plugin-database-oracle \
connection_url="system/Oracle@localhost:1521/OraDoc.localhost" \
allowed_roles="readonly"
The following warnings were returned from the Vault server: ```text
* Read access to this endpoint should be controlled via ACLs as it will return the connection details as is, including passwords, if any. $ 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:
``` ```text
$ vault write database/roles/readonly \ $ vault write database/roles/my-role \
db_name=oracle \ db_name=my-oracle-database \
creation_statements="CREATE USER {{name}} IDENTIFIED BY {{password}}; GRANT CONNECT TO {{name}}; GRANT CREATE SESSION TO {{name}};" \ creation_statements="CREATE USER {{name}} IDENTIFIED BY {{password}}; GRANT CONNECT TO {{name}}; GRANT CREATE SESSION TO {{name}};" \
default_ttl="1h" \ default_ttl="1h" \
max_ttl="24h" 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 After the secrets engine is configured and a user/machine has a Vault token with
"database/creds/readonly" endpoint. 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 ## API
The full list of configurable options can be seen in the [Oracle database The full list of configurable options can be seen in the [Oracle database plugin
plugin API](/api/secret/databases/oracle.html) page. 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.
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" layout: "docs"
page_title: "PostgreSQL Database Plugin - Database Secret Backend" page_title: "PostgreSQL - Database - Secrets Engines"
sidebar_current: "docs-secrets-databases-postgresql" sidebar_current: "docs-secrets-databases-postgresql"
description: |- 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 See the [database secrets engine](/docs/secrets/databases/index.html) docs for
backend. This plugin generates database credentials dynamically based on more information about setting up the database secrets engine.
configured roles for the PostgreSQL database.
See the [Database Backend](/docs/secrets/databases/index.html) docs for more ## Setup
information about setting up the Database Backend.
## 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 ```text
by specifying this plugin as the `"plugin_name"` argument. Here is an example $ vault secrets enable database
configuration: Success! Enabled the database secrets engine at: database/
```
``` By default, the secrets engine will enable at the name of the engine. To
$ vault write database/config/postgresql \ enable the secrets engine at a different path, use the `-path` argument.
plugin_name=postgresql-database-plugin \
allowed_roles="readonly" \
connection_url="postgresql://root:root@localhost:5432/"
The following warnings were returned from the Vault server: 1. Configure Vault with the proper plugin and connection information:
* 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 PostgreSQL connection is configured we can add a role. The PostgreSQL ```text
plugin replaces `{{expiration}}` in statements with a formated timestamp: $ vault write database/config/my-postgresql-database \
plugin_name=postgresql-database-plugin \
allowed_roles="my-role" \
connection_url="postgresql://root:root@localhost:5432/"
```
``` 1. Configure a role that maps a name in Vault to an SQL statement to execute to
$ vault write database/roles/readonly \ create the database credential:
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"
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 ## Usage
"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 ## API
The full list of configurable options can be seen in the [PostgreSQL database The full list of configurable options can be seen in the [PostgreSQL database
plugin API](/api/secret/databases/postgresql.html) page. plugin API](/api/secret/databases/postgresql.html) page.
For more information on the Database secret backend's HTTP API please see the [Database secret For more information on the database secrets engine's HTTP API please see the
backend API](/api/secret/databases/index.html) page. [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" layout: "docs"
page_title: "Identity Secret Backend" page_title: "Identity - Secrets Engines"
sidebar_current: "docs-secrets-identity" sidebar_current: "docs-secrets-identity"
description: |- 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` 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 maintains the clients who are recognized by Vault. Each client is
internally termed as an `Entity`. An entity can have multiple `Personas`. For 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 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 get inherited from entities are computed at request time. This provides
flexibility in controlling the access of tokens that are already issued. flexibility in controlling the access of tokens that are already issued.
This backend will be mounted by default. This backend cannot be unmounted or This secrets engine will be mounted by default. This secrets engine cannot be
remounted. unmounted or remounted.
## API ## API
The Identity secret backend has a full HTTP API. Please see the The Identity secrets engine has a full HTTP API. Please see the
[Identity secret backend API](/api/secret/identity/index.html) for more [Identity secrets engine API](/api/secret/identity/index.html) for more
details. details.

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

@ -1,75 +1,66 @@
--- ---
layout: "docs" layout: "docs"
page_title: "Secret Backends" page_title: "Secrets Engines"
sidebar_current: "docs-secrets" sidebar_current: "docs-secrets"
description: |- 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 engines are components which store, generate, or encrypt data. Secrets
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 Some secrets engines simply store and read data - like encrypted
secrets verbatim. Other secret backends, such as "aws", create _dynamic Redis/Memcached. Other secrets engines connect to other services and generate
secrets_: secrets that are made on demand. dynamic credentials on demand. Other secrets engines provide encryption as a
service, totp generation, certificates, and much more.
Secret backends are part of the Secrets engines are enabled at a "path" in Vault. When a request comes to Vault,
[mount system](#) the router automatically routes anything with the route prefix to the secrets
in Vault. They behave very similarly to a virtual filesystem: engine. In this way, each secrets engine defines its own paths and properties.
any read/write/delete is sent to the secret backend, and the secret To the user, secrets engines behave similar to a virtual filesystem, supporting
backend can choose to react to that operation however it sees fit. operations like read, write, and delete.
For example, the "kv" backend passes through any operation back ## Secrets Engines Lifecycle
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.
The "aws" backend, on the other hand, behaves differently. When you Most secrets engines can be enabled, disabled, tuned, and moved via the CLI or
write to `aws/config/root`, it expects a certain format and stores that API. Previous versions of Vault called these "mounts", but that term was
information as configuration. You can't read from this path. When you overloaded.
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.
## 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. - **Disable** - This disables an existing secrets engine. When a secrets engine
There are three operations that can be performed with a secret backend is disabled, all of its secrets are revoked (if they support it), and all of
with regards to mounting: the data stored for that engine in the physical storage layer is deleted.
* **Mount** - This mounts a new secret backend. Multiple secret - **Move** - This moves the path for an existing secrets engine. This process
backends of the same type can be mounted at the same time by revokes all secrets, since secret leases are tied to the path they were
specifying different mount points. By default, secret backends are created at. The configuration data stored for the engine persists through the
mounted to the same path as their name. This is what you want most move.
of the time.
* **Unmount** - This unmounts an existing secret backend. When a secret - **Tune** - This tunes global configuration for the secrets engine such as the
backend is unmounted, all of its secrets are revoked (if they support TTLs.
it), and all of the data stored for that backend in the physical storage
layer is deleted.
* **Remount** - This moves the mount point for an existing secret backend. Once a secrets engine is enabled, you can interact with it directly at its path
This revokes all secrets, since secret leases are tied to the path they according to its own API. Use `vault path-help` to determine the paths it
were created at. The data stored for the backend won't be deleted. responds to.
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.
## Barrier View ## Barrier View
An important concept around secret backends is that they receive a Secrets engines receive a _barrier view_ to the configured Vault physical
_barrier view_ to the configured Vault physical storage. This is a lot storage. This is a lot like a [chroot](https://en.wikipedia.org/wiki/Chroot).
like a [chroot](https://en.wikipedia.org/wiki/Chroot).
Whenever a secret backend is mounted, a random UUID is generated. This When a secrets engine is enabled, a random UUID is generated. This becomes the
becomes the data root for that backend. Whenever that backend writes to data root for that engine. Whenever that engine writes to the physical storage
the physical storage layer, it is prefixed with that UUID folder. Since layer, it is prefixed with that UUID folder. Since the Vault storage layer
the Vault storage layer doesn't support relative access (such as `..`), doesn't support relative access (such as `../`), this makes it impossible for a
this makes it impossible for a mounted backend to access any other data. enabled secrets engine to access other data.
This is an important security feature in Vault: even a malicious backend This is an important security feature in Vault - even a malicious engine
can't access the data from any other backend. 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" layout: "docs"
page_title: "Key/Value Secret Backend" page_title: "KV - Secrets Engines"
sidebar_current: "docs-secrets-kv" sidebar_current: "docs-secrets-kv"
description: |- 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 Writing to a key in the `kv` secrets engine will completely replace the old
the configured physical storage for Vault. If you followed along with value.
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` backend will replace the old value; This secrets engine honors the distinction between the `create` and `update`
sub-fields are not merged together.
This backend honors the distinction between the `create` and `update`
capabilities inside ACL policies. capabilities inside ACL policies.
**Note**: Path and key names are _not_ obfuscated or encrypted; only the values ~> **Note**: Path and key names are _not_ obfuscated or encrypted; only the
set on keys are. You should not store sensitive information as part of a values set on keys are. You should not store sensitive information as part of a
secret's path. secret's path.
## Quick Start ## Setup
The kv backend allows for writing keys with arbitrary values. When data is Most secrets engines must be configured in advance before they can perform their
returned, the `lease_duration` field (in the API JSON) or `refresh_interval` functions. These steps are usually completed by an operator or configuration
field (on the CLI) gives a hint as to how often a reader should look for a new management tool.
value. This comes from the value of the `default_lease_ttl` set on the mount,
or the system value.
There is one piece of special data handling: if a `ttl` key is provided, it The `kv` secrets engine is enabled by default at the path `secret/`. It can
will be treated as normal data, but on read the backend will attempt to parse be disabled, moved, or enabled multiple times at different paths. Each instance
it as a duration (either as a string like `1h` or an integer number of seconds of the KV secrets engine is isolated and unique.
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 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 After the secrets engine is configured and a user/machine has a Vault token with
"secret/" by default: the proper permission, it can generate credentials. The `kv` secrets engine
allows for writing keys with arbitrary values.
``` 1. Write arbitrary data:
$ vault write secret/foo \
zip=zap \ ```text
ttl=1h $ vault write secret/my-secret my-value=s3cr3t
Success! Data written to: secret/foo 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. Even will a `ttl` set, the secrets engine _never_ removes data on its own. The
We can test this by doing a read: `ttl` key is merely advisory.
``` When reading a value with a `ttl`, both the `ttl` key _and_ the refresh interval
$ vault read secret/foo will reflect the value:
Key Value
--- -----
refresh_interval 3600
ttl 1h
zip zap
```
As expected, we get the values previously set back as well as our custom TTL ```text
both as specified and translated to seconds. The duration has been set to 3600 $ vault read secret/my-secret
seconds (one hour) as specified. Key Value
--- -----
refresh_interval 30m
my-value s3cr3t
ttl 30m
```
## API ## API
The Key/Value secret backend has a full HTTP API. Please see the The KV secrets engine has a full HTTP API. Please see the
[Key/Value secret backend API](/api/secret/kv/index.html) for more [KV secrets engine API](/api/secret/kv/index.html) for more
details. details.

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

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

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

@ -1,21 +1,19 @@
--- ---
layout: "docs" layout: "docs"
page_title: "MSSQL Secret Backend" page_title: "MSSQL - Secrets Engines"
sidebar_current: "docs-secrets-mssql" sidebar_current: "docs-secrets-mssql"
description: |- 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 The MSSQL secrets engine for Vault generates database credentials
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
dynamically based on configured roles. This means that services that need dynamically based on configured roles. This means that services that need
to access a database no longer need to hardcode credentials: they can request 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. 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 Vault makes use of its own internal revocation system to ensure that users
become invalid within a reasonable time of the lease expiring. become invalid within a reasonable time of the lease expiring.
This page will show a quick start for this backend. For detailed documentation This page will show a quick start for this secrets engine. For detailed documentation
on every path, use `vault path-help` after mounting the backend. on every path, use `vault path-help` after mounting the secrets engine.
## Quick Start ## Quick Start
The first step to using the mssql backend is to mount it. The first step to using the mssql secrets engine is to mount it. Unlike the `kv`
Unlike the `kv` backend, the `mssql` backend is not mounted by default. secrets engine, the `mssql` secrets engine is not mounted by default.
``` ```
$ vault mount mssql $ vault secrets enable mssql
Successfully mounted 'mssql' at 'mssql'! Success! Enabled the mssql secrets engine at: mssql/
``` ```
Next, we must configure Vault to know how to connect to the 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 $ vault read mssql/creds/readonly
Key Value Key Value
lease_id mssql/creds/readonly/cdf23ac8-6dbd-4bf9-9919-6acaaa86ba6c --- -----
lease_duration 3600 lease_id mssql/creds/readonly/cdf23ac8-6dbd-4bf9-9919-6acaaa86ba6c
password ee202d0d-e4fd-4410-8d14-2a78c5c8cb76 lease_duration 3600
username root-a147d529-e7d6-4a16-8930-4c3e72170b19 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 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 see the dynamically generated username and password, along with a one
hour lease. 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 that trusted operators can manage the role definitions, and both
users and applications are restricted in the credentials they are users and applications are restricted in the credentials they are
allowed to read. allowed to read.
## API ## API
The MSSQL secret backend has a full HTTP API. Please see the The MSSQL secrets engine has a full HTTP API. Please see the
[MSSQL secret backend API](/api/secret/mssql/index.html) for more [MSSQL secrets engine API](/api/secret/mssql/index.html) for more
details. details.

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

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

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

@ -1,42 +1,133 @@
--- ---
layout: "docs" layout: "docs"
page_title: "PKI Secret Backend" page_title: "PKI - Secrets Engines"
sidebar_current: "docs-secrets-pki" sidebar_current: "docs-secrets-pki"
description: |- 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 secrets engine generates dynamic X.509 certificates. With this secrets
engine, services can get certificates without going through the usual manual
The PKI secret backend for Vault generates X.509 certificates dynamically based process of generating a private key and CSR, submitting to a CA, and waiting for
on configured roles. This means services can get certificates needed for both a verification and signing process to complete. Vault's built-in authentication
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
and authorization mechanisms provide the verification functionality. and authorization mechanisms provide the verification functionality.
By keeping TTLs relatively short, revocations are less likely to be needed, 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 keeping CRLs short and helping the secrets engine scale to large workloads. This
turn allows each instance of a running application to have a unique in turn allows each instance of a running application to have a unique
certificate, eliminating sharing and the accompanying pain of revocation and certificate, eliminating sharing and the accompanying pain of revocation and
rollover. rollover.
In addition, by allowing revocation to mostly be forgone, this backend allows In addition, by allowing revocation to mostly be forgone, this secrets engine
for ephemeral certificates; certificates can be fetched and stored in memory allows for ephemeral certificates. Certificates can be fetched and stored in
upon application startup and discarded upon shutdown, without ever being memory upon application startup and discarded upon shutdown, without ever being
written to disk. written to disk.
This page will show a quick start for this backend. For detailed documentation ## Setup
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.
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 ## 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 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 undertaken. You should read all of these *before* using this secrets engine or
generating the CA to use with this backend. generating the CA to use with this secrets engine.
### Be Careful with Root CAs ### 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 intermediate CA certificate and put this into Vault. This aligns with industry
best practices. best practices.
Since 0.4, the backend supports generating self-signed root CAs and creating Since 0.4, the secrets engine supports generating self-signed root CAs and
and signing CSRs for intermediate CAs. In each instance, for security reasons, creating and signing CSRs for intermediate CAs. In each instance, for security
the private key can *only* be exported at generation time, and the ability to reasons, the private key can *only* be exported at generation time, and the
do so is part of the command path (so it can be put into ACL policies). 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 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 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 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 secrets engine, only one CA certificate is allowed per secrets engine. If you
certificates from multiple CAs, mount the PKI backend at multiple mount points want to issue certificates from multiple CAs, mount the PKI secrets engine at
with separate CA certificates in each. multiple mount points with separate CA certificates in each.
This also provides a convenient method of switching to a new CA certificate 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 while keeping CRLs valid from the old CA certificate; simply mount a new secrets
backend and issue from there. engine and issue from there.
A common pattern is to have one mount act as your root CA and to use this CA 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. only to sign intermediate CA CSRs from other PKI mounts.
### Keep certificate lifetimes short, for CRL's sake ### Keep certificate lifetimes short, for CRL's sake
This backend aligns with Vault's philosophy of short-lived secrets. As such it This secrets engine aligns with Vault's philosophy of short-lived secrets. As
is not expected that CRLs will grow large; the only place a private key is ever such it is not expected that CRLs will grow large; the only place a private key
returned is to the requesting client (this backend does *not* store generated is ever returned is to the requesting client (this secrets engine does *not*
private keys, except for CA certificates). In most cases, if the key is lost, store generated private keys, except for CA certificates). In most cases, if the
the certificate can simply be ignored, as it will expire shortly. 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 If a certificate must truly be revoked, the normal Vault revocation function can
can be used; alternately a root token can be used to revoke the certificate be used; alternately a root token can be used to revoke the certificate using
using the certificate's serial number. Any revocation action will cause the CRL the certificate's serial number. Any revocation action will cause the CRL to be
to be regenerated. When the CRL is regenerated, any expired certificates are regenerated. When the CRL is regenerated, any expired certificates are removed
removed from the CRL (and any revoked, expired certificate are removed from from the CRL (and any revoked, expired certificate are removed from secrets
backend storage). engine storage).
This backend does not support multiple CRL endpoints with sliding date windows; This secrets engine does not support multiple CRL endpoints with sliding date
often such mechanisms will have the transition point a few days apart, but this windows; often such mechanisms will have the transition point a few days apart,
gets into the expected realm of the actual certificate validity periods issued but this gets into the expected realm of the actual certificate validity periods
from this backend. A good rule of thumb for this backend would be to simply not issued from this secrets engine. A good rule of thumb for this secrets engine
issue certificates with a validity period greater than your maximum comfortable would be to simply not issue certificates with a validity period greater than
CRL lifetime. Alternately, you can control CRL caching behavior on the client your maximum comfortable CRL lifetime. Alternately, you can control CRL caching
to ensure that checks happen more often. 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 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 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
in HA mode, and the CRL endpoint should be available even if a particular node
is down. is down.
### You must configure issuing/CRL/OCSP information *in advance* ### You must configure issuing/CRL/OCSP information *in advance*
This backend serves CRLs from a predictable location, but it is not possible This secrets engine serves CRLs from a predictable location, but it is not
for the backend to know where it is running. Therefore, you must configure possible for the secrets engine to know where it is running. Therefore, you must
desired URLs for the issuing certificate, CRL distribution points, and OCSP configure desired URLs for the issuing certificate, CRL distribution points, and
servers manually using the `config/urls` endpoint. It is supported to have more OCSP servers manually using the `config/urls` endpoint. It is supported to have
than one of each of these by passing in the multiple URLs as a comma-separated more than one of each of these by passing in the multiple URLs as a
string parameter. comma-separated string parameter.
### Safe Minimums ### Safe Minimums
Since its inception, this backend has enforced SHA256 for signature hashes Since its inception, this secrets engine has enforced SHA256 for signature
rather than SHA1. As of 0.5.1, a minimum of 2048 bits for RSA keys is also hashes rather than SHA1. As of 0.5.1, a minimum of 2048 bits for RSA keys is
enforced. Software that can handle SHA256 signatures should also be able to 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 handle 2048-bit keys, and 1024-bit keys are considered unsafe and are disallowed
disallowed in the Internet PKI. in the Internet PKI.
### Token Lifetimes and Revocation ### Token Lifetimes and Revocation
When a token expires, it revokes all leases associated with it. This means that 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 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 easy to forget. Starting with 0.6, root and intermediate CA certs no longer have
have associated leases, to prevent unintended revocation when not using a token associated leases, to prevent unintended revocation when not using a token with
with a long enough lifetime. To revoke these certificates, use the `pki/revoke` a long enough lifetime. To revoke these certificates, use the `pki/revoke`
endpoint. 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 ## API
The PKI secret backend has a full HTTP API. Please see the The PKI secrets engine has a full HTTP API. Please see the
[PKI secret backend API](/api/secret/pki/index.html) for more [PKI secrets engine API](/api/secret/pki/index.html) for more
details. details.

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

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

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

@ -1,115 +1,97 @@
--- ---
layout: "docs" layout: "docs"
page_title: "RabbitMQ Secret Backend" page_title: "RabbitMQ - Secrets Engines"
sidebar_current: "docs-secrets-rabbitmq" sidebar_current: "docs-secrets-rabbitmq"
description: |- 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 With every service accessing the messaging queue with unique credentials,
based on configured permissions and virtual hosts. This means that services auditing is much easier when questionable data access is discovered. Easily
that need to access a virtual host no longer need to hardcode credentials: track issues down to a specific instance of a service based on the RabbitMQ
they can request them from Vault, and use Vault's leasing mechanism to username.
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.
Vault makes use both of its own internal revocation system as well as the 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 deleting RabbitMQ users when creating RabbitMQ users to ensure that users become
become invalid within a reasonable time of the lease expiring. invalid within a reasonable time of the lease expiring.
This page will show a quick start for this backend. For detailed documentation ## Setup
on every path, use `vault path-help` after mounting the backend.
## 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 1. Enable the RabbitMQ secrets engine:
`kv` backend, the `rabbitmq` backend is not mounted by default.
```text ```text
$ vault mount rabbitmq $ vault secrets enable rabbitmq
Successfully mounted 'rabbitmq' at 'rabbitmq'! Success! Enabled the rabbitmq secrets engine at: rabbitmq/
``` ```
Next, Vault must be configured to connect to the RabbitMQ. This is done by By default, the secrets engine will mount at the name of the engine. To
writing the RabbitMQ management URI, RabbitMQ management administrator user, enable the secrets engine at a different path, use the `-path` argument.
and the user's password.
```text 1. Configure the credentials that Vault uses to communicate with RabbitMQ to
$ vault write rabbitmq/config/connection \ generate credentials:
connection_uri="http://localhost:15672" \
username="admin" \
password="password"
```
In this case, we've configured Vault with the URI "http://localhost:15672", ```text
user "admin", and password "password" connecting to a local RabbitMQ $ vault write rabbitmq/config/connection \
management instance. It is important that the Vault user have the connection_uri="http://localhost:15672" \
administrator privilege to manager users. username="admin" \
password="password"
Success! Data written to: rabbitmq/config/connection
```
Optionally, we can configure the lease settings for credentials generated It is important that the Vault user have the administrator privilege to
by Vault. This is done by writing to the `config/lease` key: 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 1. Configure a role that maps a name in Vault to virtual host permissions:
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.
The next step is to configure a role. A role is a logical name that maps ```text
to tags and virtual host permissions used to generated those credentials. $ vault write rabbitmq/roles/my-role \
For example, lets create a "readwrite" virtual host role: vhosts='{"/":{"write": ".*", "read": ".*"}}'
Success! Data written to: rabbitmq/roles/my-role
```
```text By writing to the `roles/my-role` path we are defining the `my-role` role.
$ vault write rabbitmq/roles/readwrite \ This role will be created by evaluating the given `vhosts` and `tags`
vhosts='{"/":{"write": ".*", "read": ".*"}}' statements. By default, no tags and no virtual hosts are assigned to a role.
Success! Data written to: rabbitmq/roles/readwrite You can read more about [RabbitMQ management tags][rmq-perms].
```
By writing to the `roles/readwrite` path we are defining the `readwrite` role. ## Usage
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.
To generate a new set of credentials, we simply read from that role. After the secrets engine is configured and a user/machine has a Vault token with
Vault is now configured to create and manage credentials for RabbitMQ! the proper permission, it can generate credentials.
```text 1. Generate a new credential by reading from the `/creds` endpoint with the name
$ vault read rabbitmq/creds/readwrite of the role:
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
```
By reading from the `creds/readwrite` path, Vault has generated a new ```text
set of credentials using the `readwrite` role configuration. Here we $ vault read rabbitmq/creds/my-role
see the dynamically generated username and password, along with a one Key Value
hour lease. --- -----
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 Using ACLs, it is possible to restrict using the rabbitmq secrets engine
that trusted operators can manage the role definitions, and both such that trusted operators can manage the role definitions, and both users
users and applications are restricted in the credentials they are and applications are restricted in the credentials they are allowed to read.
allowed to read.
If you get stuck at any time, simply run `vault path-help rabbitmq` or with a
subpath for interactive help output.
## API ## API
The RabbitMQ secret backend has a full HTTP API. Please see the The RabbitMQ secrets engine has a full HTTP API. Please see the
[RabbitMQ secret backend API](/api/secret/rabbitmq/index.html) for more [RabbitMQ secrets engine API](/api/secret/rabbitmq/index.html) for more
details. 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" 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" sidebar_current: "docs-secrets-ssh-dynamic-ssh-keys"
description: |- description: |-
When using this type, the administrator registers a secret key with 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 key to the `authorized_keys` file for the configured username on the remote
host. Vault uses a configurable install script to achieve this. 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 sudoers should be enabled at all remote hosts for the Vault administrative
user. user.
@ -35,8 +35,8 @@ audit the SSH session establishments.
When the credential lease expires, Vault removes the secret key from the remote When the credential lease expires, Vault removes the secret key from the remote
machine. machine.
This page will show a quick start for this backend. For detailed documentation This page will show a quick start for this secrets engine. For detailed documentation
on every path, use `vault path-help` after mounting the backend. on every path, use `vault path-help` after mounting the secrets engine.
### Drawbacks ### Drawbacks
@ -75,7 +75,7 @@ vaultadmin ALL=(ALL)NOPASSWD: ALL
Next, infrastructure configuration must be registered with Vault via roles. Next, infrastructure configuration must be registered with Vault via roles.
First, however, the shared secret key must be specified. First, however, the shared secret key must be specified.
### Mount the backend ### Mount the secrets engine
```text ```text
$ vault mount ssh $ vault mount ssh
@ -189,6 +189,6 @@ username@<IP of remote host>:~$
## API ## API
The SSH secret backend has a full HTTP API. Please see the The SSH secret secrets engine has a full HTTP API. Please see the
[SSH secret backend API](/api/secret/ssh/index.html) for more [SSH secret secrets engine API](/api/secret/ssh/index.html) for more
details. details.

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

@ -1,24 +1,24 @@
--- ---
layout: "docs" layout: "docs"
page_title: "SSH Secret Backend" page_title: "SSH - Secrets Engines"
sidebar_current: "docs-secrets-ssh" sidebar_current: "docs-secrets-ssh"
description: |- 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 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 Vault SSH secrets engine including signed SSH certificates, dynamic SSH keys,
one-time passwords. and one-time passwords.
--- ---
# SSH Secret Backend # SSH Secrets Engine
Name: `ssh` Name: `ssh`
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. The Vault SSH backend helps manage for access to machines via the SSH protocol. The Vault SSH secrets engine helps
access to machine infrastructure, providing several ways to issue SSH manage access to machine infrastructure, providing several ways to issue SSH
credentials. 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. individually documented on its own page.
- [Signed SSH Certificates](/docs/secrets/ssh/signed-ssh-certificates.html) - [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 ## API
The SSH secret backend has a full HTTP API. Please see the The SSH secrets engine has a full HTTP API. Please see the
[SSH secret backend API](/api/secret/ssh/index.html) for more [SSH secrets engine API](/api/secret/ssh/index.html) for more
details. details.

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

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

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

@ -1,11 +1,11 @@
--- ---
layout: "docs" 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" sidebar_current: "docs-secrets-ssh-signed-ssh-certificates"
description: |- description: |-
The signed SSH certificates is the simplest and most powerful in terms of 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 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. 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 performing the SSH operation. The "**host**" refers to the target machine. If
this is confusing, substitute "client" with "user". this is confusing, substitute "client" with "user".
This page will show a quick start for this backend. For detailed documentation This page will show a quick start for this secrets engine. For detailed documentation
on every path, use `vault path-help` after mounting the backend. on every path, use `vault path-help` after mounting the secrets engine.
## Client Key Signing ## 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 be configured. Usually a Vault administrator or security team performs these
steps. It is also possible to automate these actions using a configuration steps. It is also possible to automate these actions using a configuration
management tool like Chef, Puppet, Ansible, or Salt. 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 The following steps are performed in advance by a Vault administrator, security
team, or configuration management tooling. 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. must be mounted before use.
```text ```text
@ -43,8 +43,8 @@ must be mounted before use.
Successfully mounted 'ssh' at 'ssh-client-signer'! Successfully mounted 'ssh' at 'ssh-client-signer'!
``` ```
This mounts the SSH backend at the path "ssh-client-signer". It is possible This mounts the SSH secrets engine at the path "ssh-client-signer". It is possible
to mount the same secret backend multiple times using different `-path` 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, arguments. The name "ssh-client-signer" is not special - it can be any name,
but this documentation will assume "ssh-client-signer". but this documentation will assume "ssh-client-signer".
@ -197,7 +197,7 @@ accidentally SSHing into an unmanaged or malicious machine.
### Signing Key Configuration ### 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. client signer.
```text ```text
@ -480,6 +480,6 @@ forwarding. See [no prompt after login](#no-prompt-after-login) for examples.
## API ## API
The SSH secret backend has a full HTTP API. Please see the The SSH secrets engine has a full HTTP API. Please see the
[SSH secret backend API](/api/secret/ssh/index.html) for more [SSH secrets engine API](/api/secret/ssh/index.html) for more
details. details.

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

@ -1,83 +1,126 @@
--- ---
layout: "docs" layout: "docs"
page_title: "TOTP Secret Backend" page_title: "TOTP - Secrets Engines"
sidebar_current: "docs-secrets-totp" sidebar_current: "docs-secrets-totp"
description: |- 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 The TOTP secrets engine can act as both a generator (like Google Authenticator)
authentication keys in Vault and use the API to retrieve time-based one-time use passwords and a provider (like the Google.com sign in service).
on demand. The backend can also be used to generate a new key and validate passwords generated by that key.
This page will show a quick start for this backend. For detailed documentation ## As a Generator
on every path, use `vault path-help` after mounting the backend.
## 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. ### Setup
Unlike the `kv` backend, the `totp` backend is not mounted by default.
```text Most secrets engines must be configured in advance before they can perform their
$ vault mount totp functions. These steps are usually completed by an operator or configuration
Successfully mounted 'totp' at 'totp'! management tool.
```
The next step is to configure a key. For example, lets create 1. Enable the TOTP secrets engine:
a "test" key by passing in a TOTP key url:
```text ```text
$ vault write totp/keys/test \ $ vault secrets enable totp
url="otpauth://totp/Vault:test@gmail.com?secret=Y64VEVMBTSXCYIWRSHRNDZW62MPGVU2G&issuer=Vault" Success! Enabled the totp secrets engine at: totp/
Success! Data written to: totp/keys/test ```
```
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 ```text
$ vault read totp/code/test $ vault write totp/keys/my-key \
Key Value url="otpauth://totp/Vault:test@test.com?secret=Y64VEVMBTSXCYIWRSHRNDZW62MPGVU2G&issuer=Vault"
code 135031 Success! Data written to: totp/keys/my-key
``` ```
Vault is now configured to create time-based one-time use passwords!
By reading from the `code/test` path, Vault has generated a new The `url` corresponds to the secret key or value from the barcode provided
time-based one-time use password using the `test` key configuration. by the third-party service.
Using ACLs, it is possible to restrict using the TOTP backend such ### Usage
that trusted operators can manage the key definitions, and both
users and applications are restricted in the credentials they are
allowed to read.
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 ```text
$ vault write totp/keys/test \ $ vault read totp/code/my-key
generate=true issuer=Vault account_name=test@gmail.com Key Value
``` --- -----
A base64 encoded barcode and url will be returned upon generating a new key. These can be given to client applications that code 260610
can generate passwords. You can validate those passwords by writing to the `code/test` path. ```
```text Using ACLs, it is possible to restrict using the TOTP secrets engine such
$ vault write totp/code/test \ that trusted operators can manage the key definitions, and both users and
code=127388 applications are restricted in the credentials they are allowed to read.
Key Value
valid true
```
If you get stuck at any time, simply run `vault path-help totp` or with a ## As a Provider
subpath for interactive help output.
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 ## API
The TOTP secret backend has a full HTTP API. Please see the The TOTP secrets engine has a full HTTP API. Please see the
[TOTP secret backend API](/api/secret/totp/index.html) for more [TOTP secrets engine API](/api/secret/totp/index.html) for more
details. details.

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

@ -1,136 +1,143 @@
--- ---
layout: "docs" layout: "docs"
page_title: "Transit Secret Backend" page_title: "Transit - Secrets Engines"
sidebar_current: "docs-secrets-transit" sidebar_current: "docs-secrets-transit"
description: |- 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 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
The transit secret backend handles cryptographic functions on data in-transit. as "cryptography as a service" or "encryption as a service". The transit secrets
Vault doesn't store the data sent to the backend. It can also be viewed as engine can also sign and verify data; generate hashes and HMACs of data; and act
"cryptography as a service." as a source of random bytes.
The primary use case for `transit` is to encrypt data from applications while 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 still storing that encrypted data in some primary data store. This relieves the
burden of proper encryption/decryption from application developers and pushes burden of proper encryption/decryption from application developers and pushes
the burden onto the operators of Vault. Operators of Vault generally include the burden onto the operators of Vault.
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.
Key derivation is supported, which allows the same key to be used for multiple 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 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 mode, convergent encryption can optionally be supported, which allows the same
input values to produce the same ciphertext. 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 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 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 also return the key in plaintext to allow for immediate use, but this can be
disabled to accommodate auditing requirements. disabled to accommodate auditing requirements.
N.B.: As part of adding rotation support, the initial version of a named key ## Setup
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.
This page will show a quick start for this backend. For detailed documentation Most secrets engines must be configured in advance before they can perform their
on every path, use `vault path-help` after mounting the backend. 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` ```text
backend, the `transit` backend is not mounted by default. $ vault secrets enable transit
Success! Enabled the transit secrets engine at: transit/
```
``` By default, the secrets engine will mount at the name of the engine. To
$ vault mount transit enable the secrets engine at a different path, use the `-path` argument.
Successfully mounted 'transit' at 'transit'!
```
The next step is to create a named encryption key. A named key is used so that 1. Create a named encryption key ring:
many different applications can use the transit backend with independent keys.
This is done by doing a write against the backend:
``` ```text
$ vault write -f transit/keys/foo $ vault write -f transit/keys/my-key
Success! Data written to: transit/keys/foo Success! Data written to: transit/keys/my-key
``` ```
This will create the "foo" named key in the transit backend. We can inspect Usually each application has its own encryption key ring.
the settings of the "foo" key by reading it:
``` ## Usage
$ 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
```
Now, if we wanted to encrypt a piece of plain text, we use the encrypt After the secrets engine is configured and a user/machine has a Vault token with
endpoint using our named key: the proper permission, it can use this secrets engine.
``` 1. Encrypt some plaintext data using the `/encrypt` endpoint with a named key:
$ echo -n "the quick brown fox" | base64 | vault write transit/encrypt/foo plaintext=-
Key Value
ciphertext vault:v1:czEwyKqGZY/limnuzDCUUe5AK0tbBObWqeZgFqxCuIqq7A84SeiOq3sKD0Y/KUvv
```
The encryption endpoint expects the plaintext to be provided as a base64 encoded ```text
strings, so we must first convert it. Vault does not store the plaintext or the $ vault write transit/encrypt/my-key plaintext=$(base64 <<< "my secret data")
ciphertext, but only handles it _in transit_ for processing. The application
is free to store the ciphertext in a database or file at rest.
To decrypt, we simply use the decrypt endpoint using the same named key: Key Value
--- -----
ciphertext vault:v1:8SDd3WHDOjf7mq69CyCqYjBXAiQQAVZRkFM13ok481zoCmHnSeDX9vyf7w==
```
``` All plaintext data **must be base64-encoded**. The reason for this
$ vault write transit/decrypt/foo ciphertext=vault:v1:czEwyKqGZY/limnuzDCUUe5AK0tbBObWqeZgFqxCuIqq7A84SeiOq3sKD0Y/KUvv requirement is that Vault does not require that the plaintext is "text". It
Key Value could be a binary file such as a PDF or image. The easiest safe transport
plaintext dGhlIHF1aWNrIGJyb3duIGZveAo= mechanism for this data as part of a JSON payload is to base64-encode it.
$ echo "dGhlIHF1aWNrIGJyb3duIGZveAo=" | base64 -d Note that Vault does not _store_ any of this data. The caller is responsible
the quick brown fox 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 1. Decrypt a piece of data using the `/decrypt` endpoint with a named key:
that trusted operators can manage the named keys, and applications can
only encrypt or decrypt using the named keys they need access to. ```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 ## API
The Transit secret backend has a full HTTP API. Please see the The Transit secrets engine has a full HTTP API. Please see the
[Transit secret backend API](/api/secret/transit/index.html) for more [Transit secrets engine API](/api/secret/transit/index.html) for more
details. 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 Plugin backends utilize the [plugin system][plugin-system] to enable
third-party secret and auth methods to be mounted. 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 operate under the same underlying plugin mechanism, they are slightly different
in design than plugin backends demonstrated in this guide. The database backend in design than plugin backends demonstrated in this guide. The database secrets
manages multiple plugins under the same backend mount point, whereas plugin engine manages multiple plugins under the same backend mount point, whereas
backends are generic backends that function as either secret or auth methods. 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 This guide provides steps to build, register, and mount non-database external
plugin backends. 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, - `userpass` – The renew function now uses the backend's configured maximum TTL,
if set; otherwise the mount maximum TTL is used. 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 - `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 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/ 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 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 mounted can be accessed at `auth/github`. You can use `vault path-help` to
learn more about it. 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, Dynamic secrets are secrets that are generated when they're accessed,
and aren't statically written like we did in and aren't statically written like we did in
[Your First Secret](/intro/getting-started/first-secret.html). [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. generate AWS access keys.
The power of dynamic secrets is that they simply don't exist before 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 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. case the AWS backend is a dynamic backend for generating AWS access credentials.
## Configuring the AWS Backend ## Configuring the AWS Backend
@ -59,7 +59,7 @@ $ vault write aws/config/root \
Success! Data written to: 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 reading/writing a path, so this path stores this configuration for
later. Notice you can't read it back: 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 Vault to store arbitrary secrets. On its own this is already a useful
but basic feature. 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 # Built-in Help
You've now worked with `vault write` and `vault read` for multiple 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 credentials with the AWS backend provider at `aws/`. In both cases, the
structure and usage of each backend differed, for example the AWS structure and usage of each backend differed, for example the AWS
backend has special paths like `aws/config`. 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" layout: "intro"
page_title: "Secret Backends - Getting Started" page_title: "Secrets Engines - Getting Started"
sidebar_current: "gettingstarted-secretbackends" sidebar_current: "gettingstarted-secretbackends"
description: |- 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 Previously, we saw how to read and write arbitrary secrets to Vault. To
do this, we used the `secret/` prefix. This prefix specifies which 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 stored data is retained, but all secrets are revoked since secrets are
closely tied to their mount paths. 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: 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). 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 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 ## 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 This is important knowledge to move forward and learn about other secret
backends. 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 cryptographic operations to be performed. However, Vault goes much further than
just key management. 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 including database credentials, API keys, PKI keys, and encryption keys. Vault
also supports dynamic secrets, generating credentials on-demand for also supports dynamic secrets, generating credentials on-demand for
fine-grained security controls, auditing, and non-repudiation. fine-grained security controls, auditing, and non-repudiation.

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

@ -11,7 +11,7 @@
<hr> <hr>
<li<%= sidebar_current("docs-http-secret") %>> <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"> <ul class="nav">
<li<%= sidebar_current("docs-http-secret-aws") %>> <li<%= sidebar_current("docs-http-secret-aws") %>>
<a href="/api/secret/aws/index.html">AWS</a> <a href="/api/secret/aws/index.html">AWS</a>

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

@ -323,7 +323,7 @@
<hr> <hr>
<li<%= sidebar_current("docs-secrets") %>> <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"> <ul class="nav">
<li<%= sidebar_current("docs-secrets-aws") %>> <li<%= sidebar_current("docs-secrets-aws") %>>
<a href="/docs/secrets/aws/index.html">AWS</a> <a href="/docs/secrets/aws/index.html">AWS</a>

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

@ -58,7 +58,7 @@
</li> </li>
<li<%= sidebar_current("gettingstarted-secretbackends") %>> <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>
<li<%= sidebar_current("gettingstarted-dynamicsecrets") %>> <li<%= sidebar_current("gettingstarted-dynamicsecrets") %>>