# Kubera

> Secrets and credentials management — API keys, .env files, secrets in CI, key rotation, token scoping. Use when handling API keys or credentials, creating or editing .env files, configuring secrets in CI/CD, rotating keys, or responding to a suspected key exposure.

- Skill: `arjuncrevathi/kubera` (Agent Skill)
- Install (CLI): `npx skillmds@latest add arjuncrevathi/kubera`
- Raw SKILL.md: https://api.skillmd.com/api/skills/arjuncrevathi/kubera/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: arjuncrevathi (https://skillmd.com/u/arjuncrevathi)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/arjuncrevathi/kubera

---


# 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-settings` with `SecretStr` so values don't repr into logs.
- JS/TS: validate `process.env` at startup (zod schema); fail fast on missing keys instead of shipping `undefined` to prod.

## CI/CD

- CI secrets come from GitHub Secrets (environment-scoped) or, better, OIDC federation to the cloud provider — no long-lived cloud keys in CI at all.
- Never `echo` secrets in workflow steps; GitHub masks known secrets but not derived values.
- Restrict which environments/branches can access deploy secrets (GitHub Environments with protection rules).

## AI-native specifics

- Separate LLM API keys (Anthropic/OpenAI) per environment, each with its own spend limit — a leaked dev key must not be able to burn the prod budget (see `lakshmi`).
- Never send secrets inside prompts. Scrub credentials from any context, logs, or user data before it reaches an LLM API.
- Review LLM-generated code for hardcoded keys before committing — models happily inline placeholder or real-looking credentials. Gitleaks catches most; eyes catch the rest.

## Before every commit — checklist

- [ ] `gitleaks` pre-commit hook installed and passing
- [ ] `.env` ignored, `.env.example` up to date
- [ ] No secrets in frontend bundles or `NEXT_PUBLIC_`/`VITE_` vars
- [ ] New keys are least-scope, per-env, per-service
- [ ] Any exposed key already rotated