gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-01-08 19:30:51 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['.github/pull_request_template.md', 'src/README.md', 'src/pe

Browse Source
This commit is contained in:
Translator
2025-01-02 00:01:28 +00:00
parent 4bcd54c1b6
commit c0ee8b41f2
215 changed files with 1371 additions and 1387 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
src/pentesting-cloud/openshift-pentesting/openshift-jenkins/README.md
View File

@@ -6,7 +6,7 @@ Diese Seite gibt einige Hinweise, wie Sie eine Jenkins-Instanz angreifen können
## 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 gezeigte Payload, YAML oder Technik anpassen. Für weitere Informationen zum Angreifen von Jenkins können Sie [diese Seite](../../../pentesting-ci-cd/jenkins-security/) besuchen.
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](../../../pentesting-ci-cd/jenkins-security/) besuchen.
## Voraussetzungen
@@ -18,7 +18,7 @@ Grundsätzlich funktioniert fast alles im Hintergrund genauso wie bei einer regu
### 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). Dasselbe 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.
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
@@ -26,7 +26,7 @@ Sie haben mehrere Hauptmöglichkeiten, um einen Build auszulösen, wie zum Beisp
1. Sie haben UI-Zugriff auf Jenkins
Eine sehr einfache und bequeme Möglichkeit ist die Verwendung der Replay-Funktionalität eines vorhandenen 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.
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.
2. Sie haben Schreibzugriff auf das SCM und automatisierte Builds sind über Webhook konfiguriert