Elimina las Access Keys en tus Pipelines: Configuración de OIDC entre GitLab y AWS para Máxima Seguridad

#aws #terraform #gitlab #crosscloudx

¿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.