Notions de base sur la sécurité des conteneurs : Charge de travail

Si vous débutez dans cette série, vous souhaiterez peut-être commencer par le début : 
Notions de base sur la sécurité des conteneurs : Introduction
Notions de base sur la sécurité des conteneurs : Pipeline
Notions de base sur la sécurité des conteneurs : Orchestration

La charge de travail est un terme assez récent qui est souvent utilisé pour décrire les applications , mais peut également faire référence aux services d'infrastructure. C’est important, car il peut y avoir une variété de « charges de travail » exécutées dans vos clusters de conteneurs qui ne proviennent pas nécessairement de vos développeurs. L’utilisation de services gratuits et open source à diverses fins dans des environnements de conteneurs est en pleine croissance. C'est également vrai pour les opérations informatiques, qui ont été la première catégorie de téléchargements de logiciel libre au cours de l'année écoulée.

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

Ajoutez ensuite à cette liste toutes les passerelles API, les caches et les contrôleurs d’entrée que vous avez déployés pour prendre en charge votre environnement Kubernetes. C'est là qu'une liste complète des matériaux est importante et pourquoi il est essentiel de réaliser un inventaire régulier pour maintenir un environnement sécurisé.

Une fois que vous avez établi votre liste, il est temps d’aborder les principaux problèmes de sécurité de la charge de travail.

• 1. L'authentification n'est pas facultative
  Si vous avez suivi toute cette série, c'est du déjà-vu pour vous. C’est l’un des thèmes communs à tous les aspects de la sécurité des conteneurs : verrouiller la porte d’entrée.
  
  Tous ces services s’exécutent en tant que charges de travail dans un cluster. Cela signifie souvent des informations d’identification par défaut ou une configuration initiale « ouverte » pour accéder aux API et aux données. La sécurité de la charge de travail inclut tous les composants, logiciels et services application nécessaires au fonctionnement et à la fonctionnalité de application . 
  
  

• 2. Le contenu malveillant est malveillant
  Même après avoir verrouillé la porte en exigeant des informations d'identification et en appliquant un contrôle d'accès, vous devez toujours vous soucier du contenu malveillant. Cela est vrai pour les applications, les microservices et les services opérationnels en cours d’utilisation. 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 à risque.

  C'est là que la numérisation et l'action sont indispensables. La première étape consiste à détecter les vulnérabilités au niveau de la couche application , qu’il s’agisse de HTTP ou de la logique application . Une fois que vous les avez trouvés, il est temps de faire quelque chose à leur sujet. S'il s'agit d'une application personnalisée, renvoyez-la au développement. S'il s'agit d'un composant tiers, déterminez si une version corrigée/mise à niveau existe ou non. Les composants tiers sont souvent livrés dans des images de conteneur et, comme l'a noté Snyk dans son rapport 2019 sur l'état de la sécurité Open Source , 44 % d'entre eux présentent des vulnérabilités connues pour lesquelles il existe des images de base plus récentes et plus sécurisées .
  
  Répétons-le : exécuter une analyse ne contribue en rien à améliorer la sécurité si vous ne prenez pas de mesures correctives.
  
  Si vous avez un trou dans votre mur qui permet aux cambrioleurs potentiels de contourner facilement les portes verrouillées, vous devez les boucher. Alors bouchez les trous virtuels dans vos murs virtuels.
  
  L’utilisation d’un pare-feu application Web ou d’une passerelle de sécurité API peut fournir un moyen de remédier aux vulnérabilités lorsque les développeurs ne peuvent pas immédiatement traiter ou n’ont pas encore été résolus par des fournisseurs tiers.
  
  Cela peut être résumé par « filtrer vos appels », car il s’agit d’inspecter et d’évaluer les demandes adressées à n’importe quelle charge de travail avant de l’accepter.
  
  
• 3. Des ressources partagées signifient un risque partagé
  Comme la virtualisation traditionnelle, les conteneurs ne sont pas complètement isolés. Les conteneurs partagent finalement le même système d’exploitation physique. Cela signifie que les vulnérabilités dans le système d’exploitation partagé signifient des vulnérabilités partagées.

Si un attaquant parvient à exploiter une vulnérabilité dans les composants du système d’exploitation, il peut compromettre une ou plusieurs charges de travail. Ces vulnérabilités pourraient être révélées si vous ne « verrouillez pas la porte » ou ne « filtrez pas vos appels ». Ce n’est pas un scénario tiré par les cheveux, comme nous l’avons vu avec CVE-2019-5736 , dans lequel une vulnérabilité runc au niveau de la couche OS a plongé Internet dans la panique. 

Le principe de sécurité fondamental ici a été énoncé par Dan Walsh , gourou de la sécurité des conteneurs SELinux et RedHat : « Les conteneurs ne contiennent pas » . 

Il est important de noter que tout le trafic réseau avec des services et des utilisateurs en dehors du nœud doit traverser le système d'exploitation hôte. La mise en réseau entre les pods et les conteneurs sur un nœud s'effectue via un réseau virtuel avec des ponts virtuels et une utilisation intelligente d'iptables. Mais en fin de compte, le trafic doit quitter ce nœud physique et cela signifie qu'il doit être traité au niveau du système d'exploitation hôte. Les agents, plug-ins et autres démons peuvent observer ou capturer ce trafic à des fins de sécurité ou de visibilité. Ce sont des points de compromis potentiels que vous devriez ajouter à l’inventaire que vous avez commencé à compiler après avoir lu sur la sécurité des pipelines .

• 4. Enregistrement des informations sensibles
  Vous ne vous attendiez peut-être pas à ce qu’une discussion sur la sécurité des conteneurs inclue un avertissement concernant les journaux. Mais c'est le cas, et la raison en est que parfois des informations sensibles se retrouvent dans des fichiers journaux. Jetons d'autorisation, clés de fournisseur de cryptage, informations d'identification. Tout peut être enregistré ou affiché par inadvertance par les charges de travail sur stderr . Cela est souvent dû à la nécessité de détecter des problèmes dus à des erreurs d’authentification. En général, vous devriez décourager – interdire si vous le pouvez – la journalisation de secrets dans le système.
  
  Pour aider les développeurs à être conscients de ce risque, pensez à fournir un guide de conception de journalisation et à spécifier ce qui est et n'est pas acceptable à écrire dans le journal.

Une grande partie de la sécurité de la charge de travail dans un contexte de conteneur est la même que celle de toute autre charge de travail application exécutée dans votre environnement de production. Contrôlez l'accès et exigez une authentification forte, surveillez le contenu malveillant et soyez conscient des vulnérabilités partagées et au niveau de la plate-forme.