Moatgator Vault
Un seul endroit pour les secrets de votre backend, de votre CI et de votre app mobile
Placez une référence mg:// là où se trouvait la valeur. La CLI, GitHub Actions et le SDK mobile la résolvent à l'exécution, et votre app ne reçoit un secret que sur un appareil validé par Attest.
Inclus à partir du plan Startup.
$ moatgator secrets run --env-file .env.tpl -- npm start$ moatgator secrets inject -i .env.tpl -o .env$ moatgator secrets get mg://api/prod/DATABASE_URLRéférences mg://
Versionnez la référence, pas la valeur
Une référence désigne un projet, un environnement et un secret, comme dans mg://api/prod/DATABASE_URL. Vous pouvez la garder dans Git sans risque : seule une identité disposant d'un accès la transforme en valeur.
01
Un .env.tpl dans votre dépôt
Gardez un modèle avec des références. moatgator secrets inject écrit le .env avec les permissions 0600 et n'écrase pas un fichier existant sans --force.
.env.tplExemple # .env.tpl: safe to commitDATABASE_URL=mg://api/prod/DATABASE_URLSTRIPE_KEY=mg://api/prod/STRIPE_KEYSENTRY_DSN=mg://api/prod/SENTRY_DSN02
moatgator secrets run
Exécute votre commande avec les secrets comme variables d'environnement et masque leurs valeurs dans la sortie de la commande. moatgator secrets get lit une seule référence.
terminalExemple $ moatgator secrets run --env-file .env.tpl -- npm start$ moatgator secrets inject -i .env.tpl -o .env$ moatgator secrets get mg://api/prod/DATABASE_URL03
La même référence dans l'app
Dans le SDK Android, Moatgator.vault.get("mg://mobile/prod/PARTNER_KEY") lit l'environnement lié à l'app dans la console. La valeur n'est jamais embarquée dans l'APK.
KotlinExemple // Android (Kotlin), off the main threadMoatgator.startSession(playIntegrityProvider)val key = Moatgator.vault.get("mg://mobile/prod/PARTNER_KEY")
Projets, environnements et versions
Projets et environnements
Chaque projet démarre avec dev, staging et prod. Ajoutez vos propres environnements quand vous en avez besoin.
Héritage et surcharges
Un environnement peut hériter d'un autre, sur trois niveaux au plus. Un secret du même nom remplace celui hérité.
Environnements protégés
prod est protégé dès le départ : seuls les propriétaires et les admins peuvent lire ses valeurs ou y écrire.
Versions et rollback
Chaque modification crée une version avec historique. Un rollback crée une nouvelle version, l'historique n'est donc jamais réécrit.
Révocation immédiate
Révoquez un secret ou un jeton de service et la lecture suivante est refusée, sans attendre une date d'expiration.
Rôles
Les rôles propriétaire, admin, développeur et lecteur déterminent qui voit les valeurs et qui les modifie.
Seulement sur des appareils attestés
Le même secret, livré à votre app mobile seulement sur un appareil validé par Attest
Les gestionnaires de secrets servent en général les serveurs, les développeurs et la CI. Le Vault sert aussi l'app entre les mains de vos utilisateurs : le SDK demande le secret à l'exécution, l'API vérifie l'appareil via Attest (Play Integrity ou App Attest, plus les signaux du RASP Moatgator) et envoie la valeur chiffrée pour une clé éphémère propre à cette session. Rien n'est placé dans le binaire.
Le SDK garde la valeur en mémoire seulement, jamais sur disque ni dans les logs. Les références mg:// sont disponibles dans le SDK Android.
Politiques par secret
- Verdict minimalChoisissez le verdict Attest le plus bas autorisé à recevoir chaque secret.
- Attestation de la plateforme exigéeExigez un résultat d'attestation de la plateforme, pas seulement les signaux du SDK lui-même.
- Ancienneté maximale de l'attestationRefusez le secret quand l'attestation de l'appareil est plus ancienne que ce que vous autorisez.
CI et serveurs
Aucun jeton de longue durée stocké dans votre CI
L'Action GitHub moatgator-hq/github-action/vault échange le jeton OIDC du job contre un jeton de lecture valable 15 minutes. Les pull requests ne reçoivent jamais de jeton. Là où OIDC n'est pas disponible, utilisez un jeton de service.
- Les jetons de service (mgvt_…) sont en lecture seule et liés à un projet et aux environnements que vous choisissez.
- L'expiration est obligatoire : 90 jours par défaut, un an au maximum.
- Les valeurs sont masquées dans le log du job et ne deviennent jamais des sorties d'étape.
- Une référence qui ne se résout pas fait échouer l'étape sans rien exporter.
permissions: { contents: read, id-token: write }steps: - uses: moatgator-hq/github-action/vault@v1 with: project-id: vpj_… secrets: | DATABASE_URL=mg://api/prod/DATABASE_URL - run: ./deploy.sh # $DATABASE_URL, *** in the logSync et rotation
Envoyez les secrets là où vous déployez, et faites-en la rotation selon un calendrier
Un sync garde un environnement, avec héritage, copié dans les secrets GitHub Actions, dans Railway ou dans Vercel. Il s'exécute à sa création, puis après chaque modification de cet environnement ou d'un environnement dont il hérite.
Secrets GitHub Actions
Sync vers un dépôt ou vers un environnement GitHub. Chaque valeur est chiffrée avec la clé publique du dépôt avant de quitter Moatgator.
Railway
Sync vers les variables d'un projet et d'un environnement Railway, ou d'un seul service.
Vercel
Sync vers les variables production, preview ou development d'un projet Vercel, enregistrées comme variables chiffrées.
Autorisation explicite et statut
Vous confirmez chaque destination et lui donnez un jeton propre à cette seule destination, stocké chiffré. Chaque sync indique sa dernière exécution, le nombre de secrets écrits et les éventuelles erreurs.
Rotation planifiée
- Une nouvelle valeur aléatoire à échéancePour les secrets que seule votre entreprise utilise, comme les clés HMAC et les secrets de session : Moatgator génère une nouvelle valeur, crée une version et lance les syncs.
- Un rappel pour les clés d'autres fournisseursPour une clé émise par un autre service, les propriétaires et les admins reçoivent un e-mail à l'échéance, et la console affiche la rotation en retard jusqu'à l'enregistrement d'une nouvelle valeur.
Un sync ne fait qu'écrire dans la destination, et n'y supprime que les secrets qu'il a lui-même écrits. Supprimer un sync laisse la destination telle quelle.
Chiffré par organisation, audité à chaque lecture
Chiffrement d'enveloppe par tenant
Chaque organisation a sa propre clé, enveloppée par une clé maîtresse.
Texte chiffré lié à son emplacement
Chaque texte chiffré est lié à son projet, son environnement, son nom et sa version, et ne peut donc pas être déplacé vers un autre secret.
Les valeurs restent hors des logs
Les valeurs des secrets ne sont jamais écrites dans nos logs, et la CLI et l'Action les masquent dans votre sortie.
Piste d'audit de chaque lecture
Pour chaque lecture : qui l'a faite, d'où, quelle version et le résultat.
Comparer
Moatgator Vault, 1Password et Doppler
1Password et Doppler sont des gestionnaires de secrets établis, et tous deux font une grande partie de ce que fait le Vault. Le tableau montre où se situe chacun, avec une source publique et la date de notre vérification pour chaque cellule les concernant. Le Vault n'est pas un gestionnaire de mots de passe pour les personnes : il se concentre sur les apps, la CI et les appareils mobiles.
| Fonctionnalité | Moatgator Vault | 1Password | Doppler |
|---|---|---|---|
| Des références à la place des valeurs | mg://project/environment/NAME, aussi dans le SDK mobile | 1 op://vault/item/field | Partiel23 références ${…} dans Doppler ; modèles {{.NAME}} pour les fichiers |
| Exécuter une commande avec les secrets comme variables d'environnement | valeurs masquées dans la sortie | 4 op run, valeurs masquées dans la sortie par défaut | 56 doppler run ; masquage de la sortie non documenté pour la CLI |
| Générer un fichier à partir d'un modèle | fichier écrit avec les permissions 0600 | 7 op inject | 3 secrets substitute et --mount |
| Environnements avec héritage | jusqu'à 3 niveaux, surcharge par nom | Partiel8 les Environments existent, indépendants les uns des autres | 910 les branch configs héritent de la config racine ; héritage de configs sur Team et Enterprise |
| Historique des versions et rollback | le rollback crée une nouvelle version | 11 historique de l'élément et restauration | 12 rollback depuis les logs |
| Jetons machine à portée limitée, avec expiration | lecture seule, par projet et environnement, expiration obligatoire | 1314 service accounts avec permissions par coffre et expiration optionnelle | 15 service tokens par config, expiration optionnelle |
| Révocation immédiate des jetons | 16 | 15 | |
| CI avec OIDC, sans jeton stocké | GitHub Actions, jeton de 15 minutes | Partiel1718 load-secrets-action utilise un jeton stocké ; Credential Broker avec OIDC en préversion publique | 196 service account identities, plans Team et Enterprise |
| Sync vers GitHub Actions, Railway et Vercel | après chaque modification ; écrit seulement, ne supprime que ce qu'il a écrit | Partiel820 Environments avec sync vers AWS Secrets Manager (beta) ; GitHub, Railway et Vercel introuvables | 2122 les intégrations GitHub, Vercel et Railway envoient les secrets automatiquement |
| Rotation planifiée | Partiel nouvelle valeur aléatoire pour vos propres secrets ; rappel par e-mail pour les clés tierces | Introuvable dans la documentation publique2316 jetons de service account renouvelés à la main ; rotation planifiée des secrets stockés introuvable | 24 rotation automatique des services pris en charge, comme les bases de données, sur Team et Enterprise |
| Rôles et production protégée | propriétaire, admin, développeur et lecteur ; prod protégé | 258 permissions par coffre et par Environment | 26 rôles par projet et par environnement |
| Audit de chaque lecture de secret | qui, d'où, version et résultat | 27 rapports d'utilisation sur 1Password Business | Partiel28 le journal d'accès conserve la première et la dernière lecture de chaque acteur |
| Livraison à une app mobile seulement sur un appareil attesté | Attest plus RASP, chiffré par session | Introuvable dans la documentation publique2930 introuvable dans la documentation du SDK et de Connect | Introuvable dans la documentation publique3121 introuvable dans la documentation du SDK et des intégrations |
Les points forts de 1Password
Les points forts de Doppler
Sources
- 1. 1Password CLI — Secret references · vérifié le
- 2. Doppler — Secrets (referencing) · vérifié le
- 3. Doppler — Secret injection with templates · vérifié le
- 4. 1Password CLI — op run · vérifié le
- 5. Doppler — Accessing secrets (run, --mount) · vérifié le
- 6. Doppler — GitHub OIDC examples · vérifié le
- 7. 1Password — Load secrets into config files (op inject) · vérifié le
- 8. 1Password Environments · vérifié le
- 9. Doppler — Branch configs · vérifié le
- 10. Doppler — Config inheritance · vérifié le
- 11. 1Password — View and restore previous versions of items · vérifié le
- 12. Doppler — Versioning · vérifié le
- 13. 1Password CLI — op service-account · vérifié le
- 14. 1Password CLI — op connect · vérifié le
- 15. Doppler — Service tokens · vérifié le
- 16. 1Password — Manage service accounts · vérifié le
- 17. 1Password — GitHub Actions (load-secrets-action) · vérifié le
- 18. 1Password Credential Broker — GitHub Actions (public preview) · vérifié le
- 19. Doppler — Service account identities (OIDC) · vérifié le
- 20. 1Password — Sync Environments to AWS Secrets Manager (beta) · vérifié le
- 21. Doppler — Integrations · vérifié le
- 22. Doppler — GitHub Actions integration · vérifié le
- 23. 1Password Secrets Automation · vérifié le
- 24. Doppler — Secrets rotation · vérifié le
- 25. 1Password — Create, share, and manage vaults · vérifié le
- 26. Doppler — Project permissions · vérifié le
- 27. 1Password — Reports (usage reports) · vérifié le
- 28. Doppler — Access logs · vérifié le
- 29. 1Password SDKs · vérifié le
- 30. 1Password Connect · vérifié le
- 31. Doppler — Future SDKs and integration roadmap · vérifié le
- 32. 1Password — About the 1Password security model · vérifié le
- 33. 1Password — About your Secret Key · vérifié le
- 34. Doppler — Security fact sheet · vérifié le
- 35. Doppler — Pricing · vérifié le
1Password et Doppler sont des marques de leurs propriétaires respectifs, citées seulement pour identifier les produits comparés. Ce que nous en disons provient de leur documentation publique à la date indiquée. « Introuvable » signifie que nous ne l'avons pas trouvé dans les pages citées, pas que le produit en est dépourvu. Si quelque chose a changé, écrivez-nous et nous corrigerons.
Plans
Le Vault est inclus dans les plans Startup, Scale et Enterprise.
| Plan | Projets par organisation | Secrets par environnement |
|---|---|---|
| Startup | 5 | 100 |
| Scale | 50 | 500 |
| Enterprise | 200 | 1 000 |
Questions fréquentes
Dois-je modifier mon code pour utiliser le Vault ?
Pas sur les serveurs et la CI : votre code continue de lire des variables d'environnement, et vous lancez le processus avec moatgator secrets run ou l'Action GitHub. Dans l'app Android, appelez Moatgator.vault.get avec la référence.
Quelqu'un qui a mon APK peut-il lire un secret du Vault ?
La valeur n'est pas dans l'APK. L'API ne l'envoie qu'à un appareil validé par Attest selon la politique du secret, chiffrée pour cette session, et le SDK la garde en mémoire seulement. Un appareil peut encore être compromis après sa validation, alors conservez des contrôles côté serveur pour tout ce qui déplace de l'argent.
Que se passe-t-il si un jeton de service fuite ?
Révoquez-le dans la console et la requête suivante est refusée. Les jetons de service sont en lecture seule, limités à un projet et aux environnements choisis, et expirent après 90 jours par défaut.
Le Vault remplace-t-il 1Password ou Doppler ?
Pas forcément. Si vous utilisez déjà l'un d'eux pour les serveurs et la CI, vous pouvez le garder. Le Vault ajoute la livraison à votre app mobile sur des appareils attestés, et peut aussi couvrir les serveurs et la CI si vous préférez un seul outil.
Quels plans incluent le Vault ?
Startup, Scale et Enterprise. Projets par organisation : 5, 50 et 200. Secrets par environnement : 100, 500 et 1 000.
Commencez avec un secret
Créez un projet, ajoutez un secret et résolvez-le depuis la CLI, votre CI ou votre app.