Aller au contenu
DevSecOps Logo DevSecOps
Docs
Blog
Blog

Des runners GitLab CI dans des cluster Kubernetes

Mise à jour :

logo kubernetes

L’exécution des jobs GitLab CI/CD sur un cluster Kubernetes permet de bénéficier d’une infrastructure scalable, isolée et optimisée pour le déploiement d’applications. Grâce à un GitLab Runner Kubernetes, les jobs s’exécutent directement dans des pods, offrant une gestion efficace des ressources et une meilleure intégration avec les environnements cloud-native.

Pourquoi utiliser un GitLab Runner sur Kubernetes ?

L’intégration d’un GitLab Runner sur un cluster Kubernetes présente plusieurs avantages :

  • Scalabilité automatique : Kubernetes peut gérer dynamiquement les ressources en ajoutant ou supprimant des pods selon la charge des jobs CI/CD.
  • Isolation des jobs : Chaque job s’exécute dans un pod dédié, évitant les conflits entre différentes exécutions et améliorant la sécurité.
  • Gestion centralisée des ressources : Kubernetes permet d’attribuer précisément CPU, mémoire et stockage aux jobs CI/CD, optimisant l’utilisation des ressources disponibles.
  • Déploiements simplifiés : Les applications peuvent être directement déployées sur Kubernetes après la phase de build et de test, sans infrastructure additionnelle.

Comment fonctionne un runner GitLab sur Kubernetes ?

  1. GitLab envoie un job : Lorsqu’un pipeline CI/CD démarre, GitLab attribue le job à un runner actif disposant du bon tag.
  2. Le GitLab Runner crée un pod Kubernetes : Chaque job CI/CD est exécuté dans un pod temporaire contenant un conteneur avec l’environnement requis.
  3. Exécution du job dans le pod : Le script défini dans le .gitlab-ci.yml s’exécute dans le pod, effectuant des tâches comme la compilation, les tests ou le déploiement.
  4. Destruction automatique du pod : Une fois le job terminé, le pod est automatiquement supprimé pour libérer les ressources du cluster.

Installation de l’agent GitLab Runner à un cluster Kubernetes

Nous allons maintenant installer et configurer un GitLab Runner sur notre cluster Minikube afin qu’il puisse exécuter les jobs CI/CD directement dans Kubernetes. Pour cela, nous utiliserons Helm, un gestionnaire de packages pour Kubernetes.

  1. Récupérez le token GitLab : Dans le projet GitLab → Settings → CI/CD → Runners → Create runner → Entrez un tag → Cliquez sur Create → Copiez le token.

Token Gitlab Runner

  1. Ajoutez le repository Helm
Terminal window
helm repo add gitlab https://charts.gitlab.io
helm repo update
  1. Créez un fichier de configuration pour Helm
Terminal window
helm show values gitlab/gitlab-runner > gitlab-runner-values.yaml

Modifiez les valeurs essentielles :

gitlabUrl: https://gitlab.robert.local/


runnerToken: "<votre_token_gitlab>" # le token généré dans GitLab gnénéré ci-dessus


rbac:
  create: true
runners:
  config: |
    [[runners]]
      [runners.kubernetes]
        namespace = "{{.Release.Namespace}}"
        image = "alpine"
  tags: "shared"
  name: "shared"
  1. Déployez le GitLab Runner
Terminal window
helm install -f gitlab-runner-values.yaml gitlab-runner gitlab/gitlab-runner
  1. Vérifiez son état
Terminal window
kubectl get pods -A


default             gitlab-runner-b5f5cd898-qgf4x                             1/1     Running   0          43h
gitlab-agent-test   test-gitlab-agent-v2-66b898b96d-xg95h                     1/1     Running   0          43h
gitlab-agent-test   test-gitlab-agent-v2-66b898b96d-xgnqb                     1/1     Running   0          43h

Dans GitLab, votre runner devrait maintenant apparaître comme actif.

GitLab Runner Kubernetes

Tester un pipeline GitLab sur Kubernetes

  1. Créez un projet GitLab
  2. Ajoutez un fichier .gitlab-ci.yml avec le contenu suivant :
build-job:
  stage: build
  tags:
    - shared # le tag défini dans le fichier de configuration du runner
  script:
    - echo "Compilation en cours..."
    - echo "Compilation terminée."
  1. Commitez et poussez vos modifications.
  2. Vérifiez l’exécution du pipeline dans l’onglet CI/CD → Pipelines.

Si tout fonctionne, vous verrez votre job s’exécuter sur votre cluster Kubernetes !

GitLab Runner Kubernetes

Sécurisation des GitLab Runners sur Kubernetes

L’exécution de jobs CI/CD sur Kubernetes implique des risques en termes de sécurité, gestion des ressources et isolation. Voici quelques recommendations pour sécuriser un GitLab Runner Kubernetes.

Contrôle des permissions (RBAC)

  • Limitez les permissions du runner via un ServiceAccount dédié.
  • Restreignez son accès aux seuls namespaces nécessaires.
  • Évitez d’attribuer le rôle cluster-admin.

Isolation des jobs (SecurityContext)

  • Désactivez le mode privilégié (privileged: false).
  • Empêchez l’élévation de privilèges (allowPrivilegeEscalation: false).
  • Restreignez l’accès aux capabilities Linux sensibles (NET_ADMIN, SYS_ADMIN).

Répartition et planification des jobs

  • Utilisez Node Affinity pour exécuter certains jobs sur des nœuds spécifiques.
  • Configurez Taints & Tolerations pour éviter les conflits de ressources.
  • Préférez un namespace dédié aux jobs CI/CD.

Sécurisation des secrets

  • Ne stockez jamais de clés API ou tokens en dur dans .gitlab-ci.yml.
  • Utilisez Kubernetes Secrets ou un gestionnaire comme HashiCorp Vault.
  • Limitez l’accès aux secrets via RBAC.

Monitoring & audit

  • Surveillez la consommation des jobs via Prometheus/Grafana.
  • Configurez des alertes en cas d’anomalie.

Conclusion

Commencez maintenant ! Vous n’avez plus qu’à installer votre GitLab Runner sur votre Cluser Kubernetes, sécuriser son exécution et optimiser vos pipelines CI/CD.

Attention : Si vous voulez construire des images de conteneurs, utilisez Kaniko.

Au boulot ! 💪