# OpenShift - Jenkins

**The original author of this page 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

## 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/index.html)

## Prerequisites

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

## How it works

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.

### 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.

### Triggering a build

You have multiples main ways to trigger a build such as:

1. You have UI access to 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.

2. You have write access to the SCM and automated builds are configured via webhook

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.

## Jenkins Build Pod YAML override

{{#ref}}
openshift-jenkins-build-overrides.md
{{#endref}}



