HackTricks CloudOpenShift - Jenkins
Reading time: 2 minutes
Der ursprüngliche Autor dieser Seite ist Fares
Diese Seite gibt einige Hinweise, 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 jede angezeigte Payload, YAML oder Technik anpassen. Für weitere Informationen zum Angreifen von Jenkins können Sie diese Seite besuchen.
Voraussetzungen
1a. Benutzerzugriff auf eine Jenkins-Instanz ODER 1b. Benutzerzugriff mit Schreibberechtigung auf ein SCM-Repository, in dem ein automatisierter Build nach einem Push/Merge ausgelöst wird.
So funktioniert es
Grundsätzlich funktioniert fast alles im Hintergrund genauso wie bei einer regulären Jenkins-Instanz, die in einer VM läuft. Der Hauptunterschied ist die 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/Sklaven/Arbeiter delegiert. In diesem Kontext ist der Masterknoten nur ein regulärer Pod, der in einem Namespace läuft (der möglicherweise anders ist als der, in dem die Arbeiter laufen). Das Gleiche gilt für die Arbeiter/Sklaven, jedoch werden sie zerstört, sobald der Build abgeschlossen ist, während der Master immer aktiv bleibt. Ihr Build wird normalerweise innerhalb eines Pods ausgeführt, unter Verwendung einer standardmäßigen Pod-Vorlage, die von den Jenkins-Administratoren definiert wurde.
Auslösen eines Builds
Sie haben mehrere Hauptmöglichkeiten, um einen Build auszulösen, wie zum Beispiel:
- Sie haben UI-Zugriff auf Jenkins
Eine sehr einfache und bequeme Möglichkeit ist die Verwendung der Replay-Funktionalität eines vorhandenen Builds. Sie ermöglicht es Ihnen, einen zuvor ausgeführten Build erneut abzuspielen, während Sie das Groovy-Skript aktualisieren können. Dies erfordert Berechtigungen für einen Jenkins-Ordner und eine vordefinierte Pipeline. Wenn Sie unauffällig sein müssen, können Sie Ihre ausgelösten Builds löschen, wenn Sie genügend Berechtigungen haben.
- Sie haben Schreibzugriff auf das SCM und automatisierte Builds sind über Webhook konfiguriert
Sie können einfach ein Build-Skript (wie 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 benötigt, um Ihre Spuren zu verwischen.