gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-07-29 07:00:29 -07:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['.github/pull_request_template.md', 'src/pentesting-cloud/az

Browse Source
This commit is contained in:
Translator
2024-12-31 19:00:04 +00:00
parent 7770a50092
commit 10e2881a9b
244 changed files with 8499 additions and 11339 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/pentesting-cloud/openshift-pentesting/openshift-scc.md
+21 -31
View File
@@ -1,36 +1,35 @@
# Openshift - SCC
**The original author of this page is** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
**Originalni autor ove stranice je** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
## Definition
## Definicija
In the context of OpenShift, SCC stands for **Security Context Constraints**. Security Context Constraints are policies that control permissions for pods running on OpenShift clusters. They define the security parameters under which a pod is allowed to run, including what actions it can perform and what resources it can access.
U kontekstu OpenShift-a, SCC označava **Security Context Constraints**. Security Context Constraints su politike koje kontrolišu dozvole za podove koji rade na OpenShift klasterima. One definišu bezbednosne parametre pod kojima je podu dozvoljeno da radi, uključujući koje akcije može da izvrši i koje resurse može da pristupi.
SCCs help administrators enforce security policies across the cluster, ensuring that pods are running with appropriate permissions and adhering to organizational security standards. These constraints can specify various aspects of pod security, such as:
SCC pomažu administratorima da sprovode bezbednosne politike širom klastera, osiguravajući da podovi rade sa odgovarajućim dozvolama i pridržavaju se organizacionih bezbednosnih standarda. Ove restrikcije mogu specificirati različite aspekte bezbednosti poda, kao što su:
1. Linux capabilities: Limiting the capabilities available to containers, such as the ability to perform privileged actions.
2. SELinux context: Enforcing SELinux contexts for containers, which define how processes interact with resources on the system.
3. Read-only root filesystem: Preventing containers from modifying files in certain directories.
4. Allowed host directories and volumes: Specifying which host directories and volumes a pod can mount.
5. Run as UID/GID: Specifying the user and group IDs under which the container process runs.
6. Network policies: Controlling network access for pods, such as restricting egress traffic.
1. Linux sposobnosti: Ograničavanje sposobnosti dostupnih kontejnerima, kao što je sposobnost izvršavanja privilegovanih akcija.
2. SELinux kontekst: Sprovođenje SELinux konteksta za kontejnere, koji definiše kako procesi interaguju sa resursima na sistemu.
3. Read-only root filesystem: Sprečavanje kontejnera da modifikuju datoteke u određenim direktorijumima.
4. Dozvoljeni host direktorijumi i volumeni: Specifikovanje koji host direktorijumi i volumeni mogu biti montirani od strane poda.
5. Run as UID/GID: Specifikovanje korisničkih i grupnih ID-ova pod kojima proces kontejnera radi.
6. Mrežne politike: Kontrolisanje mrežnog pristupa za podove, kao što je ograničavanje izlaznog saobraćaja.
By configuring SCCs, administrators can ensure that pods are running with the appropriate level of security isolation and access controls, reducing the risk of security vulnerabilities or unauthorized access within the cluster.
Konfigurišući SCC, administratori mogu osigurati da podovi rade sa odgovarajućim nivoom bezbednosne izolacije i kontrola pristupa, smanjujući rizik od bezbednosnih ranjivosti ili neovlašćenog pristupa unutar klastera.
Basically, every time a pod deployment is requested, an admission process is executed as the following:
U suštini, svaki put kada se zatraži implementacija poda, izvršava se proces prijema kao što je sledeće:
<figure><img src="../../images/Managing SCCs in OpenShift-1.png" alt=""><figcaption></figcaption></figure>
This additional security layer by default prohibits the creation of privileged pods, mounting of the host file system, or setting any attributes that could lead to privilege escalation.
Ova dodatna bezbednosna sloj po defaultu zabranjuje kreiranje privilegovanih podova, montiranje host fajl sistema ili postavljanje bilo kojih atributa koji bi mogli dovesti do eskalacije privilegija.
{{#ref}}
../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/pod-escape-privileges.md
{{#endref}}
## List SCC
To list all the SCC with the Openshift Client :
## Lista SCC
Da biste naveli sve SCC sa Openshift klijentom:
```bash
$ oc get scc #List all the SCCs
@@ -38,25 +37,20 @@ $ oc auth can-i --list | grep securitycontextconstraints #Which scc user can use
$ oc describe scc $SCC #Check SCC definitions
```
Svi korisnici imaju pristup podrazumevanju SCC "**restricted**" i "**restricted-v2**" koji su najstroži SCC-ovi.
All users have access the default SCC "**restricted**" and "**restricted-v2**" which are the strictest SCCs.
## Use SCC
The SCC used for a pod is defined inside an annotation :
## Koristite SCC
SCC koji se koristi za pod definisan je unutar anotacije :
```bash
$ oc get pod MYPOD -o yaml | grep scc
openshift.io/scc: privileged
openshift.io/scc: privileged
```
When a user has access to multiple SCCs, the system will utilize the one that aligns with the security context values. Otherwise, it will trigger a forbidden error.
Kada korisnik ima pristup više SCC-ova, sistem će koristiti onaj koji se usklađuje sa vrednostima bezbednosnog konteksta. U suprotnom, biće pokrenuta greška zabranjeno.
```bash
$ oc apply -f evilpod.yaml #Deploy a privileged pod
Error from server (Forbidden): error when creating "evilpod.yaml": pods "evilpod" is forbidden: unable to validate against any security context constrain
Error from server (Forbidden): error when creating "evilpod.yaml": pods "evilpod" is forbidden: unable to validate against any security context constrain
```
## SCC Bypass
{{#ref}}
@@ -66,7 +60,3 @@ openshift-privilege-escalation/openshift-scc-bypass.md
## References
- [https://www.redhat.com/en/blog/managing-sccs-in-openshift](https://www.redhat.com/en/blog/managing-sccs-in-openshift)