Managing Dynamic MongoDB Secrets with HashiCorp Vault

MongoDB credentials embedded in application configuration are difficult to rotate safely. They spread through source repositories, container images, CI logs, backup files and engineers’ laptops. HashiCorp Vault’s database secrets engine provides a cleaner model: an application requests a short-lived username and password when it needs access, and Vault creates that account directly in MongoDB.

This approach suits hybrid environments where MongoDB may run on premises, in VMware, or through a managed cloud service. It also gives systems administrators a central place to define lease duration, revoke credentials and audit secret access without manually changing every application deployment.

Australian teams often need to balance operational simplicity with data residency, scheduled maintenance windows and controls such as APRA CPS 234. A MongoDB cluster in AWS Sydney (ap-southeast-2) may serve local workloads, while a Vault cluster in Melbourne or an on-premises data centre handles identity and policy decisions.

Approach	Credential lifetime	Suitable use	Main operational concern
Static MongoDB account	Indefinite	Legacy applications	Rotation is manual and easily missed
Vault dynamic account	Minutes to days	Services and automation	Applications must renew or recreate leases
Managed identity integration	Provider-dependent	Cloud-native deployments	MongoDB and platform support can vary
Vault plus static root account	Root only for provisioning	Transitional environments	The bootstrap credential needs strict protection

Plan The Vault And MongoDB Relationship

The database secrets engine needs a MongoDB connection that can create and remove users. Use a dedicated provisioning account rather than the MongoDB administrator account. Grant only the roles required to create users, assign roles and remove accounts, and store that account’s password in Vault’s protected configuration.

Enable the engine and configure a connection with the MongoDB plugin supported by your Vault release. A typical starting point resembles:

vault secrets enable database

vault write database/config/mongodb \
  plugin_name=mongodb-database-plugin \
  allowed_roles="orders-readonly" \
  connection_url="mongodb://{{username}}:{{password}}@mongo01.internal:27017/admin" \
  username="vault-provisioner" \
  password="$MONGO_PROVISIONER_PASSWORD"

Use TLS in production, including certificate validation and a private CA where appropriate. Avoid placing credentials directly in shell history. For an internet-facing service, an Australian gaming example illustrates why public applications need tightly scoped database access even when the database itself is isolated from the internet.

Define Roles With Minimal MongoDB Privileges

A Vault database role connects a Vault policy to MongoDB user creation statements. For a read-only application, restrict access to the required database and collections where practical. MongoDB roles such as read, readWrite, and custom roles should reflect the service’s real behaviour rather than convenience.

For example:

vault write database/roles/orders-readonly \
  db_name=mongodb \
  creation_statements='{"db":"orders","roles":[{"role":"read","db":"orders"}]}' \
  default_ttl="1h" \
  max_ttl="24h"

The exact JSON format and supported fields can vary by Vault and MongoDB plugin version, so test the statement against a non-production cluster first. Separate roles for reporting, API access, background jobs and administration. A reporting process should not receive the same privileges as a service that updates customer records.

Create a Vault policy that permits only the required credential path:

path "database/creds/orders-readonly" {
  capabilities = ["read"]
}

Bind that policy to the workload’s authentication method, such as Kubernetes, AppRole, AWS IAM or a VMware-hosted automation identity. The policy should identify the service, not a broad team group, so a compromised reporting pod cannot request credentials intended for an order-processing service.

Integrate Credential Retrieval Into Applications

Applications should request credentials at startup and keep the returned lease metadata. Vault’s response includes a dynamic username, password, lease duration and lease ID. The service should renew the lease before expiry when renewal is supported, or fetch a replacement and rebuild its MongoDB connection pool.

Connection handling matters. Existing MongoDB sessions normally continue until the user is removed, but new connections will fail after Vault revokes the account. Configure the driver to respond to authentication failures, close stale pools and retry with freshly retrieved credentials. Do not write the generated password to application logs, exception traces or health-check output.

For containerised workloads, a Vault Agent sidecar or CSI integration can simplify delivery, although applications still need a sensible refresh strategy. For traditional Windows services or PowerShell automation, a startup task can retrieve the secret and place it in a protected process-specific location rather than a shared configuration file. This reduces exposure on mixed Windows and Linux estates common in Australian organisations.

Rotate, Revoke And Troubleshoot Leases

Dynamic users are removed when their lease expires or is revoked, subject to the plugin’s behaviour and MongoDB connectivity. Test both paths. Run vault lease revoke against a test lease, confirm that the MongoDB user disappears, and verify that the application can obtain a new account without operator intervention.

Common failures include a wrong authentication database, missing userAdmin permissions, a certificate name mismatch, blocked firewall ports and a MongoDB replica set that advertises unreachable hostnames. Check Vault audit logs, plugin logs and MongoDB authentication events together. A time difference between hosts can also cause confusing TLS or token errors, so use reliable NTP across Sydney, Perth and remote sites.

Keep a short runbook with commands, expected responses and escalation contacts. Operator notes can complement internal documentation, but production teams should record their own Vault version, plugin version, MongoDB topology and approved recovery steps. Never place live passwords or unredacted audit output in that runbook.

Operate Vault For Australian Hybrid Environments

Deploy Vault for availability rather than treating it as a single utility server. Use an integrated storage cluster or another supported HA backend, protect unseal and recovery keys, and monitor seal status, storage latency, token failures and database-plugin health. If the primary Vault cluster is in Sydney, document what happens when a Brisbane office, Perth site or interstate VPN cannot reach it.

Align lease durations with workload behaviour and business controls. A one-hour credential may be sensible for an API, while a batch process running during an overnight change window may need renewal permissions. Short leases reduce exposure, but overly aggressive expiry can create avoidable outages when a service cannot contact Vault during a network event.

Apply separate controls to development, test and production. Keep MongoDB backups encrypted and ensure restored environments do not accidentally reconnect to production through copied configuration. Review Vault audit records with the same care as privileged access logs, and map access reviews to internal security obligations, Essential Eight practices and, where relevant, APRA expectations.

Before production release, test startup, renewal, Vault unavailability, MongoDB failover, lease revocation and application rollback. With those paths automated, dynamic MongoDB accounts become a repeatable part of infrastructure management rather than a fragile credential workaround.