bige-ops Gratuit

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 » côté bige-ops. Chiffrez le disque, verrouillez la session, sachez qui a accès au poste et aux sauvegardes.

Solutions actuelles

Le coffre local (vault.local.json) est toujours la source primaire sur ta machine. En option, tu peux synchroniser vers des backends que tu contrôles — rien n’est imposé.

Backend	Rôle	Statut
Local	Coffre sur le poste → génère `.env` au deploy	Prêt · primary
GitHub Actions secrets	Pousse les secrets vers un repo que tu choisis (API Actions)	Prêt · sync optionnelle
HashiCorp Vault	KV (mount + path) sur ton Vault — token local	Prêt · sync optionnelle

Config non secrète : bige-ops/vault.config.json. Tokens (GitHub / Vault) : Settings desktop, machine-local. Jamais de vault SaaS bige-ops au milieu.

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 (access keys) — 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és API LLM (Anthropic, OpenAI, Gemini, Mistral), 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.

Ce que couvre le coffre

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 intégré, pas d’audit d’accès fin. Les sync GitHub / HashiCorp poussent ce que tu actives — ce n’est pas un Secrets Manager entreprise clé en main. L’assistant IA ne lit ni n’écrit aucun de ces fichiers.