HashiCorp Vault Operations Professional exam practice guide — Part 5

Dynamic secrets

• Part 1 (deploying & initializing Vault)
• Part 2 (transit secrets engine & auto-unseal)
• Part 3 (auth methods, policies, and tokens)
• Part 4 (Vault agent & auto-auth)
• Part 6 (Vault HA cluster, backup & recovery)

Dynamic secrets

I absolutely love this feature from HashiCorp Vault. The ability to generate ephemeral credentials on the fly is every system administrator’s dream scenario. Because I have written about setting up dynamic Google Cloud credentials in the past, I will dive into a different example to illustrate the power of Vault’s secrets engines.

MariaDB (MySQL) database setup

I installed MariaDB on my Vault agent server which we configured in part 4. I will not go into too much detail regarding the setup of the database, but once you have it up & running and it is able to accept external access (HINT: set bind-address in the server config to 0.0.0.0), you will have to create a user for Vault which allows it to create other users:

CREATE USER 'vaultuser'@'%' IDENTIFIED BY 'vaultpassword123';

GRANT ALL ON *.* TO 'vaultuser'@'%' WITH GRANT OPTION;

NOTE: be careful not to GRANT ALL PRIVILEGES. You already have a a root user with that role

ANOTHER NOTE: the WITH GRANT OPTION here is what allows users to grant their privileges to other users

ONE MORE NOTE: on the exam, if there are any external systems that require configuring, you will NOT be asked to do so. You will be provided with credentials or anything else that you may require that is not directly related to Vault. Remember: this is a Vault certification exam — not MySQL, GCP, AWS, etc.

Database secrets engine

We will be using the database secrets engine to demonstrate completing the following steps on our Vault server.

• Enable database secrets engine:

vault secrets enable -path=mariadb10 database

• Create connection configuration:

vault write mariadb10/config/mariadb-config \
  plugin_name=mysql-database-plugin \
  connection_url="{{username}}:{{password}}@tcp(10.128.0.48:3306)/" \
  username="vaultuser" \
  password="vaultpassword123" \
  allowed_roles="db-user-role"

NOTE: at this point, db-user-role does not yet exist (that will be our next step)

• Create (dynamic) credentials user role

vault write mariadb10/roles/db-user-role \
  db_name=mariadb-config \
  creation_statements="CREATE USER '{{name}}'@'%' IDENTIFIED BY '{{password}}'; GRANT SELECT ON *.* TO '{{name}'@'%';" \
  default_ttl="15m" \
  max_ttl="1h"

Let us review what is going on here. In order for dynamic secrets to be generated, Vault needs to be given access to an account that has the permissions to create username/password, GCP credentials files, AWS keys, etc. You then define a role with a specific set of permissions and constraints. Finally, Vault to provision you the credentials upon request and will cleanup after you once the token has reached the end of its TTL.

• Generate dynamic database secrets:

vault read mariadb10/creds/db-user-role

Key                Value
---                -----
lease_id           mariadb10/creds/db-user-role/uxtnyDQ6ePwbS4DZAbVsY7UT
lease_duration     15m
lease_renewable    true
password           QKTM4Loql0-PbQ8TXmb-
username           v-root-db-user-ro-Ehup40XxgVDkON

CHALLENGE #1: secure the above example by rotating vaultuser’s password

CHALLENGE #2: configure a secrets engine from a cloud provider

>> SPOILER ALERT!!! SOLUTION GUIDE BELOW!!! <<

Challenge solutions guide

SOLUTION #1

Rotate the password used in your database secret config with the following:

vault write -force mariadb10/rotate-root/mariadb-config

Even thought the endpoint is called /rotate-root, it is rotating the (initial) password you used to configure the database connection with. Now, if you were to try and connect to the MariaDB server as the user, vaultuser using the password, vaultpassword123, you will be denied access.

SOLUTION #2

I have written an article about this before using the GCP secrets engine.