GitHub Actions secrets: desplegar sin publicar contraseñas ni claves
Publicado el 2026-10-26 por frfrand
Configurar secretos CI y permisos mínimos en GitHub Actions
La automatización de un deploy pierde sentido si para usarla terminás pegando la contraseña del servidor en un YAML público. GitHub Actions permite manejar secretos y tokens, pero también hay que limitar qué workflows pueden usarlos.
La idea es resolver un problema de datos o despliegue que aparece en aplicaciones reales. Vamos a ver el concepto sin vueltas, un ejemplo de implementación y qué comprobar antes de llevarlo a producción.
Qué hace GitHub Actions secrets
Los Actions secrets y variables se configuran por repositorio, entorno u organización según permisos. Los secretos no deben imprimirse ni enviarse a artefactos. Para servicios cloud, las credenciales efímeras basadas en OIDC pueden ser más seguras que claves permanentes cuando el proveedor lo soporta.
No alcanza con repetir una receta si no entendés quién lee los datos, desde qué proceso y con qué permisos. En una aplicación con reservas, facturas o usuarios, una condición de carrera o una política de acceso mal hecha puede ser más grave que una API lenta.
Un ejemplo concreto
# Extracto ilustrativo de workflow
name: test
on: [push]
jobs:
checks:
runs-on: ubuntu-latest
permissions:
contents: read
steps:
- uses: actions/checkout@v4
- run: echo 'Ejecutar pruebas antes del deploy'
# Secrets: se referencian desde secrets.*, nunca se escriben en YAMLLos nombres, tablas y claves de este ejemplo son ilustrativos. Probalo primero en una base o entorno de ensayo y adaptá permisos, índices y versiones. Cuando haya operaciones de escritura, no ejecutes consultas de muestra sobre datos de clientes sin revisar qué modifican.
Paso a paso
- Separá pruebas de publicación: no todo push debe llegar automáticamente a producción.
- Concedé
permissionsmínimos al token GITHUB_TOKEN del workflow. - Guardá credenciales en Secrets y usá ambientes protegidos con aprobación cuando corresponda.
- Revisá permisos de PR externas, forks y dependencias de terceros.
- Verificá logs y artefactos para asegurarte de que no contienen valores sensibles.
Al final no te quedes con «el SQL no dio error». Comprobá el efecto real desde la API y con pruebas de concurrencia o permisos según corresponda. En bases de datos hay errores que sólo aparecen cuando dos usuarios hacen algo a la vez.
Ejemplo de proyecto de trabajo
Una agencia tiene dos repositorios de clientes y despliega una API Django a cada VPS. Una credencial de despliegue por cliente evita que un workflow comprometido acceda a todos los proyectos.
Ese escenario ayuda a distinguir rendimiento de consistencia. Acelerar una consulta no sirve si permite crear dos reservas para una sola plaza, ni una base enorme arregla que el backend permita consultar datos de otro cliente.
El error típico
Aunque GitHub enmascare ciertos patrones, imprimir secretos transformados o pasarlos a procesos de terceros puede filtrarlos. No uses pull_request_target con código no confiable sin analizar riesgos.
También conviene tener un plan de recuperación. Antes de tocar esquema, usuarios o políticas, guardá una copia verificable o migración reversible y comprobá que la aplicación pueda seguir funcionando durante el cambio.
¿Cómo lo resolvería con ArduMaker?
Con ArduMaker podés conectar repositorios Git y organizar despliegues por Empresa. Si mantenés CI en GitHub Actions, separá permisos de tests y las credenciales mínimas necesarias para publicar cada proyecto.
ArduMaker te permite desplegar servicios desde Git y trabajar con bases y procesos dentro del VPS. El panel no reemplaza la lógica de tu aplicación: transacciones, permisos y validaciones deben quedar correctamente diseñados en el código y la base de datos.
Tres comprobaciones antes de publicar
Integridad: si una petición se repite o falla a mitad de camino, ¿los datos terminan en un estado válido?
Seguridad: ¿un usuario autenticado puede acceder sólo a su información, y la API utiliza una identidad de base con permisos mínimos?
Recuperación: ¿sabés restaurar los datos y revertir la versión de código compatible si una actualización sale mal?
Si podés responder a esas tres preguntas con pruebas, tu backend está bastante mejor preparado que cuando sólo miraste si el endpoint devolvía 200.
Recursos para profundizar
Para cerrar: elegí la solución más simple que permita mantener datos correctos, seguros y recuperables. El rendimiento viene después de medir.