Exposing Services in Kubernetes

Leer AWS-hacking vanaf nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun:

Daar is verskillende maniere om dienste bloot te stel in Kubernetes sodat beide interne en eksterne eindpunte daartoe toegang kan verkry. Hierdie Kubernetes-konfigurasie is baie krities, aangesien die administrateur toegang kan gee aan aanvallers tot dienste waarop hulle nie toegang behoort te hê nie.

Outomatiese Opsomming

Voordat jy begin met die opsomming van die maniere waarop K8s dienste aan die publiek blootstel, moet jy weet dat as jy namespaces, dienste en ingresses kan lys, jy alles wat aan die publiek blootgestel is, kan vind met:

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

'n ClusterIP-diens is die verstek Kubernetes diens. Dit gee jou 'n diens binne jou cluster wat ander programme binne jou cluster kan bereik. Daar is geen eksterne toegang nie.

Dit kan egter toegang verkry deur die gebruik van die Kubernetes Proxy:

kubectl proxy --port=8080

Nou kan jy deur die Kubernetes API navigeer om dienste te bereik deur hierdie skema te gebruik:

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

Byvoorbeeld kan jy die volgende URL gebruik:

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

om toegang tot hierdie diens te verkry:

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

Hierdie metode vereis dat jy kubectl uitvoer as 'n geautentiseerde gebruiker.

NodePort

Wanneer NodePort gebruik word, word 'n aangewese poort beskikbaar gestel op alle Nodes (wat die Virtuele Masjiene verteenwoordig). Verkeer wat na hierdie spesifieke poort gerig word, word dan sistematies geroeteer na die diens. Gewoonlik word hierdie metode nie aanbeveel nie as gevolg van sy nadele.

'n Voorbeeld van 'n NodePort-spesifikasie:

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

As jy die nodePort nie spesifiseer nie (dit is die poort wat oopgemaak sal word) sal 'n poort in die reeks 30000–32767 gebruik word.

LoadBalancer

Stel die Diens ekstern bloot deur gebruik te maak van 'n wolkverskaffer se balansstaaf. Op GKE sal dit 'n Network Load Balancer opstel wat jou 'n enkele IP-adres sal gee wat alle verkeer na jou diens sal stuur.

Jy moet vir 'n LoadBalancer per blootgestelde diens betaal, wat duur kan wees.

ExternalName

Van die dokumentasie: Dienste van die tipe ExternalName koppel 'n Diens aan 'n DNS-naam, nie aan 'n tipiese selekteerder soos my-service of cassandra. Jy spesifiseer hierdie Dienste met die spec.externalName parameter.

Hierdie Diensdefinisie koppel byvoorbeeld die my-service Diens in die prod-naamruimte aan my.database.example.com:

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

Wanneer jy die gasheer my-service.prod.svc.cluster.local opsoek, gee die cluster DNS-diens 'n CNAME-rekord terug met die waarde my.database.example.com. Toegang tot my-service werk op dieselfde manier as ander Dienste, maar met die kritieke verskil dat herleiing plaasvind op die DNS-vlak eerder as deur middel van proksies of deurstuur.

Eksterne IP's

Verkeer wat in die cluster inkom met die eksterne IP (as bestemmings-IP), op die Dienspoort, sal geroeteer word na een van die Diens-eindpunte. externalIPs word nie deur Kubernetes bestuur nie en is die verantwoordelikheid van die cluster-administrator.

In die Diens-spesifikasie kan externalIPs saam met enige van die ServiceTypes gespesifiseer word. In die onderstaande voorbeeld kan "my-service" deur kliënte benader word op "80.11.12.10:80" (externalIP:port)

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

In teenstelling tot al die voorbeelde hierbo, is Ingress NIE 'n tipe diens nie. In plaas daarvan sit dit voor meerdere dienste en tree op as 'n "slim router" of toegangspunt tot jou groep.

Jy kan baie verskillende dinge doen met 'n Ingress, en daar is baie tipes Ingress-beheerders wat verskillende vermoëns het.

Die verstek GKE Ingress-beheerder sal 'n HTTP(S) Laaibalansier vir jou opstel. Dit sal jou in staat stel om beide pad-gebaseerde en subdomein-gebaseerde roetes na agterste dienste te stuur. Byvoorbeeld, jy kan alles op foo.joudomein.com na die foo-diens stuur, en alles onder die joudomein.com/bar/ pad na die bar-diens.

Die YAML vir 'n Ingress-voorwerp op GKE met 'n L7 HTTP Laaibalansier kan so lyk:

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

Verwysings

Leer AWS-hacking van nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun:

Last updated