Des runners GitLab CI dans des cluster 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.

2. Ajoutez le repository Helm

helm repo add gitlab https://charts.gitlab.io
helm repo update

3. Créez un fichier de configuration pour Helm

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"

4. Déployez le GitLab Runner

helm install -f gitlab-runner-values.yaml gitlab-runner gitlab/gitlab-runner

5. Vérifiez son état

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.

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

3. Commitez et poussez vos modifications.
4. 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 !

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 ! 💪

×

📖 Voir la documentation →