mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-30 14:40:37 -08:00
Translated ['.github/pull_request_template.md', 'src/pentesting-cloud/az
This commit is contained in:
@@ -1,43 +1,39 @@
|
||||
# OpenShift - Jenkins
|
||||
|
||||
**The original author of this page is** [**Fares**](https://www.linkedin.com/in/fares-siala/)
|
||||
**Der ursprüngliche Autor dieser Seite ist** [**Fares**](https://www.linkedin.com/in/fares-siala/)
|
||||
|
||||
This page gives some pointers onto how you can attack a Jenkins instance running in an Openshift (or Kubernetes) cluster
|
||||
Diese Seite gibt einige Hinweise, wie Sie eine Jenkins-Instanz angreifen können, die in einem Openshift- (oder Kubernetes-) Cluster läuft.
|
||||
|
||||
## Disclaimer
|
||||
## Haftungsausschluss
|
||||
|
||||
A Jenkins instance can be deployed in both Openshift or Kubernetes cluster. Depending in your context, you may need to adapt any shown payload, yaml or technique. For more information about attacking Jenkins you can have a look at [this page](../../../pentesting-ci-cd/jenkins-security/)
|
||||
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.
|
||||
|
||||
## Prerequisites
|
||||
## Voraussetzungen
|
||||
|
||||
1a. User access in a Jenkins instance OR 1b. User access with write permission to an SCM repository where an automated build is triggered after a push/merge
|
||||
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.
|
||||
|
||||
## How it works
|
||||
## So funktioniert es
|
||||
|
||||
Fundamentally, almost everything behind the scenes works the same as a regular Jenkins instance running in a VM. The main difference is the overall architecture and how builds are managed inside an openshift (or kubernetes) cluster.
|
||||
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
|
||||
|
||||
When a build is triggered, it is first managed/orchestrated by the Jenkins master node then delegated to an agent/slave/worker. In this context, the master node is just a regular pod running in a namespace (which might be different that the one where workers run). The same applies for the workers/slaves, however they destroyed once the build finished whereas the master always stays up. Your build is usually run inside a pod, using a default pod template defined by the Jenkins admins.
|
||||
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.
|
||||
|
||||
### Triggering a build
|
||||
### Auslösen eines Builds
|
||||
|
||||
You have multiples main ways to trigger a build such as:
|
||||
Sie haben mehrere Hauptmöglichkeiten, um einen Build auszulösen, wie zum Beispiel:
|
||||
|
||||
1. You have UI access to Jenkins
|
||||
1. Sie haben UI-Zugriff auf Jenkins
|
||||
|
||||
A very easy and convenient way is to use the Replay functionality of an existing build. It allows you to replay a previously executed build while allowing you to update the groovy script. This requires privileges on a Jenkins folder and a predefined pipeline. If you need to be stealthy, you can delete your triggered builds if you have enough permission.
|
||||
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.
|
||||
|
||||
2. You have write access to the SCM and automated builds are configured via webhook
|
||||
2. Sie haben Schreibzugriff auf das SCM und automatisierte Builds sind über Webhook konfiguriert
|
||||
|
||||
You can just edit a build script (such as Jenkinsfile), commit and push (eventually create a PR if builds are only triggered on PR merges). Keep in mind that this path is very noisy and need elevated privileges to clean your tracks.
|
||||
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 override
|
||||
## Jenkins Build Pod YAML-Überschreibung
|
||||
|
||||
{{#ref}}
|
||||
openshift-jenkins-build-overrides.md
|
||||
{{#endref}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user