mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-01-18 23:55:38 -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/)
|
||||
**Die oorspronklike skrywer van hierdie bladsy is** [**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
|
||||
Hierdie bladsy gee 'n paar leidrade oor hoe jy 'n Jenkins-instantie wat in 'n Openshift (of Kubernetes) kluster loop, kan aanval.
|
||||
|
||||
## Disclaimer
|
||||
|
||||
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/)
|
||||
'n Jenkins-instantie kan in beide Openshift of Kubernetes klusters ontplooi word. Afhangende van jou konteks, mag jy enige getoonde payload, yaml of tegniek moet aanpas. Vir meer inligting oor die aanval op Jenkins kan jy [hierdie bladsy](../../../pentesting-ci-cd/jenkins-security/) kyk.
|
||||
|
||||
## Prerequisites
|
||||
## Voorvereistes
|
||||
|
||||
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. Gebruikers toegang in 'n Jenkins-instantie OF 1b. Gebruikers toegang met skryfregte tot 'n SCM-repositori waar 'n geoutomatiseerde bou geaktiveer word na 'n push/merge.
|
||||
|
||||
## How it works
|
||||
## Hoe dit werk
|
||||
|
||||
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.
|
||||
Fundamenteel werk byna alles agter die skerms dieselfde as 'n gewone Jenkins-instantie wat in 'n VM loop. Die hoofverskil is die algehele argitektuur en hoe boue binne 'n openshift (of kubernetes) kluster bestuur word.
|
||||
|
||||
### Builds
|
||||
### Boue
|
||||
|
||||
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.
|
||||
Wanneer 'n bou geaktiveer word, word dit eers bestuur/georkestreer deur die Jenkins meesterknoop en dan gedelegeer aan 'n agent/slave/werker. In hierdie konteks is die meesterknoop net 'n gewone pod wat in 'n naamruimte loop (wat dalk anders kan wees as die een waar werkers loop). Dieselfde geld vir die werkers/slaves, egter word hulle vernietig sodra die bou klaar is terwyl die meester altyd aanhou loop. Jou bou word gewoonlik binne 'n pod uitgevoer, met 'n standaard pod-sjabloon wat deur die Jenkins-administrateurs gedefinieer is.
|
||||
|
||||
### Triggering a build
|
||||
### Aktivering van 'n bou
|
||||
|
||||
You have multiples main ways to trigger a build such as:
|
||||
Jy het verskeie hoofmaniere om 'n bou te aktiveer, soos:
|
||||
|
||||
1. You have UI access to Jenkins
|
||||
1. Jy het UI-toegang tot 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.
|
||||
'n Baie maklike en gerieflike manier is om die Replay-funksionaliteit van 'n bestaande bou te gebruik. Dit laat jou toe om 'n voorheen uitgevoerde bou te herhaal terwyl jy die groovy-skrip kan opdateer. Dit vereis voorregte op 'n Jenkins-gids en 'n vooraf gedefinieerde pyplyn. As jy stil wil wees, kan jy jou geaktiveerde boue verwyder as jy genoeg toestemming het.
|
||||
|
||||
2. You have write access to the SCM and automated builds are configured via webhook
|
||||
2. Jy het skryfregte tot die SCM en geoutomatiseerde boue is via webhook geconfigureer
|
||||
|
||||
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.
|
||||
Jy kan eenvoudig 'n bou-skrip (soos Jenkinsfile) redigeer, commit en push (eventueel 'n PR skep as boue slegs geaktiveer word op PR-merges). Hou in gedagte dat hierdie pad baie lawaaierig is en verhoogde voorregte benodig om jou spore skoon te maak.
|
||||
|
||||
## Jenkins Build Pod YAML override
|
||||
## Jenkins Bou Pod YAML oorskryding
|
||||
|
||||
{{#ref}}
|
||||
openshift-jenkins-build-overrides.md
|
||||
{{#endref}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user