Translated ['', 'src/pentesting-cloud/aws-security/aws-post-exploitation

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation/README.md

@@ -4,28 +4,28 @@
 
 ## EKS
 
-Kwa taarifa zaidi angalia
+Kwa habari zaidi angalia
 
 {{#ref}}
 ../../aws-services/aws-eks-enum.md
 {{#endref}}
 
-### Orodhesha klasta kutoka AWS Console
+### Enumerate the cluster from the AWS Console
 
-Ikiwa una ruhusa **`eks:AccessKubernetesApi`** unaweza **kuona vitu vya Kubernetes** kupitia AWS EKS console ([Learn more](https://docs.aws.amazon.com/eks/latest/userguide/view-workloads.html)).
+Ikiwa una ruhusa **`eks:AccessKubernetesApi`** unaweza **kuangalia Kubernetes objects** kupitia AWS EKS console ([Learn more](https://docs.aws.amazon.com/eks/latest/userguide/view-workloads.html)).
 
-### Unganisha kwenye AWS Kubernetes Cluster
+### Connect to AWS Kubernetes Cluster
 
 - Njia rahisi:
 ```bash
 # Generate kubeconfig
 aws eks update-kubeconfig --name aws-eks-dev
 ```
-- Njia sio rahisi hivyo:
+- Sio njia rahisi hivyo:
 
-Ikiwa unaweza **pata token** kwa kutumia **`aws eks get-token --name <cluster_name>`** lakini huna ruhusa za kupata taarifa za cluster (describeCluster), unaweza **andaa yako mwenyewe `~/.kube/config`**. Hata hivyo, ukishokuwa na token, bado unahitaji **url endpoint ya kuunganishia** (ikiwa umefanikiwa kupata JWT token kutoka kwa pod soma [here](aws-eks-post-exploitation/README.md#get-api-server-endpoint-from-a-jwt-token)) na **jina la cluster**.
+Ukifanikiwa **kupata token** kwa **`aws eks get-token --name <cluster_name>`** lakini huna ruhusa za kupata taarifa za cluster (describeCluster), unaweza **kuandaa `~/.kube/config` yako mwenyewe**. Hata hivyo, ukiwa na token, bado unahitaji **url endpoint ya kuunganisha** (ukifanikiwa kupata JWT token kutoka kwa pod soma [hapa](aws-eks-post-exploitation/README.md#get-api-server-endpoint-from-a-jwt-token)) na **jina la cluster**.
 
-Katika kesi yangu, sikuipata taarifa hiyo kwenye CloudWatch logs, lakini **niliikuta kwenye LaunchTemaplates userData** na **pia kwenye EC2 machines katika userData**. Unaweza kuona taarifa hii katika **userData** kwa urahisi, kwa mfano katika mfano ufuatao (jina la cluster lilikuwa cluster-name):
+Kwa upande wangu, sikupata taarifa kwenye CloudWatch logs, lakini **niliipata kwenye LaunchTemaplates userData** na pia **kwenye EC2 machines katika userData**. Unaweza kuona taarifa hii kwenye **userData** kwa urahisi, kwa mfano katika mfano ufuatao (jina la cluster lilikuwa cluster-name):
 ```bash
 API_SERVER_URL=https://6253F6CA47F81264D8E16FAA7A103A0D.gr7.us-east-1.eks.amazonaws.com
 
@@ -70,35 +70,55 @@ provideClusterInfo: false
 ```
 </details>
 
-### From AWS to Kubernetes
+### Kutoka AWS hadi Kubernetes
 
-The **muumba** wa **EKS cluster** atakuwa **DAIMA** na uwezo wa kuingia katika sehemu ya klasta ya **kubernetes** ya kundi **`system:masters`** (k8s admin). Wakati wa kuandika haya kuna **hakuna njia ya moja kwa moja** ya kupata **nani aliyeunda** klasta (unaweza kuangalia CloudTrail). Na **hakuna njia** ya **kuondoa** hiyo **idhini**.
+**Muumba** wa **EKS cluster** **DAIMA** ataweza kuingia kwenye sehemu ya kubernetes cluster ya group **`system:masters`** (k8s admin). Kufikia wakati huu wa kuandika, **hakuna njia ya moja kwa moja** ya kujua **nani aliunda** cluster hiyo (unaweza kuangalia CloudTrail). Na **hakuna njia** ya **kuondoa** **privilege** hiyo.
 
-Njia ya kuwapa ufikiaji kwa **K8s** kwa watumiaji au roles zaidi za **AWS IAM** ni kutumia **configmap** **`aws-auth`**.
+#### Abusing configmap
+
+Njia ya jadi ya kutoa **access to over K8s kwa AWS IAM users au roles zaidi** ni kutumia **configmap** **`aws-auth`**.
 
 > [!WARNING]
-> Hivyo basi, yeyote aliye na **write access** kwenye config map **`aws-auth`** ataweza **compromise the whole cluster**.
+> Kwa hivyo, yeyote aliye na **write access** kwenye config map **`aws-auth`** ataweza **kucompromise whole cluster**.
 
-Kwa maelezo zaidi kuhusu jinsi ya **grant extra privileges to IAM roles & users** katika **akaunti ile ile au tofauti** na jinsi ya **abuse** hii: [**privesc check this page**](../../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/index.html#aws-eks-aws-auth-configmaps).
+Kwa taarifa zaidi kuhusu jinsi ya **kutoa extra privileges kwa IAM roles & users** katika **account moja au tofauti** na jinsi ya **abuse** hili kwa [**privesc angalia ukurasa huu**](../../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/index.html#aws-eks-aws-auth-configmaps).
 
-Angalia pia [**this awesome**](https://blog.lightspin.io/exploiting-eks-authentication-vulnerability-in-aws-iam-authenticator) **chapisho hili ili kujifunza jinsi authentication IAM -> Kubernetes inavyofanya kazi**.
+Angalia pia[ **this awesome**](https://blog.lightspin.io/exploiting-eks-authentication-vulnerability-in-aws-iam-authenticator) **post ili kujifunza jinsi authentication ya IAM -> Kubernetes inavyofanya kazi**.
 
-### From Kubernetes to AWS
+#### Abusing Access Entries
 
-Inawezekana kuruhusu **OpenID authentication for kubernetes service account** ili kuwaruhusu kuchukua roles kwenye AWS. Jifunze jinsi [**hii inavyofanya kazi kwenye ukurasa huu**](../../../kubernetes-security/kubernetes-pivoting-to-clouds.md#workflow-of-iam-role-for-service-accounts-1).
+AWS imeweka njia ya ziada ya kutoa IAM users access kwa Kubernetes cluster kupitia access entries. Ukiwa na permissions za `eks:CreateAccessEntry` na `eks:AssociateAccessPolicy`, unaweza pia kuweza kuteua Kubernetes administrator role kwa user wako au rol mahususi.
 
-### GET Api Server Endpoint from a JWT Token
+Kwanza, **unda access entry kwa user au role yako**:
+```
+aws eks create-access-entry --cluster-name <cluster_name> --region <region> --principal-arn <arn_from_your_user_or_role> --type STANDARD
+```
+Ukiwa na entry hiyo imeundwa, sasa unaweza kuwa na uwezo wa kuassign policy moja kwa moja kwake. Kuna built-in AWS policy inayoitwa *AmazonEKSClusterAdminPolicy* ambayo inaweza kutumika moja kwa moja. Kumbuka kwamba ikiwa environment yako ina custom policies nyingine zinazotoa pia elevated privileges katika EKS, unaweza kubadilisha `--policy-arn` kuwa yoyote kati ya hizo:
+```
+aws eks associate-access-policy --cluster-name <cluster_name> --region <region> --principal-arn <arn_from_your_user_or_role> --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy --access-scope type=cluster
+```
+Unaweza kutafuta sera hii katika nyaraka rasmi za AWS [**hapa**](https://docs.aws.amazon.com/eks/latest/userguide/access-policy-permissions.html#access-policy-permissions-amazoneksclusteradminpolicy)
 
-Kwa kutafsiri token ya JWT tunapata cluster id na pia region. ![image](https://github.com/HackTricks-wiki/hacktricks-cloud/assets/87022719/0e47204a-eea5-4fcb-b702-36dc184a39e9) Ikijulikana kuwa muundo wa kawaida wa EKS url ni
+Kuanzia hapa na kuendelea, sasa unaweza kuwa na uwezo wa kuomba token ya *k8s* na kuingiliana na cluster kama administrator:
+```
+aws eks get-token --cluster-name <cluster_name> --output json | jq -r '.status.token'
+```
+### Kutoka Kubernetes kwenda AWS
+
+Inawezekana kuruhusu **OpenID authentication kwa kubernetes service account** ili kuwawezesha kuassume roles katika AWS. Jifunze jinsi [**hii inavyofanya kazi katika ukurasa huu**](../../../kubernetes-security/kubernetes-pivoting-to-clouds.md#workflow-of-iam-role-for-service-accounts-1).
+
+### GET Api Server Endpoint kutoka kwa JWT Token
+
+Kwa ku-decode JWT token tunapata cluster id & pia region. ![image](https://github.com/HackTricks-wiki/hacktricks-cloud/assets/87022719/0e47204a-eea5-4fcb-b702-36dc184a39e9) Kujua kwamba standard format kwa EKS url ni
 ```bash
 https://<cluster-id>.<two-random-chars><number>.<region>.eks.amazonaws.com
 ```
-Sikupata nyaraka yoyote inayofafanua vigezo vya 'two chars' na 'number'. Lakini baada ya kufanya majaribio nimeona hizi zikirudiwa mara kwa mara:
+Sikupata nyaraka zozote zinazofafanua vigezo vya 'two chars' na 'number'. Lakini baada ya kufanya baadhi ya majaribio kwa niaba yangu, naona vinajirudia hivi:
 
 - gr7
 - yl4
 
-Vivyo hivyo, ni chars 3 tu; tunaweza bruteforce. Tumia script iliyo hapa chini kuzalisha orodha
+Hata hivyo, ni chars 3 tu, tunaweza kuzib bruteforce. Tumia script iliyo hapa chini kwa kutengeneza list
 ```python
 from itertools import product
 from string import ascii_lowercase
@@ -114,30 +134,30 @@ for comb in product(letter_combinations, number_combinations)
 with open('out.txt', 'w') as f:
 f.write('\n'.join(result))
 ```
-Kisha kwa wfuzz
+Kisha kwa kutumia wfuzz
 ```bash
 wfuzz -Z -z file,out.txt --hw 0 https://<cluster-id>.FUZZ.<region>.eks.amazonaws.com
 ```
 > [!WARNING]
 > Kumbuka kubadilisha & .
 
-### Kuepuka CloudTrail
+### Bypass CloudTrail
 
-If an attacker obtains credentials of an AWS with **permission over an EKS**. If the attacker configures it's own **`kubeconfig`** (without calling **`update-kubeconfig`**) as explained previously, the **`get-token`** doesn't generate logs in Cloudtrail because it doesn't interact with the AWS API (it just creates the token locally).
+Ikiwa mshambulizi atapata credentials za AWS yenye **permission juu ya EKS**. Ikiwa mshambulizi anasanidi **`kubeconfig`** yake mwenyewe (bila kuita **`update-kubeconfig`**) kama ilivyoelezwa awali, **`get-token`** haitengenezi logs katika Cloudtrail kwa sababu haiingiliani na AWS API (huunda token locally tu).
 
-Hivyo wakati the attacker anazungumza na EKS cluster, **cloudtrail won't log anything related to the user being stolen and accessing it**.
+Kwa hiyo mshambulizi anapozungumza na EKS cluster, **cloudtrail haitalog kitu chochote kinachohusiana na user aliyeibiwa na kuipata**.
 
-Note that the **EKS cluster might have logs enabled** that will log this access (although, by default, they are disabled).
+Kumbuka kwamba **EKS cluster inaweza kuwa na logs zimewezeshwa** ambazo zitalog access hii (ingawa, kwa default, zimezimwa).
 
-### EKS Fidya?
+### EKS Ransom?
 
-By default the **user or role that created** a cluster is **ALWAYS going to have admin privileges** over the cluster. And that the only "secure" access AWS will have over the Kubernetes cluster.
+Kwa default **user au role iliyounda** cluster **DAIMA** itakuwa na admin privileges juu ya cluster. Na huo ndio "secure" access pekee ambayo AWS itakuwa nayo juu ya Kubernetes cluster.
 
-So, if an **attacker compromises a cluster using fargate** and **removes all the other admins** and d**eletes the AWS user/role that created** the Cluster, ~~the attacker could have **ransomed the cluste**~~**r**.
+Kwa hiyo, ikiwa **mshambulizi anahatarisha cluster kwa kutumia fargate** na **anaondoa admin wengine wote** na d**eletes AWS user/role iliyounda** Cluster, ~~mshambulizi angeweza **kuiteka nyara cluster**~~**r**.
 
 > [!TIP]
-> Kumbuka kwamba ikiwa cluster ilikuwa ikitumia **EC2 VMs**, inawezekana kupata Admin privileges kutoka kwa **Node** na kurejesha cluster.
+> Kumbuka kwamba ikiwa cluster ilikuwa ikitumia **EC2 VMs**, inaweza kuwa inawezekana kupata Admin privileges kutoka kwa **Node** na kurejesha cluster.
 >
-> Kwa kweli, If the cluster is using Fargate you could EC2 nodes or move everything to EC2 to the cluster and recover it accessing the tokens in the node.
+> Kwa kweli, ikiwa cluster inatumia Fargate unaweza kutumia EC2 nodes au kuhamisha kila kitu kwenda EC2 kwenye cluster na kuirejesha kwa kufikia tokens kwenye node.
 
 {{#include ../../../../banners/hacktricks-training.md}}