OpenShift - Jenkins
Der ursprüngliche Autor dieser Seite ist Fares
Diese Seite gibt einige Hinweise darauf, wie Sie eine Jenkins-Instanz angreifen können, die in einem Openshift- (oder Kubernetes-) Cluster läuft.
Haftungsausschluss
Eine Jenkins-Instanz kann sowohl in einem Openshift- als auch in einem Kubernetes-Cluster bereitgestellt werden. Je nach Kontext müssen Sie möglicherweise jedes gezeigte Payload, YAML oder jede Technik anpassen. Weitere Informationen zum Angriff auf Jenkins finden Sie auf dieser Seite
Voraussetzungen
1a. Benutzerzugriff auf eine Jenkins-Instanz ODER 1b. Benutzerzugriff mit Schreibberechtigung für ein SCM-Repository, in dem nach einem Push/Merge ein automatisierter Build ausgelöst wird
Funktionsweise
Grundsätzlich funktioniert fast alles hinter den Kulissen genauso wie eine reguläre Jenkins-Instanz, die in einer VM läuft. Der Hauptunterschied besteht in der Gesamtarchitektur und wie Builds innerhalb eines Openshift- (oder Kubernetes-)Clusters verwaltet werden.
Builds
Wenn ein Build ausgelöst wird, wird er zuerst vom Jenkins-Masterknoten verwaltet/orchestriert und dann an einen Agenten/Slave/Worker delegiert. In diesem Kontext ist der Masterknoten nur ein regulärer Pod, der in einem Namespace läuft (der möglicherweise unterschiedlich ist als der, in dem die Worker ausgeführt werden). Das Gleiche gilt für die Worker/Slaves, jedoch werden sie nach Abschluss des Builds zerstört, während der Master immer aktiv bleibt. Ihr Build wird normalerweise innerhalb eines Pods ausgeführt, der von den Jenkins-Administratoren definiert ist.
Auslösen eines Builds
Es gibt mehrere Hauptmethoden, um einen Build auszulösen, wie z.B.:
Sie haben UI-Zugriff auf Jenkins
Ein sehr einfacher und bequemer Weg ist die Verwendung der Wiederholungsfunktion eines bereits ausgeführten Builds. Sie ermöglicht es Ihnen, einen zuvor ausgeführten Build erneut abzuspielen und dabei das Groovy-Skript zu aktualisieren. Dies erfordert Berechtigungen in einem Jenkins-Ordner und eine vordefinierte Pipeline. Wenn Sie unauffällig sein müssen, können Sie Ihre ausgelösten Builds löschen, wenn Sie ausreichende Berechtigungen haben.
Sie haben Schreibzugriff auf das SCM und automatisierte Builds sind über Webhook konfiguriert
Sie können einfach ein Build-Skript (wie z.B. Jenkinsfile) bearbeiten, committen und pushen (eventuell einen PR erstellen, wenn Builds nur bei PR-Merges ausgelöst werden). Beachten Sie, dass dieser Weg sehr laut ist und erhöhte Berechtigungen erfordert, um Ihre Spuren zu verwischen.
Jenkins Build Pod YAML-Überschreibung
OpenShift - Jenkins Build Pod OverrideLast updated