Comment sécuriser Kubernetes ?
En une décennie, Kubernetes s’est imposé comme l’orchestrateur de containers de référence sur le marché du numérique. Il est devenu l’infrastructure logicielle clé pour supporter les applications cloud de nouvelle génération. Par conséquent, le sécuriser se révèle désormais un élément des plus stratégiques. La question ne fait plus débat. Reste à savoir quelles sont les bonnes pratiques permettant de le protéger.
"L’un des premiers points à avoir en tête concerne le niveau d’exposition. Pour avoir cette vision, il faudra échanger avec les équipes applicatives pour connaître les composants qui seront nécessairement visibles depuis l’extérieur", souligne Florent Houy, head of cloud security team au sein d’Orange Cyberdefense. Au sein de la société de services en logiciels libres (SS2L) Alter Way (groupe Smile), on conseille d’opter pour une version d’Ubuntu durcie dans le cas où le déploiement de Kubernetes serait réalisé sur site.
Autre OS serveur recommandé par Alter Way : Talos OS, édité par Sidero. "Avec cette distribution, Kubernetes et l’OS ne font qu’un. Vous accédez à l’orchestrateur uniquement par API. La surface d’attaque est ainsi minimisée car le back end est isolé du front end", explique Hervé Leclerc, directeur technique de la SS2L. Un simple changement dans le manifeste de l’OS permettra en outre de passer à une version supérieure de l’orchestrateur. Exit les migrations lourdes impliquant une gestion des plans de contrôle, des workers, etc.
Maîtriser les flux entrants
"Ensuite, on mettra en place des règles de pare-feu frontaux pour maîtriser les flux entrants", note Florent Houy. Côté Kubernetes en tant que tel, on commencera par installer la boîte à outils kubeadm, mais aussi kubelet qui gérera le démarrage des pods et des containers. Ces deux composants installés, ne reste plus qu’à déployer le plan de contrôle qui n’est autre que le chef d’orchestre du cluster. "A partir de là, vous allez pouvoir déployer les WorkerNodes, là où vont s'exécuter vos applications", résume Hervé Leclerc.
Une fois le cluster Kubernetes installé, un outil baptisé kube-bench viendra contrôler si l’environnement a été correctement sécurisé. Il passera en revue les points de contrôle référencés dans le benchmark CIS Kubernetes. Il est conseillé d’éviter que les applications ne s’exécutent en mode root. Objectif : empêcher toute personne malintentionnée ayant pénétré un Pod et ses containers de profiter des droits de superadministrateur pour en prendre le contrôle. "Elle aurait alors la capacité d’installer de potentiels codes malicieux", prévient Hervé Leclerc.
"La segmentation réseau devra être finement mise en œuvre, tout comme le versionning de la distribution Kubernetes retenue, de Rancher à OpenShift"
Autre bonne pratique : paramétrer le système de fichiers des containers en read only. Seul le répertoire /tmp pourra par exemple avoir les droits d’écriture. Là encore, l’objectif est de limiter la surface d’attaque au minimum. De même, on installera au sein des images de container Docker uniquement les composants nécessaires à l’exécution des applications. Exit les composants Shell. Ce qui rendra certes l’application plus difficile à déboguer, mais contribuera à sécuriser l’environnement.
L’installation du composant Gatekeeper est aussi recommandée. Il s’agit d’une webhook d'admission personnalisable pour Kubernetes qui appliquera les politiques du standard open policy agent (OPA). Principale alternative : Kyverno. Ces contrôleurs permettent de vérifier la bonne application des règles de l’entreprise qui contribuent à renforcer la sécurité du système. Il pourra s’agir par exemple d’éviter de faire tourner des briques qui ne sont pas versionnées ou pour lesquelles il n’y aura pas eu de limites d’allocation de mémoire préalablement fixées. Le contrôleur bloquera l’installation de l’application ciblée, voire appliquera un correctif le cas échéant. Quant à Trivy, cette outil open source détectera les vulnérabilités ou les mauvaises configurations.
En parallèle, il est conseillé de bien veiller aux network policy. Il s’agit de définir la communication, pour une même application, entre les pods Kubernetes. "On va gérer les flux est-ouest et nord-sud, c'est-à-dire, les flux qui partent des pods vers d'autres pods, qu’ils soient dans le même namespace, ou dans des namespace différents. Mais également la manière dont les pods vont interagir avec l'extérieur, et réciproquement", détaille Hervé Leclerc. Et Florent Houy d’ajouter : "La segmentation réseau devra être finement mise en œuvre tout comme le versionning de la distribution Kubernetes retenue, de Rancher à OpenShift."
Normaliser les procédures
La composante opérationnelle devra elle-aussi être passée au crible. "Sur ce point se pose un certain nombre de questions clés : Comment l’environnement est-il exploité au quotidien ? Qui le met à jour ? Qui est le garant de toute la chaîne, depuis la sécurité et la gestion des identités en tant que telles à l’évolutivité en passant par l'aspect réseau", égraine Florent Houy. "L’objectif est de s'assurer que toute cette chaîne est bien conçue, notamment, par exemple, en matière de gestion des matrices de flux, de routage, de mise à jour des conteneurs, etc."
Dans le même temps, le chantier doit passer par un travail de normalisation. En ligne de mire : s’assurer que les process de sécurité soient mis en œuvre de manière cohérente. "On pourra normaliser la façon de prioriser les vulnérabilités ou encore la manière d’opérer les ouvertures de flux par exemple", explique Florent Houy. Et le consultant d’insister : "Kubernetes permet d’accélérer les déploiements. Désormais, la cybersécurité, qui, dans le passé, a eu l’image d’être lente, doit s’adapter et accélérer."
En aval si l’application est bâtie autour de microservices, il sera important que les échanges entre eux soient chiffrés par authentification mutuelle. Cette bonne pratique passe par la mise en œuvre d’un service mesh qui établira les droits de communication entre les différents composants et gérera le cryptage nécessaire.
Au final, une série d’outils permet d’encadrer la démarche de cybersécurité autour de Kubernetes. Les premiers sont centrés sur l’audit de la sécurité des clusters. Parmi eux figure Kubeaudit (qui s’installe au cœur de Kubernetes). C’est aussi le cas de Popeye ou de Kube-score. En parallèle, Falco est taillé pour détecter les comportements suspects en se basant, entre autres, sur les appels système et les logs. Aux côtés de ces offres, Kubescape s’articule autour d’une plateforme offrant une couverture complète de la sécurité, de bout en bout, tout au long du cycle de développement et de déploiement sur Kubernetes. "La brique Vault sera, elle, conçue pour assurer la confidentialité du cluster en mettant en œuvre une gestion externe des secrets", indique Hervé Leclerc.
Aux côtés de cette première batterie de technologies figurent les Cloud Native Application Protection Platform. "Parmi ces solutions, on compte CrowdStrike, Palo Alto, SentinelOne, Tenable ou Wiz", indique Florent Houy. "Elles permettront de standardiser les pratiques de sécurité touchant à Kubernetes quel que soit le cloud utilisé." Une manière d’assurer la protection d’une infrastructure Kubernetes en mode multicloud.