La popularité croissante des conteneurs et de Kubernetes (K8s) a entraîné une évolution fulgurante du monde informatique. En sept ans à peine, nous sommes passés de la machine virtuelle aux conteneurs, puis à une plateforme d’orchestration des conteneurs (la première version de Docker a été lancée en 2013). Tandis que certaines jeunes entreprises découvrent encore comment exploiter ces nouvelles ressources, certaines sociétés plus établies envisagent de migrer leurs systèmes existants vers des infrastructures plus efficaces.

Si l’adoption rapide des conteneurs et de Kubernetes témoigne de leur caractère révolutionnaire, ces technologies ont également engendré de nouveaux problèmes de sécurité. Leur grande popularité et l’absence de mesures de sécurité adéquates dans de nombreuses entreprises ont fait de la conteneurisation et de Kubernetes une cible parfaite pour les cybercriminels.

Un cluster Kubernetes est un ensemble de machines gérées par un nœud maître (et ses répliques). Il peut couvrir plusieurs milliers de machines et services et peut à ce titre devenir un vecteur d’attaque privilégié. C’est pourquoi il est indispensable d’adopter des pratiques de sécurité rigoureuses.

Sécurisation du cluster

Un cluster Kubernetes contient de nombreux éléments qui doivent être correctement sécurisés. Cependant, il est impossible d’assurer la sécurité du cluster en un seul processus. La sécurité de l’ensemble du cluster nécessite la mise en œuvre d’un certain nombre de bonnes pratiques et une équipe de sécurité chevronnée.

Dans cet article, nous aborderons plusieurs vecteurs d’attaque Kubernetes différents, ainsi que les bonnes pratiques permettant d’assurer la sécurité de votre cluster Kubernetes.

Mise à jour de Kubernetes et ses nœuds

Kubernetes est un système open source qui est mis à jour en continu. Son référentiel GitHub est l’un des référentiels les plus actifs de la plateforme. Ainsi, de nouvelles fonctionnalités, optimisations et mises à jour de sécurité sont constamment introduites.

Tous les quatre mois, une nouvelle version principale de Kubernetes est publiée. Chaque nouvelle version comprend de nouvelles fonctionnalités destinées à améliorer le service, mais pouvant également introduire de nouveaux problèmes de sécurité ou bugs — ce à quoi tout logiciel est sujet, surtout s’il est fréquemment mis à jour.

Cependant, même les anciennes versions peuvent comporter des failles de sécurité. Il est donc essentiel de comprendre comment l’équipe de Kubernetes gère les mises à jour de sécurité dans les anciennes versions. Contrairement aux distributions Linux ou à d’autres plateformes, Kubernetes ne propose pas de version LTS avec support à long terme. En effet, le système Kubernetes tente de rétroporter les corrections des problèmes de sécurité dans les trois dernières versions principales distribuées.

Il est donc essentiel de maintenir votre cluster dans l’une des trois versions principales les plus récentes, d’appliquer régulièrement les correctifs de sécurité et de prévoir une mise à jour vers la dernière version principale au moins tous les douze mois.

Outre ses principaux composants, Kubernetes gère également les nœuds qui exécutent la charge de travail assignée au cluster. Ces nœuds peuvent être des machines physiques ou virtuelles dotées d’un système d’exploitation. Chaque nœud représente un vecteur d’attaque potentiel qui doit être mis à jour pour éliminer les problèmes de sécurité. Les nœuds doivent donc être aussi propres que possible afin de réduire la surface d’attaque.

Contrôle de l’accès des utilisateurs

Le contrôle d’accès basé sur les rôles constitue l’un des meilleurs moyens de contrôler quels utilisateurs ont accès au cluster et comment. Il permet de définir un ensemble d’autorisations granulaires pour chaque utilisateur. Comme les règles s’ajoutent les unes aux autres, toute autorisation doit être explicitement définie. Grâce au contrôle d’accès basé sur les rôles, il est possible de limiter les autorisations d’accès (affichage, lecture ou écriture) à chaque objet Kubernetes, des pods (la plus petite unité de calcul de Kubernetes) aux espaces de noms.

Le contrôle d’accès basé sur les rôles peut également être rattaché à un autre service d’annuaire à l’aide de tokens de connexion OpenID. Cela permet de définir la gestion des groupes et des utilisateurs de manière centralisée pour une utilisation plus large au sein de l’entreprise.

L’autorisation d’accès n’est pas limitée à Kubernetes. Parfois, les utilisateurs peuvent avoir besoin d’accéder à un nœud de cluster pour identifier des problèmes, par exemple. Le cas échéant, il est préférable de créer des utilisateurs temporaires pour résoudre ces problèmes, puis de les supprimer.

Bonnes pratiques en matière de conteneurs

Docker, la principale technologie de conteneurs, est composé de couches : la couche interne est la structure la plus primitive, tandis que la couche externe est la plus spécifique. Ainsi, toutes les images Docker commencent par un type de prise en charge de langage ou de distribution, et chaque nouvelle couche complète ou modifie la fonctionnalité précédente jusqu’à la toute dernière couche. Le conteneur dispose alors de tout ce dont il a besoin pour faire tourner l’application.

Ces couches (également appelées images) peuvent être disponibles publiquement dans Docker Hub ou à titre privé dans un autre registre d’images. L’image peut être exprimée sous deux formes : sous la forme d’un nom assorti d’un libellé (par exemple, node:latest) ou par son identifiant SHA immuable (par exemple, sha256:d64072a554283e64e1bfeb1bb457b7b293b6cd5bb61504afaa3bdd5da2a7bc4b pour la même image au moment de la rédaction).

L’image associée au libellé peut être modifiée à tout moment par le propriétaire du référentiel ; ainsi, le marqueur latest indique la dernière version disponible. Cela signifie également que lors de la création d’une nouvelle image ou de l’exécution d’une image avec marqueur, la couche interne peut être modifiée subitement, sans préavis.

Cette stratégie pose bien sûr certains problèmes : (1) Vous perdez le contrôle de ce qui se passe dans votre instance Kubernetes puisqu’une couche supérieure peut être mise à jour et ajouter un conflit, ou (2) l’image peut être modifiée intentionnellement pour introduire une faille de sécurité.

Pour prévenir le premier problème, évitez d’utiliser le marqueur latest, et optez pour un marqueur plus spécifique à la version (par exemple, node:14.5.0). Et pour éviter le deuxième problème, optez pour des images officielles, clonez l’image dans votre référentiel privé, ou utilisez la valeur SHA.

Une autre approche consiste à utiliser un outil de détection des vulnérabilités pour analyser en permanence les images utilisées. Ces outils peuvent fonctionner conjointement avec les pipelines d’intégration continue et peuvent surveiller le référentiel d’images afin d’identifier les problèmes non détectés jusque là.

Lors de la création d’une nouvelle image, il est important de se rappeler que chaque image ne doit contenir qu’un seul service. Toute l’image doit être créée de façon à n’avoir que les dépendances nécessaires à cette application et rien d’autre. Cela réduit la surface d’attaque aux seuls éléments essentiels au service. Le fait de n’avoir qu’une seule application par image facilite également la mise à jour vers une nouvelle version et l’allocation des ressources dans le module d’orchestration.

Sécurité réseau

Les recommandations de la section précédente se concentraient sur la réduction de la surface d’attaque, et le même principe s’applique aux réseaux. Kubernetes contient des réseaux virtuels à l’intérieur du cluster, qui peuvent restreindre l’accès entre les pods et contrôler l’accès externe de sorte que seuls les services autorisés soient accessibles. Il s’agit là d’une solution primitive qui fonctionne bien pour les petits clusters.

Cependant, les clusters de grande taille qui contiennent plusieurs services développés par différentes équipes sont beaucoup plus complexes, et une approche centralisée peut être impossible à gérer. Dans de tels cas, les maillages de services sont actuellement la meilleure méthode disponible. Les maillages de services créent une couche de chiffrement du réseau qui permet aux services de communiquer entre eux en toute sécurité. Ils fonctionnent généralement comme un agent sidecar attaché à chaque pod et qui assure la communication entre les services. Le rôle des maillages de services n’est pas limité à la sécurité. En effet, ils permettent également la découverte des services, la surveillance/le traçage/la journalisation, et préviennent les interruptions de service en jouant le rôle de disjoncteur par exemple.

Établissement de quotas de ressources

Comme les applications sont mises à jour en permanence, l’implémentation des mesures présentées ci-dessus pour sécuriser votre cluster est en soi insuffisante, car il existe toujours un risque de faille de sécurité.

L’utilisation de quotas de ressources, où Kubernetes limite la protection contre les pannes aux contraintes établies, constitue une autre mesure importante. Si les contraintes sont bien conçues, elles empêcheront que tous les services du cluster ne soient indisponibles en raison de l’épuisement des ressources.

Elles peuvent également vous éviter d’avoir à payer une facture cloud astronomique à la fin du mois.

Surveillance et journalisation

La surveillance du cluster, du cluster aux pods, est indispensable pour découvrir les pannes et en déterminer la cause. Il s’agit de détecter les comportements anormaux. Si le trafic réseau a augmenté ou si le processeur des nœuds agit différemment, il convient de rechercher les causes du phénomène afin d’écarter tout problème. Si la surveillance porte essentiellement sur les mesures telles que l’utilisation du processeur, de la mémoire ou de la bande passante, la journalisation peut fournir des informations supplémentaires (historiques) qui peuvent aider à détecter des comportements récurrents inhabituels ou à identifier rapidement la source du problème.

L’utilisation conjointe de Prometheus et Grafana permet une surveillance efficace de Kubernetes. Prometheus est une base de données de séries temporelles extrêmement performante, tandis que Grafana est un tableau de bord graphique capable de lire les données de Prometheus et de les synthétiser dans des tableaux de bord conviviaux.

ElasticSearch est également très utile. Il s’agit de l’un des outils les plus prisés pour la journalisation centralisée en temps quasi réel de l’application, des nœuds et de Kubernetes lui-même.

Installation cloud ou sur site sous l’angle de la sécurité

Kubernetes peut soit être installé sur site, soit reposer sur un service de gestion cloud. Dans le scénario sur site, chaque étape de configuration (installation de nouvelles machines, mise en réseau et sécurisation de l’application) doit être effectuée manuellement. Les services gérés tels que Google GKE, AWS EKS ou Azure AKS permettent d’installer Kubernetes avec une configuration minimale et sont compatibles avec les autres services du fournisseur de services cloud.

Du point de vue de la sécurité, les solutions sur site exigent beaucoup plus d’attention. Comme indiqué précédemment, chaque nouvelle mise à jour doit être téléchargée et configurée par le système, et les nœuds doivent également être mis à jour. Il est donc recommandé que seules les équipes expérimentées déploient Kubernetes sur site.

Avec les services de gestion cloud, en revanche, le processus est beaucoup plus simple, puisque Kubernetes est déjà installé et que le fournisseur cloud maintient tous les nœuds à jour avec les dernières fonctionnalités de sécurité. En ce qui concerne le cluster, la plupart des fournisseurs cloud permettent aux utilisateurs de choisir la version de Kubernetes la mieux adaptée à leurs besoins parmi un nombre d’options limité, et leur offrent également des moyens de la mettre à jour vers une nouvelle version. Ainsi, si cette méthode est plus simple, elle est aussi moins flexible.

Pour conclure

Face à des mises à jour continues et à une multitude de nouveaux outils sur le marché, il peut être difficile de rester à jour et de se tenir au courant des vulnérabilités. Les compromissions sont inévitables. Avec Kubernetes, le défi est encore plus grand, car ce n’est pas qu’un simple outil. Kubernetes est plutôt un ensemble d’outils qui gère d’autres outils, les machines et les réseaux ; sa sécurité est donc primordiale.

Mais vu le nombre d’éléments en jeu, assurer la sécurité de Kubernetes n’est pas une mince affaire, alors assurez-vous de suivre ces recommandations :

• Effectuez des analyses régulières sur les applications exécutées sur Kubernetes afin de détecter les problèmes de sécurité.
• Limitez et contrôlez l’accès.
• Veillez à appliquer les dernières mises à jour de sécurité et surveillez le cluster en continu afin de remédier immédiatement aux pannes et ainsi de limiter les dommages.

Le défi est encore plus grand dans le cas des déploiements sur site, où il faut gérer du matériel physique, créer des automatisations et maintenir à jour un nombre encore accru de logiciels. Toutefois, en suivant les bonnes pratiques décrites dans cet article, vous pouvez garder une longueur d’avance sur les cybercriminels et préserver la sécurité et le bon fonctionnement de votre environnement Kubernetes.

La plateforme SentinelOne prend en charge les machines physiques et virtuelles, Docker, les déploiements Kubernetes autogérés et les déploiements Kubernetes gérés par un fournisseur cloud tels qu’AWS EKS. Pour en savoir plus, demandez une démonstration gratuite dès aujourd’hui.