Moatgator Vault
Un solo lugar para los secretos de tu backend, tu CI y tu app móvil
Pon una referencia mg:// donde antes estaba el valor. La CLI, GitHub Actions y el SDK móvil la resuelven al ejecutarse, y tu app recibe un secreto solo en un dispositivo que pasó Attest.
Incluido desde el 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_URLReferencias mg://
Haz commit de la referencia, no del valor
Una referencia nombra un proyecto, un entorno y un secreto, como en mg://api/prod/DATABASE_URL. Es seguro guardarla en Git: solo una identidad con acceso la convierte en un valor.
01
Un .env.tpl en tu repositorio
Mantén una plantilla con referencias. moatgator secrets inject escribe el .env con permisos 0600 y no sobrescribe un archivo existente sin --force.
.env.tplEjemplo # .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
Ejecuta tu comando con los secretos como variables de entorno y oculta sus valores en la salida del comando. moatgator secrets get lee una sola referencia.
terminalEjemplo $ 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 misma referencia en la app
En el SDK de Android, Moatgator.vault.get("mg://mobile/prod/PARTNER_KEY") lee el entorno vinculado a la app en la consola. El valor nunca va dentro del APK.
KotlinEjemplo // Android (Kotlin), off the main threadMoatgator.startSession(playIntegrityProvider)val key = Moatgator.vault.get("mg://mobile/prod/PARTNER_KEY")
Proyectos, entornos y versiones
Proyectos y entornos
Cada proyecto empieza con dev, staging y prod. Añade tus propios entornos cuando los necesites.
Herencia y sobrescritura
Un entorno puede heredar de otro, hasta tres niveles. Un secreto con el mismo nombre sobrescribe al heredado.
Entornos protegidos
prod empieza protegido: solo propietarios y administradores pueden leer sus valores o escribir en él.
Versiones y rollback
Cada cambio crea una versión con historial. Un rollback crea una versión nueva, así que el historial nunca se reescribe.
Revocación inmediata
Revoca un secreto o un token de servicio y la siguiente lectura se rechaza, sin esperar a una fecha de caducidad.
Roles
Los roles de propietario, administrador, desarrollador y lector deciden quién ve los valores y quién los cambia.
Solo en dispositivos atestados
El mismo secreto, entregado a tu app móvil solo en un dispositivo que pasó Attest
Los gestores de secretos suelen dar servicio a servidores, desarrolladores y CI. El Vault también atiende a la app que tus usuarios tienen en la mano: el SDK pide el secreto en tiempo de ejecución, la API comprueba el Attest del dispositivo (Play Integrity o App Attest, más las señales del RASP de Moatgator) y envía el valor cifrado para una clave efímera de esa sesión. Nada va dentro del binario.
El SDK guarda el valor solo en memoria, nunca en disco ni en logs. Las referencias mg:// están disponibles en el SDK de Android.
Políticas por secreto
- Veredicto mínimoElige el veredicto de Attest más bajo que puede recibir cada secreto.
- Atestación de la plataforma obligatoriaExige un resultado de atestación de la plataforma, no solo las señales del propio SDK.
- Antigüedad máxima de la atestaciónRechaza el secreto cuando la atestación del dispositivo es más antigua de lo que permites.
CI y servidores
Ningún token de larga duración guardado en tu CI
La GitHub Action moatgator-hq/github-action/vault intercambia el token OIDC del job por un token de lectura que dura 15 minutos. Los pull requests nunca reciben un token. Donde OIDC no esté disponible, usa un token de servicio.
- Los tokens de servicio (mgvt_…) son de solo lectura y están vinculados a un proyecto y a los entornos que elijas.
- La caducidad es obligatoria: 90 días por defecto, un año como máximo.
- Los valores se enmascaran en el log del job y nunca se convierten en salidas de un paso.
- Una referencia que no se resuelve hace fallar el paso sin exportar nada.
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 y rotación
Lleva los secretos adonde despliegas y rótalos según un calendario
Un sync mantiene un entorno, con herencia, copiado en los secretos de GitHub Actions, en Railway o en Vercel. Se ejecuta al crearlo y de nuevo tras cada cambio en ese entorno o en un entorno del que hereda.
Secretos de GitHub Actions
Sync a un repositorio o a un entorno de GitHub. Cada valor se cifra con la clave pública del repositorio antes de salir de Moatgator.
Railway
Sync a las variables de un proyecto y entorno de Railway, o de un único servicio.
Vercel
Sync a las variables de production, preview o development de un proyecto de Vercel, guardadas como variables cifradas.
Permiso explícito y estado
Confirmas cada destino y le das un token solo para ese destino, guardado cifrado. Cada sync muestra cuándo se ejecutó por última vez, cuántos secretos escribió y cualquier error.
Rotación programada
- Un valor aleatorio nuevo según el calendarioPara secretos que solo usa tu empresa, como claves HMAC y secretos de sesión: Moatgator genera un valor nuevo, crea una versión y ejecuta los syncs.
- Un recordatorio para claves de otros proveedoresPara una clave emitida por otro servicio, los propietarios y administradores reciben un correo cuando vence, y la consola muestra la rotación como atrasada hasta que se guarde un valor nuevo.
Un sync solo escribe en el destino, y allí solo borra los secretos que él mismo escribió. Borrar un sync deja el destino como está.
Cifrado por organización, auditado en cada lectura
Cifrado de sobre por tenant
Cada organización tiene su propia clave, envuelta por una clave maestra.
Texto cifrado vinculado a su lugar
Cada texto cifrado está vinculado a su proyecto, entorno, nombre y versión, así que no se puede mover a otro secreto.
Los valores quedan fuera de los logs
Los valores de los secretos nunca se escriben en nuestros logs, y la CLI y la Action los ocultan en tu salida.
Registro de auditoría de cada lectura
En cada lectura: quién la hizo, desde dónde, qué versión y el resultado.
Comparar
Moatgator Vault, 1Password y Doppler
1Password y Doppler son gestores de secretos consolidados, y ambos hacen buena parte de lo que hace el Vault. La tabla muestra dónde está cada uno, con una fuente pública y la fecha en que la comprobamos en cada celda sobre ellos. El Vault no es un gestor de contraseñas para personas: se centra en apps, CI y dispositivos móviles.
| Capacidad | Moatgator Vault | 1Password | Doppler |
|---|---|---|---|
| Referencias en lugar de valores | mg://project/environment/NAME, también en el SDK móvil | 1 op://vault/item/field | Parcial23 referencias ${…} dentro de Doppler; plantillas {{.NAME}} para archivos |
| Ejecutar un comando con secretos como variables de entorno | valores ocultos en la salida | 4 op run, valores enmascarados en la salida por defecto | 56 doppler run; enmascaramiento de la salida no documentado para la CLI |
| Generar un archivo a partir de una plantilla | archivo escrito con permisos 0600 | 7 op inject | 3 secrets substitute y --mount |
| Entornos con herencia | hasta 3 niveles, sobrescritura por nombre | Parcial8 existen Environments, independientes entre sí | 910 las branch configs heredan de la config raíz; herencia de configs en Team y Enterprise |
| Historial de versiones y rollback | el rollback crea una versión nueva | 11 historial del ítem y restauración | 12 rollback desde los logs |
| Tokens de máquina con alcance y caducidad | solo lectura, por proyecto y entorno, caducidad obligatoria | 1314 service accounts con permisos por bóveda y caducidad opcional | 15 service tokens por config, caducidad opcional |
| Revocación inmediata de tokens | 16 | 15 | |
| CI con OIDC, sin token guardado | GitHub Actions, token de 15 minutos | Parcial1718 load-secrets-action usa un token guardado; Credential Broker con OIDC en vista previa pública | 196 service account identities, planes Team y Enterprise |
| Sync con GitHub Actions, Railway y Vercel | tras cada cambio; solo escribe, borra solo lo que escribió | Parcial820 Environments con sync a AWS Secrets Manager (beta); GitHub, Railway y Vercel no encontrados | 2122 las integraciones con GitHub, Vercel y Railway envían los secretos automáticamente |
| Rotación programada | Parcial valor aleatorio nuevo para tus propios secretos; recordatorio por correo para claves de terceros | No encontrado en la documentación pública2316 tokens de service account rotados a mano; rotación programada de secretos guardados no encontrada | 24 rotación automática de servicios compatibles, como bases de datos, en Team y Enterprise |
| Roles y producción protegida | propietario, administrador, desarrollador y lector; prod protegido | 258 permisos por bóveda y por Environment | 26 roles por proyecto y por entorno |
| Auditoría de cada lectura de secretos | quién, desde dónde, versión y resultado | 27 informes de uso en 1Password Business | Parcial28 el registro de acceso guarda la primera y la última lectura de cada actor |
| Entrega a una app móvil solo en un dispositivo atestado | Attest más RASP, cifrado por sesión | No encontrado en la documentación pública2930 no encontrado en la documentación del SDK y de Connect | No encontrado en la documentación pública3121 no encontrado en la documentación del SDK y de las integraciones |
Puntos fuertes de 1Password
Puntos fuertes de Doppler
- Una lista documentada de integraciones nativas con plataformas de nube y de CI.21
- doppler run --mount entrega los secretos a través de una tubería con nombre (named pipe) efímera en lugar de un archivo en disco.5
- Una clave de cifrado por workplace, y claves gestionadas por el cliente (EKM) en el plan Enterprise.3435
Fuentes
- 1. 1Password CLI — Secret references · comprobado el
- 2. Doppler — Secrets (referencing) · comprobado el
- 3. Doppler — Secret injection with templates · comprobado el
- 4. 1Password CLI — op run · comprobado el
- 5. Doppler — Accessing secrets (run, --mount) · comprobado el
- 6. Doppler — GitHub OIDC examples · comprobado el
- 7. 1Password — Load secrets into config files (op inject) · comprobado el
- 8. 1Password Environments · comprobado el
- 9. Doppler — Branch configs · comprobado el
- 10. Doppler — Config inheritance · comprobado el
- 11. 1Password — View and restore previous versions of items · comprobado el
- 12. Doppler — Versioning · comprobado el
- 13. 1Password CLI — op service-account · comprobado el
- 14. 1Password CLI — op connect · comprobado el
- 15. Doppler — Service tokens · comprobado el
- 16. 1Password — Manage service accounts · comprobado el
- 17. 1Password — GitHub Actions (load-secrets-action) · comprobado el
- 18. 1Password Credential Broker — GitHub Actions (public preview) · comprobado el
- 19. Doppler — Service account identities (OIDC) · comprobado el
- 20. 1Password — Sync Environments to AWS Secrets Manager (beta) · comprobado el
- 21. Doppler — Integrations · comprobado el
- 22. Doppler — GitHub Actions integration · comprobado el
- 23. 1Password Secrets Automation · comprobado el
- 24. Doppler — Secrets rotation · comprobado el
- 25. 1Password — Create, share, and manage vaults · comprobado el
- 26. Doppler — Project permissions · comprobado el
- 27. 1Password — Reports (usage reports) · comprobado el
- 28. Doppler — Access logs · comprobado el
- 29. 1Password SDKs · comprobado el
- 30. 1Password Connect · comprobado el
- 31. Doppler — Future SDKs and integration roadmap · comprobado el
- 32. 1Password — About the 1Password security model · comprobado el
- 33. 1Password — About your Secret Key · comprobado el
- 34. Doppler — Security fact sheet · comprobado el
- 35. Doppler — Pricing · comprobado el
1Password y Doppler son marcas de sus respectivos titulares, mencionadas solo para identificar los productos comparados. Lo que decimos sobre ellos proviene de su documentación pública en la fecha indicada. “No encontrado” significa que no lo encontramos en las páginas citadas, no que el producto carezca de ello. Si algo cambió, escríbenos y lo corregiremos.
Planes
El Vault está incluido en los planes Startup, Scale y Enterprise.
| Plan | Proyectos por organización | Secretos por entorno |
|---|---|---|
| Startup | 5 | 100 |
| Scale | 50 | 500 |
| Enterprise | 200 | 1000 |
Preguntas frecuentes
¿Tengo que cambiar mi código para usar el Vault?
En servidores y CI, no: tu código sigue leyendo variables de entorno, y arrancas el proceso con moatgator secrets run o con la GitHub Action. En la app Android, llama a Moatgator.vault.get con la referencia.
¿Alguien que tenga mi APK puede leer un secreto del Vault?
El valor no está en el APK. La API solo lo envía a un dispositivo que pasó Attest según la política del secreto, cifrado para esa sesión, y el SDK lo guarda solo en memoria. Un dispositivo todavía puede verse comprometido después de pasar, así que mantén las comprobaciones en el servidor para todo lo que mueva dinero.
¿Qué pasa si se filtra un token de servicio?
Revócalo en la consola y la siguiente solicitud se rechaza. Los tokens de servicio son de solo lectura, están limitados a un proyecto y a los entornos que elegiste, y caducan a los 90 días por defecto.
¿El Vault reemplaza a 1Password o a Doppler?
No necesariamente. Si ya usas uno de ellos para servidores y CI, puede quedarse. El Vault añade la entrega a tu app móvil en dispositivos atestados, y también puede cubrir servidores y CI si prefieres una sola herramienta.
¿Qué planes incluyen el Vault?
Startup, Scale y Enterprise. Proyectos por organización: 5, 50 y 200. Secretos por entorno: 100, 500 y 1.000.
Empieza con un secreto
Crea un proyecto, añade un secreto y resuélvelo desde la CLI, tu CI o tu app.