OpenShift - Jenkins

Reading time: 3 minutes

tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

Überprüfen Sie die Abonnementpläne!
Treten Sie der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folgen Sie uns auf Twitter 🐦 @hacktricks_live.
Teilen Sie Hacking-Tricks, indem Sie PRs an die HackTricks und HackTricks Cloud GitHub-Repos senden.

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

Es gibt mehrere Hauptwege, um einen Build auszulösen, wie zum Beispiel:

Sie haben UI-Zugriff auf Jenkins

Ein sehr einfacher und bequemer Weg ist die Verwendung der Replay-Funktionalität eines bestehenden Builds. Damit können Sie einen zuvor ausgeführten Build erneut abspielen und gleichzeitig das Groovy-Skript aktualisieren. 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.

Jenkins Build Pod YAML-Überschreibung

OpenShift - Jenkins Build Pod Override

tip