Kubernetes Basics
Kubernetes Grundlagen
Lernen Sie & üben Sie AWS-Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lernen Sie & üben Sie GCP-Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Der ursprüngliche Autor dieser Seite ist Jorge (lesen Sie seinen Originalbeitrag hier)
Architektur & Grundlagen
Was macht Kubernetes?
Ermöglicht das Ausführen von Container/n in einem Container-Engine.
Der Scheduler ermöglicht eine effiziente Containerzuweisung.
Hält Container am Leben.
Ermöglicht die Kommunikation zwischen Containern.
Ermöglicht Bereitstellungstechniken.
Behandelt große Datenmengen.
Architektur
Node: Betriebssystem mit Pod oder Pods.
Pod: Wrapper um einen Container oder mehrere Container. Ein Pod sollte nur eine Anwendung enthalten (normalerweise führt ein Pod nur 1 Container aus). Der Pod ist die Art und Weise, wie Kubernetes die Container-Technologie abstrahiert.
Service: Jeder Pod hat 1 interne IP-Adresse aus dem internen Bereich des Knotens. Es kann jedoch auch über einen Service freigegeben werden. Der Service hat ebenfalls eine IP-Adresse und sein Ziel ist es, die Kommunikation zwischen den Pods aufrechtzuerhalten, sodass, wenn einer stirbt, der neue Ersatz (mit einer anderen internen IP) über die gleiche IP des Dienstes zugänglich sein wird. Er kann als intern oder extern konfiguriert werden. Der Service fungiert auch als Lastenausgleicher, wenn 2 Pods mit demselben Service verbunden sind. Wenn ein Service erstellt wird, können Sie die Endpunkte jedes Dienstes finden, indem Sie
kubectl get endpoints
ausführen.Kubelet: Primärer Knotenagent. Die Komponente, die die Kommunikation zwischen Knoten 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 Dienst, der für die Kommunikation (Dienste) zwischen dem API-Server und dem Knoten zuständig ist. Die Basis ist ein IPtables für Knoten. Erfahrenere Benutzer könnten auch andere Kube-Proxies 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 die Container-Technologie verwenden, um alle Abhängigkeiten für die Anwendung zu bündeln, damit sie überall ausgeführt werden kann. Ein Container macht nur eine Sache und macht diese Sache sehr gut.
Master-Prozess:
API-Server: Ist die Art und Weise, wie Benutzer und Pods mit dem Master-Prozess kommunizieren. Es sollten nur authentifizierte Anfragen zugelassen werden.
Scheduler: Die Planung bezieht sich darauf, sicherzustellen, dass Pods den Knoten zugeordnet sind, damit Kubelet sie ausführen kann. Er verfügt über genügend Intelligenz, um zu entscheiden, welcher Knoten über mehr verfügbare Ressourcen verfügt und den neuen Pod diesem zuweist. Beachten Sie, dass der Scheduler keine neuen Pods startet, sondern nur mit dem im Knoten ausgeführten Kubelet-Prozess kommuniziert, der den neuen Pod starten wird.
Kube-Controller-Manager: Überprüft Ressourcen wie Replikamengen oder Bereitstellungen, um zu überprüfen, ob beispielsweise die richtige Anzahl von Pods oder Knoten ausgeführt wird. Wenn ein Pod fehlt, wird er mit dem Scheduler kommunizieren, um einen neuen zu starten. Er steuert Replikationen, Token und Kontodienste für die API.
etcd: Datenspeicherung, 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 Knoten, Anzahl der ausgeführten Pods...).
Cloud-Controller-Manager: Ist der spezifische Controller für Flusssteuerungen und Anwendungen, z. B. wenn Sie Cluster in AWS oder OpenStack haben.
Beachten Sie, dass es möglicherweise mehrere Knoten (die mehrere Pods ausführen) gibt, es möglicherweise auch mehrere Master-Prozesse gibt, deren Zugriff auf den API-Server ausbalanciert ist und deren etcd synchronisiert ist.
Volumes:
Wenn ein Pod Daten erstellt, die nicht verloren gehen sollten, wenn der Pod verschwindet, sollten sie in einem physischen Volume gespeichert werden. Kubernetes ermöglicht das Anhängen eines Volumes an einen Pod, um die Daten zu persistieren. Das Volume kann sich auf der lokalen Maschine oder in einem externen Speicher befinden. Wenn Sie Pods auf verschiedenen physischen Knoten ausführen, sollten Sie einen externen Speicher verwenden, damit alle Pods darauf zugreifen können.
Andere Konfigurationen:
ConfigMap: Sie können URLs konfigurieren, um auf Dienste zuzugreifen. Der Pod wird Daten von hier abrufen, um zu wissen, wie er mit dem Rest der Dienste (Pods) kommunizieren soll. Beachten Sie, dass dies nicht der empfohlene Ort zum Speichern von Anmeldeinformationen ist!
Secret: Hier werden geheime Daten wie Passwörter, API-Schlüssel... codiert in B64 gespeichert. Der Pod kann auf diese Daten zugreifen, um die erforderlichen Anmeldeinformationen zu verwenden.
Bereitstellungen: Hier werden die von Kubernetes auszuführenden Komponenten angegeben. Ein Benutzer arbeitet normalerweise nicht direkt mit Pods, Pods werden in Replika-Sets (Anzahl der replizierten gleichen Pods) abstrahiert, die über Bereitstellungen ausgeführt werden. Beachten Sie, dass Bereitstellungen für zustandslose Anwendungen sind. Die Mindestkonfiguration für eine Bereitstellung 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 freizugeben. Beachten Sie, dass dies auch mit externen Diensten möglich ist, aber dies ist der richtige Weg, um die Anwendung freizugeben.
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 und überprüft und sie an die Dienste weiterleitet. Der Ingress-Controller wird die Anfrage basierend auf den konfigurierten Ingress-Regeln weiterleiten. Beachten Sie, dass die Ingress-Regeln auf verschiedene Pfade oder sogar Subdomains zu verschiedenen internen Kubernetes-Diensten verweisen können.
Eine bessere Sicherheitspraxis wäre die Verwendung eines Cloud-Lastenausgleichs oder eines Proxy-Servers als Einstiegspunkt, um keinen Teil des Kubernetes-Clusters freizulegen.
Wenn eine Anfrage eingeht, die keiner Ingress-Regel entspricht, leitet der Ingress-Controller sie an den "Standard-Backend" weiter. Sie können
describe
des Ingress-Controllers verwenden, um die Adresse dieses Parameters zu erhalten.minikube addons enable ingress
PKI Infrastruktur - Zertifizierungsstelle CA:
Die CA ist die vertrauenswürdige Wurzel für alle Zertifikate innerhalb des Clusters.
Ermöglicht es den Komponenten, sich gegenseitig zu validieren.
Alle Cluster-Zertifikate werden von der CA signiert.
ETCd hat sein eigenes Zertifikat.
Arten:
apiserver-Zertifikat.
kubelet-Zertifikat.
scheduler-Zertifikat.
Grundlegende Aktionen
Minikube
Minikube kann verwendet werden, um einige schnelle Tests auf Kubernetes durchzuführen, ohne eine komplette Kubernetes-Umgebung bereitzustellen. Es führt die Master- und Node-Prozesse auf einer Maschine aus. Minikube verwendet VirtualBox, um den Node auszuführen. Siehe hier, wie man es installiert.
Kubectl Grundlagen
Kubectl
ist das Befehlszeilentool für Kubernetes-Cluster. Es kommuniziert mit dem API-Server des Master-Prozesses, um Aktionen in Kubernetes auszuführen oder Daten abzurufen.
Minikube-Dashboard
Das Dashboard ermöglicht es Ihnen, einfacher zu sehen, was Minikube ausführt. Sie finden die URL zum Zugriff darauf unter:
Beispiele für YAML-Konfigurationsdateien
Jede Konfigurationsdatei besteht aus 3 Teilen: Metadaten, Spezifikation (was gestartet werden muss) und Status (gewünschter Zustand). Innerhalb der Spezifikation der Bereitstellungskonfigurationsdatei finden Sie die Vorlage, die mit einer neuen Konfigurationsstruktur definiert ist, die das auszuführende Image angibt:
Beispiel für Bereitstellung + Service, die in derselben Konfigurationsdatei deklariert sind (von hier)
Da ein Dienst normalerweise mit einer Bereitstellung zusammenhängt, ist es möglich, beide in derselben Konfigurationsdatei zu deklarieren (der in dieser Konfiguration deklarierte Dienst ist nur intern zugänglich):
Beispiel für die Konfiguration eines externen Dienstes
Dieser Dienst wird extern zugänglich sein (überprüfen Sie die nodePort
und type: LoadBalancer
Attribute):
Dies ist nützlich für Tests, aber für die Produktion sollten Sie nur interne Dienste und einen Ingress haben, um die Anwendung freizugeben.
Beispiel einer Ingress-Konfigurationsdatei
Dies wird die Anwendung unter http://dashboard.com
freigeben.
Beispiel einer Secrets-Konfigurationsdatei
Beachten Sie, wie die Passwörter in B64 codiert sind (was nicht sicher ist!)
Beispiel für ConfigMap
Ein ConfigMap ist die Konfiguration, die den Pods gegeben wird, damit sie wissen, wie sie andere Dienste lokalisieren 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):
Dann kann diese Adresse innerhalb einer Bereitstellungskonfiguration folgendermaßen angegeben werden, damit sie im env des Pods geladen wird:
Beispiel für Volumenkonfiguration
Sie können verschiedene Beispiele für Speicherkonfigurations-YAML-Dateien unter https://gitlab.com/nanuchi/youtube-tutorial-series/-/tree/master/kubernetes-volumes finden. Beachten Sie, dass Volumes nicht innerhalb von Namespaces liegen
Namespaces
Kubernetes unterstützt mehrere virtuelle Cluster, die vom selben physischen Cluster unterstützt werden. Diese virtuellen Cluster werden Namespaces genannt. Diese sind für die Verwendung in Umgebungen mit vielen Benutzern verteilt auf mehrere Teams oder Projekte gedacht. Für Cluster mit einigen bis zehn Benutzern sollten Sie keine Namespaces erstellen oder darüber nachdenken müssen. Sie sollten nur Namespaces verwenden, um eine bessere Kontrolle und Organisation jedes Teils der Anwendung bereitzustellen, die in Kubernetes bereitgestellt wird.
Namespaces bieten einen Bereich für Namen. Namen von Ressourcen müssen innerhalb eines Namespaces eindeutig sein, aber nicht über Namespaces hinweg. Namespaces können nicht ineinander verschachtelt werden und jede Kubernetes-Ressource kann nur in einem Namespace sein.
Es gibt standardmäßig 4 Namespaces, wenn Sie minikube verwenden:
kube-system: Es ist nicht für die Benutzer gedacht und du solltest es nicht berühren. Es ist für Master- und kubectl-Prozesse.
kube-public: Öffentlich zugängliche Daten. Enthält einen Configmap, der Clusterinformationen enthält.
kube-node-lease: Bestimmt die Verfügbarkeit eines Knotens.
default: Der Namespace, den der Benutzer zum Erstellen von Ressourcen verwenden wird.
Beachten Sie, dass die meisten Kubernetes-Ressourcen (z. B. Pods, Services, Replikationscontroller und andere) in bestimmten Namespaces sind. Allerdings gehören andere Ressourcen wie Namespace-Ressourcen und Ressourcen auf niedriger Ebene, wie Nodes und PersistenVolumes, nicht zu einem Namespace. Um zu sehen, welche Kubernetes-Ressourcen in einem Namespace sind und welche nicht:
Sie können den Namespace für alle nachfolgenden kubectl-Befehle in diesem Kontext speichern.
Helm
Helm ist der Paketmanager für Kubernetes. Es ermöglicht das Verpacken von YAML-Dateien und deren Verteilung in öffentlichen und privaten Repositories. Diese Pakete werden als Helm-Charts bezeichnet.
Kubernetes Geheimnisse
Ein Secret ist ein Objekt, das sensible Daten wie ein Passwort, ein Token oder einen Schlüssel enthält. Solche Informationen könnten anderweitig in einer Pod-Spezifikation oder in einem Image platziert werden. Benutzer können Secrets erstellen und das System erstellt auch Secrets. Der Name eines Secret-Objekts muss ein gültiger DNS-Subdomänenname sein. Lesen Sie hier die offizielle Dokumentation.
Geheimnisse könnten Dinge wie:
API, SSH-Schlüssel.
OAuth-Token.
Anmeldeinformationen, Passwörter (Klartext oder b64 + Verschlüsselung).
Informationen oder Kommentare.
Datenbankverbindungscodes, Zeichenfolgen... .
Es gibt verschiedene Arten von Secrets in Kubernetes
Eingebauter Typ | Verwendung |
---|---|
Undurchsichtig | beliebige benutzerdefinierte Daten (Standard) |
kubernetes.io/service-account-token | Servicekonto-Token |
kubernetes.io/dockercfg | serialisierte ~/.dockercfg-Datei |
kubernetes.io/dockerconfigjson | serialisierte ~/.docker/config.json-Datei |
kubernetes.io/basic-auth | Anmeldeinformationen für die Basisauthentifizierung |
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 |
Der Opaque-Typ ist der Standardtyp, das typische Schlüssel-Wert-Paar, das von Benutzern definiert wird.
Wie Secrets funktionieren:
Die folgende Konfigurationsdatei definiert ein Secret namens mysecret
mit 2 Schlüssel-Wert-Paaren username: YWRtaW4=
und password: MWYyZDFlMmU2N2Rm
. Es definiert auch eine Pod namens secretpod
, die den in mysecret
definierten username
und password
in den Umgebungsvariablen SECRET_USERNAME
und SECRET_PASSWOR
freigibt. Es wird auch das username
-Secret innerhalb von mysecret
im Pfad /etc/foo/my-group/my-username
mit Berechtigungen 0640
einhängen.
Geheimnisse in etcd
etcd ist ein konsistenter und hochverfügbarer Schlüssel-Wert-Speicher, der als Kubernetes-Back-End-Speicher für alle Clusterdaten verwendet wird. Lassen Sie uns auf die in etcd gespeicherten Geheimnisse zugreifen:
Du wirst Zertifikate, Schlüssel und URLs sehen, die sich im Dateisystem befinden. Sobald du sie hast, wirst du in der Lage sein, eine Verbindung zum etcd herzustellen.
Sobald Sie die Kommunikation hergestellt haben, können Sie die Geheimnisse erhalten:
Verschlüsselung zum ETCD hinzufügen
Standardmäßig werden alle Geheimnisse im Klartext im etcd gespeichert, es sei denn, Sie wenden eine Verschlüsselungsschicht an. Das folgende Beispiel basiert auf https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/
Danach müssen Sie das --encryption-provider-config
-Flag auf dem kube-apiserver
so setzen, dass es auf den Speicherort der erstellten Konfigurationsdatei zeigt. Sie können /etc/kubernetes/manifest/kube-apiserver.yaml
bearbeiten und die folgenden Zeilen hinzufügen:
Scrolle nach unten im volumeMounts:
Scrolle im volumeMounts zum hostPath:
Überprüfen, ob Daten verschlüsselt sind
Daten werden verschlüsselt, wenn sie in etcd geschrieben werden. Nach dem Neustart Ihres kube-apiservers
sollten neu erstellte oder aktualisierte Secrets verschlüsselt gespeichert werden. Zur Überprüfung können Sie das Befehlszeilenprogramm etcdctl
verwenden, um den Inhalt Ihres Secrets abzurufen.
Erstellen Sie ein neues Secret namens
secret1
im Namespacedefault
:
Lesen Sie mit dem Befehlszeilenprogramm
etcdctl
dieses Secret aus etcd:
ETCDCTL_API=3 etcdctl get /registry/secrets/default/secret1 [...] | hexdump -C
wobei [...]
die zusätzlichen Argumente für die Verbindung zum etcd-Server sein müssen. 3. Überprüfen Sie, ob das gespeicherte Secret mit k8s:enc:aescbc:v1:
beginnt, was darauf hinweist, dass der Anbieter aescbc
die resultierenden Daten verschlüsselt hat. 4. Überprüfen Sie, ob das Secret korrekt entschlüsselt wird, wenn es über die API abgerufen wird:
sollte mykey: bXlkYXRh
entsprechen, wobei mydata
codiert ist. Überprüfen Sie Entschlüsselung eines Secrets, um das Secret vollständig zu entschlüsseln.
Da Secrets beim Schreiben verschlüsselt sind, wird der Inhalt bei einem Update des Secrets verschlüsselt:
Abschließende Tipps:
Versuchen Sie, keine Geheimnisse im Dateisystem zu speichern, sondern holen Sie sie aus anderen Orten.
Schauen Sie sich https://www.vaultproject.io/ an, um Ihren Geheimnissen zusätzlichen Schutz zu bieten.
Referenzen
Lernen Sie & üben Sie AWS-Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lernen Sie & üben Sie GCP-Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Last updated