Saltar al contenido
Contáctanos

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.

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_URL

Referencias 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.

  1. 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_DSN
  2. 02

    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_URL
  3. 03

    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.
.github/workflows/deploy.ymlEjemplo
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 log

Sync 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.

Capacidades de gestión de secretos, lado a lado
CapacidadMoatgator Vault1PasswordDoppler
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 tokens1615
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 programadaParcial

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

  • Cifrado de extremo a extremo, con una Secret Key que nunca se envía a 1Password.3233
  • op run enmascara por defecto los valores de los secretos en la salida del comando.4
  • SDKs oficiales para Go, JavaScript y Python.29

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. 1. 1Password CLI — Secret references · comprobado el
  2. 2. Doppler — Secrets (referencing) · comprobado el
  3. 3. Doppler — Secret injection with templates · comprobado el
  4. 4. 1Password CLI — op run · comprobado el
  5. 5. Doppler — Accessing secrets (run, --mount) · comprobado el
  6. 6. Doppler — GitHub OIDC examples · comprobado el
  7. 7. 1Password — Load secrets into config files (op inject) · comprobado el
  8. 8. 1Password Environments · comprobado el
  9. 9. Doppler — Branch configs · comprobado el
  10. 10. Doppler — Config inheritance · comprobado el
  11. 11. 1Password — View and restore previous versions of items · comprobado el
  12. 12. Doppler — Versioning · comprobado el
  13. 13. 1Password CLI — op service-account · comprobado el
  14. 14. 1Password CLI — op connect · comprobado el
  15. 15. Doppler — Service tokens · comprobado el
  16. 16. 1Password — Manage service accounts · comprobado el
  17. 17. 1Password — GitHub Actions (load-secrets-action) · comprobado el
  18. 18. 1Password Credential Broker — GitHub Actions (public preview) · comprobado el
  19. 19. Doppler — Service account identities (OIDC) · comprobado el
  20. 20. 1Password — Sync Environments to AWS Secrets Manager (beta) · comprobado el
  21. 21. Doppler — Integrations · comprobado el
  22. 22. Doppler — GitHub Actions integration · comprobado el
  23. 23. 1Password Secrets Automation · comprobado el
  24. 24. Doppler — Secrets rotation · comprobado el
  25. 25. 1Password — Create, share, and manage vaults · comprobado el
  26. 26. Doppler — Project permissions · comprobado el
  27. 27. 1Password — Reports (usage reports) · comprobado el
  28. 28. Doppler — Access logs · comprobado el
  29. 29. 1Password SDKs · comprobado el
  30. 30. 1Password Connect · comprobado el
  31. 31. Doppler — Future SDKs and integration roadmap · comprobado el
  32. 32. 1Password — About the 1Password security model · comprobado el
  33. 33. 1Password — About your Secret Key · comprobado el
  34. 34. Doppler — Security fact sheet · comprobado el
  35. 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.

PlanProyectos por organizaciónSecretos por entorno
Startup5100
Scale50500
Enterprise2001000
Ver todos los planes

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.