Managing secrets for containerized Node.js on Kubernetes

WHAT THIS TESTS This probes whether the engineer treats secrets as a first-class security concern in a distributed deployment, not just a config detail. It separates people who have run production clusters from those who only know local development.

A GOOD ANSWER COVERS Store credentials in Kubernetes Secret objects rather than ConfigMaps or hard-coded values. Enable encryption at rest for etcd so Secrets are not stored in plaintext on disk. Use RBAC to limit which service accounts and namespaces can read a Secret. Prefer mounting secrets as files into the pod, because file mounts update when the Secret rotates and are less likely to leak than environment variables. For stronger guarantees, integrate an external manager such as HashiCorp Vault or a cloud KMS-backed store, fetch credentials at runtime, and support short-lived dynamic credentials with automatic rotation.

COMMON WRONG ANSWERS Saying environment variables are a secure mechanism. Env vars are inherited by child processes, can surface in crash dumps and error tracking, are readable through container introspection, and often get logged accidentally. Another mistake is thinking base64-encoded Secrets are encrypted; base64 is encoding, trivially reversible.

LIKELY FOLLOW-UPS How does rotation work without restarting pods? How do you prevent secrets from landing in image layers or git history? How would you audit secret access? What is the trust boundary if a single pod is compromised?

ONE CONCRETE EXAMPLE A team stored a database password in a Deployment env var. A library crash printed the full process environment into Sentry, exposing the credential to everyone with dashboard access. Moving the password to a mounted Secret file, scoping read access via RBAC, and enabling etcd encryption closed the leak, and adopting Vault dynamic credentials meant the exposed password would have expired within an hour anyway.