Guten Tag zusammen,
ich denke, dass die meisten in diesem Forum mit den Begriffen GitLab und Kubernetes etwas anfangen können. Da mein Eindruck ist, dass hier im Forum technisch sehr versierte DevOps unterwegs sind, wollte ich die Chance mal nutzen um ein paar Implikationen des Betriebs eines GitLab CI Runners in einem Kubernetes Cluster zu diskutieren.
Folgendes ist die Situation: Auf einigen meiner (viel zu vielen, aber das ist ein anderes Problem) NetCup-Maschinen läuft ein kleines Kubernetes-Cluster. Dieses Cluster würde ich gerne dazu nutzen, um CI-Jobs, welche auf gitlab.com oder einer privaten Instanz laufen, abzuarbeiten. Dies stellt an sich erst mal kein Problem da.
Interessanter wird es jedoch, wenn man versucht, über diese CI-Runner auch Docker-Images bauen und in eine Registry pushen zu lassen. Dies benötigt Zugriff auf docker-in-docker (dind), für das man wiederum den Runner mit aktivierten privileged-Flag starten muss (https://docs.gitlab.com/runner…tes.html#using-dockerdind).
Ja, der privileged-Modus ist ein wenig kritisch, das ist mir klar. Aber ganz konkret: Was genau ist das Problem? Was kann jemand schlimmstenfalls mit einem CI-Job anrichten, wenn er einen privileged Runner zur Verfügung hat - und wie genau bekommt er das hin? Wie genau schafft es dann aber GitLab.com selbst, Shared Runner anzubieten, welche dind unterstützen? Leider finde ich auf all diese Fragen nur Antworten wie (sinng.) "Ja, ist nicht optimal. Aber ist halt so."
Vielleicht schaffen wir es ja hier, gemeinsam ein wenig Licht da reinzubringen und zumindest mein Unwissen darüber zu verringern.
Ich freue mich auf eure Antworten!
Viele Grüße
Matthias