Lorsque vous concevez une application sécurisée, vous lui interdisez généralement toute connexion sortante hors de son Virtual Private Cloud (VPC). Mais il faut parfois ouvrir une brèche, par exemple lorsque votre application doit interroger une API tierce.
Gateway to Domain, façon Lovecraft. Crédit : StableDiffusion
L'approche habituelle consiste à autoriser l'egress uniquement vers les adresses IP concernées, telles que configurées dans le Firewall de Google Cloud Platform ou dans les Network ACLs d'AWS. Mais les adresses IP peuvent évoluer au fil du temps, alors que le Fully Qualified Domain Name (FQDN) — par exemple api.example.com — fournit un point d'accès stable et public. C'est pourquoi la plupart des applications sont configurées pour cibler un FQDN plutôt qu'une adresse IP.
Dans cet article, je passe en revue plusieurs façons de n'autoriser l'egress que vers un FQDN spécifique, avec les avantages et les inconvénients de chaque approche.
Nous chercherons des options peu coûteuses, faciles à maintenir, robustes et simples.
Nous examinerons aussi les options qui apportent une fonctionnalité supplémentaire : la prise en compte de Kubernetes. Par exemple, si votre application tourne sur Kubernetes, vous voudrez peut-être autoriser l'egress depuis un namespace donné et pas depuis les autres.
Nous pouvons également souhaiter une granularité de contrôle au niveau du domaine, puisqu'une même adresse IP peut héberger plusieurs domaines, comme dans le cas du virtual hosting basé sur le nom. La plupart des solutions présentées ici ne le gèrent pas : si vous autorisez l'accès à un domaine pointant vers une adresse IP donnée, elles autoriseront l'egress vers tous les domaines hébergés derrière cette adresse. Nous présenterons quelques solutions qui prennent ce cas en charge.
Voici les options examinées :
- Squid, exemple de proxy auto-géré
- AWS Network Firewall, avec inspection approfondie des paquets, qui permet un contrôle au niveau du domaine, y compris en virtual hosting.
- Une nouvelle fonctionnalité de Google Firewall, qui apporte le contrôle par FQDN avec le confort d'un service serverless
- Le nouveau Google Secure Web Gateway, qui ajoute un contrôle granulaire jusqu'au domaine et même à l'URL.
- Les solutions orientées Kubernetes : Cilium et Istio.
(À propos des couches OSI : comme les noms de domaine et le DNS se situent au niveau de la couche application du modèle réseau OSI, soit la couche 7, le contrôle d'egress par FQDN est parfois appelé contrôle d'egress de couche 7. À l'inverse, la couche 3 est celle où sont définies les adresses IP, contrôlées par les firewalls classiques ou les Network ACLs.)
L'implémenter soi-même
Voyons d'abord comment nous pourrions l'implémenter nous-mêmes. Non que je le recommande, mais cela permet de mieux comprendre ce que ces solutions font sous le capot.
Bien que l'application soit configurée avec le FQDN de l'API tierce, les noms de domaine n'interviennent qu'avant la tentative de connexion, lorsque le client résout l'adresse IP à partir du nom de domaine. Au-delà, le trafic réseau circule par adresses IP, et c'est ce que votre solution doit bloquer.
Notez aussi qu'un même FQDN peut correspondre à plusieurs adresses IP. Cela ne pose pas de problème : une résolution DNS classique les renvoie toutes, et vous pouvez donc autoriser l'accès à une liste d'adresses IP.
Vous disposez d'un Firewall ou d'une Network ACL qui bloque tout le trafic, à l'exception des adresses IP concernées.
Vous écrivez et déployez une application qui interroge périodiquement le DNS pour récupérer l'adresse IP courante du FQDN de l'API, api.example.com. (Pour exécuter cela à faible coût, GCP Cloud Functions ou AWS Lambda déclenchés périodiquement constituent un bon choix.) Dans les rares cas où l'adresse IP a changé, votre application met à jour le Firewall ou la Network ACL.
Reverse proxies web auto-gérés
Une solution classique de contrôle d'egress par FQDN est le reverse proxy web, dont Squid est la référence open source la plus connue. Vous utilisez le service de routage de votre cloud pour faire transiter tout le trafic sortant par une VM exécutant le proxy Squid ; celui-ci vérifie alors que l'adresse IP correspond bien au nom de domaine — tel que défini dans une whitelist ACL — et fait suivre le trafic en cas de correspondance.
Squid est disponible sur l'AWS Marketplace ; voir cette discussion d'architecture. Il est également disponible sur le GCP Marketplace ; voir cette configuration réseau. Voir aussi cette discussion sur le contrôle d'egress par FQDN dans Squid et d'autres proxies, comme DiscrimiNAT et Aviatrix.
Les proxies tels que Squid, exécutés sur une VM, induisent un coût de maintenance, par exemple pour la mise à jour des systèmes d'exploitation ou la gestion des pannes. Comme l'ensemble du trafic réseau transite par une seule VM (à moins de mettre en place un déploiement à charge équilibrée, ce qui demande un effort supplémentaire), la charge peut être lourde, ce qui menace la robustesse et peut imposer une VM plus puissante en 24x7, même lorsque ce n'est pas pleinement nécessaire.
AWS Network Firewall
AWS Network Firewall procède à une inspection approfondie des paquets et gagne ainsi en puissance de filtrage. Il n'est donc pas strictement comparable à Google Firewall, qui se rapproche davantage des AWS Network ACLs.
AWS Network Firewall prend en charge le contrôle d'egress par FQDN via des stateful domain list rule groups. Grâce au Server Name Indicator (SNI) transmis lors de la négociation d'une connexion TCP pour le trafic HTTPS, il sait distinguer plusieurs domaines en virtual hosting.
Network Firewall peut s'intégrer à Route 53 DNS Firewall, qui bloque les tentatives de résolution DNS, de sorte qu'une requête DNS pour api.example.com émise par une application au sein du VPC ne soit pas résolue en adresse IP. Mais le DNS Firewall n'empêche pas réellement l'accès à cette adresse IP ; c'est Network Firewall qui s'en charge.
Network Firewall est un bon choix, mais il peut devenir coûteux : il est conçu pour des environnements d'entreprise multi-réseaux complexes. (Voir mon article sur le DoiT Blog qui compare les cas d'usage des nombreux services de type Firewall sur AWS.)
Google Firewall et Web Gateway
Il est plus simple d'utiliser une solution entièrement gérée par le fournisseur cloud que de gérer soi-même la VM. Et Google sort justement plusieurs solutions pour le permettre.
Google Firewall propose une nouvelle fonctionnalité FQDN Objects, actuellement en Preview restreinte. Elle utilise Cloud DNS toutes les 30 secondes pour récupérer l'adresse IP courante du service externe.
Un autre service en Preview restreinte, Secure Web Gateway (renommé Secure Web Proxy), permet également un contrôle au niveau du domaine. Pour cela, vous lui donnez accès à vos certificats SSL via GCP Certificate Manager afin qu'il puisse déchiffrer et chiffrer votre trafic HTTPS. Cet accès en profondeur lui confère la capacité de contrôler l'egress au niveau du domaine, même en virtual hosting. Comme il voit l'intégralité de la requête HTTP, il vous permet même un contrôle au niveau de l'URL.
Cilium
Les solutions ci-dessus opèrent au niveau du VPC. Mais si votre application tourne sur Kubernetes, vous voudrez sans doute que le contrôle d'egress s'aligne sur les concepts de Kubernetes. Pour cela, vous pouvez introduire CiliumNetworkPolicy. Il s'agit d'une Custom Resource Definition (CRD) qui exécute la logique de résolution des noms de domaine en adresses IP, puis bloque ou autorise le trafic sur la couche réseau Cilium reposant sur eBPF. (Voir deux articles sur le DoiT blog.) La CRD intègre la logique Kubernetes, ce qui vous permet de distinguer les pods par namespace : certains autorisés à accéder à l'API externe, d'autres non. Une autre CRD, CiliumClusterwideNetworkPolicy, fait la même chose, mais sa configuration s'applique au-delà des namespaces, à l'ensemble du cluster.
Cette solution ajoute une certaine complexité à votre cluster, en raison de la couche réseau Cilium supplémentaire. Bientôt, comme l'indique la documentation Cilium, toutes les fonctionnalités seront fusionnées dans le format de ressource standard et cette CRD ne sera plus nécessaire. Aucune spécification standard n'est encore disponible, mais le Kubernetes Networking Special Interest Group y travaille actuellement.
Istio
La solution la plus riche en fonctionnalités est fournie par le service mesh Istio. Istio contrôle l'intégralité du trafic, ce qui vous permet de bloquer tout l'egress, sauf ce qui est défini dans une ServiceEntry. Lorsque vous indiquez resolution: DNS, vous demandez à Istio de ne pas se fier à l'adresse IP à laquelle le client (un pod) se connecte, mais plutôt de résoudre périodiquement le nom de domaine via DNS. Le service Istio peut être exposé uniquement aux namespaces de votre choix. Istio offre le plus grand contrôle, mais il ajoute davantage de complexité que Cilium, avec toute la puissance et les fonctionnalités d'une couche service mesh.
Que faire ?
Vous disposez d'un large éventail d'options : Squid (ou un autre reverse proxy web), éprouvé sur le terrain ; les nouveaux services managés Google Firewall FQDN Objects et AWS Network Firewall ; Secure Web Gateway, qui agit comme proxy HTTP ; et enfin Cilium et Istio, qui intègrent la logique Kubernetes.
Si vous recherchez une solution stable et managée, je recommande de choisir le nouveau Google Firewall (une fois sa maturité atteinte) et AWS Network Firewall (si la tarification entre dans votre budget). Si vous avez besoin d'un contrôle au niveau des namespaces Kubernetes, la solution la plus simple est une CRD Cilium ; lorsque le standard natif Kubernetes sera publié, optez pour celui-ci.
Addendum
Août 2023 : mon collègue
a récemment publié des articles approfondis sur plusieurs de ces sujets, intégrant les nouvelles versions Google de ce qui était en alpha lors de la rédaction de cet article, avec davantage de détails techniques.