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.
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.
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 .
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.