docs
Dashboard
Guides

Sécurité

Comment Bunkle protège vos secrets.

Architecture de sécurité

Bunkle utilise une approche de sécurité en couches pour protéger vos variables d'environnement.

┌─────────────────────────────────────────┐
│            UTILISATEUR                  │
│         (email + password)              │
└─────────────────────────────────────────┘
                    │
                    ▼
┌─────────────────────────────────────────┐
│          AUTHENTIFICATION               │
│         (Supabase Auth)                 │
│    • JWT tokens                         │
│    • Session management                 │
└─────────────────────────────────────────┘
                    │
                    ▼
┌─────────────────────────────────────────┐
│         ROW LEVEL SECURITY              │
│    • Chaque user ne voit que           │
│      ses propres données                │
└─────────────────────────────────────────┘
                    │
                    ▼
┌─────────────────────────────────────────┐
│           CHIFFREMENT                   │
│         (AES-256-GCM)                   │
│    • Données chiffrées au repos         │
└─────────────────────────────────────────┘

Chiffrement AES-256-GCM

Toutes les valeurs de variables sont chiffrées avec l'algorithme AES-256-GCM avant d'être stockées dans la base de données.

PropriétéValeur
AlgorithmeAES-256-GCM
Taille de clé256 bits
IV (vecteur d'initialisation)12 bytes aléatoires par valeur
Auth Tag16 bytes pour l'intégrité

Note : Chaque valeur est chiffrée avec un IV unique, ce qui signifie que la même valeur produit un texte chiffré différent à chaque fois.

Row Level Security (RLS)

Supabase RLS garantit que chaque utilisateur ne peut accéder qu'à ses propres données, même si quelqu'un obtenait un accès direct à la base de données.

sqlsql
-- Politique RLS pour les projets
CREATE POLICY "Users can only see their own projects"
ON projects
FOR SELECT
USING (auth.uid() = user_id);
-- Les variables sont liées aux projets
-- Donc automatiquement protégées

Stockage local

Le CLI stocke les informations de session localement sur votre machine :

  • Access token (JWT) - expire après 1 heure
  • Refresh token - permet de renouveler la session
  • ID du projet courant

🔒 Sécurité : Les tokens ne sont jamais affichés dans les logs ou l'historique du terminal. Utilisez bunkle logout pour supprimer la session.

Bonnes pratiques

✅ À faire

  • Utiliser des mots de passe forts et uniques
  • Se déconnecter sur les machines partagées
  • Différencier les credentials entre environnements
  • Faire une rotation régulière des secrets
  • Ajouter .env* au .gitignore

❌ À éviter

  • Commiter des fichiers .env dans Git
  • Partager des credentials via Slack/WhatsApp
  • Utiliser les mêmes credentials en dev et prod
  • Stocker des credentials dans le code source

Mode lecture seule

Pour afficher les variables sans exposer les valeurs complètes :

bashbash
$ bunkle pull mon-api --readonly
📦 Variables (lecture seule)
[production]
  DATABASE_URL=post****5432
  API_KEY=sk-****9876
  SECRET=xxxx****xxxx

Utile pour vérifier la présence des variables sans risquer d'exposer les valeurs lors d'un partage d'écran.

Voir aussi