Skip to content

Credentials exposed as env vars instead of mounted read-only volumes #3161

Description

@pdixit26

Summary
The operator injects sensitive credentials as plaintext environment variables into pod containers instead of mounting them as read-only volumes:

  • PGPASSWORD_SUPERUSER, PGPASSWORD_STANDBY
  • AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY

Per OWASP's Kubernetes Security Cheat Sheet: "It is best for secrets to be mounted into read-only volumes in your containers, rather than exposing them as environment variables." Env vars are readable via /proc//environ, process listings, and are prone to leaking into logs/crash dumps.

Expected Behavior

  • AWS credentials for WAL-E/WAL-G should be mounted as a read-only credentials file (e.g. ~/.aws/credentials) instead of AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY env vars. This requires corresponding support in spilo's entry_point.sh, which currently reads these values from the environment.
  • Postgres superuser/standby/monitoring passwords should be mounted as a read-only .pgpass file (or equivalent Patroni file-based credential support) instead of PGPASSWORD_SUPERUSER/PGPASSWORD_STANDBY/POSTGRES_PASSWORD env vars.

Impact

Compromise of any of these containers, or any way to read /proc//environ, exposes long-lived AWS IAM keys (full access to the WAL backup bucket — exfiltrate, delete, or tamper with backups) and/or the Postgres superuser password (full database access).

Reference

OWASP Kubernetes Security Cheat Sheet — "Keep secrets as secrets": https://cheatsheetseries.owasp.org/cheatsheets/Kubernetes_Security_Cheat_Sheet.html#keep-secrets-as-secrets

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions