mirror of
https://github.com/hashicorp/vault.git
synced 2025-08-07 07:07:05 +02:00
* Updated the PostgreSQL database creation command to ensure the static role name is consistent. The role name specified in allowed_roles="my-role" under the section "Rootless Configuration and Password Rotation for Static Roles" should align with the static role name in step #3. Previously, the command incorrectly used "my-static-role"; it should be "my-role" to match the earlier step. The same role name should also be used when reading the static credentials in step #4 * Added the file changelog/29138.txt * Delete changelog/29138.txt --------- Co-authored-by: Yoko Hyakuna <yoko@hashicorp.com> Co-authored-by: akshya96 <87045294+akshya96@users.noreply.github.com> Co-authored-by: Violet Hynes <violet.hynes@hashicorp.com>
259 lines
11 KiB
Plaintext
259 lines
11 KiB
Plaintext
---
|
|
layout: docs
|
|
page_title: PostgreSQL database secrets engine
|
|
description: >-
|
|
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 secrets engine
|
|
|
|
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, and also supports [Static
|
|
Roles](/vault/docs/secrets/databases#static-roles).
|
|
|
|
See the [database secrets engine](/vault/docs/secrets/databases) docs for
|
|
more information about setting up the database secrets engine.
|
|
|
|
The PostgreSQL secrets engine uses [pgx][pgxlib], the same database library as the
|
|
[PostgreSQL storage backend](/vault/docs/configuration/storage/postgresql). Connection string
|
|
options, including SSL options, can be found in the [pgx][pgxlib] and
|
|
[PostgreSQL connection string][pg_conn_docs] documentation.
|
|
|
|
## Capabilities
|
|
|
|
| Plugin Name | Root Credential Rotation | Dynamic Roles | Static Roles | Username Customization | Credential Types |
|
|
| ---------------------------- | ------------------------ | ------------- | ------------ | ---------------------- | ---------------------------- |
|
|
| `postgresql-database-plugin` | Yes | Yes | Yes | Yes (1.7+) | password, gcp_iam |
|
|
|
|
## Setup
|
|
|
|
1. Enable the database secrets engine if it is not already enabled:
|
|
|
|
```shell-session
|
|
$ 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-session
|
|
$ vault write database/config/my-postgresql-database \
|
|
plugin_name="postgresql-database-plugin" \
|
|
allowed_roles="my-role" \
|
|
connection_url="postgresql://{{username}}:{{password}}@localhost:5432/database-name" \
|
|
username="vaultuser" \
|
|
password="vaultpass" \
|
|
password_authentication="scram-sha-256"
|
|
```
|
|
|
|
1. Configure a role that maps a name in Vault to an SQL statement to execute to
|
|
create the database credential:
|
|
|
|
```shell-session
|
|
$ 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
|
|
```
|
|
|
|
## 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-session
|
|
$ 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 SsnoaA-8Tv4t34f41baD
|
|
username v-vaultuse-my-role-x
|
|
```
|
|
|
|
## Rootless Configuration and Password Rotation for Static Roles
|
|
|
|
<EnterpriseAlert product="vault" />
|
|
|
|
The PostgreSQL secrets engine supports using Static Roles and its password rotation mechanisms with a Rootless
|
|
DB connection configuration. In this workflow, a static DB user can be onboarded onto Vault's static role rotation
|
|
mechanism without the need of privileged root accounts to configure the connection. Instead of using a single root
|
|
connection, multiple dedicated connections to the DB are made for each static role. This workflow does not support
|
|
dynamic roles/credentials.
|
|
|
|
~> Note: It is **highly recommended** that the DB users being onboarded as static roles
|
|
have the minimum set of privileges. Each static role will open a new connection into the DB.
|
|
Granting minimum privileges to the DB users being onboarded ensures that multiple
|
|
highly-privileged connections to an external system are not being made.
|
|
|
|
~> Note: Out-of-band password rotations will cause Vault to be out of sync with the state of
|
|
the DB user, and will require manually updating the user's password in the external PostgreSQL
|
|
DB in order to resolve any errors encountered during rotation.
|
|
|
|
1. Enable the database secrets engine if it is not already enabled:
|
|
|
|
```shell-session
|
|
$ 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 connection to DB without root credentials and enable the rootless
|
|
workflow by setting the `self_managed` parameter:
|
|
|
|
```shell-session
|
|
$ vault write database/config/my-postgresql-database \
|
|
plugin_name="postgresql-database-plugin" \
|
|
allowed_roles="my-role" \
|
|
connection_url="postgresql://{{username}}:{{password}}@localhost:5432/database-name" \
|
|
self_managed=true
|
|
```
|
|
|
|
1. Configure a static role that creates a dedicated connection to a user in the DB with
|
|
the `self_managed_password` parameter:
|
|
|
|
```shell-session
|
|
$ vault write database/static-roles/my-role \
|
|
db_name="my-postgresql-database" \
|
|
username="staticuser" \
|
|
self_managed_password="password" \
|
|
rotation_period="1h"
|
|
```
|
|
|
|
1. Read static credentials:
|
|
|
|
```shell-session
|
|
$ vault read database/static-creds/my-role
|
|
Key Value
|
|
--- -----
|
|
last_vault_rotation 2024-09-11T14:15:13.764783-07:00
|
|
password XZY42BVc-UO5bMsbgxrW
|
|
rotation_period 1h
|
|
ttl 59m55s
|
|
username staticuser
|
|
```
|
|
|
|
## Client x509 certificate authentication
|
|
|
|
This plugin supports using PostgreSQl's [x509 Client-side Certificate Authentication](https://www.postgresql.org/docs/16/libpq-ssl.html#LIBPQ-SSL-CLIENTCERT).
|
|
|
|
To use this authentication mechanism, configure the plugin to consume the
|
|
PEM-encoded TLS data inline from a file on disk by prefixing with the "@"
|
|
symbol. This is useful in environments where you do not have direct access to
|
|
the machine that is hosting the Vault server. For example:
|
|
|
|
```shell-session
|
|
$ vault write database/config/my-postgresql-database \
|
|
plugin_name="postgresql-database-plugin" \
|
|
allowed_roles="my-role" \
|
|
connection_url="postgresql://{{username}}:{{password}}@localhost:5432/database-name?sslmode=verify-full" \
|
|
username="vaultuser" \
|
|
private_key=@/path/to/client.key \
|
|
tls_certificate=@/path/to/client.pem \
|
|
tls_ca=@/path/to/client.ca
|
|
```
|
|
|
|
Note: `private_key`, `tls_certificate`, and `tls_ca` map to [`sslkey`][sslkey_docs],
|
|
[`sslcert`][sslcert_docs], and [`sslrootcert`][sslrootcert_docs] configuration
|
|
options from PostgreSQL with the exception that the Vault parameters are the
|
|
contents of those files, not filenames.
|
|
|
|
[sslkey_docs]: https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-CONNECT-SSLKEY
|
|
[sslcert_docs]: https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-CONNECT-SSLCERT
|
|
[sslrootcert_docs]: https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-CONNECT-SSLROOTCERT
|
|
|
|
Alternatively, you can configure certificate authentication in environments
|
|
where the TLS certificate data is present on the machine that is running the
|
|
Vault server process. Set `sslmode` to be any of the applicable values as
|
|
outlined in the PostgreSQL documentation and set the SSL credentials in the
|
|
`sslrootcert`, `sslcert` and `sslkey` connection parameters as paths to files.
|
|
For example:
|
|
|
|
```shell-session
|
|
$ export SSL="sslmode=verify-full&sslrootcert=/path/to/ca.pem&sslcert=/path/to/client.pem&sslkey=/path/to/client.key"
|
|
$ vault write database/config/my-postgresql-database \
|
|
plugin_name="postgresql-database-plugin" \
|
|
allowed_roles="my-role" \
|
|
connection_url="postgresql://{{username}}:{{password}}@localhost:5432/database-name?sslmode=verify-full&${SSL}" \
|
|
username="vaultuser"
|
|
```
|
|
|
|
## API
|
|
|
|
The full list of configurable options can be seen in the [PostgreSQL database
|
|
plugin API](/vault/api-docs/secret/databases/postgresql) page.
|
|
|
|
For more information on the database secrets engine's HTTP API please see the
|
|
[Database secrets engine API](/vault/api-docs/secret/databases) page.
|
|
|
|
[pgxlib]: https://pkg.go.dev/github.com/jackc/pgx/stdlib
|
|
[pg_conn_docs]: https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-CONNSTRING
|
|
|
|
## Authenticating to Cloud DBs via IAM
|
|
|
|
### Google Cloud
|
|
|
|
Aside from IAM roles denoted by [Google's CloudSQL documentation](https://cloud.google.com/sql/docs/postgres/add-manage-iam-users#creating-a-database-user),
|
|
the following SQL privileges are needed by the service account's DB user for minimum functionality with Vault.
|
|
Additional privileges may be needed depending on the SQL configured on the database roles.
|
|
|
|
```sql
|
|
-- Enable service account to create roles within DB
|
|
ALTER USER "<YOUR DB USERNAME>" WITH CREATEROLE;
|
|
```
|
|
|
|
### Setup
|
|
|
|
1. Enable the database secrets engine if it is not already enabled:
|
|
|
|
```shell-session
|
|
$ 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. Here you can explicitly enable GCP IAM authentication
|
|
and use [Application Default Credentials](https://cloud.google.com/docs/authentication/provide-credentials-adc#how-to) to authenticate:
|
|
|
|
```shell-session
|
|
$ vault write database/config/my-postgresql-database \
|
|
plugin_name="postgresql-database-plugin" \
|
|
allowed_roles="my-role" \
|
|
connection_url="host=project:us-west1:mydb user=test-user@project.iam dbname=postgres sslmode=disable" \
|
|
use_private_ip="false" \
|
|
auth_type="gcp_iam"
|
|
```
|
|
|
|
You can also configure the connection and authenticate by directly passing in the service account credentials
|
|
as an encoded JSON string:
|
|
|
|
```shell-session
|
|
$ vault write database/config/my-postgresql-database \
|
|
plugin_name="postgresql-database-plugin" \
|
|
allowed_roles="my-role" \
|
|
connection_url="host=project:region:instance user=test-user@project.iam dbname=postgres sslmode=disable" \
|
|
use_private_ip="false" \
|
|
auth_type="gcp_iam" \
|
|
service_account_json="@my_credentials.json"
|
|
```
|
|
|
|
Once the connection has been configured and IAM authentication is complete, the steps to set up a role and generate
|
|
credentials are the same as the ones listed above.
|