Translated ['src/pentesting-cloud/kubernetes-security/kubernetes-pivotin

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

@@ -27,7 +27,7 @@ As jy 'n k8s-kluster binne GCP bestuur, wil jy waarskynlik hê dat 'n toepassing
 ```bash
 Copy codekubectl create serviceaccount <service-account-name>
 ```
-- Skep 'n Kubernetes Secret wat die geloofsbriewe van die GCP diensrekening bevat waartoe jy toegang tot die GKE-kluster wil verleen. Jy kan dit doen met die `gcloud` opdraglyn hulpmiddel, soos in die volgende voorbeeld getoon:
+- Skep 'n Kubernetes Secret wat die geloofsbriewe van die GCP diensrekening bevat wat jy toegang tot die GKE-kluster wil gee. Jy kan dit doen met die `gcloud` opdraglyn hulpmiddel, soos in die volgende voorbeeld getoon:
 ```bash
 Copy codegcloud iam service-accounts keys create <key-file-name>.json \
 --iam-account <gcp-service-account-email>
@@ -40,11 +40,11 @@ Copy codekubectl annotate serviceaccount <service-account-name> \
 iam.gke.io/gcp-service-account=<gcp-service-account-email>
 ```
 > [!WARNING]
-> In die **tweede stap** is die **bewyse van die GSA as geheim van die KSA** gestel. Dan, as jy daardie **geheim** van **binne** die **GKE** kluster kan **lees**, kan jy **eskaleer na daardie GCP diensrekening**.
+> In die **tweede stap** is die **bewyse van die GSA as geheim van die KSA** gestel. Dan, as jy **daardie geheim** van **binne** die **GKE** kluster kan **lees**, kan jy **eskaleer na daardie GCP diensrekening**.
 
 ### GKE Werklas Identiteit
 
-Met Werklas Identiteit kan ons 'n [Kubernetes diensrekening](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) konfigureer om op te tree as 'n [Google diensrekening](https://cloud.google.com/iam/docs/understanding-service-accounts). Pods wat met die Kubernetes diensrekening loop, sal outomaties as die Google diensrekening autentiseer wanneer hulle toegang tot Google Cloud API's verkry.
+Met Werklas Identiteit kan ons 'n [Kubernetes diensrekening](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) konfigureer om as 'n [Google diensrekening](https://cloud.google.com/iam/docs/understanding-service-accounts) op te tree. Pods wat met die Kubernetes diensrekening loop, sal outomaties as die Google diensrekening autentiseer wanneer hulle toegang tot Google Cloud API's verkry.
 
 Die **eerste reeks stappe** om hierdie gedrag te aktiveer, is om **Werklas Identiteit in GCP** te **aktiveer** ([**stappe**](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.
 
@@ -54,7 +54,7 @@ gcloud container clusters update <cluster_name> \
 --region=us-central1 \
 --workload-pool=<project-id>.svc.id.goog
 ```
-- **Skep/Opdate 'n nuwe nodepool** (Autopilot-klusters het dit nie nodig nie)
+- **Skep/Opdateer 'n nuwe nodepool** (Autopilot-klusters 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
@@ -126,7 +126,7 @@ gcloud auth activate-service-account --key-file=/var/run/secrets/google/service-
 > As 'n aanvaller binne K8s moet jy **soek na SAs** met die **`iam.gke.io/gcp-service-account` annotasie** 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 kluster te misbruik en te kyk of dit toegang het.\
 > Van GCP is dit altyd interessant om die bindings te enumerate en te weet **watter toegang jy aan SAs binne Kubernetes gee**.
 
-Dit is 'n skrip om maklik **oor al die pods** definisies **te iterer** terwyl jy soek na daardie **annotasie**:
+Dit is 'n skrip om maklik **oor al die pods** definisies **te iterer** op soek na daardie **annotasie**:
 ```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
@@ -139,11 +139,11 @@ done | grep -B 1 "gcp-service-account"
 ```
 ## AWS
 
-### Kiam & Kube2IAM (IAM rol vir Pods) <a href="#workflow-of-iam-role-for-service-accounts" id="workflow-of-iam-role-for-service-accounts"></a>
+### Kiam & Kube2IAM (IAM-rol vir Pods) <a href="#workflow-of-iam-role-for-service-accounts" id="workflow-of-iam-role-for-service-accounts"></a>
 
-'n (verouderde) manier om IAM Rol aan Pods te gee, is om 'n [**Kiam**](https://github.com/uswitch/kiam) of 'n [**Kube2IAM**](https://github.com/jtblin/kube2iam) **bediener** te gebruik. Basies moet jy 'n **daemonset** in jou kluster hardloop met 'n **soort bevoorregte IAM rol**. Hierdie daemonset sal die een wees wat toegang tot IAM rolle aan die pods wat dit nodig het, sal gee.
+'n (verouderde) manier om IAM-rolle aan Pods te gee, is om 'n [**Kiam**](https://github.com/uswitch/kiam) of 'n [**Kube2IAM**](https://github.com/jtblin/kube2iam) **bediener** te gebruik. Basies moet jy 'n **daemonset** in jou kluster laat loop met 'n **soort bevoorregte IAM-rol**. Hierdie daemonset sal die een wees wat toegang tot IAM-rolle aan die pods wat dit nodig het, sal gee.
 
-Eerstens moet jy **watter rolle binne die namespace toeganklik is, konfigureer**, en jy doen dit met 'n annotasie binne die namespace objek:
+Eerstens moet jy **watter rolle binne die naamruimte toeganklik is, konfigureer**, en jy doen dit met 'n annotasie binne die naamruimte objek:
 ```yaml:Kiam
 kind: Namespace
 metadata:
@@ -171,7 +171,7 @@ annotations:
 iam.amazonaws.com/role: reportingdb-reader
 ```
 > [!WARNING]
-> As 'n aanvaller, as jy **hierdie annotasies** in pods of namespaces of 'n kiam/kube2iam bediener wat loop (waarskynlik in kube-system) vind, kan jy **alle r**ole wat reeds **deur pods** gebruik word, en meer **naboots** (as jy toegang tot die AWS-rekening het, tel die rolle op).
+> As 'n aanvaller, as jy **hierdie annotasies** in pods of namespaces of 'n kiam/kube2iam bediener wat loop (waarskynlik in kube-system) vind, kan jy **alle r**ole wat reeds **deur pods** gebruik word, naboots en meer (as jy toegang het tot die AWS-rekening, tel die rolle op).
 
 #### Skep Pod met IAM Rol
 
@@ -236,7 +236,7 @@ aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789098:role/
 
 ### Vind Pods 'n SAs met IAM Rolle in die Kluster
 
-Dit is 'n skrip om maklik **oor al die pods en sas** definisies **te iterer** op soek na daardie **annotasie**:
+Dit is 'n skrip om maklik **oor al die pods en sas** definisies **te itereren** op soek na daardie **annotasie**:
 ```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
@@ -255,7 +255,7 @@ done | grep -B 1 "amazonaws.com"
 ```
 ### Node IAM Rol
 
-Die vorige afdeling was oor hoe om IAM Rolle met pods te steel, maar let daarop dat 'n **Node van die** K8s-kluster 'n **instansie binne die wolk** gaan wees. Dit beteken dat die Node hoogs waarskynlik 'n **nuwe IAM rol gaan hê wat jy kan steel** (_let daarop dat gewoonlik al die nodes van 'n K8s-kluster dieselfde IAM rol sal hê, so dit mag nie die moeite werd wees om op elke node te probeer kyk_).
+Die vorige afdeling was oor hoe om IAM Rolles met pods te steel, maar let daarop dat 'n **Node van die** K8s-kluster 'n **instansie binne die wolk** gaan wees. Dit beteken dat die Node hoogs waarskynlik 'n **nuwe IAM rol gaan hê wat jy kan steel** (_let daarop dat gewoonlik al die nodes van 'n K8s-kluster dieselfde IAM rol sal hê, so dit mag nie die moeite werd wees om op elke node te probeer kyk_).
 
 Daar is egter 'n belangrike vereiste om toegang tot die metadata-eindpunt vanaf die node te verkry, jy moet in die node wees (ssh-sessie?) of ten minste dieselfde netwerk hê:
 ```bash