# Openshift - SCC

**Die oorspronklike skrywer van hierdie bladsy is** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)

## 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 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:

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 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 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 bevoorregte eskalasie kan lei.

{{#ref}}
../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/pod-escape-privileges.md
{{#endref}}

## Lys SCC

Om al die SCC's met die Openshift-kliënt te lys:
```bash
$ oc get scc #List all the SCCs

$ 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.

## 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
```
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
```
## SCC Bypass

{{#ref}}
openshift-privilege-escalation/openshift-scc-bypass.md
{{#endref}}

## Verwysings

- [https://www.redhat.com/en/blog/managing-sccs-in-openshift](https://www.redhat.com/en/blog/managing-sccs-in-openshift)