open-vault/website/source/docs/secrets/databases/custom.html.md
Jeff Escalante a3dfde5cec New Docs Website (#5535)
* conversion stage 1

* correct image paths

* add sidebar title to frontmatter

* docs/concepts and docs/internals

* configuration docs and multi-level nav corrections

* commands docs, index file corrections, small item nav correction

* secrets converted

* auth

* add enterprise and agent docs

* add extra dividers

* secret section, wip

* correct sidebar nav title in front matter for apu section, start working on api items

* auth and backend, a couple directory structure fixes

* remove old docs

* intro side nav converted

* reset sidebar styles, add hashi-global-styles

* basic styling for nav sidebar

* folder collapse functionality

* patch up border length on last list item

* wip restructure for content component

* taking middleman hacking to the extreme, but its working

* small css fix

* add new mega nav

* fix a small mistake from the rebase

* fix a content resolution issue with middleman

* title a couple missing docs pages

* update deps, remove temporary markup

* community page

* footer to layout, community page css adjustments

* wip downloads page

* deps updated, downloads page ready

* fix community page

* homepage progress

* add components, adjust spacing

* docs and api landing pages

* a bunch of fixes, add docs and api landing pages

* update deps, add deploy scripts

* add readme note

* update deploy command

* overview page, index title

* Update doc fields

Note this still requires the link fields to be populated -- this is solely related to copy on the description fields

* Update api_basic_categories.yml

Updated API category descriptions. Like the document descriptions you'll still need to update the link headers to the proper target pages.

* Add bottom hero, adjust CSS, responsive friendly

* Add mega nav title

* homepage adjustments, asset boosts

* small fixes

* docs page styling fixes

* meganav title

* some category link corrections

* Update API categories page

updated to reflect the second level headings for api categories

* Update docs_detailed_categories.yml

Updated to represent the existing docs structure

* Update docs_detailed_categories.yml

* docs page data fix, extra operator page remove

* api data fix

* fix makefile

* update deps, add product subnav to docs and api landing pages

* Rearrange non-hands-on guides to _docs_

Since there is no place for these on learn.hashicorp, we'll put them
under _docs_.

* WIP Redirects for guides to docs

* content and component updates

* font weight hotfix, redirects

* fix guides and intro sidenavs

* fix some redirects

* small style tweaks

* Redirects to learn and internally to docs

* Remove redirect to `/vault`

* Remove `.html` from destination on redirects

* fix incorrect index redirect

* final touchups

* address feedback from michell for makefile and product downloads
2018-10-19 08:40:11 -07:00

4.4 KiB

layout page_title sidebar_title sidebar_current description
docs Custom - Database - Secrets Engines Custom docs-secrets-databases-custom 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 Secrets Engines

The database secrets engine allows new functionality to be added through a plugin interface without needing to modify vault's core code. This allows you write your own code to generate credentials in any database you wish. It also allows databases that require dynamically linked libraries to be used as plugins while keeping Vault itself statically linked.

~> Advanced topic! Plugin development is a highly advanced topic in Vault, and is not required knowledge for day-to-day usage. If you don't plan on writing any plugins, we recommend not reading this section of the documentation.

Please read the Plugins internals docs for more information about the plugin system before getting started building your Database plugin.

Plugin Interface

All plugins for the database secrets engine must implement the same simple interface.

type Database interface {
	Type() (string, error)
	CreateUser(ctx context.Context, statements Statements, usernameConfig UsernameConfig, expiration time.Time) (username string, password string, err error)
	RenewUser(ctx context.Context, statements Statements, username string, expiration time.Time) error
	RevokeUser(ctx context.Context, statements Statements, username string) error
	RotateRootCredentials(ctx context.Context, statements []string) (config map[string]interface{}, err error)
	Init(ctx context.Context, config map[string]interface{}, verifyConnection bool) (saveConfig map[string]interface{}, err error)
	Close() error
}

You'll notice the first parameter to a number of those functions is a Statements struct. This struct is used to pass the Role's configured statements to the plugin on function call. The struct is defined as:

type Statements struct {
	Creation   []string
	Revocation []string
	Rollback   []string
	Renewal    []string
}

It is up to your plugin to replace the {{name}}, {{password}}, and {{expiration}} in these statements with the proper values.

The Initialize function is passed a map of keys to values, this data is what the user specified as the configuration for the plugin. Your plugin should use this data to make connections to the database. It is also passed a boolean value specifying whether or not your plugin should return an error if it is unable to connect to the database.

Serving your plugin

Once your plugin is built you should pass it to vault's plugins package by calling the Serve method:

package main

import (
    "github.com/hashicorp/vault/plugins"
)

func main() {
    plugins.Serve(new(MyPlugin), nil)
}

Replacing MyPlugin with the actual implementation of your plugin.

The second parameter to Serve takes in an optional vault api.TLSConfig for configuring the plugin to communicate with vault for the initial unwrap call. This is useful if your vault setup requires client certificate checks. This config wont be used once the plugin unwraps its own TLS cert and key.

Running your plugin

The above main package, once built, will supply you with a binary of your plugin. We also recommend if you are planning on distributing your plugin to build with gox for cross platform builds.

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.

You should now be able to register your plugin into the vault catalog. To do this your token will need sudo permissions.

$ vault write sys/plugins/catalog/myplugin-database-plugin \
    sha256="..." \
    command="myplugin"
Success! Data written to: sys/plugins/catalog/myplugin-database-plugin

Now you should be able to configure your plugin like any other:

$ vault write database/config/myplugin \
    plugin_name=myplugin-database-plugin \
    allowed_roles="readonly" \
    myplugins_connection_details="..."