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

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

@@ -34,19 +34,19 @@ Copy codegcloud iam service-accounts keys create <key-file-name>.json \
 kubectl create secret generic <secret-name> \
 --from-file=key.json=<key-file-name>.json
 ```
-- Collega il Secret di Kubernetes all'account di servizio di Kubernetes utilizzando il seguente comando:
+- Collega il Kubernetes Secret all'account di servizio Kubernetes utilizzando il seguente comando:
 ```bash
 Copy codekubectl annotate serviceaccount <service-account-name> \
 iam.gke.io/gcp-service-account=<gcp-service-account-email>
 ```
 > [!WARNING]
-> Nel **secondo passo** sono state impostate le **credenziali del GSA come segreto del KSA**. Quindi, se puoi **leggere quel segreto** dall'**interno** del cluster **GKE**, puoi **escalare a quel servizio account GCP**.
+> Nel **secondo passaggio** sono state impostate le **credenziali del GSA come segreto del KSA**. Quindi, se puoi **leggere quel segreto** dall'**interno** del cluster **GKE**, puoi **escalare a quel servizio account GCP**.
 
 ### Identità del Carico di Lavoro GKE
 
-Con l'Identità del Carico di Lavoro, possiamo configurare un[ account di servizio Kubernetes](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) per agire come un[ account di servizio Google](https://cloud.google.com/iam/docs/understanding-service-accounts). I pod che girano con l'account di servizio Kubernetes si autenticheranno automaticamente come l'account di servizio Google quando accedono alle API di Google Cloud.
+Con l'Identità del Carico di Lavoro, possiamo configurare un [Kubernetes service account](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) per agire come un [Google service account](https://cloud.google.com/iam/docs/understanding-service-accounts). I pod che girano con il Kubernetes service account si autenticheranno automaticamente come il Google service account quando accedono alle API di Google Cloud.
 
-La **prima serie di passi** per abilitare questo comportamento è **abilitare l'Identità del Carico di Lavoro in GCP** ([**passi**](https://medium.com/zeotap-customer-intelligence-unleashed/gke-workload-identity-a-secure-way-for-gke-applications-to-access-gcp-services-f880f4e74e8c)) e creare il SA GCP che vuoi che k8s impersoni.
+La **prima serie di passaggi** per abilitare questo comportamento è **abilitare l'Identità del Carico di Lavoro in GCP** ([**passaggi**](https://medium.com/zeotap-customer-intelligence-unleashed/gke-workload-identity-a-secure-way-for-gke-applications-to-access-gcp-services-f880f4e74e8c)) e creare il GCP SA che vuoi che k8s impersoni.
 
 - **Abilita l'Identità del Carico di Lavoro** su un nuovo cluster
 ```bash
@@ -126,7 +126,7 @@ gcloud auth activate-service-account --key-file=/var/run/secrets/google/service-
 > Come attaccante all'interno di K8s dovresti **cercare SAs** con l'**annotazione `iam.gke.io/gcp-service-account`** poiché indica che l'SA può accedere a qualcosa in GCP. Un'altra opzione sarebbe cercare di abusare di ogni KSA nel cluster e controllare se ha accesso.\
 > Da GCP è sempre interessante enumerare i binding e sapere **quale accesso stai dando agli SAs all'interno di Kubernetes**.
 
-Questo è uno script per **iterare facilmente su tutte le definizioni dei pod** **cercando** quella **annotazione**:
+Questo è uno script per **iterare facilmente su tutte le definizioni dei pod** **cercando** quell'**annotazione**:
 ```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
@@ -161,7 +161,7 @@ iam.amazonaws.com/allowed-roles: |
 ["role-arn"]
 name: default
 ```
-Una volta che il namespace è configurato con i ruoli IAM che i Pods possono avere, puoi **indicare il ruolo che desideri in ciascuna definizione del pod con qualcosa come**:
+Una volta che lo spazio dei nomi è configurato con i ruoli IAM che i Pod possono avere, puoi **indicare il ruolo che desideri in ciascuna definizione del pod con qualcosa come**:
 ```yaml:Kiam & Kube2iam
 kind: Pod
 metadata:
@@ -194,7 +194,7 @@ args: ["-c", "sleep 100000"]' | kubectl apply -f -
 ```
 ### IAM Role per gli Account di Servizio K8s tramite OIDC <a href="#workflow-of-iam-role-for-service-accounts" id="workflow-of-iam-role-for-service-accounts"></a>
 
-Questo è il **metodo raccomandato da AWS**.
+Questo è il **modo raccomandato da AWS**.
 
 1. Prima di tutto, è necessario [creare un provider OIDC per il cluster](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html).
 2. Poi si crea un ruolo IAM con i permessi di cui avrà bisogno l'SA.
@@ -234,7 +234,7 @@ aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789098:role/
 ../aws-security/aws-basic-information/aws-federation-abuse.md
 {{#endref}}
 
-### Trova Pods e SAs con Ruoli IAM nel Cluster
+### Trova Pods e SAs con IAM Roles nel Cluster
 
 Questo è uno script per **iterare facilmente su tutti i pod e le definizioni di sas** **cercando** quella **annotazione**:
 ```bash
@@ -263,7 +263,7 @@ kubectl run NodeIAMStealer --restart=Never -ti --rm --image lol --overrides '{"s
 ```
 ### Rubare il Token del Ruolo IAM
 
-In precedenza abbiamo discusso di come **allegare i Ruoli IAM ai Pod** o addirittura di come **fuggire al Nodo per rubare il Ruolo IAM** che l'istanza ha allegato ad esso.
+In precedenza abbiamo discusso di come **allegare i Ruoli IAM ai Pod** o addirittura di come **fuggire al Nodo per rubare il Ruolo IAM** che l'istanza ha ad esso allegato.
 
 Puoi utilizzare il seguente script per **rubare** le tue nuove e faticosamente guadagnate **credenziali del ruolo IAM**:
 ```bash