Chez DoiT International, nous accompagnons nos clients sur tous les sujets cloud, et certaines questions reviennent plus souvent que d'autres — l'une d'elles m'a même suivi depuis mon précédent poste :
" Quelle est la bonne façon de rediriger le trafic HTTP vers HTTPS avec le contrôleur d'Ingress GCLB par défaut de GKE ? "
Auparavant, je proposais des contournements : maintenir un backend dédié à la redirection, ou se rabattre sur des solutions d'Ingress tierces dépourvues des fonctionnalités avancées de gestion de trafic des GCLB.
Mais tout devient beaucoup plus simple depuis que Google Cloud a publié la prise en charge native des redirections dans les load balancers Ingress de GKE.
Au programme :
- Pourquoi cette nouveauté change la donne
- Comment elle simplifie la gestion de votre infrastructure as code
Photo de Jamie Street sur Unsplash
Pourquoi s'en préoccuper ?
Le HTTP non chiffré vit ses derniers jours. Entre les services de certificats gratuits proposés par les plateformes cloud comme AWS et GCP, et les fournisseurs indépendants tels que Let's Encrypt, ZeroSSL, BuyPass Go SSL et bien d'autres, plus aucune excuse pour ne pas activer TLS, au moins sur vos load balancers de front-end en production.
La vraie question, c'est ce qu'il convient de faire sur le port 80, le cas échéant. Vous pouvez choisir de le laisser fermé, en espérant que le navigateur tente ensuite TLS sur le port 443. Mais cela peut entraîner des délais indésirables, et le moindre lien http complet involontaire vers votre site renverra une page d'erreur. Même si les navigateurs privilégient désormais les connexions TLS et que des extensions de navigateur permettent d'aller plus loin, il reste de bonnes raisons de garder le port 80 ouvert. Et n'oublions pas les déclarations HTTP Strict Transport Security et Upgrade Insecure Requests, qui imposent l'usage de connexions TLS.
Encore faut-il que le navigateur connaisse ces directives, et donc qu'il les ait téléchargées au moins une fois — sauf si vous faites partie du club très fermé des adresses hsts codées en dur dans les navigateurs. Comme TLS n'ajoute plus aucune surcharge de calcul, rien ne justifie de servir le même contenu à la fois chiffré et en clair, et bien des raisons de s'en abstenir.
Dans la plupart des cas, ce que l'on cherche, c'est une redirection HTTP vers HTTPS avec un statut 301 ou 308. Quelle est donc la manière idiomatique d'y parvenir dans Kubernetes, sans bidouillages locaux ni infrastructure supplémentaire à maintenir ?
Redirections HTTPS dans l'Ingress Kubernetes
La redirection depuis le port HTTP est l'affaire du contrôleur d'Ingress. Une première version bêta de la spécification Ingress mentionnait l'annotation ingress.kubernetes.io/ssl-redirect, mais la prise en charge réelle ne s'est imposée qu'au travers d'annotations personnalisées propres à chaque contrôleur.
Le célèbre contrôleur d'Ingress nginx effectue d'ailleurs la redirection par défaut dès que TLS est activé. Sur Google Cloud, en revanche, le contrôleur d'Ingress par défaut de GKE, ingress-gce, repose sur des load balancers GCLB qui — pour excellents qu'ils soient — n'ont pas pris en charge les redirections HTTP vers HTTPS pendant très, très longtemps. Cela a enfin changé avec l'arrivée de la prise en charge des redirections dans la gestion du trafic HTTP. Reste qu'exploiter cette fonctionnalité depuis une déclaration Ingress n'était toujours pas possible, d'où une multitude de bidouillages, contournements et frustrations.
Jusqu'à aujourd'hui. 🎉
Versions de GKE prises en charge
La solution décrite ci-dessous n'est officiellement prise en charge qu'à partir de Kubernetes 1.18.10-gke.600, mais elle fonctionne aussi sur les versions 1.17.x-gke actuellement disponibles. Si vous êtes sur le canal de publication stable, vous pouvez donc l'activer en faisant passer vos clusters sur la série 1.17, ou utiliser n'importe quelle version des canaux regular ou rapid.
Versions de GKE prises en charge au moment de la rédaction
Redirection SSL dans l'Ingress GKE : FrontendConfig
La redirection HTTPS native est donc enfin arrivée dans GKE. L'implémentation repose sur des CRD FrontendConfig (qui régissent aussi les politiques SSL, au passage).
Cinq codes de statut HTTP sont disponibles pour la redirection elle-même.
Voici un exemple avec une redirection permanente de statut 308 :
apiVersion: networking.gke.io/v1beta1
kind: FrontendConfig
metadata:
name: my-frontend-config
spec:
redirectToHttps:
enabled: true
responseCodeName: PERMANENT_REDIRECT
L'association de cette ressource FrontendConfig à votre objet Ingress se fait via la clé d'annotation networking.gke.io/v1beta1.FrontendConfig dans la déclaration de l'Ingress :
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
networking.gke.io/v1beta1.FrontendConfig: "my-frontend-config"
...
Notez qu'il faut utiliser un namespace d'apiVersion v1beta1 pour que cela fonctionne. La prise en charge sera vraisemblablement étendue plus tard aux versions non-bêta : gardez donc un œil sur ces déclarations en prévision de futures montées de version de cluster.
J'ai publié un exemple complet et fonctionnel sur Github. Pour tous les détails de configuration de cette fonctionnalité, rendez-vous sur la documentation officielle des fonctionnalités de l'Ingress chez Google.
Pour aller plus loin
- Documentation GCP sur les fonctionnalités de l'Ingress : redirection https
- Le projet d'exemple sur l'espace Github de DoiT International
Je suis ravi que GCP ait écouté la communauté et implémenté cette fonctionnalité attendue de longue date. Démarrez 2021 du bon pied : oubliez vos bidouillages locaux et adoptez une approche propre, déclarative et idiomatique pour reléguer définitivement le HTTP non chiffré au passé !