mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-04 11:47:21 -07:00
Translated ['.github/pull_request_template.md', 'src/README.md', 'src/pe
This commit is contained in:
Translator
@@ -23,11 +23,11 @@ Da biste se prijavili koristeći CLI:
|
||||
oc login -u=<username> -p=<password> -s=<server>
|
||||
oc login -s=<server> --token=<bearer token>
|
||||
```
|
||||
### **OpenShift - Ograničenja konteksta bezbednosti** <a href="#a94e" id="a94e"></a>
|
||||
### **OpenShift - Ograničenja bezbednosnog konteksta** <a href="#a94e" id="a94e"></a>
|
||||
|
||||
Pored [RBAC resursa](https://docs.openshift.com/container-platform/3.11/architecture/additional_concepts/authorization.html#architecture-additional-concepts-authorization) koji kontrolišu šta korisnik može da radi, OpenShift Container Platform pruža _ograničenja konteksta bezbednosti_ (SCC) koja kontrolišu akcije koje pod može da izvrši i šta ima mogućnost da pristupi.
|
||||
Pored [RBAC resursa](https://docs.openshift.com/container-platform/3.11/architecture/additional_concepts/authorization.html#architecture-additional-concepts-authorization) koji kontrolišu šta korisnik može da radi, OpenShift Container Platform pruža _ograničenja bezbednosnog konteksta_ (SCC) koja kontrolišu akcije koje pod može da izvrši i šta ima mogućnost da pristupi.
|
||||
|
||||
SCC je objekat politike koji ima posebna pravila koja odgovaraju samoj infrastrukturi, za razliku od RBAC-a koji ima pravila koja odgovaraju Platformi. Pomaže nam da definišemo koje Linux funkcije kontrole pristupa kontejner treba da može da zahteva/izvrši. Primer: Linux sposobnosti, SECCOMP profili, Montiranje lokalnih direktorijuma, itd.
|
||||
SCC je objekat politike koji ima posebna pravila koja odgovaraju samoj infrastrukturi, za razliku od RBAC-a koji ima pravila koja odgovaraju Platformi. Pomaže nam da definišemo koje Linux funkcije kontrole pristupa kontejner treba da može da zahteva/izvrši. Primer: Linux mogućnosti, SECCOMP profili, Montiranje lokalnih direktorijuma, itd.
|
||||
|
||||
{{#ref}}
|
||||
openshift-scc.md
|
||||
|
||||
@@ -6,19 +6,19 @@ Ova stranica daje nekoliko smernica o tome kako možete napasti Jenkins instancu
|
||||
|
||||
## Odricanje od odgovornosti
|
||||
|
||||
Jenkins instanca može biti postavljena u Openshift ili Kubernetes klasteru. U zavisnosti od vašeg konteksta, možda ćete morati da prilagodite bilo koji prikazani payload, yaml ili tehniku. Za više informacija o napadu na Jenkins možete pogledati [ovu stranicu](../../../pentesting-ci-cd/jenkins-security/)
|
||||
Jenkins instanca može biti postavljena u Openshift ili Kubernetes klasteru. U zavisnosti od vašeg konteksta, možda ćete morati da prilagodite bilo koji prikazani payload, yaml ili tehniku. Za više informacija o napadu na Jenkins možete pogledati [ovu stranicu](../../../pentesting-ci-cd/jenkins-security/).
|
||||
|
||||
## Preduslovi
|
||||
|
||||
1a. Korisnički pristup u Jenkins instanci ILI 1b. Korisnički pristup sa dozvolom za pisanje na SCM repozitorijum gde se automatska izgradnja pokreće nakon push/merge.
|
||||
1a. Korisnički pristup u Jenkins instanci ILI 1b. Korisnički pristup sa pravima pisanja na SCM repozitorijumu gde se automatska izgradnja pokreće nakon push/merge.
|
||||
|
||||
## Kako to funkcioniše
|
||||
|
||||
Fundamentalno, gotovo sve iza kulisa funkcioniše isto kao i redovna Jenkins instanca koja radi u VM-u. Glavna razlika je u ukupnoj arhitekturi i načinu na koji se izgradnje upravljaju unutar Openshift (ili Kubernetes) klastera.
|
||||
Fundamentalno, gotovo sve iza scene funkcioniše isto kao i redovna Jenkins instanca koja radi u VM-u. Glavna razlika je u ukupnoj arhitekturi i načinu na koji se izgradnje upravljaju unutar Openshift (ili Kubernetes) klastera.
|
||||
|
||||
### Izgradnje
|
||||
|
||||
Kada se izgradnja pokrene, prvo njome upravlja/orchestrira Jenkins master čvor, a zatim se delegira agentu/slavi/radniku. U ovom kontekstu, master čvor je samo redovni pod koji radi u namespace-u (koji može biti različit od onog gde radnici rade). Isto važi i za radnike/slave, međutim oni se uništavaju kada se izgradnja završi, dok master uvek ostaje aktivan. Vaša izgradnja se obično pokreće unutar poda, koristeći pod šablon koji su definisali Jenkins administratori.
|
||||
Kada se izgradnja pokrene, prvo njome upravlja/orchestrira Jenkins master čvor, a zatim se delegira agentu/slavi/radniku. U ovom kontekstu, master čvor je samo redovan pod koji radi u namespace-u (koji može biti različit od onog gde radnici rade). Isto važi i za radnike/slave, međutim oni se uništavaju kada se izgradnja završi, dok master uvek ostaje aktivan. Vaša izgradnja se obično pokreće unutar poda, koristeći pod šablon koji su definisali Jenkins administratori.
|
||||
|
||||
### Pokretanje izgradnje
|
||||
|
||||
@@ -26,7 +26,7 @@ Imate više glavnih načina za pokretanje izgradnje, kao što su:
|
||||
|
||||
1. Imate UI pristup Jenkins-u
|
||||
|
||||
Veoma lak i praktičan način je korišćenje Replay funkcionalnosti postojeće izgradnje. Omogućava vam da ponovo pokrenete prethodno izvršenu izgradnju dok vam omogućava da ažurirate groovy skriptu. Ovo zahteva privilegije na Jenkins folderu i unapred definisanu pipeline. Ako trebate biti diskretni, možete obrisati svoje pokrenute izgradnje ako imate dovoljno dozvola.
|
||||
Veoma lak i praktičan način je korišćenje Replay funkcionalnosti postojeće izgradnje. Omogućava vam da ponovo pokrenete prethodno izvršenu izgradnju dok vam omogućava da ažurirate groovy skriptu. Ovo zahteva privilegije na Jenkins folderu i unapred definisanu pipeline. Ako trebate biti diskretni, možete obrisati svoje pokrenute izgradnje ako imate dovoljno prava.
|
||||
|
||||
2. Imate pristup za pisanje na SCM i automatske izgradnje su konfigurirane putem webhook-a
|
||||
|
||||
|
||||
+15
-15
@@ -1,10 +1,10 @@
|
||||
# Jenkins u Openshift-u - preklapanje build pod-a
|
||||
# Jenkins u Openshift-u - prepravke build pod-a
|
||||
|
||||
**Originalni autor ove stranice je** [**Fares**](https://www.linkedin.com/in/fares-siala/)
|
||||
|
||||
## Kubernetes plugin za Jenkins
|
||||
Ovaj plugin je uglavnom odgovoran za osnovne funkcije Jenkinsa unutar openshift/kubernetes klastera. Zvanična dokumentacija [ovde](https://plugins.jenkins.io/kubernetes/)
|
||||
Nudi nekoliko funkcionalnosti kao što je mogućnost za programere da preklapaju neke podrazumevane konfiguracije jenkins build pod-a.
|
||||
Ovaj plugin je uglavnom odgovoran za osnovne funkcije Jenkins-a unutar openshift/kubernetes klastera. Zvanična dokumentacija [ovde](https://plugins.jenkins.io/kubernetes/)
|
||||
Nudi nekoliko funkcionalnosti kao što je mogućnost za programere da preprave neke podrazumevane konfiguracije jenkins build pod-a.
|
||||
|
||||
## Osnovna funkcionalnost
|
||||
|
||||
@@ -34,9 +34,9 @@ sh 'mvn -B -ntp clean install'
|
||||
}
|
||||
}
|
||||
```
|
||||
## Neka zloupotreba korišćenjem pod yaml override
|
||||
## Neka zloupotrebe koriste pod yaml override
|
||||
|
||||
Međutim, može se zloupotrebiti da se koristi bilo koja dostupna slika kao što je Kali Linux i izvrši proizvoljne komande koristeći unapred instalirane alate iz te slike.
|
||||
Međutim, može se zloupotrebiti da se koristi bilo koja dostupna slika kao što je Kali Linux i izvrše proizvoljne komande koristeći unapred instalirane alate iz te slike.
|
||||
U sledećem primeru možemo eksfiltrirati token serviceaccount-a pokrenutog poda.
|
||||
```groovy
|
||||
podTemplate(yaml: '''
|
||||
@@ -94,7 +94,7 @@ sh 'env'
|
||||
}
|
||||
}
|
||||
```
|
||||
Primer za prepisivanje imena prostora pod-a
|
||||
Primer za prepisivanje imenskog prostora pod-a
|
||||
```groovy
|
||||
pipeline {
|
||||
stages {
|
||||
@@ -128,7 +128,7 @@ sh 'env'
|
||||
}
|
||||
}
|
||||
```
|
||||
Još jedan primer koji pokušava da montira serviceaccount (koji može imati više dozvola od podrazumevanog, koji pokreće vašu izgradnju) na osnovu njegovog imena. Možda ćete morati da pogodite ili enumerišete postojeće serviceaccounts prvo.
|
||||
Još jedan primer koji pokušava da montira serviceaccount (koji može imati više dozvola od podrazumevanog, koji pokreće vašu izgradnju) na osnovu njegovog imena. Možda ćete prvo morati da pogodite ili enumerišete postojeće serviceaccounts.
|
||||
```groovy
|
||||
pipeline {
|
||||
stages {
|
||||
@@ -161,26 +161,26 @@ sh 'env'
|
||||
}
|
||||
}
|
||||
```
|
||||
Ista tehnika se primenjuje za pokušaj montiranja Sekreta. Krajnji cilj ovde bi bio da se otkrije kako da konfigurišete svoj pod build da efikasno pivotira ili dobije privilegije.
|
||||
Ista tehnika se primenjuje da se pokuša montirati Secret. Krajnji cilj ovde bi bio da se otkrije kako da konfigurišete svoj pod build da efikasno pivotirate ili dobijete privilegije.
|
||||
|
||||
## Idemo dalje
|
||||
|
||||
Kada se naviknete da se igrate s tim, iskoristite svoje znanje o Jenkinsu i Kubernetesu/Openshiftu da pronađete loše konfiguracije / zloupotrebe.
|
||||
Kada se naviknete da se igrate s tim, iskoristite svoje znanje o Jenkins-u i Kubernetes/Openshift-u da pronađete loše konfiguracije / zloupotrebe.
|
||||
|
||||
Postavite sebi sledeća pitanja:
|
||||
|
||||
- Koji servisni nalog se koristi za implementaciju build podova?
|
||||
- Koje uloge i dozvole ima? Da li može da čita sekrete imenskog prostora u kojem se trenutno nalazim?
|
||||
- Koje uloge i dozvole ima? Da li može da čita tajne prostora imena u kojem se trenutno nalazim?
|
||||
- Mogu li dalje da enumerišem druge build podove?
|
||||
- Sa kompromitovanim sa, mogu li da izvršavam komande na master čvoru/podu?
|
||||
- Mogu li dalje da enumerišem klaster da pivotiram negde drugde?
|
||||
- Da li mogu da izvršavam komande na master čvoru/podu iz kompromitovanog sa?
|
||||
- Mogu li dalje da enumerišem klaster da bih pivotirao negde drugde?
|
||||
- Koji SCC je primenjen?
|
||||
|
||||
Možete saznati koje oc/kubectl komande da izdate [ovde](../openshift-basic-information.md) i [ovde](../../kubernetes-security/kubernetes-enumeration.md).
|
||||
|
||||
### Mogući privesc/pivoting scenariji
|
||||
|
||||
Pretpostavimo da ste tokom vaše procene otkrili da se svi jenkins buildovi izvršavaju unutar imenskog prostora pod nazivom _worker-ns_. Utvrdili ste da je podrazumevajući servisni nalog pod nazivom _default-sa_ montiran na build podovima, međutim, nema mnogo dozvola osim pristupa za čitanje na nekim resursima, ali ste uspeli da identifikujete postojeći servisni nalog pod nazivom _master-sa_.
|
||||
Pretpostavimo da ste tokom vaše procene otkrili da se svi jenkins build-ovi izvršavaju unutar prostora imena pod nazivom _worker-ns_. Utvrdili ste da je pod default servisni nalog pod nazivom _default-sa_ montiran na build podovima, međutim, nema mnogo dozvola osim pristupa za čitanje na nekim resursima, ali ste uspeli da identifikujete postojeći servisni nalog pod nazivom _master-sa_.
|
||||
Takođe pretpostavimo da imate instaliranu oc komandu unutar pokrenutog build kontejnera.
|
||||
|
||||
Sa sledećim build skriptom možete preuzeti kontrolu nad _master-sa_ servisnim nalogom i dalje enumerisati.
|
||||
@@ -220,11 +220,11 @@ U zavisnosti od vašeg pristupa, ili treba da nastavite svoj napad iz skripte za
|
||||
```bash
|
||||
oc login --token=$token --server=https://apiserver.com:port
|
||||
```
|
||||
Ako ovaj sa ima dovoljno dozvola (kao što je pod/exec), takođe možete preuzeti kontrolu nad celom jenkins instancom izvršavanjem komandi unutar pod-a master čvora, ako se pokreće unutar istog imenskog prostora. Ovaj pod možete lako identifikovati putem njegovog imena i činjenice da mora montirati PVC (persistant volume claim) koji se koristi za čuvanje jenkins podataka.
|
||||
Ako ovaj sa ima dovoljno dozvola (kao što su pod/exec), takođe možete preuzeti kontrolu nad celim jenkins instance izvršavanjem komandi unutar pod-a master čvora, ako se pokreće unutar istog imenskog prostora. Ovaj pod možete lako identifikovati putem njegovog imena i činjenice da mora montirati PVC (persistant volume claim) koji se koristi za čuvanje jenkins podataka.
|
||||
```bash
|
||||
oc rsh pod_name -c container_name
|
||||
```
|
||||
U slučaju da master node pod ne radi unutar iste namespace kao radnici, možete pokušati slične napade ciljanjem master namespace. Pretpostavimo da se zove _jenkins-master_. Imajte na umu da serviceAccount master-sa treba da postoji u _jenkins-master_ namespace (i možda ne postoji u _worker-ns_ namespace)
|
||||
U slučaju da master node pod ne radi unutar iste namespace kao radnici, možete pokušati slične napade usmeravajući se na master namespace. Pretpostavimo da se zove _jenkins-master_. Imajte na umu da serviceAccount master-sa treba da postoji u _jenkins-master_ namespace (i možda ne postoji u _worker-ns_ namespace)
|
||||
```groovy
|
||||
pipeline {
|
||||
stages {
|
||||
|
||||
+2
-2
@@ -2,11 +2,11 @@
|
||||
|
||||
## Nedostajući servisni nalog
|
||||
|
||||
Dešava se da je klaster postavljen sa unapred konfigurisanom šablonom koja automatski postavlja Uloge, RoleBindings i čak SCC na servisni nalog koji još nije kreiran. To može dovesti do eskalacije privilegija u slučaju da ih možete kreirati. U ovom slučaju, mogli biste dobiti token novokreiranog SA i ulogu ili SCC povezanu s njim. Ista situacija se dešava kada je nedostajući SA deo nedostajućeg projekta; u ovom slučaju, ako možete kreirati projekat, a zatim i SA, dobijate Uloge i SCC povezane s njim.
|
||||
Dešava se da je klaster postavljen sa unapred konfigurisanom šablonom koja automatski postavlja Uloge, RoleBindings i čak SCC na servisni nalog koji još nije kreiran. To može dovesti do eskalacije privilegija u slučaju da ih možete kreirati. U tom slučaju, mogli biste dobiti token novokreiranog SA i ulogu ili SCC koji su povezani. Ista situacija se dešava kada je nedostajući SA deo nedostajućeg projekta, u tom slučaju, ako možete kreirati projekat, a zatim i SA, dobijate Uloge i SCC povezane.
|
||||
|
||||
<figure><img src="../../../images/openshift-missing-service-account-image1.png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Na prethodnom grafikonu imamo više AbsentProject, što znači više projekata koji se pojavljuju u Role Bindings ili SCC, ali još nisu kreirani u klasteru. U istom kontekstu imamo i AbsentServiceAccount.
|
||||
Na prethodnom grafikonu imamo više AbsentProject, što znači više projekata koji se pojavljuju u Role Bindings ili SCC, ali još nisu kreirani u klasteru. U istom smislu imamo i AbsentServiceAccount.
|
||||
|
||||
Ako možemo kreirati projekat i nedostajući SA u njemu, SA će naslediti Ulogu ili SCC koji su ciljali na AbsentServiceAccount. Što može dovesti do eskalacije privilegija.
|
||||
|
||||
|
||||
+9
-9
@@ -1,10 +1,10 @@
|
||||
# Openshift - SCC bypass
|
||||
|
||||
**The original author of this page is** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
|
||||
**Originalni autor ove stranice je** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
|
||||
|
||||
## Privileged Namespaces
|
||||
## Privilegovani Namespaces
|
||||
|
||||
Podrazumevano, SCC se ne primenjuje na sledeće projekte:
|
||||
Po defaultu, SCC se ne primenjuje na sledeće projekte:
|
||||
|
||||
- **default**
|
||||
- **kube-system**
|
||||
@@ -13,14 +13,14 @@ Podrazumevano, SCC se ne primenjuje na sledeće projekte:
|
||||
- **openshift-infra**
|
||||
- **openshift**
|
||||
|
||||
Ako implementirate podove unutar jednog od ovih prostora imena, nijedna SCC neće biti primenjena, što omogućava implementaciju privilegovanih podova ili montiranje datotečnog sistema domaćina.
|
||||
Ako implementirate podove unutar jednog od ovih namespaces, SCC se neće primenjivati, što omogućava implementaciju privilegovanih podova ili montiranje host fajl sistema.
|
||||
|
||||
## Namespace Label
|
||||
|
||||
Postoji način da se onemogući primena SCC na vašem podu prema RedHat dokumentaciji. Moraćete da imate najmanje jednu od sledećih dozvola:
|
||||
Postoji način da se onemogući primena SCC na vašem podu prema RedHat dokumentaciji. Biće vam potrebna najmanje jedna od sledećih dozvola:
|
||||
|
||||
- Kreirajte Namespace i kreirajte Pod u ovom Namespace-u
|
||||
- Uredite Namespace i kreirajte Pod u ovom Namespace-u
|
||||
- Kreirajte Namespace i kreirajte Pod u ovom Namespace
|
||||
- Uredite Namespace i kreirajte Pod u ovom Namespace
|
||||
```bash
|
||||
$ oc auth can-i create namespaces
|
||||
yes
|
||||
@@ -28,7 +28,7 @@ yes
|
||||
$ oc auth can-i patch namespaces
|
||||
yes
|
||||
```
|
||||
Specifična oznaka `openshift.io/run-level` omogućava korisnicima da zaobiđu SCC-e za aplikacije. Prema RedHat dokumentaciji, kada se ova oznaka koristi, nijedna SCC nije primenjena na sve podove unutar tog imenskog prostora, efikasno uklanjajući sve restrikcije.
|
||||
Specifična oznaka `openshift.io/run-level` omogućava korisnicima da zaobiđu SCC-e za aplikacije. Prema RedHat dokumentaciji, kada se ova oznaka koristi, nijedni SCC-i se ne primenjuju na sve podove unutar tog imenskog prostora, efikasno uklanjajući sve restrikcije.
|
||||
|
||||
<figure><img src="../../../images/Openshift-RunLevel4.png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
@@ -107,7 +107,7 @@ Pokušajte da potražite prilagođene oznake ako možete da pročitate neke resu
|
||||
$ oc get pod -o yaml | grep labels -A 5
|
||||
$ oc get namespace -o yaml | grep labels -A 5
|
||||
```
|
||||
## Lista svih privilegovanih imena prostora
|
||||
## Nabrojite sve privilegovane imenske prostore
|
||||
```bash
|
||||
$ oc get project -o yaml | grep 'run-level' -b5
|
||||
```
|
||||
|
||||
+5
-5
@@ -1,14 +1,14 @@
|
||||
# OpenShift - Tekton
|
||||
|
||||
**The original author of this page is** [**Haroun**](https://www.linkedin.com/in/haroun-al-mounayar-571830211)
|
||||
**Originalni autor ove stranice je** [**Haroun**](https://www.linkedin.com/in/haroun-al-mounayar-571830211)
|
||||
|
||||
### Šta je tekton
|
||||
|
||||
Prema dokumentaciji: _Tekton je moćan i fleksibilan open-source okvir za kreiranje CI/CD sistema, omogućavajući programerima da grade, testiraju i implementiraju aplikacije na različitim cloud provajderima i lokalnim sistemima._ I Jenkins i Tekton se mogu koristiti za testiranje, izgradnju i implementaciju aplikacija, međutim Tekton je Cloud Native. 
|
||||
|
||||
Sa Tekton-om, sve je predstavljeno YAML datotekama. Programeri mogu kreirati Prilagođene Resurse (CR) tipa `Pipelines` i odrediti više `Tasks` u njima koje žele da pokrenu. Da bi se pokrenuo Pipeline, moraju se kreirati resursi tipa `PipelineRun`.
|
||||
Sa Tekton-om, sve je predstavljeno YAML datotekama. Programeri mogu kreirati Custom Resources (CR) tipa `Pipelines` i odrediti više `Tasks` u njima koje žele da pokrenu. Da bi se pokrenula Pipeline, moraju biti kreirani resursi tipa `PipelineRun`.
|
||||
|
||||
Kada je tekton instaliran, kreira se servisni nalog (sa) pod nazivom pipeline u svakoj namespaces. Kada se Pipeline pokrene, pod će biti pokrenut koristeći ovaj sa pod nazivom `pipeline` da izvrši zadatke definisane u YAML datoteci.
|
||||
Kada je tekton instaliran, servisni nalog (sa) pod nazivom pipeline se kreira u svakoj namespaces. Kada se Pipeline pokrene, pod će biti pokrenut koristeći ovaj sa pod nazivom `pipeline` da izvrši zadatke definisane u YAML datoteci.
|
||||
|
||||
{{#ref}}
|
||||
https://tekton.dev/docs/getting-started/pipelines/
|
||||
@@ -30,11 +30,11 @@ openshift:
|
||||
scc:
|
||||
default: "pipelines-scc"
|
||||
```
|
||||
U bilo kojem namespace-u, ako možete dobiti token za servisni nalog pipeline-a, moći ćete da koristite `pipelines-scc`.
|
||||
U bilo kojem namespace-u, ako možete dobiti token servisnog naloga pipeline-a, moći ćete da koristite `pipelines-scc`.
|
||||
|
||||
### Problemi sa konfiguracijom
|
||||
|
||||
Problem je u tome što je podrazumevani scc koji može koristiti pipeline sa podložan kontroli korisnika. To se može uraditi korišćenjem oznake u definiciji namespace-a. Na primer, ako mogu da kreiram namespace sa sledećom yaml definicijom:
|
||||
Problem je u tome što je podrazumevani scc koji servisni nalog pipeline-a može koristiti pod kontrolom korisnika. To se može uraditi korišćenjem oznake u definiciji namespace-a. Na primer, ako mogu da kreiram namespace sa sledećom yaml definicijom:
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Namespace
|
||||
|
||||
@@ -4,16 +4,16 @@
|
||||
|
||||
## Definicija
|
||||
|
||||
U kontekstu OpenShift-a, SCC označava **Security Context Constraints**. Security Context Constraints su politike koje kontrolišu dozvole za podove koji rade na OpenShift klasterima. One definišu bezbednosne parametre pod kojima je podu dozvoljeno da radi, uključujući koje akcije može da izvrši i koje resurse može da pristupi.
|
||||
U kontekstu OpenShift-a, SCC označava **Security Context Constraints**. Security Context Constraints su politike koje kontrolišu dozvole za podove koji rade na OpenShift klasterima. One definišu bezbednosne parametre pod kojima je pod dozvoljeno da radi, uključujući koje akcije može da izvršava i koje resurse može da pristupa.
|
||||
|
||||
SCC pomažu administratorima da sprovode bezbednosne politike širom klastera, osiguravajući da podovi rade sa odgovarajućim dozvolama i pridržavaju se organizacionih bezbednosnih standarda. Ove restrikcije mogu specificirati različite aspekte bezbednosti poda, kao što su:
|
||||
SCC pomažu administratorima da sprovode bezbednosne politike širom klastera, osiguravajući da podovi rade sa odgovarajućim dozvolama i da se pridržavaju organizacionih bezbednosnih standarda. Ove restrikcije mogu specificirati različite aspekte bezbednosti poda, kao što su:
|
||||
|
||||
1. Linux sposobnosti: Ograničavanje sposobnosti dostupnih kontejnerima, kao što je sposobnost izvršavanja privilegovanih akcija.
|
||||
2. SELinux kontekst: Sprovođenje SELinux konteksta za kontejnere, koji definiše kako procesi interaguju sa resursima na sistemu.
|
||||
3. Read-only root filesystem: Sprečavanje kontejnera da modifikuju datoteke u određenim direktorijumima.
|
||||
4. Dozvoljeni host direktorijumi i volumeni: Specifikovanje koji host direktorijumi i volumeni mogu biti montirani od strane poda.
|
||||
5. Run as UID/GID: Specifikovanje korisničkih i grupnih ID-ova pod kojima proces kontejnera radi.
|
||||
6. Mrežne politike: Kontrolisanje mrežnog pristupa za podove, kao što je ograničavanje izlaznog saobraćaja.
|
||||
5. Pokreni kao UID/GID: Specifikovanje ID-eva korisnika i grupe pod kojima proces kontejnera radi.
|
||||
6. Mrežne politike: Kontrolisanje mrežnog pristupa za podove, kao što je ograničavanje egress saobraćaja.
|
||||
|
||||
Konfigurišući SCC, administratori mogu osigurati da podovi rade sa odgovarajućim nivoom bezbednosne izolacije i kontrola pristupa, smanjujući rizik od bezbednosnih ranjivosti ili neovlašćenog pristupa unutar klastera.
|
||||
|
||||
@@ -41,12 +41,12 @@ Svi korisnici imaju pristup podrazumevanju SCC "**restricted**" i "**restricted-
|
||||
|
||||
## Koristite SCC
|
||||
|
||||
SCC koji se koristi za pod definisan je unutar anotacije :
|
||||
SCC koji se koristi za pod definisan je unutar anotacije:
|
||||
```bash
|
||||
$ oc get pod MYPOD -o yaml | grep scc
|
||||
openshift.io/scc: privileged
|
||||
```
|
||||
Kada korisnik ima pristup više SCC-ova, sistem će koristiti onaj koji se usklađuje sa vrednostima bezbednosnog konteksta. U suprotnom, biće pokrenuta greška zabranjeno.
|
||||
Kada korisnik ima pristup više SCC-ova, sistem će koristiti onaj koji se usklađuje sa vrednostima sigurnosnog konteksta. U suprotnom, biće pokrenuta greška zabranjeno.
|
||||
```bash
|
||||
$ oc apply -f evilpod.yaml #Deploy a privileged pod
|
||||
Error from server (Forbidden): error when creating "evilpod.yaml": pods "evilpod" is forbidden: unable to validate against any security context constrain
|
||||
|
||||
Reference in New Issue
Block a user