Quando in DoiT International assistiamo i clienti su tutto ciò che riguarda il cloud, alcuni temi ricorrono più di altri — e una domanda in particolare mi ha seguito persino dal mio precedente lavoro:
"Qual è il modo corretto per reindirizzare il traffico HTTP verso HTTPS usando l'ingress controller GCLB (predefinito) di GKE?"
In passato proponevo workaround come mantenere un backend dedicato al redirect oppure ricorrere a soluzioni di ingress di terze parti, prive però delle funzionalità avanzate di traffic management dei GCLB.
Adesso però le cose sono diventate molto più semplici grazie al rilascio da parte di Google Cloud del supporto nativo ai redirect nei load balancer dell'Ingress GKE.
Continui a leggere per scoprire:
- Perché si tratta di una novità così rilevante e
- Come semplificare, grazie a questa funzionalità, la gestione della propria infrastruttura come codice
Foto di Jamie Street su Unsplash
Perché preoccuparsene?
L'HTTP non cifrato ha ormai i giorni contati. Con i servizi di certificazione gratuiti offerti da piattaforme cloud come AWS e GCP, oltre a provider indipendenti come Let's Encrypt, ZeroSSL, BuyPass Go SSL e molti altri, non c'è più alcuna scusa per non adottare TLS, almeno sui load balancer di front-end in produzione.
La domanda più interessante è cosa fare sulla porta 80, ammesso di voler fare qualcosa. Si può scegliere semplicemente di lasciarla chiusa, sperando che il browser provi poi TLS sulla porta 443. Questo però può comportare ritardi indesiderati e qualsiasi link http completo non intenzionale verso il proprio sito produrrà una pagina di errore. Anche con i browser che iniziano a preferire le connessioni TLS e con le estensioni del browser dedicate a ulteriori ottimizzazioni, esistono buone ragioni per lasciare disponibile la porta 80. E non dimentichiamo le direttive HTTP Strict Transport Security e Upgrade Insecure Requests, pensate per imporre l'uso di connessioni TLS.
Per conoscere queste direttive, però, il browser deve comunque scaricarle almeno una volta — a meno di non far parte del club esclusivo degli indirizzi hsts integrati direttamente nei browser. Visto che TLS non comporta più alcun overhead computazionale, non ha senso servire lo stesso contenuto sia in forma cifrata sia in chiaro, mentre ci sono molte ottime ragioni per non farlo.
In generale, nella maggior parte dei casi d'uso ciò che serve è un redirect con codice di stato HTTP 301 o 308 da HTTP a HTTPS. Qual è dunque il modo idiomatico di farlo in Kubernetes, senza ricorrere ad hack locali e a ulteriore infrastruttura da gestire?
Redirect HTTPS nell'ingress di Kubernetes
Reindirizzare dalla porta HTTP è compito dell'ingress controller. Una prima versione beta della specifica ingress menzionava l'annotazione ingress.kubernetes.io/ssl-redirect, ma il supporto effettivo si è diffuso davvero solo attraverso annotazioni personalizzate (specifiche per ciascun controller).
Il diffusissimo ingress controller nginx esegue addirittura il redirect per impostazione predefinita quando TLS è abilitato. Su Google Cloud, invece, l'ingress controller predefinito di GKE ingress-gce utilizza i load balancer GCLB che — pur essendo per il resto eccezionali — per moltissimo tempo non hanno supportato i redirect da HTTP a HTTPS. La situazione è finalmente cambiata con l'introduzione del supporto ai redirect nel traffic management HTTP. Sfruttare questa funzionalità da una dichiarazione di ingress, però, non era ancora possibile, generando una marea di hack, workaround e frustrazione.
Fino a oggi. 🎉
Versioni di GKE supportate
La soluzione descritta di seguito è ufficialmente supportata solo a partire da Kubernetes 1.18.10-gke.600, ma funziona anche nelle versioni 1.17.x-gke attualmente disponibili. Quindi, se utilizza il release channel stable, può abilitare il supporto aggiornando i propri cluster alla serie 1.17, oppure adottare una qualsiasi versione dei channel regular o rapid.
Versioni di GKE supportate al momento della stesura
Supporto al redirect SSL nell'ingress di GKE: FrontendConfig
Il supporto nativo al redirect HTTPS è dunque finalmente arrivato in GKE. L'implementazione si basa sui CRD FrontendConfig (che, tra l'altro, regolano anche le policy SSL).
Per il redirect vero e proprio si può scegliere tra cinque diversi codici di stato HTTP.
Ecco un esempio con un redirect permanente di stato 308:
apiVersion: networking.gke.io/v1beta1
kind: FrontendConfig
metadata:
name: my-frontend-config
spec:
redirectToHttps:
enabled: true
responseCodeName: PERMANENT_REDIRECT
L'associazione di questa risorsa FrontendConfig con l'oggetto Ingress avviene tramite la chiave di annotazione networking.gke.io/v1beta1.FrontendConfig nella dichiarazione di ingress:
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
networking.gke.io/v1beta1.FrontendConfig: "my-frontend-config"
...
Si noti che, perché tutto funzioni, occorre utilizzare il namespace apiVersion v1beta1. In una fase successiva è probabile che il supporto si estenda anche alle versioni non beta, quindi conviene tenere d'occhio le dichiarazioni in vista di futuri aggiornamenti del cluster.
Ho pubblicato un esempio funzionante più completo su Github. Per tutti i dettagli su come configurare questa funzionalità, faccia riferimento alla documentazione ufficiale delle Ingress Features di Google.
Ulteriori informazioni
- Documentazione GCP sulle Ingress Features: redirect https
- Il progetto di esempio nello spazio Github di DoiT International
Sono entusiasta che GCP abbia ascoltato la community e implementato questa funzionalità tanto attesa. Inizi il 2021 con il piede giusto: abbandoni gli hack locali e si goda un approccio pulito, dichiarativo e idiomatico per relegare definitivamente al passato l'HTTP non cifrato!