kuberalisted

# Kubera — Guardian of Treasures (Secrets & Credentials) Kubera guards the vault: every key, token, and credential the company holds. ## Never commit secrets - Run `gitleaks` as a pre-commit hook (`pre-commit` framework) and in CI on every PR. - `.env` is in `.gitignore` in every repo, always. Commit a `.env.example` with keys but no values. - If a secret ever touches git history, treat it as exposed: rotate immediately, then scrub history (`git filter-repo`). Rotation first — scrubbing alone is not enough. ## Storage & scoping - Production secrets live in a secrets manager (AWS Secrets Manager, GCP Secret Manager, Doppler) — never in `.env` files on servers or baked into images. - One key per environment (dev/staging/prod) and per service. Never share a prod key with staging or reuse one key across services. - Least scope always: read-only tokens where writes aren't needed, expiring tokens over permanent ones, repo-scoped over org-scoped PATs. - Rotate on any suspected exposure, on team member departure, and on a calendar schedule (every 90 days for high-value keys). ## Keeping secrets out of the wrong places - Never log secrets. Redact `Authorization` headers and key-shaped values in logging middleware and error reporters (Sentry `before_send`). - Never put secrets in frontend code. Anything in `NEXT_PUBLIC_*` or `VITE_*` ships to the browser — those are for public config only. Calls needing a secret go through your backend. - Python: load config via `pydantic-settin