AnsibleByExample

Ansible hashicorp.vault Module Example: Dynamic Secrets in a Playbook

Beginner
2024-01-014By Luca Berton

Lesson 1 of 15 in Foundations

Ansible Foundations to Production — full curriculum
  1. 1. Introduction to Ansible and Automation
  2. 2. Installing and Configuring Ansible
  3. 3. Running Ad-Hoc Commands
  4. 4. Writing Your First Playbook
  5. 5. Understanding and Using Modules
  6. 6. Variables and Facts
  7. 7. Conditionals and Loops
  8. 8. Handlers and Idempotency
  9. 9. Structuring Projects with Roles
  10. 10. Inventory Management
  11. 11. Using Ansible Vault for Secrets
  12. 12. Debugging and Troubleshooting
  13. 13. Real-World Automation Examples
  14. 14. Final Project: Deploy a Web Server
  15. 15. Bonus - What's Next with Ansible?
View path overview →

The hashicorp.vault collection lets a playbook pull secrets straight out of HashiCorp Vault instead of hardcoding them in a vars file. It was one of 12 new content collections announced for AAP 2.7 at Red Hat Tech Day Netherlands 2026 in Bunnik, alongside OIDC, PKI, dynamic credentials, and Event-Driven Ansible (EDA) integration. Below is a minimal playbook that reads a static secret and requests a short-lived dynamic database credential in the same run.

Example playbook

---
- name: Fetch secrets from Vault
  hosts: localhost
  gather_facts: false
  vars:
    vault_addr: "https://vault.internal.example.com:8200"
  tasks:
    - name: Read a static application secret
      community.hashi_vault.vault_kv2_get:
        url: "{{ vault_addr }}"
        auth_method: token
        token: "{{ lookup('env', 'VAULT_TOKEN') }}"
        engine_mount_point: secret
        path: app/database
      register: db_static_secret

    - name: Request a dynamic database credential
      community.hashi_vault.vault_read:
        url: "{{ vault_addr }}"
        auth_method: token
        token: "{{ lookup('env', 'VAULT_TOKEN') }}"
        path: database/creds/readonly-role
      register: db_dynamic_creds

    - name: Show the dynamic credential lease details
      ansible.builtin.debug:
        msg: >
          Username: {{ db_dynamic_creds.data.data.username }},
          lease duration: {{ db_dynamic_creds.data.lease_duration }}s

    - name: Configure the app with the dynamic credential
      ansible.builtin.template:
        src: templates/app-db.conf.j2
        dest: /etc/myapp/db.conf
        mode: "0600"
      vars:
        db_user: "{{ db_dynamic_creds.data.data.username }}"
        db_password: "{{ db_dynamic_creds.data.data.password }}"

What it does

The first task uses vault_kv2_get to read a plain KV v2 secret at secret/app/database — the kind of static value you'd otherwise store in an encrypted vars file. The second task calls vault_read against a database secrets engine path (database/creds/readonly-role), which Vault generates on demand: every run gets a brand-new username and password with a lease duration instead of a value that sits in Vault forever. The third task just prints the lease so you can see it expire on its own schedule, and the last task writes the freshly minted credential into a config file with tight file permissions.

Authentication here uses a token for simplicity, but hashicorp.vault also supports OIDC login, so a playbook run through AAP 2.7 can authenticate with the platform's own identity provider instead of a long-lived Vault token. Combined with the collection's PKI support for issuing short-lived certificates, and its dynamic-credentials integration with AAP's credential system, the pattern above extends naturally to TLS material, cloud IAM credentials, and other secret types Vault can broker.

Notes / Gotchas

  • Install the module dependency first: ansible-galaxy collection install community.hashi_vault and pip install hvac on the control node (or execution environment) — the FQCN examples above assume the modules are available under community.hashi_vault.
  • Never print real secret values with debug in production; the example above logs metadata only. Mask sensitive output with no_log: true on any task handling the actual password.
  • Dynamic credentials expire. If db_dynamic_creds.data.lease_duration is shorter than your automation window, renew or re-request the lease rather than caching the value across long-running jobs.
  • Set VAULT_TOKEN via an AAP credential or environment injection, not in plaintext vars — the whole point of dynamic secrets is to stop hardcoding anything long-lived.
  • Because the collection also integrates with Event-Driven Ansible, secret rotation events or lease-expiry warnings from Vault can trigger a rulebook that reruns the credential-fetch playbook automatically.

Dynamic secrets turn "here's a password" into "here's a credential that expires," and hashicorp.vault gives Ansible a first-class way to request, use, and discard them inside a single playbook run.

References

All Tutorials