Vaulted
Actualizado

Compartir secretos en GitHub Actions — sin Vault

Por

Puedes compartir secretos en GitHub Actions sin HashiCorp Vault usando la GitHub Action de Vaulted, que crea enlaces cifrados que se autodestruyen con cero infraestructura. Usa cifrado AES-256-GCM del lado del cliente y funciona como un único paso del flujo de trabajo: no requiere ningún servidor de gestor de secretos ni configuración en la nube.

Los pipelines de CI necesitan credenciales temporales constantemente. Una clave de despliegue que solo debería vivir durante una ejecución. Un token que se pasa entre dos repositorios durante una migración. Una credencial que se rota en un flujo de trabajo y se consume en otro.

El consejo habitual es "usa un gestor de secretos". Pero levantar HashiCorp Vault o configurar AWS Secrets Manager solo para entregar una única credencial entre flujos de trabajo es como alquilar un almacén para enviar una carta.

Los secretos de repositorio de GitHub manejan bien el caso estático: claves de API de larga duración, tokens de despliegue, credenciales de cuentas de servicio. Pero se quedan cortos para cualquier cosa temporal o dinámica.

El hueco: compartir secretos temporales en CI/CD

Los secretos de repositorio están diseñados para valores que cambian con poca frecuencia y son consumidos por un único repositorio. No cubren:

  • Entregas únicas durante la rotación de claves — Rotas una credencial en un flujo de trabajo y necesitas que otro flujo de trabajo (o equipo) recoja el nuevo valor exactamente una vez.
  • Compartir credenciales entre repositorios — Dos repositorios necesitan intercambiar un token de corta duración, pero ninguno debería almacenarlo de forma permanente.
  • Acceso temporal para colaboradores externos — Un token de CI que debería caducar después de que se cierre la ventana de despliegue de un colaborador externo.
  • Saber cuándo se consumió un secreto — Los secretos de repositorio no ofrecen visibilidad sobre si un valor se leyó o cuándo.

Estos son problemas temporales que necesitan una solución temporal.

Un enfoque más ligero: enlaces cifrados que se autodestruyen

La GitHub Action de Vaulted te permite crear y recuperar secretos cifrados que se autodestruyen directamente desde tus flujos de trabajo, sin infraestructura que gestionar.

Crear un secreto:

- name: Share rotated credential
  id: share
  uses: vaulted-fyi/share-secret@v1
  with:
    secret: ${{ steps.rotate.outputs.new_token }}
    views: 1
    expires: 1h

El paso genera una URL que contiene el secreto cifrado. La clave de cifrado vive en el fragmento de la URL, por lo que nunca toca los servidores de Vaulted.

Recuperar un secreto:

- name: Get shared credential
  id: get
  uses: vaulted-fyi/share-secret/get@v1
  with:
    url: ${{ needs.rotate.outputs.secret_url }}

- name: Deploy with rotated credential
  run: ./deploy.sh
  env:
    API_TOKEN: ${{ steps.get.outputs.secret }}

Tras la recuperación, el enlace se consume y el texto cifrado del lado del servidor se elimina. El secreto existe únicamente en la memoria del runner durante la duración de ese job.

Modelo de seguridad

Tres propiedades hacen que esto sea seguro para su uso en CI/CD:

  1. Cifrado de conocimiento cero. El secreto se cifra con AES-256-GCM dentro del runner de GitHub antes de salir del proceso. La clave de cifrado se incrusta en el fragmento de la URL, que nunca se envía al servidor. Vaulted solo almacena texto cifrado que no puede descifrar. Esto es cifrado del lado del cliente aplicado a CI/CD.

  2. Enmascarado automático de logs. La action llama a core.setSecret antes de core.setOutput, registrando cada línea del valor del secreto con el enmascarador de logs de GitHub. Los secretos multilínea se enmascaran línea por línea, de modo que incluso las coincidencias parciales se censuran en los logs del flujo de trabajo.

  3. Enlaces que se autodestruyen. Los límites de vistas y la caducidad por tiempo se aplican del lado del servidor. Un secreto creado con views: 1 y expires: 1h se elimina permanentemente tras la primera recuperación o después de una hora, lo que ocurra primero.

Cuándo usar esto frente a un gestor de secretos

EscenarioGestor de secretosAction de Vaulted
Credenciales de producción de larga duraciónSíNo
Configuración de ejecución de la app (URLs de BD, claves de API)SíNo
Entrega única de credenciales entre flujos de trabajoExcesivoSí
Compartir tokens temporales entre repositoriosExcesivoSí
Acceso temporal de CI para colaboradores externosExcesivoSí
Distribución de credenciales tras una rotaciónExcesivoSí

Los gestores de secretos son la herramienta adecuada para los secretos que las aplicaciones consumen en tiempo de ejecución. Vaulted es para la entrega: el momento en que una credencial se mueve de un lugar a otro y no debería persistir.

Primeros pasos

Añade la action a cualquier flujo de trabajo:

- uses: vaulted-fyi/share-secret@v1
  with:
    secret: ${{ secrets.TEMP_CREDENTIAL }}
    views: 1
    expires: 1h

Encuéntrala en el GitHub Marketplace. Los secretos creados por la action son compatibles con la aplicación web y la CLI: cualquier cosa creada en una se puede recuperar desde otra.

Sin servidor de Vault. Sin políticas de IAM. Sin infraestructura. Solo enlaces cifrados que se autodestruyen.

Relacionado