Question

A financial services company runs dozens of microservices across a Kubernetes cluster. Each service currently reads a long-lived static database password from an environment variable set during deployment. Auditors flagged that these credentials are never rotated, are visible in pod manifests, and cannot be attributed to a specific service when misuse occurs. The security architect must redesign credential handling to minimize the blast radius of a leaked credential while providing per-service attribution. Which approach BEST meets these requirements?

Accepted Answer

Deploy a centralized secrets manager that issues short-lived, dynamically generated database credentials to each service on demand, scoped per service and automatically revoked after a lease TTL

Answer

Encrypt the static database passwords at rest in the manifests using a KMS-backed sealed-secrets controller and rotate them manually every 90 days

Answer

Move the static passwords into Kubernetes Secrets objects and restrict access with RBAC so only the deploying namespace can read them

Answer

Store a single shared database credential in an external vault and have all services retrieve it at startup over mutual TLS