How are you managing database credentials for Kubernetes apps at scale?

Separate the durable authorization policy from the credentials. A reviewed repo for migration roles, application roles, grants, and the configuration that issues credentials is a reasonable direction. Keep the schema changes with each application, but make ownership of the database roles explicit.

The missing piece is inventory and cleanup. Record which service and environment owns each role, secret, and database user. Then make decommissioning include revoking access and removing the corresponding users and secrets. Short-lived credentials can reduce the stale-password problem, but they don't automatically tell you whether a durable role is still needed.

Vault is worth a look if credential issuance and revocation are the main gaps, but budget time for operating it, not just installing it. You'll need to work through authentication from EKS, database configuration, policies, application delivery, and how credentials get renewed or replaced.

Vault Secrets Operator can sync secrets into Kubernetes Secrets. That's convenient for applications that already consume them, although it also means accepting Kubernetes Secrets as part of the storage path. Test the end-to-end flow with one service before committing to a fleet-wide rollout. Compare OpenBao against the same operational requirements rather than assuming the choice of product solves the lifecycle by itself.

Revisit IAM authentication for the RDS engines and configurations that support it. EKS Pod Identity can give a workload AWS permissions without distributing long-lived AWS keys, and the app can obtain a database authentication token.

That doesn't remove database roles or grants, and it may require application or connection-management changes. Check token handling and driver support with your developers first. It also isn't a blanket replacement for your Redshift and DocumentDB plans.

For Redshift and DocumentDB, I'd start by listing the exact roles and grants you need, then check what your chosen tooling can actually manage before building a provider. A small purpose-built provisioning job, potentially a Lambda function, could be easier to maintain than a custom Terraform provider.

Whatever runs it should make ownership, review, and deletion clear. Otherwise you've just moved the existing CI library into a different runtime.

Don't overlook a simpler secrets delivery setup if dynamic credentials aren't a requirement for every service. An operator can sync credentials from a secrets manager into Kubernetes, and a UI can make stored credentials easier to find. That's useful, but it won't by itself create database users, reconcile grants, or clean up orphaned accounts.