Configuring a Secrets Engine for Dynamic Credentials

In this lesson, we’ll walk through how to enable and configure Vault’s dynamic Secrets Engines to generate on-demand credentials for external systems. Unlike the KV engine (which only needs to be enabled), dynamic engines such as AWS, Databases, Azure, GCP, Consul, and RabbitMQ require:

1. Granting Vault access to the backend platform.
2. Defining Vault roles that map to the platform’s permission sets.

The examples below for AWS and a relational database illustrate the common workflow.

Step 1: Grant Vault Access to the Backend Platform

Vault must authenticate to the external system to provision credentials. Depending on your deployment, you can use API keys, instance metadata, environment variables, or service principals.

AWS Example

Vault’s AWS Secrets Engine supports multiple authentication methods:

• IAM access key & secret key
• EC2/EKS instance roles (when Vault runs in AWS)
• Environment variables

To configure Vault with AWS API access, enable the engine and write the root credentials at aws/config/root:

vault write aws/config/root \
    access_key="AKIAIOSFODNN7EXAMPLE" \
    secret_key="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" \
    region="us-east-1"

Response:

Success! Data written to: aws/config/root

Database Example

Vault’s Database Secrets Engine supports popular databases via plugins (MySQL, PostgreSQL, Oracle, etc.). To configure a connection:

vault write database/config/prod-database \
    plugin_name="mysql-aurora-database-plugin" \
    connection_url="{{username}}:{{password}}@tcp(prod.cluster.us-east-1.rds.amazonaws.com:3306)/" \
    allowed_roles="app-integration,app-lambda" \
    username="vault-admin" \
    password="vneJ4908fkd3084Bmrk39fmslsl#e&349"

Response:

Success! Data written to: database/config/prod-database

Repeat this configuration for each database instance you wish Vault to manage.

Step 2: Define Vault Roles to Map to Backend Permissions

Roles tell Vault which permissions to request or create when issuing credentials.

AWS Roles

Create a Vault role for each AWS permission set or account:

Example role definitions:

When you create a role, Vault attaches (or references) an IAM policy. For example:

vault write aws/roles/prod-read-only \
    credential_type="iam_user" \
    policy_document=@read_only_policy.json \
    max_ttl="24h"

Database Roles

Similarly, define SQL-based roles for each database connection:

Example for an Oracle database:

vault write database/roles/prod-app-01-rw \
    db_name="prod-database" \
    creation_statements="CREATE USER '{{name}}' IDENTIFIED BY '{{password}}'; \
GRANT SELECT, INSERT, UPDATE ON orders TO '{{name}}';" \
    default_ttl="1h" \
    max_ttl="24h"

Generating Dynamic Credentials

After configuring the engine and roles, clients authenticate to Vault and request temporary credentials.

AWS Credential Retrieval

vault read aws/creds/data-scientist

Sample output:

Key               Value
---               -----
lease_id          aws/creds/data-scientist/123abc
lease_duration    1h
lease_renewable   true
access_key        AKIAIOSFODNN7EXAMPLE
secret_key        wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
security_token    <nil>

Database Credential Retrieval

vault read database/creds/oracle-reporting

Sample output:

Key              Value
---              -----
lease_id         database/creds/oracle-reporting/456def
lease_duration   1h
lease_renewable  true
username         V_VAULTUSE_MY_ROLE_ABC123XYZ
password         yRUSyd-vPYDg5NkU9kDg

Summary

Vault’s dynamic Secrets Engines streamline credential management by centralizing access, automating rotation, and enforcing least privilege.

1. Configure Vault’s engine with backend access.
2. Define roles that encapsulate specific permission sets.
3. Authenticate to Vault and request credentials; Vault leases and renews them automatically.

References

• Vault AWS Secrets Engine
• Vault Database Secrets Engine
• Vault Authentication Methods
• HashiCorp Vault Documentation