ENG-3566: Wire all DB connections through DBCredentialProvider

[erosselli]

Ticket ENG-3566

Stacked on: #8175 (must be merged first)

Description Of Changes

Wires the DBCredentialProvider (from #8175) into all database connection paths so credentials always come from the provider — no hardcoded user/password in config required for AWS Secrets Manager deployments.

Code Changes

• engine_creators.py — module-level _db_cred_provider replaces get_db_credentials()/get_readonly_db_credentials(); creator signatures unchanged (no call site changes to ctl_session, session_management, tasks)
• db_credential_provider.py — added get_database_url() for callers that need a connection URI
• session.py — get_db_session() defaults to make_sync_creator() when no engine provided (fixes 6 callers that used URI-based path)
• env.py — alembic online migrations use make_sync_creator(), offline uses get_database_url()
• app_setup.py — startup configure_db uses provider URL
• admin.py — migrate/reset/configure endpoints use provider URL
• health.py — health check uses provider URL
• test_engine_creators.py — removed tests for deleted credential helpers, added SSL context integration test

Steps to Confirm

1. Start Fides normally (static provider) — GET /health/database returns healthy
2. Configure AWS Secrets Manager with DB credentials — Fides starts and connects without user/password in config
3. Run nox -s "pytest(lib)" and nox -s "pytest(misc-unit)" — all tests pass

Pre-Merge Checklist

• Issue requirements met
• All CI pipelines succeeded
• CHANGELOG.md updated
  • Updates unreleased work already in Changelog, no new entry necessary
• UX feedback:
  • No UX review needed
• Followup issues:
  • Followup issues created
• Database migrations:
  • No migrations
• Documentation:
  • No documentation updates required

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

2 Skipped Deployments

Project	Deployment	Actions	Updated (UTC)
fides-plus-nightly	Ignored	Preview	May 15, 2026 1:48pm
fides-privacy-center	Ignored		May 15, 2026 1:48pm

[codecov]

Codecov Report

❌ Patch coverage is 94.44444% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 85.61%. Comparing base (d64e6f1) to head (2afa345).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
src/fides/common/engine_creators.py	87.50%	1 Missing and 1 partial ⚠️
src/fides/api/app_setup.py	75.00%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #8176      +/-   ##
==========================================
+ Coverage   85.59%   85.61%   +0.01%     
==========================================
  Files         658      658              
  Lines       42847    42858      +11     
  Branches     5018     5016       -2     
==========================================
+ Hits        36675    36691      +16     
+ Misses       5064     5063       -1     
+ Partials     1108     1104       -4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[erosselli]

I will address this in a follow-up PR -- I suspect I can also remove the sync_database_uri and async_database_uri builders in the db settings , but I want to make sure that wouldn't break anything before removing it.

[JadeCara]

Only thing I saw that we might want to document or something in case it ever becomes an issue is the catch-all isinstance(exc, Psycopg2OperationalError). The docstring explicitly acknowledges the tradeoff.

The concern for dynamic-credential deployments with this is: during a DB outage, every pool connection attempt across all workers will hammer Secrets Manager simultaneously (thundering herd). With n workers × m pool_size = many concurrent invalidation calls, this could hit AWS rate limits.

[erosselli]

@JadeCara re the thundering-herd issue:

The concern for dynamic-credential deployments with this is: during a DB outage, every pool connection attempt across all workers will hammer Secrets Manager simultaneously (thundering herd). With n workers × m pool_size = many concurrent invalidation calls, this could hit AWS rate limits.

The thundering-herd protection in AWSSecretsManagerProvider handles concurrent calls for the same secret within a single process (per-secret lock), though each pod will have its own lock.

The circuit breaker pattern is built to mitigate this: after the first failed refresh (credentials are fine, DB is just down), subsequent invalidate() calls within the 30s cooldown are no-ops. So the burst is bounded to one SM call per pod per 30 seconds, not per connection attempt. The cooldown period is also configurable via FIDES__SECRETS__AWS_SECRETS_MANAGER__CIRCUIT_BREAKER_COOLDOWN_SECONDS