¿Sigues usando Access Keys en tus pipelines? 🛑 ¡Es hora de cambiar! En este artículo, aprenderás cómo configurar OpenID Connect (OIDC) entre GitLab y AWS, eliminando la necesidad de credenciales estáticas y mejorando la seguridad de tus despliegues. 🔐

🏗️ ¿Qué es OIDC?

OIDC es un estándar de autenticación basado en tokens que permite a las aplicaciones autenticar usuarios sin necesidad de contraseñas o credenciales estáticas. Con GitLab y AWS, esto se traduce en un flujo más seguro para tus pipelines CI/CD.

✨ Ventajas de usar OIDC:

  • 🔒 Elimina credenciales estáticas: No más Access Keys expuestas en tu repositorio o variables de entorno.
  • 🔄 Tokens dinámicos: Los tokens son temporales y están limitados en alcance.
  • 🏢 Ideal para empresas: GitLab puede ser hosteado on-premise, perfecto para organizaciones con altos estándares de seguridad.
  • 📈 Mejor gobernanza: Los permisos se gestionan mediante políticas de IAM en AWS.

🔧 Pasos para configurar OIDC con GitLab y AWS:

  • 🛠️ Crear un Proveedor OIDC en AWS: Configura AWS para reconocer los tokens emitidos por GitLab.
  • 🔑 Configurar roles y permisos IAM: Define los permisos necesarios para tu pipeline CI/CD.
  • 🤝 Integrar GitLab con AWS: Actualiza tu archivo .gitlab-ci.yml para incluir el flujo de OIDC.

🚀 Configurar OIDC en AWS para GitLab CI/CD con Terraform

Este proyecto configura un Proveedor de Identidad OIDC en AWS para permitir que GitLab CI/CD asuma roles de IAM usando tokens OIDC. Esto elimina la necesidad de Access Keys en los pipelines, mejorando la seguridad y simplificando la gestión de credenciales.

Puedes encontrar la implementación completa en el repositorio:

🔗 GitHub: francotel/gitlab-to-aws-oidc-with-tf

1. Inicio de autenticación

  • El cliente (GitLab CI/CD) solicita un token al Identity Provider (IdP) configurado (GitLab).
  • GitLab genera un JWT como parte del protocolo OIDC.
  • GitLab crea un token con:
    • Datos de identificación: nombre del pipeline, proyecto, etc.
    • Firma criptográfica: para asegurar la integridad del token.
  • El token incluye:
    • Issuer: URL del IdP (por ejemplo, https://gitlab.com).
    • Audience: consumidor del token (AWS).

2. Validación en AWS

  • AWS recibe el ID Token (JWT) como parte de la solicitud para asumir un rol IAM.
  • AWS valida que:
    • El token no haya expirado (timestamp).
    • La firma sea válida (usando claves públicas del IdP).
    • Si el token es válido, AWS otorga un token temporal

3. Asignación del rol solicitado

  • El cliente (GitLab) de acuerdo al token puede asumir el rol solicitado que permite al cliente realizar las acciones definidas.

4. Acceso a recursos

  • El cliente usa el token temporal para interactuar con servicios como EC2, RDS, o S3.

📊 Comparativa: OIDC vs Access Keys

Aspecto OIDC Access Keys
🔐 Seguridad Tokens dinámicos y temporales. Credenciales estáticas y reutilizables.
🕒 Duración Temporal, configurada por sesión. Hasta que las elimines manualmente.
📋 Gestión de permisos Basada en políticas IAM por rol. Asociada directamente a las keys.
🏢 Ideal para empresas Compatible con GitLab on-premise. Limitado a configuraciones en la nube.

¡No te lo pierdas! Sígueme en LinkedIn para estar al tanto de todas las actualizaciones y futuros artículos:

☕ Apóyame con un café

Si este contenido te ha sido útil y quieres apoyarme para seguir creando más, considera invitarme un café. ¡Tu apoyo hace la diferencia! 🥰

¡Gracias por leer y hasta la próxima! 👋

Author Of article : francotel Read full article