Concepto clave

En el mundo del desarrollo moderno, los secretos y variables de entorno son como las llaves de tu casa y la dirección donde vives. Los secretos son información sensible que nunca debe exponerse públicamente, como contraseñas, tokens de API o claves de cifrado. Las variables de entorno son configuraciones que cambian según el contexto, como URLs de bases de datos o nombres de entornos (desarrollo, producción).

Imagina que estás construyendo una aplicación que se conecta a una base de datos. La contraseña de la base de datos es un secreto que solo tu aplicación debe conocer, mientras que la URL de la base de datos podría ser una variable de entorno que cambia si estás en desarrollo local o en producción. GitHub Actions te permite gestionar estos elementos de forma segura, evitando que terminen en tu repositorio de código donde cualquiera podría verlos.

Cómo funciona en la práctica

GitHub Actions maneja secretos y variables de entorno a través de dos mecanismos principales: secrets almacenados en la configuración del repositorio o organización, y variables de entorno definidas en los workflows. Los secrets se cifran y solo se exponen en los runners durante la ejecución, mientras que las variables pueden ser más dinámicas.

Paso a paso: primero, defines tus secrets en la sección Settings > Secrets and variables > Actions de tu repositorio en GitHub. Luego, en tu archivo YAML de GitHub Actions, los referencias usando la sintaxis ${{ secrets.NOMBRE_SECRETO }}. Para variables de entorno, puedes definirlas a nivel de job, step o incluso pasarlas entre jobs. Esto permite, por ejemplo, tener un workflow que use diferentes credenciales para desarrollo y producción sin modificar el código.

Codigo en accion

Antes: un archivo de configuración inseguro con credenciales hardcodeadas.

# .github/workflows/deploy.yml (ANTES - NO HACER ESTO)
name: Deploy to Cloud
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Deploy app
        run: |
          # Credenciales expuestas en el código
          AWS_ACCESS_KEY_ID="AKIAIOSFODNN7EXAMPLE"
          AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
          echo "Desplegando con credenciales inseguras"

Después: usando secrets de GitHub Actions de forma segura.

# .github/workflows/deploy.yml (DESPUÉS - FORMA CORRECTA)
name: Deploy to Cloud
on:
  push:
    branches: [main]
env:
  DEPLOY_ENV: production  # Variable de entorno a nivel de workflow
jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production  # Asocia el job a un entorno para gestión avanzada
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: us-east-1
      - name: Deploy to S3
        run: |
          echo "Desplegando en entorno: $DEPLOY_ENV"
          # Comandos de despliegue usando credenciales seguras
          aws s3 sync ./dist s3://my-bucket

Errores comunes

Commitear secretos por accidente: Si subes un archivo .env o configuración con credenciales a tu repositorio, aunque lo borres, quedará en el historial. Usa .gitignore para archivos sensibles y revoca inmediatamente cualquier secreto expuesto.
Usar secrets en logs o outputs públicos: GitHub Actions puede imprimir valores en logs. Asegúrate de no hacer echo o print de secrets, ya que GitHub los ofusca, pero errores podrían filtrarlos. Usa run: echo "Secret value: ${{ secrets.MY_SECRET }}" con precaución.
No rotar secrets regularmente: Los secrets deben actualizarse periódicamente, especialmente después de incidentes o cambios de personal. Configura recordatorios para revisar y rotar credenciales cada 3-6 meses.
Confundir secrets con variables: Los secrets son para datos sensibles, las variables para configuraciones no sensibles. No uses variables para contraseñas; siempre usa secrets para mayor seguridad.
No usar entornos para gestión avanzada: GitHub Actions permite definir entornos (como staging o production) con approvals y secrets específicos. No gestiones todo desde los secrets del repositorio; aprovecha los entornos para flujos complejos.

Checklist de dominio

He configurado al menos 3 secrets en mi repositorio de GitHub (ej. API keys, tokens).
Puedo referenciar secrets y variables de entorno en un workflow YAML sin exponerlos.
Sé cómo usar .gitignore para prevenir commits accidentales de archivos sensibles.
He probado un workflow que despliega a un entorno cloud usando secrets de forma segura.
Entiendo la diferencia entre secrets a nivel de repositorio, organización y entorno.
Puedo rotar un secret y actualizar el workflow sin romper el despliegue.
He revisado los logs de mis workflows para asegurarme de que no hay fugas de información.

Configura un despliegue seguro a AWS usando GitHub Secrets

En este ejercicio, crearás un workflow de GitHub Actions que despliega una aplicación estática a un bucket de AWS S3, utilizando secrets para las credenciales de AWS de forma segura. Sigue estos pasos:

Prepara tu repositorio: Crea un repositorio en GitHub con una carpeta dist que contenga un archivo HTML simple (ej. index.html).
Configura secrets en GitHub: Ve a Settings > Secrets and variables > Actions en tu repositorio. Agrega dos secrets:
- AWS_ACCESS_KEY_ID con tu clave de acceso de AWS (crea una IAM user con permisos para S3 si no tienes).
- AWS_SECRET_ACCESS_KEY con tu clave secreta correspondiente.
Crea el workflow: En tu repositorio, crea un archivo en .github/workflows/deploy.yml con el contenido del ejemplo "Después" de la sección "Código en acción", ajustando el nombre del bucket S3 (my-bucket) al tuyo.
Ejecuta el workflow: Haz un push a la rama main para trigger el workflow. Verifica en la pestaña Actions de GitHub que se ejecute sin errores.
Verifica el despliegue: Accede a tu bucket de S3 en AWS Console para confirmar que los archivos se hayan subido correctamente.

Pistas

Asegúrate de que el IAM user en AWS tenga permisos para S3 (ej. AmazonS3FullAccess).
Si el workflow falla, revisa los logs en GitHub Actions para ver mensajes de error específicos de AWS.
Puedes probar con un bucket de S3 en una región gratuita como us-east-1 para minimizar costos.

Evalua tu comprension

Completa el quiz interactivo de arriba para ganar XP.

Maneja secretos y variables de entorno de forma segura