Translated ['.github/pull_request_template.md', 'src/README.md', 'src/pe

2026-01-06 17:53:37 -08:00 · 2025-01-02 00:01:28 +00:00
parent 4bcd54c1b6
commit c0ee8b41f2
215 changed files with 1371 additions and 1387 deletions
--- a/src/pentesting-cloud/kubernetes-security/kubernetes-basics.md
+++ b/src/pentesting-cloud/kubernetes-security/kubernetes-basics.md
@@ -11,7 +11,7 @@
 ### Was macht Kubernetes?

 - Ermöglicht das Ausführen von Containern in einer Container-Engine.
- Der Scheduler ermöglicht eine effiziente Planung von Containermissionen.
+- Der Scheduler ermöglicht eine effiziente Planung von Containern.
 - Hält Container am Leben.
 - Ermöglicht die Kommunikation zwischen Containern.
 - Ermöglicht Bereitstellungstechniken.
@@ -26,13 +26,13 @@
 - **Service**: Jeder Pod hat 1 interne **IP-Adresse** aus dem internen Bereich des Nodes. Er kann jedoch auch über einen Service exponiert werden. Der **Service hat ebenfalls eine IP-Adresse** und sein Ziel ist es, die Kommunikation zwischen Pods aufrechtzuerhalten, sodass, wenn einer ausfällt, der **neue Ersatz** (mit einer anderen internen IP) **über die gleiche IP des Services zugänglich ist**. Er kann als intern oder extern konfiguriert werden. Der Service fungiert auch als **Lastenausgleich, wenn 2 Pods mit demselben Service verbunden sind**.\
 Wenn ein **Service** **erstellt** wird, können Sie die Endpunkte jedes Services mit `kubectl get endpoints` finden.
 - **Kubelet**: Primärer Node-Agent. Die Komponente, die die Kommunikation zwischen Node und kubectl herstellt und nur Pods ausführen kann (über den API-Server). Der Kubelet verwaltet keine Container, die nicht von Kubernetes erstellt wurden.
- **Kube-proxy**: Ist der Service, der für die Kommunikation (Services) zwischen dem Apiserver und dem Node verantwortlich ist. Die Basis ist ein IPtables für Nodes. Erfahrene Benutzer könnten andere Kube-Proxys von anderen Anbietern installieren.
+- **Kube-proxy**: Ist der Service, der für die Kommunikation (Services) zwischen dem apiserver und dem Node verantwortlich ist. Die Basis ist ein IPtables für Nodes. Erfahrene Benutzer könnten andere Kube-Proxys von anderen Anbietern installieren.
 - **Sidecar-Container**: Sidecar-Container sind die Container, die zusammen mit dem Hauptcontainer im Pod ausgeführt werden sollten. Dieses Sidecar-Muster erweitert und verbessert die Funktionalität der aktuellen Container, ohne sie zu ändern. Heutzutage wissen wir, dass wir Containertechnologie verwenden, um alle Abhängigkeiten für die Anwendung zu verpacken, damit sie überall ausgeführt werden kann. Ein Container macht nur eine Sache und macht diese Sache sehr gut.
 - **Master-Prozess:**
- **Api Server:** Ist der Weg, den die Benutzer und die Pods verwenden, um mit dem Master-Prozess zu kommunizieren. Nur authentifizierte Anfragen sollten erlaubt sein.
+- **Api Server:** Ist der Weg, wie die Benutzer und die Pods mit dem Master-Prozess kommunizieren. Nur authentifizierte Anfragen sollten erlaubt sein.
 - **Scheduler**: Die Planung bezieht sich darauf, sicherzustellen, dass Pods den Nodes zugeordnet werden, damit Kubelet sie ausführen kann. Er hat genug Intelligenz, um zu entscheiden, welcher Node mehr verfügbare Ressourcen hat, um den neuen Pod zuzuweisen. Beachten Sie, dass der Scheduler keine neuen Pods startet, sondern nur mit dem Kubelet-Prozess kommuniziert, der im Node läuft und den neuen Pod starten wird.
 - **Kube Controller Manager**: Er überprüft Ressourcen wie Replica-Sets oder Deployments, um zu überprüfen, ob beispielsweise die richtige Anzahl von Pods oder Nodes läuft. Falls ein Pod fehlt, kommuniziert er mit dem Scheduler, um einen neuen zu starten. Er steuert Replikation, Tokens und Kontodienste für die API.
- **etcd**: Datenspeicher, persistent, konsistent und verteilt. Ist die Datenbank von Kubernetes und der Schlüssel-Wert-Speicher, in dem der vollständige Zustand der Cluster gespeichert wird (jede Änderung wird hier protokolliert). Komponenten wie der Scheduler oder der Controller Manager sind auf diese Daten angewiesen, um zu wissen, welche Änderungen aufgetreten sind (verfügbare Ressourcen der Nodes, Anzahl der laufenden Pods...).
+- **etcd**: Datenspeicher, persistent, konsistent und verteilt. Ist die Datenbank von Kubernetes und der Schlüssel-Wert-Speicher, in dem der vollständige Zustand der Cluster gespeichert wird (jede Änderung wird hier protokolliert). Komponenten wie der Scheduler oder der Controller Manager hängen von diesen Daten ab, um zu wissen, welche Änderungen aufgetreten sind (verfügbare Ressourcen der Nodes, Anzahl der laufenden Pods...).
 - **Cloud Controller Manager**: Ist der spezifische Controller für Flusskontrollen und Anwendungen, d.h.: wenn Sie Cluster in AWS oder OpenStack haben.

 Beachten Sie, dass es mehrere Nodes (die mehrere Pods ausführen) geben kann, und es kann auch mehrere Master-Prozesse geben, deren Zugriff auf den Api-Server lastenausgeglichen und deren etcd synchronisiert ist.
@@ -47,10 +47,10 @@ Wenn ein Pod Daten erstellt, die nicht verloren gehen sollten, wenn der Pod vers
 - **Secret**: Dies ist der Ort, um **geheime Daten** wie Passwörter, API-Schlüssel... in B64 kodiert zu speichern. Der Pod kann auf diese Daten zugreifen, um die erforderlichen Anmeldeinformationen zu verwenden.
 - **Deployments**: Hier werden die Komponenten angegeben, die von Kubernetes ausgeführt werden sollen. Ein Benutzer arbeitet normalerweise nicht direkt mit Pods, Pods sind in **ReplicaSets** abstrahiert (Anzahl der gleichen Pods, die repliziert werden), die über Deployments ausgeführt werden. Beachten Sie, dass Deployments für **zustandslose** Anwendungen gedacht sind. Die minimale Konfiguration für ein Deployment ist der Name und das auszuführende Image.
 - **StatefulSet**: Diese Komponente ist speziell für Anwendungen wie **Datenbanken** gedacht, die **auf denselben Speicher zugreifen** müssen.
- **Ingress**: Dies ist die Konfiguration, die verwendet wird, um **die Anwendung öffentlich mit einer URL exponieren**. Beachten Sie, dass dies auch mit externen Services erfolgen kann, aber dies ist der richtige Weg, um die Anwendung zu exponieren.
+- **Ingress**: Dies ist die Konfiguration, die verwendet wird, um die Anwendung öffentlich mit einer URL **auszusetzen**. Beachten Sie, dass dies auch mit externen Services erfolgen kann, aber dies ist der richtige Weg, um die Anwendung exponiert zu machen.
 - Wenn Sie ein Ingress implementieren, müssen Sie **Ingress-Controller** erstellen. Der Ingress-Controller ist ein **Pod**, der der Endpunkt sein wird, der die Anfragen empfängt, überprüft und sie an die Services lastenausgleicht. Der Ingress-Controller wird **die Anfrage basierend auf den konfigurierten Ingress-Regeln senden**. Beachten Sie, dass die Ingress-Regeln auf verschiedene Pfade oder sogar Subdomains zu verschiedenen internen Kubernetes-Services verweisen können.
 - Eine bessere Sicherheitspraktik wäre es, einen Cloud-Lastenausgleich oder einen Proxy-Server als Einstiegspunkt zu verwenden, um keinen Teil des Kubernetes-Clusters exponiert zu haben.
- Wenn eine Anfrage empfangen wird, die keiner Ingress-Regel entspricht, wird der Ingress-Controller sie an den "**Default backend**" weiterleiten. Sie können den Ingress-Controller `describe` verwenden, um die Adresse dieses Parameters zu erhalten.
+- Wenn eine Anfrage eingeht, die keiner Ingress-Regel entspricht, wird der Ingress-Controller sie an den "**Default backend**" weiterleiten. Sie können den Ingress-Controller `describe` verwenden, um die Adresse dieses Parameters zu erhalten.
 - `minikube addons enable ingress`

 ### PKI-Infrastruktur - Zertifizierungsstelle CA:
@@ -70,7 +70,7 @@ Wenn ein Pod Daten erstellt, die nicht verloren gehen sollten, wenn der Pod vers

 ### Minikube

-**Minikube** kann verwendet werden, um einige **schnelle Tests** auf Kubernetes durchzuführen, ohne eine gesamte Kubernetes-Umgebung bereitstellen zu müssen. Es wird die **Master- und Node-Prozesse auf einer Maschine** ausführen. Minikube verwendet VirtualBox, um den Node auszuführen. Siehe [**hier, wie man es installiert**](https://minikube.sigs.k8s.io/docs/start/).
+**Minikube** kann verwendet werden, um einige **schnelle Tests** auf Kubernetes durchzuführen, ohne eine vollständige Kubernetes-Umgebung bereitstellen zu müssen. Es wird die **Master- und Node-Prozesse auf einer Maschine** ausführen. Minikube verwendet VirtualBox, um den Node auszuführen. Siehe [**hier, wie man es installiert**](https://minikube.sigs.k8s.io/docs/start/).
 ```
 $ minikube start
 😄  minikube v1.19.0 on Ubuntu 20.04
@@ -156,7 +156,7 @@ http://127.0.0.1:50034/api/v1/namespaces/kubernetes-dashboard/services/http:kube
 ### YAML-Konfigurationsdateien Beispiele

 Jede Konfigurationsdatei hat 3 Teile: **Metadaten**, **Spezifikation** (was gestartet werden muss), **Status** (gewünschter Zustand).\
-Innerhalb der Spezifikation der Bereitstellungs-Konfigurationsdatei finden Sie die Vorlage, die mit einer neuen Konfigurationsstruktur definiert ist, die das auszuführende Image definiert:
+Innerhalb der Spezifikation der Bereitstellungskonfigurationsdatei finden Sie die Vorlage, die mit einer neuen Konfigurationsstruktur definiert ist, die das auszuführende Image definiert:

 **Beispiel für Bereitstellung + Dienst, die in derselben Konfigurationsdatei deklariert sind (von** [**hier**](https://gitlab.com/nanuchi/youtube-tutorial-series/-/blob/master/demo-kubernetes-components/mongo.yaml)**)**

@@ -247,9 +247,9 @@ paths:
 serviceName: kubernetes-dashboard
 servicePort: 80
 ```
-**Beispiel einer Secrets-Konfigurationsdatei**
+**Beispiel einer Geheimnisse-Konfigurationsdatei**

-Beachten Sie, wie die Passwörter in B64 kodiert sind (was nicht sicher ist!)
+Beachten Sie, dass die Passwörter in B64 codiert sind (was nicht sicher ist!)
 ```yaml
 apiVersion: v1
 kind: Secret
@@ -262,7 +262,7 @@ mongo-root-password: cGFzc3dvcmQ=
 ```
 **Beispiel für ConfigMap**

-Ein **ConfigMap** ist die Konfiguration, die den Pods gegeben wird, damit sie wissen, wie sie andere Dienste finden und darauf zugreifen können. In diesem Fall wird jeder Pod wissen, dass der Name `mongodb-service` die Adresse eines Pods ist, mit dem sie kommunizieren können (dieser Pod wird ein mongodb ausführen):
+Eine **ConfigMap** ist die Konfiguration, die den Pods gegeben wird, damit sie wissen, wie sie andere Dienste finden und darauf zugreifen können. In diesem Fall wird jeder Pod wissen, dass der Name `mongodb-service` die Adresse eines Pods ist, mit dem sie kommunizieren können (dieser Pod wird ein mongodb ausführen):
 ```yaml
 apiVersion: v1
 kind: ConfigMap
@@ -271,7 +271,7 @@ name: mongodb-configmap
 data:
 database_url: mongodb-service
 ```
-Dann kann diese Adresse innerhalb einer **deployment config** auf folgende Weise angegeben werden, sodass sie in die Umgebungsvariablen des Pods geladen wird:
+Dann kann diese Adresse innerhalb einer **Deployment-Konfiguration** folgendermaßen angegeben werden, damit sie in die Umgebungsvariablen des Pods geladen wird:
 ```yaml
 [...]
 spec:
@@ -301,7 +301,7 @@ Sie finden verschiedene Beispiele für Speicher-Konfigurations-YAML-Dateien in [

 Kubernetes unterstützt **mehrere virtuelle Cluster**, die von demselben physischen Cluster unterstützt werden. Diese virtuellen Cluster werden **Namespaces** genannt. Sie sind für den Einsatz in Umgebungen mit vielen Benutzern, die über mehrere Teams oder Projekte verteilt sind, gedacht. Für Cluster mit wenigen bis mehreren Dutzend Benutzern sollten Sie keine Namespaces erstellen oder darüber nachdenken müssen. Sie sollten nur beginnen, Namespaces zu verwenden, um eine bessere Kontrolle und Organisation jedes Teils der in Kubernetes bereitgestellten Anwendung zu haben.

-Namespaces bieten einen Geltungsbereich für Namen. Die Namen von Ressourcen müssen innerhalb eines Namespaces eindeutig sein, jedoch nicht über Namespaces hinweg. Namespaces können nicht ineinander geschachtelt werden, und **jede** Kubernetes **Ressource** kann nur **in** **einem** **Namespace** sein.
+Namespaces bieten einen Geltungsbereich für Namen. Die Namen von Ressourcen müssen innerhalb eines Namespaces eindeutig sein, jedoch nicht über Namespaces hinweg. Namespaces können nicht ineinander geschachtelt werden und **jede** Kubernetes **Ressource** kann nur **in** **einem** **Namespace** sein.

 Es gibt standardmäßig 4 Namespaces, wenn Sie Minikube verwenden:
 ```
@@ -321,7 +321,7 @@ kube-system       Active   1d
 kubectl create namespace my-namespace
 ```
 > [!NOTE]
-> Beachten Sie, dass die meisten Kubernetes-Ressourcen (z. B. Pods, Dienste, Replikationscontroller und andere) in einigen Namespaces sind. Andere Ressourcen wie Namespace-Ressourcen und Low-Level-Ressourcen, wie Knoten und persistentVolumes, befinden sich jedoch nicht in einem Namespace. Um zu sehen, welche Kubernetes-Ressourcen sich in einem Namespace befinden und welche nicht:
+> Beachten Sie, dass die meisten Kubernetes-Ressourcen (z. B. Pods, Dienste, Replikationscontroller und andere) in einigen Namespaces sind. Andere Ressourcen wie Namespace-Ressourcen und Low-Level-Ressourcen, wie Knoten und persistentVolumes, sind jedoch nicht in einem Namespace. Um zu sehen, welche Kubernetes-Ressourcen sich in einem Namespace befinden und welche nicht:
 >
 > ```bash
 > kubectl api-resources --namespaced=true #In einem Namespace
@@ -342,11 +342,11 @@ Helm ist auch eine Template-Engine, die es ermöglicht, Konfigurationsdateien mi

 ## Kubernetes Secrets

-Ein **Secret** ist ein Objekt, das **sensible Daten** wie ein Passwort, ein Token oder einen Schlüssel **enthält**. Solche Informationen könnten andernfalls in einer Pod-Spezifikation oder in einem Image gespeichert werden. Benutzer können Secrets erstellen und das System erstellt ebenfalls Secrets. Der Name eines Secret-Objekts muss ein gültiger **DNS-Subdomänenname** sein. Lesen Sie hier [die offizielle Dokumentation](https://kubernetes.io/docs/concepts/configuration/secret/).
+Ein **Secret** ist ein Objekt, das **sensible Daten** wie ein Passwort, ein Token oder einen Schlüssel **enthält**. Solche Informationen könnten andernfalls in einer Pod-Spezifikation oder in einem Image abgelegt werden. Benutzer können Secrets erstellen und das System erstellt ebenfalls Secrets. Der Name eines Secret-Objekts muss ein gültiger **DNS-Subdomänenname** sein. Lesen Sie hier [die offizielle Dokumentation](https://kubernetes.io/docs/concepts/configuration/secret/).

-Secrets können Dinge wie Folgendes sein:
+Secrets können Dinge sein wie:

- API-, SSH-Schlüssel.
+- API, SSH-Schlüssel.
 - OAuth-Token.
 - Anmeldeinformationen, Passwörter (im Klartext oder b64 + Verschlüsselung).
 - Informationen oder Kommentare.
@@ -355,15 +355,15 @@ Secrets können Dinge wie Folgendes sein:
 Es gibt verschiedene Arten von Secrets in Kubernetes

 | Eingebauter Typ                      | Verwendung                                 |
-| ------------------------------------ | ----------------------------------------- |
-| **Opaque**                           | **willkürliche benutzerdefinierte Daten (Standard)** |
-| kubernetes.io/service-account-token  | Token des Dienstkontos                   |
-| kubernetes.io/dockercfg              | serialisierte \~/.dockercfg-Datei        |
-| kubernetes.io/dockerconfigjson       | serialisierte \~/.docker/config.json-Datei |
-| kubernetes.io/basic-auth             | Anmeldeinformationen für die grundlegende Authentifizierung |
-| kubernetes.io/ssh-auth               | Anmeldeinformationen für die SSH-Authentifizierung |
-| kubernetes.io/tls                    | Daten für einen TLS-Client oder -Server  |
-| bootstrap.kubernetes.io/token        | Bootstrap-Token-Daten                    |
+| ------------------------------------- | ------------------------------------------ |
+| **Opaque**                            | **willkürliche benutzerdefinierte Daten (Standard)** |
+| kubernetes.io/service-account-token   | Token des Dienstkontos                    |
+| kubernetes.io/dockercfg               | serialisierte \~/.dockercfg-Datei         |
+| kubernetes.io/dockerconfigjson        | serialisierte \~/.docker/config.json-Datei |
+| kubernetes.io/basic-auth              | Anmeldeinformationen für die grundlegende Authentifizierung |
+| kubernetes.io/ssh-auth                | Anmeldeinformationen für die SSH-Authentifizierung |
+| kubernetes.io/tls                     | Daten für einen TLS-Client oder -Server   |
+| bootstrap.kubernetes.io/token         | Bootstrap-Token-Daten                     |

 > [!NOTE]
 > **Der Opaque-Typ ist der Standardtyp, das typische Schlüssel-Wert-Paar, das von Benutzern definiert wird.**
@@ -372,7 +372,7 @@ Es gibt verschiedene Arten von Secrets in Kubernetes

 ![](https://sickrov.github.io/media/Screenshot-164.jpg)

-Die folgende Konfigurationsdatei definiert ein **Secret** namens `mysecret` mit 2 Schlüssel-Wert-Paaren `username: YWRtaW4=` und `password: MWYyZDFlMmU2N2Rm`. Es definiert auch ein **Pod** namens `secretpod`, das die in `mysecret` definierten `username` und `password` in den **Umgebungsvariablen** `SECRET_USERNAME` \_\_ und \_\_ `SECRET_PASSWOR` verfügbar macht. Es wird auch das `username`-Secret innerhalb von `mysecret` im Pfad `/etc/foo/my-group/my-username` mit `0640` Berechtigungen **einbinden**.
+Die folgende Konfigurationsdatei definiert ein **Secret** namens `mysecret` mit 2 Schlüssel-Wert-Paaren `username: YWRtaW4=` und `password: MWYyZDFlMmU2N2Rm`. Sie definiert auch einen **Pod** namens `secretpod`, der die in `mysecret` definierten `username` und `password` in den **Umgebungsvariablen** `SECRET_USERNAME` \_\_ und \_\_ `SECRET_PASSWOR` verfügbar macht. Es wird auch das `username`-Secret innerhalb von `mysecret` im Pfad `/etc/foo/my-group/my-username` mit `0640` Berechtigungen **gemountet**.
 ```yaml:secretpod.yaml
 apiVersion: v1
 kind: Secret
@@ -424,7 +424,7 @@ env | grep SECRET && cat /etc/foo/my-group/my-username && echo
 ```
 ### Secrets in etcd <a href="#discover-secrets-in-etcd" id="discover-secrets-in-etcd"></a>

-**etcd** ist ein konsistenter und hochverfügbarer **Key-Value-Speicher**, der als Kubernetes-Backend-Speicher für alle Cluster-Daten verwendet wird. Lassen Sie uns auf die in etcd gespeicherten Secrets zugreifen:
+**etcd** ist ein konsistenter und hochverfügbarer **Key-Value-Speicher**, der als Kubernetes-Backend-Speicher für alle Cluster-Daten verwendet wird. Lassen Sie uns auf die in etcd gespeicherten Geheimnisse zugreifen:
 ```bash
 cat /etc/kubernetes/manifests/kube-apiserver.yaml | grep etcd
 ```
@@ -434,7 +434,7 @@ Sie werden sehen, dass Zertifikate, Schlüssel und URLs im Dateisystem (FS) gesp

 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
 ```
-Sobald Sie die Kommunikation hergestellt haben, können Sie die Geheimnisse abrufen:
+Sobald Sie die Kommunikation hergestellt haben, können Sie die Geheimnisse erhalten:
 ```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>

@@ -456,7 +456,7 @@ keys:
 secret: cjjPMcWpTPKhAdieVtd+KhG4NN+N6e3NmBPMXJvbfrY= #Any random key
 - identity: {}
 ```
-Nach dem müssen Sie das `--encryption-provider-config`-Flag auf dem `kube-apiserver` setzen, um auf den Speicherort der erstellten Konfigurationsdatei zu verweisen. Sie können `/etc/kubernetes/manifest/kube-apiserver.yaml` bearbeiten und die folgenden Zeilen hinzufügen:
+Danach müssen Sie das Flag `--encryption-provider-config` auf dem `kube-apiserver` setzen, um auf den Speicherort der erstellten Konfigurationsdatei zu verweisen. Sie können `/etc/kubernetes/manifest/kube-apiserver.yaml` bearbeiten und die folgenden Zeilen hinzufügen:
 ```yaml
 containers:
 - command:
@@ -499,7 +499,7 @@ wobei `[...]` die zusätzlichen Argumente für die Verbindung zum etcd-Server se
 kubectl describe secret secret1 -n default
 ```

-sollte `mykey: bXlkYXRh` entsprechen, mydata ist kodiert, überprüfen Sie [das Dekodieren eines Geheimnisses](https://kubernetes.io/docs/concepts/configuration/secret#decoding-a-secret), um das Geheimnis vollständig zu dekodieren.
+sollte `mykey: bXlkYXRh` entsprechen, mydata ist kodiert, überprüfen Sie [decoding a secret](https://kubernetes.io/docs/concepts/configuration/secret#decoding-a-secret), um das Geheimnis vollständig zu dekodieren.

 **Da Geheimnisse beim Schreiben verschlüsselt werden, wird das Aktualisieren eines Geheimnisses diesen Inhalt verschlüsseln:**
 ```
@@ -507,7 +507,7 @@ kubectl get secrets --all-namespaces -o json | kubectl replace -f -
 ```
 **Abschließende Tipps:**

- Versuche, keine Geheimnisse im FS zu speichern, hole sie aus anderen Quellen.
+- Versuche, keine Geheimnisse im FS zu speichern, hole sie dir aus anderen Quellen.
 - Schau dir [https://www.vaultproject.io/](https://www.vaultproject.io) an, um zusätzlichen Schutz für deine Geheimnisse zu erhalten.
 - [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)