Configuración de secretos de GitHub para desplegar en Azure
Contenido del curso
Geisemberg Marcos Zamora Yuave
Geisemberg Marcos Zamora Yuave
Geisemberg Marcos Zamora Yuave
¿Qué pasa si expongo mis credenciales de despliegue?
Exponer credenciales en código abierto o incluso en repositorios privados es uno de los errores más costosos en el desarrollo de software. Si un atacante encuentra tus llaves de acceso a la nube, las consecuencias son inmediatas y devastadoras. Existen bots que escanean repositorios 24/7 buscando este tipo de descuidos. En cuestión de minutos, pueden usar tus credenciales para crear cientos de servidores virtuales de alta capacidad y utilizarlos para minar criptomonedas, dejándote con una factura de miles de dólares. Además, podrían acceder a tus bases de datos, robar información sensible de tus clientes, o secuestrar tu infraestructura para pedir un rescate (Ransomware). Por eso, los gestores de secretos son innegociables. Mantienen las variables sensibles encriptadas y las inyectan en el entorno de ejecución solo durante el tiempo exacto que dura el proceso de despliegue, enmascarando los valores en los logs para que nunca sean visibles.
¿Por qué usar un Service Principal para desplegar?
Un Service Principal (o entidad de servicio) es esencialmente una "cuenta de usuario" diseñada específicamente para aplicaciones, servicios y herramientas de automatización, en lugar de una persona real. Si usaras tu cuenta personal de la nube para desplegar, le estarías dando a tu repositorio acceso absoluto a toda tu facturación, bases de datos y configuraciones. Al crear un Service Principal con comandos como az ad sp create-for-rbac, estás emitiendo una tarjeta de identificación con permisos estrictamente limitados (conocido como Role-Based Access Control o RBAC). Por ejemplo, puedes asignarle el rol de Contributor únicamente a un grupo de recursos específico. Si por alguna razón esta credencial se ve comprometida, el atacante solo tendría acceso a esa pequeña porción de tu infraestructura, y tú puedes revocar o eliminar ese Service Principal en segundos sin afectar tu cuenta principal. Es una regla de oro en ciberseguridad: otorgar siempre el principio de menor privilegio.
¿Cómo conectar GitHub con Azure de forma segura?
Para lograr una conexión segura, la clave está en utilizar GitHub Secrets. Piensa en los secretos como una caja fuerte virtual dentro de tu repositorio. En lugar de escribir tus contraseñas directamente en el código (lo cual es un riesgo de seguridad masivo), guardas estas llaves en la configuración del proyecto. Cuando una herramienta de automatización, como GitHub Actions, necesita comunicarse con la nube, simplemente "pide prestada" la llave de la caja fuerte temporalmente. En el caso de Azure, necesitas un bloque de texto en formato JSON que contiene identificadores únicos (clientId, clientSecret, subscriptionId, tenantId). Al guardar este JSON como un secreto, garantizas que tus flujos de trabajo puedan autenticarse y crear recursos sin que ningún desarrollador o visitante del repositorio pueda ver las credenciales reales. Es la base fundamental del enfoque DevSecOps.
