Exposing Services in Kubernetes

Lernen Sie AWS-Hacking von Grund auf mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen:

Es gibt verschiedene Möglichkeiten, Dienste in Kubernetes zu exponieren, damit sowohl interne Endpunkte als auch externe Endpunkte darauf zugreifen können. Diese Kubernetes-Konfiguration ist ziemlich kritisch, da der Administrator Angreifern Zugriff auf Dienste geben könnte, auf die sie keinen Zugriff haben sollten.

Automatische Enumeration

Bevor Sie damit beginnen, die Möglichkeiten zu enumerieren, die K8s bietet, um Dienste für die Öffentlichkeit zugänglich zu machen, wissen Sie, dass Sie, wenn Sie Namespaces, Dienste und Ingresses auflisten können, alles, was der Öffentlichkeit zugänglich ist, finden können mit:

kubectl get namespace -o custom-columns='NAME:.metadata.name' | grep -v NAME | while IFS='' read -r ns; do
echo "Namespace: $ns"
kubectl get service -n "$ns"
kubectl get ingress -n "$ns"
echo "=============================================="
echo ""
echo ""
done | grep -v "ClusterIP"
# Remove the last '| grep -v "ClusterIP"' to see also type ClusterIP

ClusterIP

Ein ClusterIP-Dienst ist der Standard-Kubernetes-Dienst. Es bietet Ihnen einen Dienst innerhalb Ihres Clusters, auf den andere Apps innerhalb Ihres Clusters zugreifen können. Es gibt keinen externen Zugriff.

Es kann jedoch über den Kubernetes-Proxy zugegriffen werden:

kubectl proxy --port=8080

Nun können Sie durch die Kubernetes-API navigieren, um auf Dienste zuzugreifen, die dieses Schema verwenden:

http://localhost:8080/api/v1/proxy/namespaces/<NAMESPACE>/services/<SERVICE-NAME>:<PORT-NAME>/

Zum Beispiel könnten Sie die folgende URL verwenden:

http://localhost:8080/api/v1/proxy/namespaces/default/services/my-internal-service:http/

um auf diesen Dienst zuzugreifen:

apiVersion: v1
kind: Service
metadata:
name: my-internal-service
spec:
selector:
app: my-app
type: ClusterIP
ports:
- name: http
port: 80
targetPort: 80
protocol: TCP

Dieser Methode erfordert, dass Sie kubectl als authentifizierter Benutzer ausführen.

NodePort

Wenn NodePort verwendet wird, wird ein bestimmter Port auf allen Nodes (die die virtuellen Maschinen repräsentieren) verfügbar gemacht. Der Datenverkehr, der an diesen spezifischen Port gerichtet ist, wird dann systematisch zum Service geroutet. Normalerweise wird diese Methode aufgrund ihrer Nachteile nicht empfohlen.

Ein Beispiel für die NodePort-Spezifikation:

apiVersion: v1
kind: Service
metadata:
name: my-nodeport-service
spec:
selector:
app: my-app
type: NodePort
ports:
- name: http
port: 80
targetPort: 80
nodePort: 30036
protocol: TCP

Wenn Sie den nodePort nicht in der yaml angeben (es ist der Port, der geöffnet wird), wird ein Port im Bereich 30000–32767 verwendet.

LoadBalancer

Stellt den Service extern unter Verwendung eines Load Balancers des Cloud-Anbieters bereit. Auf GKE wird dies einen Network Load Balancer starten, der Ihnen eine einzelne IP-Adresse zur Verfügung stellt, die den gesamten Datenverkehr an Ihren Service weiterleitet.

Sie müssen für jeden freigegebenen Service einen LoadBalancer bezahlen, was teuer werden kann.

ExternalName

Aus den Dokumenten: Services vom Typ ExternalName ordnen einen Service einem DNS-Namen zu, nicht einem typischen Selektor wie my-service oder cassandra. Sie geben diese Services mit dem Parameter spec.externalName an.

Diese Service-Definition ordnet beispielsweise den Service my-service im Namespace prod zu my.database.example.com zu:

apiVersion: v1
kind: Service
metadata:
name: my-service
namespace: prod
spec:
type: ExternalName
externalName: my.database.example.com

Beim Aufrufen des Hosts my-service.prod.svc.cluster.local gibt der Cluster-DNS-Dienst einen CNAME-Datensatz mit dem Wert my.database.example.com zurück. Der Zugriff auf my-service funktioniert genauso wie bei anderen Diensten, jedoch mit dem entscheidenden Unterschied, dass die Weiterleitung auf DNS-Ebene erfolgt und nicht über Proxys oder Weiterleitungen.

Externe IPs

Datenverkehr, der in den Cluster mit der externen IP (als Ziel-IP) eintritt, wird auf den Serviceport zu einem der Service-Endpunkte geroutet. externalIPs werden nicht von Kubernetes verwaltet und liegen in der Verantwortung des Cluster-Administrators.

In der Service-Spezifikation können externalIPs zusammen mit einem der ServiceTypes angegeben werden. Im folgenden Beispiel kann "my-service" von Clients unter "80.11.12.10:80" (externalIP:port) erreicht werden.

apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app: MyApp
ports:
- name: http
protocol: TCP
port: 80
targetPort: 9376
externalIPs:
- 80.11.12.10

Ingress

Im Gegensatz zu allen obigen Beispielen ist Ingress KEIN Typ von Service. Stattdessen sitzt es vor mehreren Services und fungiert als "intelligenter Router" oder Einstiegspunkt in Ihren Cluster.

Sie können viele verschiedene Dinge mit einem Ingress tun, und es gibt viele Arten von Ingress-Controllern, die unterschiedliche Fähigkeiten haben.

Der Standard GKE Ingress-Controller wird einen HTTP(S) Load Balancer für Sie starten. Dies ermöglicht Ihnen sowohl routing basierend auf Pfaden als auch routing basierend auf Subdomains zu Backend-Services. Zum Beispiel können Sie alles auf foo.yourdomain.com zum Foo-Service senden und alles unter dem Pfad yourdomain.com/bar/ zum Bar-Service.

Das YAML für ein Ingress-Objekt auf GKE mit einem L7 HTTP Load Balancer könnte so aussehen:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: my-ingress
spec:
backend:
serviceName: other
servicePort: 8080
rules:
- host: foo.mydomain.com
http:
paths:
- backend:
serviceName: foo
servicePort: 8080
- host: mydomain.com
http:
paths:
- path: /bar/*
backend:
serviceName: bar
servicePort: 8080

Referenzen

Erlernen Sie AWS-Hacking von Null auf Held mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen:

Last updated