bige-ops Beta démo

Secrets, coffre & credentials

Il n’y a pas de vault SaaS bige-ops. Aucun backend à nous ne voit vos clés. Tout vit en local, dans votre workspace et dans vos réglages desktop ; après un deploy, les secrets d’exécution vivent côté Outscale, sur vos VMs ou dans votre cluster.

Vos secrets = votre responsabilité. On ne stocke rien « quelque part pour vous ». Chiffrez le disque, verrouillez la session, sachez qui a accès au poste et aux sauvegardes. Si vous avez déjà un vault d’entreprise, utilisez-le — en dehors de bige-ops : l’app n’impose pas le sien et ne cherche pas à le remplacer.

flowchart LR
  V[Coffre local vault.local.json] --> E[bige-ops/.env]
  E --> D[Deploy]
  D --> VM[VM Outscale / cluster]
  V -.exclu.-> G[config-history GitHub]
  E -.exclu.-> G

Le coffre alimente le deploy. La branche config-history ne reçoit jamais les secrets.

Où vit quoi

Chemins réels, relatifs au workspace ou à la simulation :

Fichier	Contenu
`accounts/<id>/credentials.local.json`	Credentials Outscale du compte — l’emplacement recommandé
`bige-ops/credentials.local.json`	Credentials propres à une simulation
`credentials.default.json`	Credentials partagés du workspace (legacy)
`bige-ops/vault.local.json`	Secrets applicatifs — le Coffre de Visual / Workspace
`bige-ops/.env`	Généré depuis le coffre pour le deploy
`bige-ops/terraform/terraform.tfvars`	Clés API + `image_id` pour Terraform
`bige-ops/*/.pem`	Clés SSH générées par le module keypair
`bige-ops/kubeconfigs/`	Kubeconfigs OKS
`bige-ops/.state/`	`hosts.json`, statut de deploy, snapshots
`~/.config/bige-ops/settings.json`	Réglages desktop : token GitHub, clé API Anthropic, chemin du workspace

Ce qui n’est jamais poussé sur le config-history

Le dépôt config-history versionne la stack, pas vos secrets. Sont exclus du push :

les fichiers de credentials Outscale
vault.local.json, .env
terraform.tfvars et les tfstate
les *.pem (clés SSH)
l’inventaire, .app-src/, .state/

Le reste de bige-ops/ — project.yaml, Terraform généré, specs OKS, compose — est versionné normalement. C’est justement l’intérêt : un historique lisible et partageable sans fuite.

Secrets de build

La clé build.secrets déclare les secrets nécessaires à la construction des images Docker (token de registry privé, token de package…). Ils ne sont pas écrits en dur : ils sont injectés au moment du deploy depuis le coffre. Voir repos, VMs & Dockerfiles.

bige-ops/
  vault.local.json      # coffre — jamais pushé
  .env                  # généré au deploy — jamais pushé
  terraform/
    terraform.tfvars    # clés API + image_id — jamais pushé

Après le deploy

Une fois la stack déployée, les secrets d’exécution vivent là où tourne votre application : variables d’environnement sur la VM, fichiers montés, objets sur OOS si vous le décidez. bige-ops ne les rapatrie pas et ne les surveille pas. Rotation, expiration, révocation : c’est votre process, pas une fonctionnalité de l’app.

Limites honnêtes

Ce que bige-ops ne fait pas. Pas de chiffrement applicatif du coffre au-delà des permissions du système de fichiers, pas de rotation automatique, pas de partage d’équipe, pas d’audit d’accès, pas d’intégration Vault / KMS / Secrets Manager. Le coffre est un confort local pour démarrer vite — pas une solution de gestion de secrets pour une équipe en production. L’assistant IA, lui, ne lit ni n’écrit aucun de ces fichiers.