Por qué guardar secretos en Git es arriesgado y cómo Semaphore Key Store resuelve el problema

Los desarrolladores siguen incrustando tokens de API, contraseñas y credenciales directamente en el código o en archivos .env y subiéndolos a Git. Ocurre en proyectos personales y en producción por igual.

La razón es sencilla: sin una forma adecuada de pasar secretos a la automatización y a los flujos de despliegue, Git parece la única opción fiable. «Lo arreglaremos después». Pero en Git nada desaparece del todo.

Por qué Git es peligroso para los secretos #

Git es un sistema de control de versiones. Todo lo que se confirma forma parte del historial. Puedes quitar un token del último commit: los commits anteriores ya lo contienen. Y el historial se copia por todas partes: repos locales, agentes de automatización, espejos, forks. En cuanto un secreto entra en un commit, queda expuesto.

El acceso al repositorio suele ser más amplio de lo debido. Contratistas externos, colaboradores temporarios, forks de prueba: todos pueden ver credenciales que no deberían.

GitHub y GitLab escanean activamente en busca de credenciales. Si la plataforma marca un token, trátalo como comprometido y revócalo de inmediato.

Qué debería sustituir a Git #

Un secreto no es un archivo estático. Es una credencial de acceso que debe vivir fuera del código, con permisos controlados, rotación y aislamiento por entorno.

Podrías usar Vault u OpenBao, pero eso implica infraestructura, mantenimiento y carga operativa.

Semaphore incluye un Key Store integrado directamente en sus flujos de automatización. Los secretos pueden residir en uno de dos sitios:

• la base de datos cifrada de Semaphore (predeterminado)
• un almacén externo como HashiCorp Vault, Devolutions u OpenBao (función PRO)

Elige la opción integrada sencilla o conecta el sistema corporativo de secretos que ya tengáis. Funciona sin configuración compleja.

Qué almacena Key Store #

• tokens de API
• claves SSH
• contraseñas
• variables de entorno
• JSON y otros archivos de configuración

Los secretos no tocan el código. Solo se inyectan en tiempo de ejecución del trabajo. Puedes definir credenciales distintas para desarrollo, staging y producción y acotar el acceso a usuarios, equipos o flujos concretos.

Cómo funciona en la práctica #

Creas un Key Store, añades un secreto y lo referencias en la configuración del workflow. Semaphore inyecta el valor en tiempo de ejecución.

En un despliegue en AWS, por ejemplo, las claves de acceso existen solo mientras se ejecuta ese trabajo concreto, solo en el agente que lo ejecuta. Los desarrolladores no ven el secreto. No pasa por Git.

Ejemplo #

Crea un secreto desde la interfaz: Secrets → New Secret y añade las variables:

• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY

Referencia el secreto por nombre en el workflow: Semaphore inyecta los valores como variables de entorno en tiempo de ejecución:

blocks:
  - name: Deploy
    task:
      secrets:
        - name: aws-credentials
      jobs:
        - name: deploy
          commands:
            - aws s3 sync ./dist s3://my-bucket

Para SSH, crea un secreto con tu clave privada. Semaphore la coloca automáticamente en ~/.ssh/:

blocks:
  - name: Deploy via SSH
    task:
      secrets:
        - name: production-ssh-key
      jobs:
        - name: deploy
          commands:
            - ssh deploy@production-server "cd /app && git pull"

Key Store frente a otras opciones #

Método	Seguro	Visibilidad	Revocable
.env en Git	No	Todo el equipo	No
GitHub Actions Secrets	Parcial	Depende	Sí
Semaphore Key Store	Sí	Acotada	Sí

Además: rotar tokens sin tocar el código, controlar el acceso por rol o equipo, usar secretos distintos por entorno.

Conclusión #

Cualquier token confirmado en Git debe considerarse comprometido. El historial se propaga entre colaboradores, forks, espejos y agentes: cada copia es otro punto de exposición.

Key Store mantiene los secretos fuera de los repos, los inyecta solo en tiempo de ejecución y te da control sobre rotación y acceso. Para equipos que usan Ansible, Terraform, OpenTofu o automatización con PowerShell no es infraestructura opcional: es la base.

Twitter

Opción 1

Secretos en Git = secretos expuestos. Para siempre.

El historial de Git se replica en forks, espejos y agentes de CI. Un token en un commit es un token comprometido de forma indefinida.

Escribimos por qué sigue ocurriendo y cómo lo soluciona Semaphore Key Store.

Opción 2

Cómo Semaphore Key Store gestiona los secretos:

→ Guardar tokens, claves SSH y variables de entorno fuera del repo

→ Referenciar con {{ your_secret }} en la configuración del trabajo

→ Inyectar en tiempo de ejecución, en el agente, solo para ese trabajo

Los desarrolladores no lo ven. No toca Git.
Análisis completo → [enlace]

LinkedIn

Acabamos de publicar un análisis de cómo funciona Semaphore Key Store y por qué existe.

En resumen: los secretos no pertenecen a Git. Nunca. Pero sin una alternativa adecuada, los equipos siguen poniéndolos ahí.

Key Store se integra directamente en los flujos de automatización de Semaphore. El flujo real es:

1. Crear un Key Store en la interfaz
2. Añadir secretos: tokens API, claves SSH, variables de entorno, archivos de configuración
3. Referenciarlos en la configuración del trabajo con {{ your_secret }}
4. Semaphore los inyecta en tiempo de ejecución, en el agente, solo para ese trabajo

El desarrollador no ve el secreto. No toca el repositorio. Cuando el trabajo termina, desaparece del entorno de ejecución.

Puedes acotar el acceso por usuario, equipo o entorno. Rotar un token sin cambiar una línea de código. Usar credenciales distintas para dev, staging y prod.

Para equipos con Ansible, Terraform u OpenTofu, es la pieza que falta entre «funciona» y «es realmente seguro».

Análisis completo →