Sécuriser Azure Kubernetes avec Falco

Entré à la Cloud Native Computing Foundation comme « projet Sandbox » en 2018, le moteur de sécurité open source Falco - développé à l'origine par Sysdig - est sorti début mars du programme d'incubation de la CNCF pour passer au niveau de maturité Graduated. Cela signifie qu'il est considéré comme stable et prêt à servir dans les environnements de production, y compris Azure. Falco rejoint de nombreux composants clés des plateformes cloud native, notamment Helm, Envoy, etcd, KEDA et Cloud Events. Lors d’une récente conversation avec Loris Degioanni, CTO et fondateur de l’entreprise de sécurité Sysdig à l’origine du développement de Falco, ce dernier a évoqué la philosophie du projet et la manière dont il est utilisé dans les applications Kubernetes.

Pourquoi Falco ?

Les outils de sécurité capables de fonctionner dans Kubernetes et dans les conteneurs étaient devenus nécessaires. Les environnements de microservices qui montent et descendent en charge à la demande sont très éloignés des applications monolithiques d'autrefois ou des architectures plus récentes, comme N-tier ou orientées service. Les nouvelles instances doivent être dépistées et surveillées dès leur démarrage, de façon à disposer de la visibilité nécessaire pour les sécuriser au fur et à mesure de l’extension et de la complexification des maillages de services. D’une certaine façon, la sécurité cloud native est assez proche de l'observabilité dans le devops. La recherche ne porte pas sur des incidents spécifiques, mais sur des exceptions à la norme dans les schémas des données de télémétrie. Les outils de sécurité traditionnels peuvent aider à protéger le code exécuté dans un conteneur, mais pas à gérer les modèles sans serveur ou l'infrastructure dynamique. Sponsorisé et conçu par l’entreprise de sécurité du cloud Sysdig, le moteur de sécurité Falco peut fonctionner à un niveau très bas dans les conteneurs et les applications, avec un accès direct aux fonctions de mise en réseau au niveau du noyau et détecter ainsi les intrusions et les compromissions en temps réel dans l'ensemble de l'infrastructure applicative.

Falco peut travailler avec n'importe quelle distribution Kubernetes. (Crédit Sysdig)

Les données d'événements sont collectées et un moteur de règles est utilisé pour identifier les problèmes de sécurité. Il est possible de créer ses propres règles ou de travailler avec des règles développées par la communauté. Les règles de Falco sont équivalentes à des politiques. Comme le dit Loris Degioanni, « on peut utiliser le langage de politique de Falco pour définir une politique, comme on le ferait pour démarrer un shell interactif dans un des conteneurs Redis ». Quand une politique correspond, un événement est généré et transmis à un service de surveillance central, qui l'utilise pour fournir la réponse appropriée. Pour cela, Falco s’appuie en particulier sur des capteurs eBPF. Ces scripts en bac à sable qui s'exécutent à l'intérieur du noyau Linux, offrent une surveillance directe et rapide des appels de service. Outre une identification rapide des intrusions, ils permettent d'automatiser les réponses à l'aide d'applications externes, par exemple en lançant un événement cloud et en déclenchant des actions sans serveur qui protègent les données.

Sécuriser Kubernetes à partir du noyau Linux

Falco peut fonctionner dans n'importe quel cluster Kubernetes, y compris Azure Kubernetes Service, et fournir des événements à ses outils de sécurité existants. Grâce à cette approche, il est possible d'inclure les résultats de Falco dans Azure Sentinel et de travailler avec des agents d'intelligence artificielle pour identifier les problèmes qui ne seraient pas couverts par les propres règles de Falco. Parce que Falco travaille à un bas niveau et suit l'évolution des services, il s'apparente davantage à un outil d'observabilité qu'à un moniteur de sécurité traditionnel. Selon M. Degioanni Falco répond à la problématique de sécurisation d’un environnement très dynamique en perpétuel changement.

Travailler avec Kubernetes en tant qu'orchestrateur de microservices ajoute également de la complexité. Selon M. Degioanni, le défi est le suivant : « si l’on prend l’exemple d’utilisateurs qui ont 500 conteneurs à gérer dans une seule machine à 96 cœurs, s’ils doivent mettre quelque chose à l'intérieur de tous ces conteneurs et que leur charge monte et descende, c'est absolument irréalisable. Le capteur Falco se situant dans le noyau du système d'exploitation, quel que soit le nombre de conteneurs présents dans cette machine à 96 cœurs, il n’y a qu’une seule instrumentation. Si bien que, quand un conteneur monte et descend en charge, il n’est pas nécessaire d'attendre que l’instrumentation soit active dans ce conteneur, car elle est déjà active dans le noyau sous-jacent.

La manière la plus simple d'installer un logiciel dans Azure Kubernetes Service est d'utiliser Helm. La communauté Falco maintient un diagramme Helm qui installe Falco en tant que DaemonSet à partir du dépôt Falco GitHub. Cette approche permet d'automatiser le déploiement en utilisant Azure DevOps ou GitHub Actions. Il est inutile de penser à des déploiements manuels, car Falco sera utilisé dans le cadre d'une infrastructure idempotente, où chaque nouveau déploiement remplace le précédent. L'installation du chart Falco Helm est assez simple. Il suffit d'exécuter le chart à partir de son référentiel, de créer un espace de noms Falco dans son cluster, et de configurer des instances dans ses nœuds. Si l’on exécute Falco en tant que DaemonSet, il doit y avoir un pod Falco par nœud, en utilisant son runtime de conteneur actuel.

Exécuter Falco dans les hôtes Kubernetes

Si, au lieu d'utiliser Azure Kubernetes Service, on met en place son propre environnement Kubernetes sur Azure, on peut installer Falco dans le système hôte, en l'isolant de l'instance Kubernetes qu'il surveille. Les alertes sont toujours gérées à l'intérieur de Kubernetes, mais une installation sur le système hôte apporte une solution de repli en cas de compromission grave. L'équipe Falco fournit des instructions d'installation pour différentes versions de Linux, tant pour les distributions basées sur Debian comme Ubuntu que pour celles basées sur Red Hat. Les versions ARM et x64 sont prises en charge, ce qui permet de profiter des serveurs Azure à haute densité basés sur ARM de Microsoft.

Ce tableau et le fichier values.yaml répertorient les paramètres configurables de Falco. Ceux-ci servent à contrôler le fonctionnement du service, par exemple en gérant les pilotes utilisés pour héberger les capteurs et les API utilisées pour fournir des données à des services externes. Une autre caractéristique du chart Falco Helm est son ensemble de règles par défaut. Celles-ci facilitent la mise en route, mais au fur et à mesure que les applications Kubernetes se développent et que l’on acquiert davantage d'expérience dans la sécurité cloud native, on peut ajouter ses propres règles personnalisées dans leur propre fichier référencé à partir du chart d'installation. Les règles Falco sont écrites en YAML et peuvent faire référence à des ensembles de règles supplémentaires. Par exemple, on peut s’assurer que l’application n'utilise que des ports définis ou qu'elle ne peut engendrer que des processus spécifiques et connus. Tout ce qui se produit en dehors des règles par défaut et personnalisées déclenche une alerte.

Alimenter le moniteur de sécurité

Ceux qui utilisent déjà un outil de sécurité Azure comme Sentinel, voudront peut-être ajouter Falcosidekick à leur installation. Cette extension officielle aide à gérer les alertes, en les transmettant à Azure Event Hub et à son SIEM (gestionnaire d'informations et d'événements de sécurité). Sidekick inclut la possibilité d'ajouter des champs personnalisés aux alertes, et donc d'ajouter des détails sur le cluster Kubernetes qui envoie l'alerte. Cela peut s’avérer important pour surveiller plusieurs clusters, soit en exécutant des applications différentes dans chaque cluster, soit en géo-répliquant des applications à travers des régions Azure. D'autres outils permettent de se connecter au service managé Azure Monitor pour Prometheus, et d'utiliser Grafana pour construire et exécuter des tableaux de bord qui fournissent des informations de sécurité à l’équipe secops. Mais pourquoi utiliser Falco plutôt que d'autres outils de sécurité Kubernetes ? La réponse est simple : Falco est capable d'identifier de nouveaux schémas d'attaque pas forcément visibles par d'autres outils. Pouvoir comprendre, en cas de menace persistante lente ou d’exfiltration rapide, qu'une intrusion s'est produite permet de réagir rapidement, soit en verrouillant l'accès, soit en lançant des actions médico-légales plus complexes, tout en bloquant ces nouveaux comportements inattendus.

Stopper les « zero days » natifs du cloud

L’utilisation par Falco de capteurs eBPF pour identifier les activités inhabituelles au niveau du noyau maintien une certaine vigilance vis-à-vis d'éventuels exploits de type « zero-day » dans le code. Il est possible d’écrire des règles pour alerter sur des activités qui sortent du rôle courant de l’application et qui ne sont pas couvertes par les ensembles de règles existants. Ainsi, Falco offre un fourre-tout qui couvre des actions précédemment invisibles, qui pourraient indiquer des bogues dans le code ou les opérations d'un acteur de la menace. Cependant, il est inutile de déployer Falco seul. Azure dispose de ses propres outils de sécurité qui fonctionnent avec Falco pour fournir une approche stratifiée de la sécurisation de l’environnement Kubernetes. Falco ne fonctionne pas avec les applications .NET ou pour surveiller Redis ou PostgreSQL, si bien qu’il faudra travailler avec tous les outils disponibles pour protéger ses services. Il est essentiel d'alimenter un SIEM avec tous les signaux provenant de l'ensemble de l’environnement applicatif. Il faut être en mesure de travailler avec Falco et tous les autres outils de surveillance pour faire la distinction entre une attaque et une défaillance, et pour adapter ses réponses de manière appropriée. Maintenant que Falco est un projet CNCF à part entière, intégré dans la pile de plateformes Kubernetes, on peut commencer à assembler ces pièces et à construire des applications cloud-natives sécurisées et fiables, aussi bien sur site que dans le cloud.