Best practice for using Vault Agent with Redis/RabbitMQ without storing secrets in configuration files

Hi,

I’m integrating Vault Community Edition (HA + TLS + Vault Agent) with our Jenkins/Puppet deployment.

Current flow:

Vault Agent
    ↓
Fetch secrets from Vault
    ↓
Render redis.conf / rabbitmq.conf
    ↓
Start service

This works well, but our security team wants Vault to be the only source of truth and avoid plaintext secrets in runtime configuration files.

My questions are:

  1. Is rendering configuration files using Vault Agent the recommended production approach for components like Redis and RabbitMQ?
  2. Is there any supported way to avoid storing plaintext secrets on disk for such components?
  3. If a service restarts, what is the recommended pattern to fetch secrets again while ensuring high availability?

Looking for HashiCorp-recommended best practices.

Your security teams intent is fair, but needs to be grounded in what each application supports. Its been a year or 5 since I regularly supported redis, so take this with some skepticism.

Redis supports a handful of environment variables, Redis environment variables | Retool Docs so unless its one of those, this [BUG] Redis sentinel can not run in k8s with environment variables in config file · Issue #10619 · redis/redis · GitHub is likely whats in your way - it does not support variable expansion in the config file.

The thing with most config files, they are not executed like a script, they are read by the app.

Having the secret in Vault is correct, so youre still complying with the single source of truth being Vault but at some point the secrets need to get into the config file (with correct permissions to prevent someone from reading it).

RabbitMQ, based on their docs, does support variable expansion, but i do not have experience with this product.

Thanks! That clears it up. We’ll use the best approach based on what each component supports.