Saltar a contenido

GitLab Agent y acceso a Kubernetes

La conexión con los clústeres está centralizada en terraform-modules. Hay dos configuraciones: .gitlab/agents/eks-agent/config.yaml y .gitlab/agents/gke-agent/config.yaml. Cada capa platform instala un release Helm gitlab-agent en el namespace gitlab-agent, con su token y dirección KAS.

Bootstrap y operación usan rutas diferentes

La primera instalación del agente no puede depender del propio agente. El runner ejecuta los proveedores Kubernetes/Helm directamente contra el API del clúster: AWS mediante aws eks get-token, GCP mediante un token del proveedor Google. Por eso hace falta acceso de red y permisos de la identidad aprovisionadora.

Una vez instalado, el Agent proporciona la integración de Kubernetes con GitLab y los jobs de aplicación seleccionan su contexto. Cambiar los endpoints públicos a privados exige resolver el acceso del runner de aprovisionamiento, aunque el acceso posterior mediante Agent esté preparado. El código actual permite CIDRs públicos 0.0.0.0/0 en ambos proveedores; una revisión de endurecimiento debe tratar ambas rutas.

Configuración versionada

Las dos configuraciones tienen el mismo contenido:

user_access:
  access_as:
    agent: {}
  groups:
    - id: gabriel-canals-tfm
ci_access:
  groups:
    - id: gabriel-canals-tfm

ci_access autoriza a los proyectos del grupo y sus subgrupos a usar la conexión. GitLab entrega a los jobs autorizados un kubeconfig y expone su ruta mediante KUBECONFIG. user_access permite acceso de miembros del grupo; access_as.agent usa la identidad de la cuenta de servicio del agente. No equivale a asignar permisos Kubernetes individuales a cada usuario. Referencias oficiales: CI/CD y acceso de usuarios.

El alcance es todo el grupo, no una lista limitada a frontend/backend. No se definen en estos ficheros restricciones por namespace, impersonación de jobs o RBAC de cada aplicación. Los permisos efectivos del Agent dependen del chart instalado y de la configuración del clúster; como el chart no tiene versión fijada y no se ha inspeccionado el clúster real, esta documentación no certifica sus permisos efectivos.

Registro y tokens

Antes de aplicar la capa platform:

  1. Registrar en GitLab los agentes con los nombres de sus directorios y asociarlos al proyecto de configuración.
  2. Recoger la dirección KAS y los tokens mediante el flujo de registro de esa instalación.
  3. Configurar AGENT_TOKEN para AWS y GKE_AGENT_TOKEN para GCP, además de KAS_ADDRESS.
  4. Confirmar que la identidad de CI puede autenticar contra el clúster y que existe conectividad desde el runner.
  5. Aplicar platform, comprobar el estado de los pods del agente y verificar en GitLab que la conexión aparece disponible.

El registro del agente y la generación del token no se implementan como recursos Terraform del snapshot. El token del Agent, la credencial de cloud y TF_STATE_TOKEN tienen propósitos diferentes y deben gestionarse por separado. Los tokens se pasan a Helm mediante set_sensitive, lo que no elimina su posible persistencia en estado y plan.

Contextos usados por la aplicación

Destino Variable Contexto configurado
EKS EKS_KUBE_CONTEXT gabriel-canals-tfm/terraform-modules:eks-agent
GKE GKE_KUBE_CONTEXT gabriel-canals-tfm/terraform-modules:gke-agent

DEPLOY_TARGET selecciona eks o gke; el valor predeterminado de la plantilla es eks. El job comprueba los contextos, selecciona uno, crea el namespace app si no existe y aplica los manifiestos. No despliega a los dos clústeres en la misma ejecución por el mero hecho de tener ambos contextos disponibles.

La ruta de contexto combina el proyecto de configuración y el nombre del agente. Si se cambia el namespace del grupo, deben revisarse esas rutas y los IDs textuales de ci_access/user_access. Cambiar solo el nombre visible a Cloud Delivery Lab mantiene la ruta antigua y no requiere sustituir esas cadenas.

Diagnóstico sin mostrar credenciales

En un job autorizado, con el contexto elegido ya configurado:

kubectl config get-contexts
kubectl config current-context
kubectl get namespaces
kubectl get pods -n app
kubectl get serviceaccounts -n app
kubectl auth can-i get pods -n app

Si el contexto no aparece, revisar ruta/nombre del agente y la autorización ci_access. Si aparece pero el clúster no responde, revisar el Agent, KAS y conectividad. Si responde con Forbidden, revisar permisos efectivos y RBAC. Un error de acceso al Container Registry es otra integración: requiere el Secret registry, no se resuelve cambiando el contexto del Agent.

Estas órdenes no imprimen kubeconfig completo ni valores de secretos. No se ejecutaron contra clústeres reales durante la preparación de la documentación.

Límites operativos

El Agent habilita acceso; no implementa un reconciliador de despliegue continuo en los repositorios revisados. La aplicación se actualiza por un job que ejecuta kubectl apply. Los cambios hechos manualmente al clúster no quedan corregidos por un bucle de reconciliación declarado en estos ficheros. Las pantallas de operación de GitLab descritas en la memoria deben distinguirse del comportamiento de los pipelines y de las capacidades que dependen de la instalación GitLab.

Fuentes