# Security Guide

This repo crosses several trust boundaries: browser sessions, API auth, cloud
provider credentials, SSH access, and reverse-proxy tokens. Security changes
should keep those boundaries explicit.

## Auth Surfaces

- Django session auth and API key auth:
  `backend/labs/api/authentication.py`
- Google and TiDB Cloud OAuth integration:
  `backend/labs/settings.py`,
  `backend/labs/tidb_serverless/oauth.py`
- Django staff admin: nginx exposes `/admin/` only on `labs.tidb.io`; Django
  requires an active staff user and a valid OTP sudo session. The login handoff
  uses the frontend's `redirect_uri` query parameter and then passes the target
  to the OAuth backend as `next`.
- Web SSH JWT signing and verification:
  `backend/labs/lab_manager_v2/lab_instance.py`,
  `ssh-proxy/cmd/web-console-ssh/main.go`
- Reverse-proxy token handoff:
  `backend/labs/templates/labs/install_caddy.sh`

## Secrets And Configuration

- Local backend env is typically loaded from `backend/labs/.env`.
- Production secrets should come from AWS Secrets Manager through
  `LOAD_ENV_FROM_AWS_SECRETS_MANAGER`.
- Avoid committing cloud credentials, OAuth secrets, or SSH signing material to
  the repo.

## Review Checklist

- Verify auth changes on both the issuing side and the consuming side.
- Check how tokens are transported in URLs, cookies, or headers.
- Re-read deployment templates when changing externally reachable routes.
- Prefer staging validation for real provisioning or proxy changes.