Principes de base de la sécurité des conteneurs : charges de travail

Si vous découvrez cette série, nous vous conseillons de commencer par le début :
Principes fondamentaux de la sécurité des conteneurs : introduction
Principes fondamentaux de la sécurité des conteneurs : pipeline
Principes fondamentaux de la sécurité des conteneurs : orchestration

Le terme « charge de travail » est relativement récent. Il est souvent utilisé pour désigner des applications, mais peut également faire référence à des services d’infrastructure. C’est un point important, car différents types de « charges de travail » peuvent s’exécuter dans vos clusters de conteneurs sans nécessairement provenir de vos développeurs. L’utilisation de services gratuits et open source à diverses fins dans les environnements de conteneurs est en plein essor. Cette tendance s’observe d’ailleurs dans l’ensemble des opérations informatiques, qui constituaient l’an dernier la première catégorie de téléchargements de logiciels gratuits et open source.

Ainsi, lorsque nous parlons de sécurité des charges de travail, nous entendons tout logiciel que vous avez téléchargé, développé ou déployé dans votre environnement de conteneurs. Pensez à Consul. Pensez à Kubernetes lui-même. Pensez à Prometheus et à Elasticsearch. Pensez à NGINX et à istio.

Ajoutez également à cette liste toutes les passerelles API, tous les caches et tous les contrôleurs d’entrée que vous avez déployés pour prendre en charge votre environnement Kubernetes. C’est là qu’une nomenclature exhaustive prend toute son importance et qu’un inventaire régulier s’avère essentiel pour maintenir un environnement sécurisé.

Une fois votre liste établie, il est temps de vous attaquer aux principaux enjeux de sécurité des charges de travail.

• 1. L’authentification n’est pas facultative
  Si vous avez suivi l’intégralité de cette série, vous connaissez déjà le sujet. C’est l’un des thèmes récurrents dans tous les aspects de la sécurité des conteneurs : verrouillez la porte d’entrée.
  
  Tous ces services s’exécutent en tant que charges de travail dans un cluster. Cela implique souvent des identifiants par défaut ou une configuration initiale « ouverte » pour accéder aux API et aux données. La sécurité des charges de travail englobe tous les composants, logiciels et services applicatifs nécessaires au fonctionnement de l’application et à son exploitation.
  
  
• 2. Un contenu malveillant reste malveillant
  Même après avoir verrouillé la porte en exigeant des identifiants et en appliquant un contrôle d’accès, vous devez toujours vous méfier des contenus malveillants. Cela vaut pour les applications, les microservices et les services opérationnels utilisés. Toutes les charges de travail qui présentent une interface à un utilisateur (qu’il s’agisse d’un opérateur ou d’un consommateur) sont potentiellement exposées. Il est donc impératif d’effectuer des analyses et d’agir en conséquence. La première étape consiste à détecter les vulnérabilités dans la couche applicative, qu’elles concernent le protocole HTTP ou la logique applicative. Une fois ces vulnérabilités identifiées, il faut y remédier. S’il s’agit d’une application personnalisée, renvoyez-la à l’équipe de développement. S’il s’agit d’un composant tiers, vérifiez s’il existe une version corrigée ou mise à niveau. Les composants tiers sont souvent fournis sous forme d’images de conteneurs et, comme l’indique Snyk dans son rapport 2019 sur l’état de la sécurité des logiciels open source, 44 % d’entre eux présentent des vulnérabilités connues pour lesquelles des images de base plus récentes et plus sécurisées existent.
  
  Répétons-le : effectuer une analyse n’améliore en rien la sécurité si vous ne corrigez pas les vulnérabilités détectées.
  
  Si votre mur comportait une brèche permettant à d’éventuels cambrioleurs de contourner facilement les portes verrouillées, vous la colmateriez. Faites donc de même avec les brèches virtuelles de vos murs virtuels.
  
  L’utilisation d’un pare-feu applicatif web ou d’une passerelle de sécurité des API peut permettre de réduire les risques lorsque les vulnérabilités ne peuvent pas être immédiatement corrigées par les développeurs ou qu’elles n’ont pas encore été résolues par les fournisseurs tiers.
  
  En résumé, il faut « filtrer les appels », c’est-à-dire inspecter et évaluer les requêtes adressées à chaque charge de travail avant de les accepter.
  
  
• 3. Ressources partagées, risques partagés
  Comme dans le cas de la virtualisation traditionnelle, les conteneurs ne sont pas totalement isolés. Ils partagent en définitive le même système d’exploitation physique. Les vulnérabilités du système d’exploitation partagé sont donc communes à tous les conteneurs.

Si un attaquant parvient à exploiter une vulnérabilité dans des composants du système d’exploitation, il peut compromettre une ou plusieurs charges de travail. Ces vulnérabilités peuvent être exposées si vous ne « verrouillez pas la porte » ou ne « filtrez pas vos appels ». Ce scénario est loin d’être improbable, comme nous l’avons vu avec CVE-2019-5736, où une vulnérabilité de runc au niveau du système d’exploitation a semé la panique sur Internet.

Le principe de sécurité fondamental a été formulé de manière célèbre par Dan Walsh, expert de la sécurité des conteneurs chez SELinux et Red Hat, en ces termes : « Les conteneurs ne confinent pas ».

Il est important de noter que l’ensemble du trafic réseau échangé avec des services et des utilisateurs extérieurs au nœud doit transiter par le système d’exploitation hôte. La mise en réseau des pods et des conteneurs sur un nœud repose sur un réseau virtuel, des ponts virtuels et une utilisation ingénieuse d’iptables. Mais au bout du compte, le trafic doit quitter ce nœud physique, ce qui implique son traitement par le système d’exploitation hôte. Des agents, des plug-ins et d’autres démons peuvent observer ou capturer ce trafic à des fins de sécurité ou de visibilité. Il s’agit de points de compromission potentiels que vous devez ajouter à l’inventaire que vous avez commencé à dresser après avoir lu la section consacrée à la sécurité des pipelines.

• 4. Journalisation de données sensibles
  Vous ne vous attendiez peut-être pas à ce qu’une discussion sur la sécurité des conteneurs comporte une mise en garde concernant les journaux. Pourtant, c’est bien le cas, car des informations sensibles se retrouvent parfois dans les fichiers journaux : jetons d’autorisation, clés de fournisseurs de chiffrement, identifiants. Toutes ces informations peuvent être consignées par inadvertance ou affichées par des charges de travail sur stderr. Cela tient souvent à la nécessité de diagnostiquer des problèmes liés à des erreurs d’authentification. De manière générale, vous devez déconseiller — voire interdire si possible — la consignation de secrets dans le système.
  
  Pour vous assurer que les développeurs sont conscients de ce risque, envisagez de leur fournir un guide de conception de la journalisation précisant ce qu’il est acceptable ou non d’écrire dans les journaux.

Dans un environnement de conteneurs, la sécurité des charges de travail repose en grande partie sur les mêmes principes que pour toute autre charge applicative exécutée dans votre environnement de production. Contrôlez les accès et imposez une authentification forte, surveillez les contenus malveillants et tenez compte des vulnérabilités liées aux ressources partagées et à la plateforme.