# Gestion des secrets

# Gestion des secrets

> _Dernière mise à jour : 2026-05-10_

## Inventaire des secrets

| Secret | Stocké où | Rotation | Critique ? |
|---|---|---|---|
| `COOKIE_SECRET` | env var Unraid | À la création du container | Élevé : compromission = forge sessions |
| `FIRST_ADMIN_PASSWORD` | env var Unraid (boot only) | Une seule fois | Faible après boot (changé via `/me`) |
| Hash password users | SQLite (argon2id) | Par user via reset | N/A (hash, pas le clair) |
| Token de session | Map RAM (jamais persistée) | À chaque login | N/A (rotation auto) |
| `BGG_API_TOKEN` | env var Unraid | Manuel | Faible (API publique fonctionne sans) |
| `SMTP_USER` / `SMTP_PASS` | env var Unraid | Manuel | Moyen (compromission = spam from your domain) |
| Clé privée SSH oracle (`id_ed25519`) | Volume `/app/ssh/` (RO dans le container) | 6 mois recommandé | **Critique** : compromission = exécution arbitraire sur la VM oracle |
| `.credentials.json` Anthropic | Sur la VM oracle uniquement | À la rotation Anthropic | Élevé : compromission = quota du compte |
| `REGISTRY_USER` / `REGISTRY_PASSWORD` | Gitea Secrets | À la rotation Gitea | Moyen (compromission = push d'images compromises) |

## Règles

- **Jamais dans git** : `.env` est dans `.gitignore`. `Dockerfile` touche un `.env` vide pour que les npm scripts (qui passent `--env-file=.env`) ne crashent pas, mais le contenu reste passé via Docker `-e` ou Unraid UI.
- **Jamais dans les logs** : le logger ne logue jamais une env var en clair. Vérifier avec `grep` régulièrement.
- **Jamais dans la doc** : utiliser des placeholders (`<your-token-here>`) dans `.env.example`.

## Rotation

### `COOKIE_SECRET`
- Effet d'une rotation : toutes les sessions in-memory sont invalidées au restart
- Pas urgent sauf compromission. À faire si tu soupçonnes une fuite.

```bash
# Générer un nouveau secret
node -e "console.log(require('crypto').randomBytes(32).toString('hex'))"

# Mettre dans .env Unraid + restart
docker compose -f /mnt/user/appdata/boardgame-referee/docker-compose.yml restart app
```

### Clé SSH oracle
Cf. `securite/ssh-oracle.md` § "Rotation de la clé SSH". Procédure complète en 7 étapes.

### `.credentials.json` Anthropic
Sur la VM oracle :
```bash
# Sur ton compte admin VM
cp ~/.claude/.credentials.json /home/oracle/.claude/.credentials.json
chown oracle:oracle /home/oracle/.claude/.credentials.json
```

### Tokens API (BGG, registry)
Régénérer côté provider, mettre à jour dans Unraid UI / Gitea Secrets, restart.

## Stockage long terme

Recommandation : utiliser **Bitwarden self-hosted** (vaultwarden) pour les secrets :
- `COOKIE_SECRET` (genre "boardgame-referee — cookie secret")
- Clé privée SSH oracle (en attachement chiffré)
- Credentials Anthropic
- Tokens registry, BGG, SMTP

Backup régulier de Bitwarden lui-même + clé maître mémorisée par toi seul.

## Pas de secrets dans le code source

Vérifier régulièrement avec `git secrets` ou `gitleaks` :

```bash
# Installer gitleaks (binary release sur GitHub)
gitleaks detect --source . --no-git
```

Pas de scan auto en CI actuellement — peut être ajouté facilement (job `gitleaks` dans `.gitea/workflows/build.yml`).

## Si compromission

### Suspecté : `COOKIE_SECRET`
1. Régénérer immédiatement
2. Restart container (sessions invalidées)
3. Vérifier les logs récents pour activité anormale (logins multiples, IPs inhabituelles)

### Suspecté : clé SSH oracle
1. Rotation immédiate (cf. ssh-oracle.md)
2. Vérifier `/home/oracle/.claude/.credentials.json` — exfiltration possible si Read l'a vu (mais le settings.json le bloque normalement)
3. Vérifier les logs `auth.log` côté VM pour SSH inattendus

### Suspecté : credentials Anthropic
1. Révoquer le token côté console.anthropic.com
2. Générer une nouvelle session sur la VM oracle (`claude login` côté oracle)
3. Audit des appels API récents côté Anthropic dashboard