GitLab CI Runner mit Kubernetes - Sicherheits-Implikationen von privileged=true

  • 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

    Matthias Lohr Project Blog: https://mlohr.com/

    PGP: 0x8FC3060F80C31A0A

  • Dafür gibt es eine recht gute Alternative, die sogar in der offiziellen Dokumentation erwähnt wird: https://docs.gitlab.com/ee/ci/docker/using_kaniko.html

    Das ist mal ein guter Hinweis, danke! Das hab ich tatsächlich bisher sehr erfolgreich überlesen. Das werde ich mir definitiv anschauen.


    Ungeachtet dessen würde ich trotzdem gerne verstehen, wie z. B. GitLab.com mit den Sicherheitsproblemen umgeht, die mit der Bereitstellung von dind einhergehen. Offensichtlich kann man da ja auch ohne kaniko Docker-Images bauen und hochladen.

    Matthias Lohr Project Blog: https://mlohr.com/

    PGP: 0x8FC3060F80C31A0A

  • Das ist mal ein guter Hinweis, danke! Das hab ich tatsächlich bisher sehr erfolgreich überlesen. Das werde ich mir definitiv anschauen.


    Ungeachtet dessen würde ich trotzdem gerne verstehen, wie z. B. GitLab.com mit den Sicherheitsproblemen umgeht, die mit der Bereitstellung von dind einhergehen. Offensichtlich kann man da ja auch ohne kaniko Docker-Images bauen und hochladen.

    Ich glaube ja, wenn man sich die (Critical) Security Patches von Gitlab so anschaut, dass die Dind Runner wohl ihr kleinstes Problem sind :-). Da gibt es ja quasi wöchentlich irgendwelche Bugs, Code Execution Lücken etc.

    Im Grunde ist das ja auch erstmal nur ein theoretisches Problem. Dafür braucht es auch erstmal praktische Anwendungen. Die Runner werden, soweit ich weiß, auch dynamisch auf dedizierten Servern erstellt. Selbst bei einem erfolgreichen Ausbruch aus einem Container, würde man ja erstmal nicht so weit kommen. Kritischen Code sollte man sowieso nicht auf Shared Runnern ausführen lassen.