d5be4fbd6a
* Adds a summary to the top of each plugin's page showing the capabilities that the plugin has. * Fixed sidebar sorting (they weren't quite alpabetical) * Improved instructions for using the Oracle plugin * Added note about using the pluggable database rather than the container database * Replaced admin/root usernames with super-user ones to encourage users to not use the root user in Vault * Included suggestions to rotate the root user's password when the plugin is capable * Improve documentation around rotating the root user's password * Fixed various typos
174 lines
7.1 KiB
Plaintext
174 lines
7.1 KiB
Plaintext
---
|
|
layout: docs
|
|
page_title: Database - Secrets Engines
|
|
sidebar_title: Databases
|
|
description: |-
|
|
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
|
|
|
|
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. These are referred to as "dynamic roles" or "dynamic secrets".
|
|
|
|
Since every service is accessing the database with unique credentials, it makes
|
|
auditing much easier when questionable data access is discovered. You can track
|
|
it down to the specific instance of a service based on the SQL username.
|
|
|
|
Vault makes use of its own internal revocation system to ensure that users
|
|
become invalid within a reasonable time of the lease expiring.
|
|
|
|
### Static Roles
|
|
|
|
The database secrets engine supports the concept of "static roles", which are
|
|
a 1-to-1 mapping of Vault Roles to usernames in a database. The current password
|
|
for the database user is stored and automatically rotated by Vault on a
|
|
configurable period of time. This is in contrast to dynamic secrets, where a
|
|
unique username and password pair are generated with each credential request.
|
|
When credentials are requested for the Role, Vault returns the current
|
|
password for the configured database user, allowing anyone with the proper
|
|
Vault policies to have access to the user account in the database.
|
|
|
|
~> Not all database types support static roles at this time. Please consult the
|
|
specific database documentation on the left navigation or the table below under
|
|
[Database Capabilities](#database-capabilities) to see if a given database
|
|
backend supports static roles.
|
|
|
|
## 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 database secrets engine:
|
|
|
|
```shell
|
|
$ vault secrets enable database
|
|
Success! Enabled the database secrets engine at: database/
|
|
```
|
|
|
|
By default, the secrets engine will enable at the name of the engine. To
|
|
enable the secrets engine at a different path, use the `-path` argument.
|
|
|
|
1. Configure Vault with the proper plugin and connection information:
|
|
|
|
```shell
|
|
$ vault write database/config/my-database \
|
|
plugin_name="..." \
|
|
connection_url="..." \
|
|
allowed_roles="..." \
|
|
username="..." \
|
|
password="..."
|
|
```
|
|
|
|
~> It is highly recommended a user is created for Vault to use to
|
|
manage users rather than using the database's root account.
|
|
|
|
Vault will use the user specified here to create/update/revoke database
|
|
credentials. That user must have the appropriate permissions to perform
|
|
actions upon other database users.
|
|
|
|
This secrets engine can configure multiple database connections. For details
|
|
on the specific configuration options, please see the database-specific
|
|
documentation.
|
|
|
|
1. After configuring the user, it is highly recommended to rotate that user's
|
|
password such that the vault user is not accessible by any users other than
|
|
Vault itself:
|
|
|
|
```shell
|
|
$ vault write -force database/rotate-root/my-database
|
|
```
|
|
|
|
When this is done, the password for the user specified in the previous step
|
|
is no longer accessible. Because of this, it is highly recommended that a
|
|
user is created specifically for Vault to use to manage database
|
|
users.
|
|
|
|
1. Configure a role that maps a name in Vault to an SQL statement to execute to
|
|
create the database credential:
|
|
|
|
```shell
|
|
$ 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 `{{username}}` and `{{password}}` fields will be populated by the plugin
|
|
with dynamically generated values. In some plugins the `{{expiration}}`
|
|
field is also be supported.
|
|
|
|
## Usage
|
|
|
|
After the secrets engine is configured and a user/machine has a Vault token with
|
|
the proper permission, it can generate credentials.
|
|
|
|
1. Generate a new credential by reading from the `/creds` endpoint with the name
|
|
of the role:
|
|
|
|
```shell
|
|
$ 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-vaultuser-e2978cd0-
|
|
```
|
|
|
|
## Database Capabilities
|
|
| Database | Root Credential Rotation | Dynamic Roles | Static Roles |
|
|
| --- | --- | --- | --- |
|
|
| [Cassandra](/docs/secrets/databases/cassandra) | Yes | Yes | Yes |
|
|
| [Elasticsearch](/docs/secrets/databases/elasticdb) | Yes | Yes | No |
|
|
| [HanaDB](/docs/secrets/databases/hanadb) | No | Yes | No |
|
|
| [InfluxDB](/docs/secrets/databases/influxdb) | Yes | Yes | No |
|
|
| [MongoDB](/docs/secrets/databases/mongodb) | No | Yes | Yes |
|
|
| [MongoDB Atlas](/docs/secrets/databases/mongodbatlas) | No | Yes | Yes |
|
|
| [MSSQL](/docs/secrets/databases/mssql) | Yes | Yes | No |
|
|
| [MySQL/MariaDB](/docs/secrets/databases/mysql-maria) | Yes | Yes | Yes |
|
|
| [Oracle](/docs/secrets/databases/oracle) | Yes | Yes | Yes |
|
|
| [PostgreSQL](/docs/secrets/databases/postgresql) | Yes | Yes | Yes |
|
|
| [Redshift](/docs/secrets/databases/redshift) | Yes | Yes | Yes |
|
|
|
|
## Custom Plugins
|
|
|
|
This secrets engine allows custom database types to be run through the exposed
|
|
plugin interface. Please see the [custom database plugin]
|
|
(/docs/secrets/databases/custom) for more information.
|
|
|
|
## Password Generation
|
|
|
|
Password generation for both static and dynamic database credentials occurs via
|
|
the `GetPassword()` function. For static credentials, the `SetCredentials()`
|
|
function is also used on the output of `GetPassword().`
|
|
|
|
Please see the [DB plugin credentials source code]
|
|
(https://github.com/hashicorp/vault/blob/master/sdk/database/dbplugin/database.pb.go)
|
|
for more information.
|
|
|
|
## Learn
|
|
|
|
Refer to the following step-by-step tutorials for more information:
|
|
|
|
- [Secrets as a Service: Dynamic Secrets](https://learn.hashicorp.com/vault/secrets-management/sm-dynamic-secrets)
|
|
- [Database Root Credential Rotation](https://learn.hashicorp.com/vault/secrets-management/db-root-rotation)
|
|
- [Database Static Roles and Credential Rotation](https://learn.hashicorp.com/vault/secrets-management/db-creds-rotation)
|
|
|
|
## API
|
|
|
|
The database secrets engine has a full HTTP API. Please see the [Database secret
|
|
secrets engine API](/api/secret/databases) for more details.
|