HashiCorp Vault’s database secrets engine provides secure, dynamic access to databases by either managing credentials directly or delegating credential lifecycle management to external processes. When configuring Vault with PostgreSQL, the parameter self_managed=true plays a critical role in determining which workflow is followed.
This article explains the behavior observed when configuring PostgreSQL with Vault using both managed and self-managed workflows, highlighting why some configuration transitions succeed while others fail. Evidence is provided through real command-line interactions.
Scenario Analysis
1. Starting with Self-Managed and Attempting to Overwrite with Vault-Managed
vault write database/config/postgresql \
connection_url="postgresql://{{username}}:{{password}}@localhost:5432/mydb" \
plugin_name=postgresql-database-plugin \
allowed_roles="*" \
self_managed=true
# Success
When attempting to overwrite this with a Vault-managed configuration:
vault write database/config/postgresql \ connection_url="postgresql://postgres:password@localhost:5432/mydb" \ plugin_name=postgresql-database-plugin \ allowed_roles="*" # Error: cannot use both self-managed and vault-managed workflows
Why it fails:
Once a configuration is marked as self-managed, Vault enforces that paradigm strictly. Switching to a managed workflow introduces conflicting responsibilities, and Vault rejects the request to preserve integrity.
Workaround:
It is required to delete the connection and recreate the connection again.
2. Starting with Vault-Managed and Overwriting with Self-Managed
vault write database/config/postgresql123 \ connection_url="postgresql://postgres:password@localhost:5432/mydb" \ plugin_name=postgresql-database-plugin \ allowed_roles="*" # Success (with warning about plaintext password)
Overwriting with self-managed succeeds:
vault write database/config/postgresql123 \
connection_url="postgresql://{{username}}:{{password}}@localhost:5432/mydb" \
plugin_name=postgresql-database-plugin \
allowed_roles="*" \
self_managed=true
# Success
Why it succeeds:
Transitioning from Vault-managed to self-managed is considered a restriction of Vault’s control. Vault relinquishes responsibility for user creation/rotation, which is consistent and safe. Hence, the update is permitted.
Conclusion
The behavior observed in Vault highlights its strict separation between managed and self-managed database workflows. While Vault supports transitioning from Vault-managed to self-managed mode, it disallows the reverse to maintain clarity and security boundaries. By understanding these rules and following best practices, teams can design safer, more predictable database integrations with Vault.