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

src/pentesting-cloud/openshift-pentesting/openshift-scc.md

@@ -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)
-
-
-
-