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

Une série de blogues en deux parties sur les considérations à prendre en compte pour garantir la sécurité de l'utilisation des conteneurs.

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

Nous avons décrit les défis de sécurité que peuvent présenter les conteneurs dans notre premier article de blog. Cela nous amène à nous poser des questions quant à la manière dont nous devrions envisager la sécurité des conteneurs.

Nous pensons que nous devrions commencer par (et poursuivre) les conseils de Kubernetes concernant l'utilisation d'une approche de défense en profondeur à plusieurs niveaux qui tient compte de quatre C : le cloud, les clusters, les conteneurs et le code. Nous pensons également que nous devrions réfléchir à la manière de contenir les menaces qui compromettent les conteneurs, par segmentation.

Dans ces conditions, nous proposons un confinement en tant que cinquième C.

Nous avons discuté précédemment de 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 la nécessité de contenir entre en jeu.

Examinons les conseils initiaux 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, Kubernetes présente certaines considérations générales en matière de sécurité :

• Scan : scannez vos conteneurs pour détecter les vulnérabilités connues. Des outils tels que Clair de CoreOS peuvent être utiles.
• Signer des images de 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 du contenu pour les images correctement signées.
• Contrôlez les privilèges des utilisateurs : cherchez à créer des utilisateurs à l'intérieur des conteneurs qui disposent du niveau minimum de privilèges du système d'exploitation nécessaire pour atteindre l'objectif du conteneur. 

Code

En examinant le niveau de code de l'application, les conseils de Kubernetes portent sur quelques points :

• Autoriser l'accès via TLS uniquement : cryptez par défaut tout ce qui est en transit, même entre les services réseau derrière le pare-feu.
• Limitez la portée des 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.
• Test pour les attaques par sondage dynamique : utilisation Outils OWASP pour automatiser les attaques courantes telles que l'injection SQL, le CSRF, etc.

Nuage

Chaque fournisseur de cloud fournit des recommandations détaillées sur la manière d'exécuter des charges de travail de conteneurs sur son infrastructure cloud. Les offres de sécurité peuvent être différentes selon les fournisseurs de cloud et les utilisateurs doivent suivre ces recommandations avec le plus grand soin. Des liens vers les fournisseurs de cloud les plus populaires et des recommandations de sécurité se trouvent dans https://kubernetes.io/docs/concepts/security/#the-4c-s-of-cloud-native-security.

Les directives générales incluent :

• Restreindre l'accès au réseau : la plupart des fournisseurs de sécurité cloud proposent sécurité du réseau en utilisant des listes de contrôle d'accès : par exemple, AWS fournit des groupes de sécurité qui permettent de segmenter les charges de travail en groupes et de configurer les ACL par groupe.
• Restreindre l'accès aux API : dans l'idéal, seuls les serveurs nécessaires à l'administration d'un cluster devraient avoir accès aux serveurs API.
• Restreindre 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 respecte les principe du moindre privilège pour les ressources dont il a besoin pour gérer. Vous trouverez un exemple de Kops dans AWS ici : https://github.com/kubernetes/kops/blob/master/docs/iam_roles.md#iam-roles.
• Restreindre l'accès à « etcd » : c'est dans ce répertoire que se trouvent les fichiers de configuration cloud pour Kubernetes. Utilisez toujours le protocole TLS pour accéder à ces fichiers et y apporter des modifications.
• Chiffrez 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.

Clusters

• 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.
• Chiffrez toutes les clés secrètes utilisées par le cluster, y compris toutes les données d'etcd.
• Contrôlez les aspects de sécurité des pods : les objets de sécurité des pods définissent un ensemble de conditions qu'un pod doit exécuter 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 en termes de fiabilité et d'équilibrage des ressources. Il devrait donc y avoir des politiques qui limitent la quantité de ressources utilisées par ces nœuds.
• Contrôlez toutes les politiques réseau relatives aux pods à l'aide de listes de contrôle d'accès. Il s'agit des politiques de sécurité Nord-Sud. Pour les politiques internes aux centres de données, consultez la section Confinement ci-dessous.
• Restreignez tous les accès d'entrée via TLS.

Confinement

Cela nous amène au cinquième C de confinement qui empêche la propagation des brèches provoquées par un conteneur. Pour qu'il soit le plus efficace possible, le confinement doit tenir compte de plusieurs facteurs :

• Découvrez en temps réel les nouveaux conteneurs créés.
• Autorisez la segmentation automatique des nouvelles charges de travail de conteneurs afin que la sécurité soit automatiquement présente « à la naissance ».
• Centralisez la visibilité des conteneurs par rapport à d'autres environnements informatiques pour une vue unique des charges de travail conteneurisées, des machines virtuelles, des clouds privés et publics, car vous ne pouvez pas protéger ce que vous ne pouvez pas voir.
• Appliquez une politique uniforme pour tous les conteneurs, et pour tout le reste, afin de segmenter avec une politique unifiée, quel que soit l'environnement. Cela permet d'éviter la multiplication des outils de segmentation pour les machines virtuelles, les serveurs bare-metal, les clouds et les conteneurs.

Grâce à une approche globale de défense en profondeur des conteneurs, les entreprises peuvent être assurées de la viabilité sécuritaire des conteneurs pour les déployer avec encore plus de confiance.