Files
NexaPG/docs/security/secret-management.md
nessi 597579376f
Some checks are pending
Container CVE Scan (development) / Scan backend/frontend images for CVEs (push) Waiting to run
Migration Safety / Alembic upgrade/downgrade safety (push) Successful in 2m43s
PostgreSQL Compatibility Matrix / PG14 smoke (push) Successful in 8s
PostgreSQL Compatibility Matrix / PG15 smoke (push) Successful in 8s
PostgreSQL Compatibility Matrix / PG16 smoke (push) Successful in 8s
PostgreSQL Compatibility Matrix / PG17 smoke (push) Successful in 7s
PostgreSQL Compatibility Matrix / PG18 smoke (push) Successful in 7s
Proxy Profile Validation / validate (push) Successful in 3s
Python Dependency Security / pip-audit (block high/critical) (push) Successful in 26s
Docker Publish (Release) / Build and Push Docker Images (release) Successful in 1m41s
[NX-204 Issue] Add secret management guidelines and enhance security notes
Introduced a comprehensive guide for secure production secret handling (`docs/security/secret-management.md`). Updated `.env.example` files with clearer comments on best practices, emphasizing not hardcoding secrets and implementing rotation strategies. Enhanced README with a new section linking to the secret management documentation.
2026-02-15 12:29:40 +01:00

2.5 KiB

Secret Management (Production)

This guide defines secure handling for NexaPG secrets in production deployments.

In Scope Secrets

  • JWT_SECRET_KEY
  • ENCRYPTION_KEY
  • DB_PASSWORD
  • SMTP credentials (configured in Admin Settings, encrypted at rest)

Do / Don't

Do

  • Use an external secret source (Vault, cloud secret manager, orchestrator secrets, or CI/CD secret injection).
  • Keep secrets out of Git history and out of image layers.
  • Use strong random values:
    • JWT secret: at least 32+ bytes random
    • Fernet key: generated via Fernet.generate_key()
  • Restrict access to runtime secrets (least privilege).
  • Rotate secrets on schedule and on incident.
  • Store production .env with strict permissions if file-based injection is used:
    • owner-only read/write (e.g., chmod 600 .env)
  • Audit who can read/update secrets in your deployment platform.

Don't

  • Do not hardcode secrets in source code.
  • Do not commit .env with real values.
  • Do not bake production secrets into Dockerfiles or image build args.
  • Do not share secrets in tickets, chat logs, or CI console output.
  • Do not reuse the same secrets between environments.

Pick one of these models:

  1. Platform/Cloud secrets
    • AWS Secrets Manager
    • Azure Key Vault
    • Google Secret Manager
  2. HashiCorp Vault
  3. CI/CD secret injection
    • Inject as runtime env vars during deployment
  4. Docker/Kubernetes secrets
    • Prefer secret mounts or orchestrator-native secret stores

If you use plain .env files, treat them as sensitive artifacts and protect at OS and backup level.

Rotation Basics

Minimum baseline:

  1. JWT_SECRET_KEY
    • Rotate on schedule (e.g., quarterly) and immediately after compromise.
    • Expect existing sessions/tokens to become invalid after rotation.
  2. ENCRYPTION_KEY
    • Rotate with planned maintenance.
    • Re-encrypt stored encrypted values (target passwords, SMTP password) during key transition.
  3. DB_PASSWORD
    • Rotate service account credentials regularly.
    • Apply password changes in DB and deployment config atomically.
  4. SMTP credentials
    • Use dedicated sender account/app password.
    • Rotate regularly and after provider-side security alerts.

Operational Checklist

  • No production secret in repository files.
  • No production secret in container image metadata or build args.
  • Runtime secret source documented for your environment.
  • Secret rotation owner and schedule defined.
  • Incident runbook includes emergency rotation steps.