Exposing Services in Kubernetes
Last updated
Last updated
Impara e pratica il Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica il Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
Ci sono diversi modi per esporre servizi in Kubernetes in modo che sia gli endpoint interni che gli endpoint esterni possano accedervi. Questa configurazione di Kubernetes è piuttosto critica poiché l'amministratore potrebbe dare accesso a attaccanti a servizi a cui non dovrebbero poter accedere.
Prima di iniziare a enumerare i modi in cui K8s offre di esporre servizi al pubblico, sappi che se puoi elencare namespace, servizi e ingressi, puoi trovare tutto ciò che è esposto al pubblico con:
Un servizio ClusterIP è il servizio predefinito di Kubernetes. Ti offre un servizio interno al tuo cluster a cui altre app all'interno del tuo cluster possono accedere. Non c'è accesso esterno.
Tuttavia, questo può essere accessibile utilizzando il Proxy di Kubernetes:
Ora puoi navigare attraverso l'API di Kubernetes per accedere ai servizi utilizzando questo schema:
http://localhost:8080/api/v1/proxy/namespaces/<NAMESPACE>/services/<SERVICE-NAME>:<PORT-NAME>/
Ad esempio, potresti utilizzare il seguente URL:
http://localhost:8080/api/v1/proxy/namespaces/default/services/my-internal-service:http/
per accedere a questo servizio:
Questo metodo richiede di eseguire kubectl
come utente autenticato.
Elenca tutti i ClusterIP:
Quando viene utilizzato NodePort, una porta designata è resa disponibile su tutti i nodi (che rappresentano le macchine virtuali). Il traffico diretto a questa porta specifica viene quindi sistematicamente instradato al servizio. Tipicamente, questo metodo non è raccomandato a causa dei suoi svantaggi.
Elenca tutti i NodePort:
Un esempio di specifica NodePort:
Se non specifichi il nodePort nel yaml (è la porta che sarà aperta) verrà utilizzata una porta nel range 30000–32767.
Espone il Servizio esternamente utilizzando il bilanciatore di carico di un fornitore di cloud. Su GKE, questo avvierà un Network Load Balancer che ti fornirà un singolo indirizzo IP che inoltrerà tutto il traffico al tuo servizio. In AWS lancerà un Load Balancer.
Devi pagare per un LoadBalancer per ogni servizio esposto, il che può essere costoso.
Elenca tutti i LoadBalancers:
Gli IP esterni sono esposti dai servizi di tipo Load Balancer e sono generalmente utilizzati quando si utilizza un Load Balancer di un Cloud Provider esterno.
Per trovarli, controlla i load balancer con valori nel campo EXTERNAL-IP
.
Il traffico che entra nel cluster con l'IP esterno (come IP di destinazione), sulla porta del Servizio, sarà instradato a uno degli endpoint del Servizio. externalIPs
non sono gestiti da Kubernetes e sono responsabilità dell'amministratore del cluster.
Nella specifica del Servizio, externalIPs
possono essere specificati insieme a uno qualsiasi dei ServiceTypes
. Nell'esempio seguente, "my-service
" può essere accessibile dai client su "80.11.12.10:80
" (externalIP:port
)
Dalla documentazione: I servizi di tipo ExternalName mappano un servizio a un nome DNS, non a un selettore tipico come my-service
o cassandra
. Si specificano questi servizi con il parametro spec.externalName
.
Questa definizione di servizio, ad esempio, mappa il servizio my-service
nel namespace prod
a my.database.example.com
:
Quando si cerca l'host my-service.prod.svc.cluster.local
, il servizio DNS del cluster restituisce un record CNAME
con il valore my.database.example.com
. Accedere a my-service
funziona allo stesso modo degli altri servizi, ma con la differenza cruciale che la reindirizzazione avviene a livello DNS piuttosto che tramite proxy o inoltro.
Elenca tutti gli ExternalNames:
A differenza di tutti gli esempi sopra, Ingress NON è un tipo di servizio. Invece, si trova davanti a più servizi e funge da “router intelligente” o punto di ingresso nel tuo cluster.
Puoi fare molte cose diverse con un Ingress, e ci sono molti tipi di controller Ingress che hanno capacità diverse.
Il controller ingress predefinito di GKE avvierà un HTTP(S) Load Balancer per te. Questo ti permetterà di fare sia il routing basato su percorso che su sottodominio ai servizi di backend. Ad esempio, puoi inviare tutto su foo.yourdomain.com al servizio foo, e tutto sotto il percorso yourdomain.com/bar/ al servizio bar.
Il YAML per un oggetto Ingress su GKE con un L7 HTTP Load Balancer potrebbe apparire così:
Elenca tutti gli ingressi:
Sebbene in questo caso sia meglio ottenere le informazioni di ciascuno uno per uno per leggerle meglio:
Impara e pratica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)