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/README.md', 'src/pe
This commit is contained in:
Translator
@@ -6,7 +6,7 @@
|
||||
openshift-basic-information.md
|
||||
{{#endref}}
|
||||
|
||||
## Sekuriteitskonteks Beperkings
|
||||
## Sekuriteitskonteksbeperkings
|
||||
|
||||
{{#ref}}
|
||||
openshift-scc.md
|
||||
|
||||
@@ -2,15 +2,15 @@
|
||||
|
||||
**Die oorspronklike skrywer van hierdie bladsy is** [**Fares**](https://www.linkedin.com/in/fares-siala/)
|
||||
|
||||
Hierdie bladsy gee 'n paar leidrade oor hoe jy 'n Jenkins-instantie wat in 'n Openshift (of Kubernetes) kluster loop, kan aanval.
|
||||
Hierdie bladsy gee 'n paar riglyne oor hoe jy 'n Jenkins-instantie wat in 'n Openshift (of Kubernetes) kluster loop, kan aanval.
|
||||
|
||||
## Disclaimer
|
||||
## Vrywaring
|
||||
|
||||
'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.
|
||||
|
||||
## Voorvereistes
|
||||
|
||||
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.
|
||||
1a. Gebruikers toegang in 'n Jenkins-instantie OF 1b. Gebruikers toegang met skryfrechten tot 'n SCM-repositori waar 'n geoutomatiseerde bou geaktiveer word na 'n push/merge.
|
||||
|
||||
## Hoe dit werk
|
||||
|
||||
@@ -20,19 +20,19 @@ Fundamenteel werk byna alles agter die skerms dieselfde as 'n gewone Jenkins-ins
|
||||
|
||||
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.
|
||||
|
||||
### Aktivering van 'n bou
|
||||
### Om 'n bou te aktiveer
|
||||
|
||||
Jy het verskeie hoofmaniere om 'n bou te aktiveer, soos:
|
||||
|
||||
1. Jy het UI-toegang tot Jenkins
|
||||
|
||||
'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.
|
||||
'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 diskreet moet wees, kan jy jou geaktiveerde boue verwyder as jy genoeg toestemming het.
|
||||
|
||||
2. Jy het skryfregte tot die SCM en geoutomatiseerde boue is via webhook geconfigureer
|
||||
2. Jy het skryfrechten tot die SCM en geoutomatiseerde boue is via webhook geconfigureer
|
||||
|
||||
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 Bou Pod YAML oorskryding
|
||||
## Jenkins Bou Pod YAML oorskrywing
|
||||
|
||||
{{#ref}}
|
||||
openshift-jenkins-build-overrides.md
|
||||
|
||||
@@ -1,14 +1,14 @@
|
||||
# Jenkins in Openshift - build pod overrides
|
||||
# Jenkins in Openshift - boude pod oorskrywings
|
||||
|
||||
**Die oorspronklike skrywer van hierdie bladsy is** [**Fares**](https://www.linkedin.com/in/fares-siala/)
|
||||
|
||||
## 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.
|
||||
## Kubernetes-inprop vir Jenkins
|
||||
Hierdie inprop 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 bou pod te oorskry.
|
||||
|
||||
## Kernfunksionaliteit
|
||||
|
||||
Hierdie plugin bied buigsaamheid aan ontwikkelaars wanneer hulle hul kode in 'n geskikte omgewing bou.
|
||||
Hierdie inprop bied buigsaamheid aan ontwikkelaars wanneer hulle hul kode in 'n geskikte omgewing bou.
|
||||
```groovy
|
||||
podTemplate(yaml: '''
|
||||
apiVersion: v1
|
||||
@@ -34,9 +34,9 @@ sh 'mvn -B -ntp clean install'
|
||||
}
|
||||
}
|
||||
```
|
||||
## Sommige misbruik wat pod yaml oorskry gebruik
|
||||
## Sommige misbruik wat pod yaml oorskrywing benut
|
||||
|
||||
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.
|
||||
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
|
||||
@@ -93,7 +93,7 @@ sh 'env'
|
||||
}
|
||||
}
|
||||
```
|
||||
Voorbeeld om die naamruimte van die pod te oortref
|
||||
Voorbeeld om die naamruimte van die pod te oorskry
|
||||
```groovy
|
||||
pipeline {
|
||||
stages {
|
||||
@@ -170,16 +170,16 @@ Vraag jouself die volgende vrae:
|
||||
|
||||
- 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?
|
||||
- Kan ek verder ander bou pods opnoem?
|
||||
- Van 'n gecompromitteerde sa, kan ek opdragte op die meester node/pod uitvoer?
|
||||
- Kan ek die kluster verder opnoem om elders te pivot?
|
||||
- Kan ek verder die kluster opnoem om elders te pivot?
|
||||
- Watter SCC is toegepas?
|
||||
|
||||
Jy kan uitvind watter oc/kubectl opdragte om uit te reik [hier](../openshift-basic-information.md) en [hier](../../kubernetes-security/kubernetes-enumeration.md).
|
||||
|
||||
### Moontlike privesc/pivoting scenario's
|
||||
### Moglike privesc/pivoting scenario's
|
||||
|
||||
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 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.
|
||||
|
||||
Met die onderstaande bou skrip kan jy beheer oor die _master-sa_ diensrekening neem en verder opnoem.
|
||||
@@ -215,15 +215,15 @@ sh 'oc --token=$token whoami'
|
||||
}
|
||||
}
|
||||
```
|
||||
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:
|
||||
Afhangende van jou toegang, moet jy óf jou aanval vanaf die bouskrip voortset, óf jy kan direk aanmeld as hierdie sa op die lopende kluster:
|
||||
```bash
|
||||
oc login --token=$token --server=https://apiserver.com:port
|
||||
```
|
||||
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.
|
||||
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 loop. 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 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)
|
||||
As die meester node pod nie binne 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 {
|
||||
|
||||
@@ -2,13 +2,13 @@
|
||||
|
||||
## Ontbrekende Diensrekening
|
||||
|
||||
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.
|
||||
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-eskalasie in die geval waar jy hulle kan skep. In hierdie geval sal jy in staat wees om die token van die nuut geskepte SA en die rol of SCC wat daarmee geassosieer is, te verkry. 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 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.
|
||||
In die vorige grafiek het ons verskeie AbsentProjecte 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.
|
||||
|
||||
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.
|
||||
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-eskalasie.
|
||||
|
||||
Die volgende voorbeeld toon 'n ontbrekende SA wat node-exporter SCC toegeken word:
|
||||
|
||||
|
||||
@@ -13,14 +13,14 @@ Standaard, SCC geld nie op die volgende projekte nie:
|
||||
- **openshift-infra**
|
||||
- **openshift**
|
||||
|
||||
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.
|
||||
As jy pods in 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 Etiket
|
||||
|
||||
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ê:
|
||||
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
|
||||
- Skep 'n Namespace en Skep 'n Pod in hierdie Namespace
|
||||
- Wysig 'n Namespace en Skep 'n Pod in hierdie Namespace
|
||||
```bash
|
||||
$ oc auth can-i create namespaces
|
||||
yes
|
||||
@@ -47,7 +47,7 @@ name: evil
|
||||
labels:
|
||||
openshift.io/run-level: 0
|
||||
```
|
||||
Nou, alle nuwe pods wat in die naamruimte geskep word, moet geen SCC hê nie.
|
||||
Nou mag alle nuwe pods wat in die naamruimte geskep word, nie enige SCC hê nie.
|
||||
|
||||
<pre class="language-bash"><code class="lang-bash"><strong>$ oc get pod -o yaml | grep 'openshift.io/scc'
|
||||
</strong><strong>$
|
||||
@@ -94,7 +94,7 @@ Nou het dit makliker geword om voorregte te verhoog om toegang tot die gasheerst
|
||||
|
||||
### Pasgemaakte etikette
|
||||
|
||||
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.
|
||||
Boonop, gebaseer op die teikenopstelling, kan sommige pasgemaakte etikette / annotasies op dieselfde manier as die vorige aanvalscenario gebruik word. Selfs al is dit nie gemaak vir nie, kan etikette gebruik word om toestemmings te gee, 'n spesifieke hulpbron te beperk of nie.
|
||||
|
||||
Probeer om na pasgemaakte etikette te soek as jy sommige hulpbronne kan lees. Hier is 'n lys van interessante hulpbronne:
|
||||
|
||||
@@ -107,15 +107,15 @@ Probeer om na pasgemaakte etikette te soek as jy sommige hulpbronne kan lees. Hi
|
||||
$ oc get pod -o yaml | grep labels -A 5
|
||||
$ oc get namespace -o yaml | grep labels -A 5
|
||||
```
|
||||
## Lys alle bevoorregte naamruimtes
|
||||
## Lys al die bevoorregte name ruimtes
|
||||
```bash
|
||||
$ oc get project -o yaml | grep 'run-level' -b5
|
||||
```
|
||||
## Gevorderde uitbuiting
|
||||
|
||||
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, soos vroeër gedemonstreer, kan dit 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.
|
||||
|
||||
Egter, versagtingsmaatreëls soos **Open Policy Agent GateKeeper** kan voorkom dat gebruikers hierdie etiket stel.
|
||||
Daarom kan mitigasie-maatreëls soos **Open Policy Agent GateKeeper** voorkom dat gebruikers hierdie etiket stel.
|
||||
|
||||
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.**
|
||||
|
||||
|
||||
@@ -34,7 +34,7 @@ In enige naamruimte, as jy die pipeline diensrekening token kan kry, sal jy in s
|
||||
|
||||
### 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:
|
||||
Die probleem is dat die standaard scc wat die pipeline sa kan gebruik, gebruikersbeheerbaar is. Dit kan gedoen word met 'n etiket in die naamruimte definisie. Byvoorbeeld, as ek 'n naamruimte kan skep met die volgende yaml definisie:
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Namespace
|
||||
@@ -47,7 +47,7 @@ Die tekton-operateur sal aan die pyplyn-diensrekening in `test-namespace` die ve
|
||||
|
||||
### Die oplossing
|
||||
|
||||
Tekton dokumente oor hoe om die oortreding van scc te beperk deur 'n etiket in die `TektonConfig` objek by te voeg.
|
||||
Tekton dokumenteer 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/
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## Definisie
|
||||
|
||||
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.
|
||||
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 toegang.
|
||||
|
||||
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:
|
||||
|
||||
@@ -13,15 +13,15 @@ SCC's help administrateurs om sekuriteitsbeleid oor die kluster af te dwing, wat
|
||||
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.
|
||||
6. Netwerkbeleide: Beheer van netwerktoegang vir pods, soos die beperking van uitgaande verkeer.
|
||||
|
||||
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.
|
||||
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 ongeoorloofde toegang binne die kluster verminder.
|
||||
|
||||
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>
|
||||
|
||||
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.
|
||||
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 bevoorregte eskalasie kan lei.
|
||||
|
||||
{{#ref}}
|
||||
../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/pod-escape-privileges.md
|
||||
@@ -41,7 +41,7 @@ Alle gebruikers het toegang tot die standaard SCC "**restricted**" en "**restric
|
||||
|
||||
## Gebruik SCC
|
||||
|
||||
Die SCC wat vir 'n pod gebruik word, is binne 'n annotasie gedefinieer :
|
||||
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
|
||||
|
||||
Reference in New Issue
Block a user