Sécurité de Kubernetes dans le cloud Azure – partie 3 – Sécuriser les trafics Nord Sud
Les traffics Nord-Sud sont :
- les communications réseaux initiées et émises par le cluster ou les applications instanciées dans celui-ci. On parle ici de Egress ou flux sortants
- Les communications à destination du cluster et des applications instanciées. On parle ici de Ingress ou flux entrants
Controller les flux sortants
Par défaut le traffic sortant vers Internet n’est pas limité pour les nœuds d’un cluster AKS.
Ceci signifie qu’il est donc possible pour un cluster (et plus précisément les worker nodes) de télécharger des images depuis n’importe quelle Registry. Hors c’est exactement ce qu’il se passe dans le cadre d’une attaque : les assaillants vont généralement installer leurs propres outils / codes (cryptomining, outils d’attaque, solutions de rebond…) en allant chercher des images de conteneurs et en les instanciant. Il existe même désormais des vers (comme Graboid découvert par les équipes de Palo Alto) qui automatisent tous ces processus d’infection.

Il est donc vivement conseillé de réduire l’exposition à ce risque en limitant et contrôlant les flux sortants des worker nodes. Cela va être fait en utilisant une Virtual Network Appliance (instanciée sous la forme de machine virtuelle) ou un Cloud service Firewall comme Azure Firewallet en forçant les paquets sortants à passer par ce point de contrôle (via une User Defined Route).
Network Virtual Appliance : utilisation de machines virtuelles Azure (une ou plus en fonction du besoin en terme de haute disponibilité et d’élasticité) de la MarketPlace pour instancer une solution de Firewall d’un partenaire comme Fortinet, Palo Alto, CheckPoint…

Service Cloud de Firewall : Azure Firewall qui est un service PaaS élastique, hautement disponible et géré par les équipes Microsoft.

Un nombre d’addresses/noms de domaines et de ports limités pour la maintenance du cluster AKS sont nécessaires à paramétrer sur le firewall (NVA ou cloud native Firewall).
Il existe une liste établie (et maintenue à jour) des noms de domaines et plages d’adresses IP obligatoires pour le bon fonctionnement du cluster AKS que ce soit dans un environnement Azure Public, Azure China 21Vianet ou Azure US Government.
Required outbound network rules and FQDNs for AKS clusters: https://docs.microsoft.com/en-us/azure/aks/limit-egress-traffic
Cette liste comprend également les URL / FQDN optionnelles mais fortement recommandées pour :
- le téléchargement des mises à jour de sécurité Ubuntu
- le téléchargement des drivers pour les GPU Nvidia (si des workers nodes utilisent des familles de VM de type Nx)
- le téléchargement des binaires Windows pour les nodes pools Windows
- L’intégration du monitoring d’AKS avec Azure Monitor
- L’usage d’Azure Dev Spaces
- L’utilisation d’Azure Policy
A cela il va falloir ajouter :
- Les adresses IP ou mieux les FQDN des containers registries qui seront utilisées. Si ces registries sont hébergées dans Azure Container Registry elles ont un nom du type nomdelaregistry.azurecr.io, si elles sont hébergées dans Github ghcr.io/nomduprofil, celle de la Microsoft Container Registry est mcr.microsoftt.com etc.. Idéalement il ne faut pas laisser AKS aller chercher directement ses images sur le Docker Hub qui contient un peu tout et n’importe quoi
- Les adresses IP ou les FQDN des endpoints publics des services utilisées par le cluster ou les pods instanciés. Par exemple pour des bases de données as a Service ou du storage externe (Azure Storage, Bucket S3..).

Controller les flux entrants
Pour gérer et filtrer les flux entrants qui sont très souvent en http ou https, Kubernetes utilise un objet appelé Ingress. l’objet Ingress dans Kubernetes est la représentation des règles d’accès (Terminaison SSL, load balancing, virtual hosting basé sur les noms).

Ces règles seront traitées par un Ingress Controller qui est ni plus ni moins qu’une solution controllant un reverse proxy. Ce reverse proxy peut être instancié dans le cluster Kubernetes (sous la forme de pods) ou à l’extérieur (sous la forme d’un service PaaS ou d’une appliance réseau).
Les solutions pouvant être instanciées dans le cluster Kubernetes sont nombreuses, parmi les plus répandues, il y a :
- Nginx qui est une des solutions intégrées au projet Kubernetes
- Traefik qui est très populaire
- Envoy qui est utilisé dans Istio et un projet géré par la CNCF
- HA Proxy : qui est utilisé dans OpenShift
La liste est longue et le tableau suivant peut être utile pour comparer les fonctionnalités (cliquer sur l’image) :

Attention : il va falloir ici penser au cycle de vie de ces ingress controllers et maintenir à jour ceux-ci en redéployant les nouvelles versions. De plus, il va falloir parfois compléter / paramétrer ces ingress controllers pour agir en tant que Web Application Firewall pour filtrer les attaquent Web les plus classiques en s’appuyant notamment sur les régles de l’OWASP. Par exemple, avec nginx, il est possible d’utiliser ModSecurity Web Application Firewall
Une autre approche est d’utiliser un service PaaS comme reverse proxy / Web Application Firewall et de le piloter via un Ingress Controller. Dans Azure, c’est le service Azure Application Gateway qui peut servir de reverse proxy et qui sera controllé par Application Gateway Ingress Controller(instancié sous la forme d’un pod dans AKS).

Ce type de d’implémentation technique offre plusieurs bénéfices :
- Pas d’impact sur les performances du cluster Kubernetes car instancié à l’extérieur
- Amélioration en termes de latence (à vérifier au cas par cas)
- Facilité de déploiement comme toute ressource cloud (via le portail, de la ligne de commande ou de l’Infrastructure as Code)
- Elasticité en terme de performances: le service dispose d’une fonction d’autoscaling
- Haute disponibilité contractualisée par un SLA
- Maintient en condition opérationnelle et mises à jour gérés par le fournisseur Cloud
- Intégration native de Web Application Firewall
- Intégration avec le reste de la plateforme cloud (Azure Monitor, Azure Security Center, Azure Key Vault…)
- Mutualisation posssible avec d’autres services tels que Azure Web App
Du point de vue déploiement, AGIC devient désormais un add-on à AKS rendant ainsi son installation vraiment simple via la ligne de commande.

— Stanislas —