La sécurité des conteneurs - une nouvelle frontière (partie 2)

Une série de blogs en deux parties sur les considérations à prendre en compte pour sécuriser l'utilisation des conteneurs.

La sécurité des conteneurs, avec une nouvelle dimension

Dans notre premier article de blog, nous avons décrit les problèmes de sécurité que les conteneurs peuvent poser. Cela nous amène à nous interroger sur la manière dont nous devrions envisager la sécurité des conteneurs. 

Nous pensons que nous devrions commencer par (et nous appuyer sur) le conseil de Kubernetes d'utiliser une approche de défense en profondeur par couches qui tient compte des quatre C : nuage, clusters, conteneurs et code. Nous pensons également qu'il faut réfléchir à la manière de contenir les menaces qui compromettent les conteneurs, par le biais de la segmentation.

Dans ces conditions, nous proposons l'endiguement comme cinquième C. 

Nous avons évoqué précédemment la nécessité non seulement de sécuriser les conteneurs, mais aussi de veiller à ce qu'ils ne puissent pas être exploités et utilisés comme tête de pont pour se déplacer latéralement à l'intérieur d'un centre de données. C'est là que le besoin de confinement entre en jeu. 

Examinons les premières orientations de Kubernetes sur les 4 C, puis nous discuterons du confinement.

Conteneurs

Pour exécuter un logiciel dans Kubernetes, il doit se trouver dans un conteneur. Pour cette raison, il existe certaines considérations générales de sécurité que Kubernetes met en avant :

• Scannez : Recherchez les vulnérabilités connues dans vos conteneurs. Des outils comme Clair de CoreOS peuvent être utiles.
• Signez les images des conteneurs : Maintenez la confiance dans le contenu du conteneur à l'aide de Docker Content Trust, intégré au moteur Docker. Le projet Portieris d'IBM peut être utilisé comme contrôleur d'admission pour renforcer la confiance dans le contenu des images correctement signées.
• Contrôlez les privilèges des utilisateurs : Cherchez à créer des utilisateurs à l'intérieur des conteneurs qui ont le niveau le plus bas de privilèges du système d'exploitation nécessaire pour atteindre l'objectif du conteneur. 

Code

Si l'on examine le code de l'application, les conseils de Kubernetes portent sur quelques points :

• N'autorisez l'accès que par TLS : Cryptage par défaut de tout ce qui transite, même entre les services réseau derrière le pare-feu.
• Limitez les plages de ports de communication : N'exposez que les ports de votre service qui sont absolument essentiels.
• Analysez le code statique : Analysez le code pour détecter toute pratique de codage potentiellement dangereuse.
• Testez les attaques par sondage dynamique : Utilisez les outils de l'OWASP pour automatiser les attaques courantes telles que l'injection SQL, CSRF, etc.

Nuage

Chaque fournisseur d'informatique en nuage fournit des recommandations détaillées sur la manière d'exécuter des charges de travail en conteneur sur son infrastructure en nuage. Les offres de sécurité peuvent varier d'un fournisseur à l'autre et les utilisateurs doivent suivre scrupuleusement ces recommandations. Vous trouverez des liens vers des fournisseurs de services en nuage populaires et des recommandations en matière de sécurité à l'adresse https://kubernetes.io/docs/concepts/security/#the-4c-s-of-cloud-native-security.

Les orientations générales sont les suivantes :

• Restreignez l'accès au réseau : La plupart des fournisseurs de sécurité en nuage assurent la sécurité du réseau à l'aide de listes de contrôle d'accès - par exemple, AWS propose des groupes de sécurité qui permettent de segmenter les charges de travail en groupes et de configurer des listes de contrôle d'accès pour chaque groupe.
• Restreignez l'accès à l'API : Idéalement, seuls les serveurs nécessaires à l'administration d'un cluster devraient avoir accès aux serveurs API.
• Restreignez l'accès aux API du cluster Kubernetes : Il est préférable de fournir au cluster un accès au fournisseur de cloud qui suit le principe du moindre privilège pour les ressources qu'il doit administrer. Vous trouverez un exemple de Kops dans AWS à l'adresse suivante : https://github.com/kubernetes/kops/blob/master/docs/iam_roles.md#iam-roles.
• Restreignez l'accès à "etcd" : C'est dans ce répertoire que se trouvent les fichiers de configuration de Kubernetes. Utilisez toujours TLS pour accéder à ces fichiers et les modifier.
• Cryptez tous les lecteurs, en particulier les lecteurs etcd : Empêchez les utilisateurs non autorisés de consulter les fichiers de configuration critiques et les magasins de données appartenant à votre cluster Kubernetes.

Groupes d'entreprises

• Restreignez l'accès à l'API Kubernetes au cluster à l'aide de RBAC.
• Authentifiez tous les accès à l'API qui contrôle le cluster.
• Cryptez toutes les clés secrètes utilisées par le cluster, y compris toutes les données dans etcd.
• Contrôler les aspects sécuritaires des modules : Les objets de sécurité des pods définissent un ensemble de conditions qu'un pod doit respecter pour être accepté dans le système.
• Contrôlez l'utilisation des ressources : Les nœuds Kubernetes qui exécutent votre application dépendent les uns des autres pour la fiabilité et l'équilibrage des ressources. Il faut donc mettre en place des politiques qui limitent la quantité de ressources utilisées par ces nœuds.
• Contrôlez toutes les politiques de réseau vers les pods à l'aide de listes de contrôle d'accès. Il s'agit des politiques de sécurité Nord-Sud. Pour les politiques relatives aux centres de données, reportez-vous à la section "Confinement" ci-dessous.
• Limitez tous les accès entrants à TLS.

Confinement

Cela nous amène au cinquième C du confinement qui empêche la propagation des brèches initiées à partir d'un conteneur. Le confinement doit tenir compte de plusieurs éléments pour être le plus efficace possible :

• Découvrez les conteneurs nouvellement créés en temps réel.
• Permettre une segmentation automatisée pour les nouvelles charges de travail des conteneurs afin que la sécurité soit automatiquement présente "dès la naissance."
• Centralisez la visibilité des conteneurs avec d'autres environnements de calcul pour obtenir une vue unique des charges de travail conteneurisées, des machines virtuelles, des nuages privés et publics, car vous ne pouvez pas protéger ce que vous ne pouvez pas voir.
• Appliquez une politique uniforme aux conteneurs - et à tout le reste - afin de segmenter avec une politique unifiée, quel que soit l'environnement. Cela évite de multiplier les outils ponctuels de segmentation pour les VM, les serveurs bare-metal, les clouds et les conteneurs.

Avec une approche de défense en profondeur pour les conteneurs, les entreprises peuvent être assurées de la viabilité de la sécurité des conteneurs et les déployer avec encore plus de confiance.