Gestion des menaces de sécurité du moteur d’exécution dans Kubernetes

La plupart des administrateurs comprennent ce qu’est la sécurité du moteur d’exécution et quelle est son importance. Pourtant, ils sous-estiment souvent la sécurité du moteur d’exécution dans le cadre de leur stratégie de sécurité Kubernetes ou n’investissent pas assez dedans.

La raison est simple. Kubernetes est un système tellement complexe, qui offre tellement de types différents d’outils natifs pour aider à accéder à des privilèges et à isoler des workloads, que les équipes peuvent être tellement préoccupées par la sécurisation du cluster en soi qu’elles en oublient la sécurité du moteur d’exécution de Kubernetes.

Pour permettre de combler cette lacune, cet article explique les raisons pour lesquelles la sécurité du moteur d’exécution dans Kubernetes est si importante et présente les outils disponibles pour aider à sécuriser Kubernetes contre les menaces liées au moteur d’exécution.

Qu’est-ce que la sécurité du moteur d’exécution dans Kubernetes ?

La sécurité du moteur d’exécution de Kubernetes consiste à protéger les containers (ou pods) contre les menaces actives une fois les containers en cours d’exécution.

La sécurité du moteur d’exécution aide à protéger les workloads contre une variété de menaces qui pourraient apparaître après le déploiement de containers, telles que celles-ci :

L’activation d’un logiciel malveillant dans une image de container.
Attaques par élévation de privilèges dans lesquelles un container exploite des bogues de sécurité dans le moteur d’exécution du container, Kubernetes ou l’OS hôte, dans le but d’accéder à des ressources auxquelles il ne devrait pas pouvoir accéder (comme des volumes de stockage ou des fichiers binaires externes).
Le déploiement de containers non autorisés par une personne mal intentionnée qui exploite une faille dans une politique de contrôle d’accès ou un bogue dans Kubernetes.
Accès non autorisé à des informations secrètes ou sensibles qu’un container en cours d’exécution ne devrait pas pouvoir lire, mais auxquelles il parvient à accéder en raison d’une mauvaise configuration du contrôle d’accès ou d’une faille de sécurité permettant une élévation de privilèges.

Dans un monde parfait, aucune de ces menaces de moteur d’exécution ne se concrétiserait, car vous sécuriseriez vos pipelines d’application et vos clusters de façon à ce que les menaces ne se retrouvent jamais exploitables dans un environnement réel. Vous utiliseriez également des contrôles d’accès stricts pour vous assurer que chaque workload est correctement isolé, de manière à empêcher efficacement un container compromis de causer des dommages au cluster.

Dans le monde réel, bien sûr, il est impossible de s’assurer que des personnes mal intentionnées ne vont pas introduire discrètement des logiciels malveillants dans une image de container en compromettant votre référentiel de code source ou vos outils de génération, par exemple. Il n’est pas non plus possible de s’assurer que vos politiques RBAC et contextes de sécurité Kubernetes garantissent un isolement infaillible entre les différents workloads.

C’est pourquoi la sécurité du moteur d’exécution est si importante. Il s’agit de la dernière barrière de défense contre les menaces qui peuvent s’introduire dans un environnement Kubernetes. Si vous pouvez prendre toutes les mesures raisonnables pour atténuer les risques de sécurité au sein de l’architecture du pipeline et du cluster (ce qui est même indispensable), vous avez également besoin d’une sécurité du moteur d’exécution pour contrôler les menaces qui passent outre vos autres défenses et vous alerter lorsque cela se produit.

Outils de sécurité du moteur d’exécution Kubernetes

Kubernetes en soi offre relativement peu d’outils de sécurité du moteur d’exécution. La seule véritable ressource qu’il fournit est l’audit, qui vous permet de générer des journaux de façon à suivre les demandes de ressources à l’API Kubernetes.

Cependant, bien que Kubernetes puisse enregistrer ces informations, Kubernetes ne peut pas analyser les journaux d’audit ou vous alerter sur une activité suspecte.

Ainsi, plutôt que de vous tourner vers Kubernetes en soi pour sécuriser votre environnement contre les menaces liées au moteur d’exécution, vous devrez vous appuyer sur des outils de sécurité du moteur d’exécution externes. Pour Kubernetes, ces outils se répartissent en deux grandes catégories : les outils d’application et les outils d’audit.

Outils d’application de la sécurité du moteur d’exécution

Les outils d’application permettent de définir des politiques qui restreignent les droits d’accès et les autorisations des ressources dans un environnement de moteur d’exécution. Si les outils ne peuvent pas empêcher une menace de se matérialiser, ils peuvent en revanche en réduire l’impact en veillant, par exemple, à ce qu’un logiciel malveillant apparaissant dans un container ne puisse pas accéder à des ressources extérieures à ce container.

Voici une sélection des principaux outils d’application pour Kubernetes :

Seccomp : Seccomp est un outil Linux qui fonctionne au niveau du noyau, que vous pouvez utiliser pour forcer les processus à s’exécuter dans un état sécurisé. Lorsque vous utilisez Seccomp pour définir un processus dans un état sécurisé, le noyau empêche le processus d’effectuer tout appel système autre que exit, sigreturn et la lecture et l’écriture de fichiers déjà ouverts.
SELinux : SELinux est un module noyau qui vous permet de définir un large éventail de contrôles d’accès que le noyau applique. Vous pouvez utiliser SELinux pour définir des règles granulaires concernant les ressources auxquelles un container peut accéder et les types d’actions qu’il peut effectuer.
AppArmor : AppArmor est également un module noyau qui permet de définir un large éventail de règles de contrôle d’accès. Il est très similaire à SELinux sur de nombreux points ; le débat sur l’utilisation de SELinux ou d’AppArmor rejoint celui sur vi ou emacs : certaines personnes préfèrent un outil ou l’autre, mais vous pouvez obtenir globalement les mêmes résultats avec les deux solutions.

Dans une certaine mesure, on peut considérer que les politiques RBAC et les contextes de sécurité Kubernetes fournissent également un certain niveau de contrôle de l’application, car il est possible de les utiliser pour empêcher un container de fonctionner en mode privilégié ou pour interdire l’accès aux ressources de niveau noyau.

Cependant, la différence entre les politiques RBAC et les contextes de sécurité d’une part et les outils comme SELinux et AppArmor d’autre part, est que ces derniers appliquent les contrôles d’accès au niveau du noyau. Cela signifie que même si Kubernetes en soi est compromis d’une manière ou d’une autre ou est exposé à une faille de sécurité, les outils d’application au niveau du noyau peuvent réduire l’impact d’une violation de la sécurité en empêchant les containers compromis d’accéder à des ressources externes.

SELinux, AppArmor et Seccomp sont également pratiques, car ils peuvent être utilisés pour contrôler l’accès à tout type de workload Linux. Ils ne sont pas spécifiques à Kubernetes. Si vous gérez un environnement qui comprend une variété de containers et de VMs, les frameworks de contrôle d’accès au niveau du noyau peuvent vous être utiles, car vous pouvez utiliser le même outil pour gérer tous vos workloads.

Outils d’audit pour la sécurité du moteur d’exécution

Les outils d’audit de Kubernetes vous aident à détecter les menaces et à y apporter une réponse en fonction des données collectées dans votre cluster.

Là encore, Kubernetes fournit les outils nécessaires pour générer des journaux d’audit, mais n’analyse pas véritablement les journaux pour vous. C’est pour cette raison qu’un outil comme Falco, qui est un moteur de détection des menaces open source, peut vous être très utile. Falco vous permet de définir des règles qui déclencheront des alertes si le moteur Falco détecte la présence de certaines conditions basées sur des données, telles que les journaux d’audit de Kubernetes.

Par exemple, prenons cette règle de Falco :

- rule: Example rule (nginx). This is the human name for the rule.
desc: Detect any listening socket outside our expected one.
condition: evt.type in (accept,listen) and (container.

image!=myregistry/nginx or proc.name!=nginx or k8s.ns.name!=”load-
balancer”)

output: This is where I write the alert message and I provide some
extra information (command=%proc.cmdline connection=%fd.name).
priority: WARNING

Dans cette règle, tout socket d’écoute qui ne répond pas aux critères suivants déclenchera une alerte :

L’image est myregistry/nginx.
Le processus d’écoute est nginx.
Le namespace est load-balancer.

Avec une règle de ce type, vous pouvez détecter les containers qui s’exécutent dans votre environnement et qui pourraient essayer de collecter des données ou d’accéder à des ressources non autorisées. Vous pouvez également utiliser une règle comme celle-ci pour détecter les containers non autorisés.

Falco est devenu l’outil d’audit incontournable pour Kubernetes et les plates-formes similaires et ce, pour plusieurs raisons. En plus d’être open source, Falco offre la possibilité de travailler avec tout type d’environnement cloud natif, et pas uniquement Kubernetes.

En parallèle, le référentiel Cloud Native Security Hub, qui propose des dizaines de règles Falco préconfigurées et adaptées à différents types de workloads, permet de configurer Falco rapidement sans avoir à écrire à la main tout un ensemble de règles d’audit.

Meilleures pratiques pour la sécurité du moteur d’exécution Kubernetes

Alors que le déploiement d’outils d’application et d’audit compte partie les étapes incontournables pour faire face aux menaces de sécurité du moteur d’exécution de Kubernetes, vous voudrez certainement aller plus loin et ne pas vous contenter de simplement configurer ces outils. Vous devriez également respecter les points suivants :

Effectuez une analyse d’image en continu : bien que l’analyse d’image ne soit pas une opération de sécurité du moteur d’exécution en soi (elle relève de la sécurité du pipeline), elle est importante pour empêcher les logiciels malveillants d’atteindre un environnement d’exécution.
Analysez les fichiers de politique de Kubernetes : vous pouvez également faire en sorte d’éviter les problèmes de sécurité du moteur d’exécution en analysant les fichiers RBAC de Kubernetes, les déploiements et d’autres ressources afin de détecter les mauvaises configurations qui pourraient permettre ou aggraver une violation du moteur.
Analysez les fichiers de politique externe : vous devez également analyser les fichiers de politique ou les profils que vous créez pour SELinux, AppArmor ou d’autres frameworks. Des omissions dans ces fichiers pourraient fragiliser la sécurité du moteur d’exécution.
N’oubliez pas l’environnement de test et de développement : lorsque vous appliquez des défenses de sécurité du moteur d’exécution, il est probable que vous vous concentriez d’abord et avant tout sur votre environnement de production. Après tout, c’est dans cet environnement que les menaces ont généralement le plus d’impact. Mais n’oubliez pas de sécuriser également l’environnement de test et de développement. La détection des menaces du moteur d’exécution au sein de l’environnement de test et développement est un bon moyen de les empêcher d’atteindre votre environnement de production. De plus, même dans un environnement de test et de développement, un problème de sécurité du moteur d’exécution peut avoir des conséquences importantes si, par exemple, une personne mal intentionnée est capable d’accéder à des données secrètes à partir de ressources présentes dans cet environnement.
Établissez un plan pour apporter une réponse à l’incident : n’attendez pas qu’une violation se produise pour commencer à prévoir une réponse. Développez des playbooks qui guideront votre équipe à travers la gestion de différents types d’événements de sécurité du moteur d’exécution. Que ferez-vous dans le cas d’une attaque par élévation de privilèges, par exemple ? Que faire si un nœud est compromis, mais que les autres ne le sont pas ? En réfléchissant à l’avance à ces questions, vous pourrez réagir plus rapidement aux menaces qui se produiront en direct.

La sécurité du moteur d’exécution est le seul paramètre qui se dresse entre votre cluster et les menaces qui sont parvenues à échapper aux autres défenses que vous avez érigées au sein de votre pipeline de développement d’applications et de votre architecture Kubernetes. Néanmoins, en effectuant un audit de façon continue de vos environnements d’exécution et en utilisant des outils d’application pour segmenter les ressources du moteur d’exécution les unes par rapport aux autres, vous pouvez réduire l’impact potentiel des menaces qui pèsent sur le moteur.