Creacion de GitLab Runners

El objetivo de esta política es establecer directrices claras para el uso y la creación de runners en GitLab, garantizando la seguridad, eficiencia y consistencia en la infraestructura de CI/CD.

Alcance

Esta política aplica a todos los equipos y dominios que posean proyectos en el repositorio corporativo de código GitLab y requieran usar runners.

Tipos de Configuración de Runners

• Runners por Defecto: Los dominios tendrán a disposición runners publicados y mantenidos por el equipo de plataforma en los clusters de GKE¹ definidos para este objetivo. Estos runners están configurados para cumplir con los requisitos generales de la mayoría de los proyectos. Más información sobre Gitlab Runners ver Servicios > Gitlab > Runners.
• Runners Propios por dominio: Cada equipo podrá implementar sus propios runners dependiendo de sus necesidades o carga de trabajo. Para implementar sus propios runners deberán cumplir con las especificaciones entregadas en las secciones siguientes de la presente política.
• Runners públicos:
  Gitlab Shared Runners

  No está permitido el uso de runners públicos de Gitlab.

Cuadro comparativo

	Runners por defecto	Runner propios por dominio
Administración	Equipo Plataforma	Gestionada por Dominio
Facturación	Centralizado por Tecnología	Control del Billing por Dominio
Gestión de Infraestructura	- Nodepool Compartido (por defecto) - Nodepool Independiente (por solicitud)	Gestionada por Dominio
Hardening Seguridad	Equipo Seguridad	Gestionada por Dominio
Actualizaciones Runners	Equipo Plataforma	Gestionada por Dominio
Configuración Cache	Storage Centralizado	Storage en Proyecto GCP del Dominio
Artefactos Pipeline	Gestionado por equipo	Storage en Proyecto GCP del Dominio

Infraestructura Permitida para Uso de Runners

• Para implementar un Runner utilizando infraestructura independiente, se deberá usar el template que el equipo de plataforma deberá mantener disponible en gitlab con el código necesario para desplegar un cluster GKE con un runner usando terraform.
• Este proyecto deberá contener las referencias a los módulos de terraform utilizados para el despliegue los cuales serán detallados en la página de Servicios > Gitlab > Runners.

Uso de Imágenes y Charts Autorizados

• Imágenes Autorizadas: Los runners de GitLab deben utilizar exclusivamente las imágenes autorizadas por el equipo de plataforma.
  • Estas imágenes estarán almacenadas en el repositorio GCP Artifactory de LATAM Airlines.
• Imagen por defecto Ejecutores: Los runners de gitlab deben utilizar exclusivamente imágenes publicadas en el repositorio de GCP Corporativo de LATAM Airlines.
• Helm Chart del Runner: El helm chart utilizado para desplegar los runners de gitlab deberá ser el publicado por el equipo de plataforma y no se podrá utilizar helm charts de terceros.
• Actualizaciones: El equipo de plataforma será responsable de actualizar y mantener las imágenes docker y helm charts necesarios para el despliegue y ejecución de Gitlab Runners.

Runners Centralizados o implementar propios para el dominio

• Cuando elegir Runners Centralizados
  • Son los runners por defecto se necesita configurar nada.
  • No existe un equipo disponible para administrar y mantener los runners.
  • Las necesidades o Capacity del pipeline están cubiertas por los runners por defecto.
• Runners por Dominio
  • Cuándo requiere especificaciones de instancias de cómputo.
  • Cuándo tiene disponibilidad de administración.
  • Cuándo existen requerimientos específicos respecto al performance, seguridad o acceso que no pueden ser cubiertas por los runners centralizados.

Seguridad

Los runners deben ser configurados siguiendo las mejores prácticas de seguridad establecidas por el equipo de Arquitectura de Ciberseguridad de LATAM Airlines.

Despliegues sobre GKE

id	Control	Tipo
1	GKE privado con acceso o salida a internet para descarga de paquetes, imágenes Docker y comunicación entre GitRunner y las colas de trabajos pendientes del Gitlab SaaS.	Requerido
2	GKE con Workload Identity habilitado	Requerido
3	Gitlab Runner debe correr dentro de su propio namespace y debe correr con una identidad que esté impersonificando la SA en GCP.	Requerido
4	GKE debe tener instalado el agente de CSPM	Requerido
5	GKE debe ser dedicado para Gitlab Runners	Requerido
6	GKE debe tener AutoScaling de nodos acotado o limitado según conveniencia	Recomendado
7	Los artefactos generados en los diferentes stages del pipeline no deben persistir por más de 30 minutos	Recomendado
8	GKE Gitlab-Runners para proyectos PCI debe ser exclusivo	Requerido
9	GKE debe contar con VPC y Subnets acotadas y definidas para los Node Pools y las cargas de trabajo	Requerido
10	Las configuraciones generales de seguridad que debe cumplir el GKE se encuentran documentadas en el Estándar de hardening de GKE (GRT.EST.014 - Estándar de hardening de GKE - v1.5)	Requerido
11	Todo Gitlab Runner debe contar con un TAG que lo identifique; no se podrán correr pipelines sin “tagging” de runners asociados	Requerido

Despliegues sobre GCE²

id	Control	Tipo
1	Habilitar los servicios de protección y postura de seguridad definido a nivel corporativo a través de CSPM.	Requerido
2	Instancias de cómputo se deben desplegar como Shielded VM (entorno PCI).	Requerido
3	Los discos de máquinas virtuales deben tener encriptación en reposo.	Requerido
4	Se deben utilizar las imágenes base de SO hardenizadas para su despliegue.	Requerido
5	Se debe implementar el aislamiento de red a través de Network Security Group y reglas firewalls.	Requerido
6	El acceso remoto de las maquinas virtuales se debe hacer mediante un servidor pivote, bastion host o dar acceso mediante IAP.	Requerido
7	La instancia no debe tener IP pública, su acceso remoto debe hacerse a través de Tunel IAP, y su salida a internet debe ser garantizada a través de un Cloud NAT más un Router.	Recomendado
8	Asegúrese de restringir el acceso SSH (TCP 22) y Telnet (TCP 23) desde Internet (0.0.0.0/0).	Requerido
9	Asegúrese de restringir el acceso SMB (TCP/UDP 445) desde Internet (0.0.0.0/0).	Requerido
10	Asegúrese de restringir el acceso FTP (TCP 21) desde Internet (0.0.0.0/0).	Requerido
11	Asegúrese de restringir el acceso RDP (TCP 3389) desde Internet (0.0.0.0/0).	Requerido
12	Para workloads bajo PCI Compliance, se debe implementar una capacidad de detección de cambios (FIM), generando alertas sobre modificaciones o cambios no autorizados en archivos críticos del sistema.	Requerido
13	Para workloads bajo PCI Compliance, se debe implementar firewalls basados en host o herramientas de filtrado de puertos en los sistemas finales o a nivel de red, con una regla de denegación predeterminada que descarta todo el tráfico, excepto los servicios y puertos que están explícitamente permitidos.	Requerido
14	Todo Gitlab Runner debe contar con un TAG que lo identifique, no se podrán correr pipelines sin “tagging” de runners asociados.	Requerido

Revisión y Actualización

Esta política será revisada y actualizada periódicamente por el equipo de plataforma para asegurar su vigencia y adecuación a las necesidades de la organización.

Historial de Cambios

1.0.0 - 2024-07-08

Publicación del documento inicial.

• Autores:
  • Carlos Herrera: Documento general.
  • Raul Linares: Consideraciones de seguridad.
• Aprobaciones:
  • Delivery CI/CD: Mario Young el 2024-07-05.
  • Plataforma DevOps: Ronald Ponce el 2024-07-05.
  • Cloud Fundation: Cristian Herrera el 2024-07-05.
  • Arquitectura de Ciberseguridad: Raul Linares el 2024-07-08.
  • Plataforma Emantto: Roberto Esparza el 2024-07-09.

Footnotes

1. Google Kubernetes Engine. Servicio gestionado de Google Cloud para Kubernetes. Más información en https://cloud.google.com/kubernetes-engine ↩

2. Google Compute Engine. Servicio de Infraestructura como Servicio (IaaS) de Google Cloud. Más información en https://cloud.google.com/compute ↩