XEIZE
/Vulnerability documentation/Secrets/Secrets in Vault or Secret Manager

Secrets in Vault or Secret Manager

If your organization already uses a central secret store such as Vault, AWS Secrets Manager, Google Secret Manager, or Azure Key Vault, move secrets out of code and retrieve or inject them at runtime.

When to use this guide

  • Vault or a cloud secret manager is your organizational standard.
  • Kubernetes, VMs, and ECS share a central secret store.
  • Your operations team centrally manages secret rotation and access.

Recommended approach

  • Keep only secret names, paths, or reference keys in code, not the values.
  • Retrieve values at startup through the SDK, sidecar, CSI driver, or init container appropriate to your environment.
  • Define rotation intervals, access policies, and audit-log review when registering a secret.
  • Prefer dynamic credentials or short-lived tokens to long-lived static secrets when the store supports them.
  • For Google Cloud Secret Manager, consider direct API access or an official integration instead of passing values through files or environment variables when feasible.

Examples

Before

python
API_KEY = "sk-prod-123456"
DB_PASSWORD = "super-secret-password"

After

python
import os

API_KEY = os.getenv("API_KEY")
DB_PASSWORD = os.getenv("DB_PASSWORD")

Vault or Secret Manager supplies the actual API_KEY and DB_PASSWORD values to the runtime environment. This example reads values that have already been injected; it does not call the store's API. Validate required values and stop startup if they are missing.

Remediation steps

  1. Revoke exposed secrets promptly and issue new values.
  2. Register the new secrets in the approved store and remove actual values from code and configuration files.
  3. Change the application to use secret names or references.
  4. Check whether supported dynamic credentials can replace static secrets.
  5. Confirm that services work with the new values and the old values no longer work.
  6. Restrict secret-read access to the service accounts that need it.

Example instructions for the owner

  • “Remove secrets from code, register them in Vault or Secret Manager, and retrieve them at runtime.”
  • “Keep only reference names in the application and inject the actual values from the central store.”
  • “Issue new values instead of reusing exposed secrets, and minimize access permissions during migration.”

Additional checks

  • Does the service account have excessive permissions to read secrets?
  • Is there a secret rotation policy?
  • Can application errors write secret values to logs?
  • Does the environment require a pinned secret version, or is it always using latest without considering that requirement?
XEIZE DocumentationTechnical support