Les conteneurs dans le viseur des hackers

Limiter les accès, configurer ses policies Kubernetes , utiliser les bons outils complémentaires, bref, traiter ses conteneurs exactement comme n’importe quelle application serveur est LA bonne approche pour les sécuriser et laisser le moins de failles exploitables possibles pour un hacker.

La conteneurisation est largement reconnue comme ayant d’indéniables atouts en termes d’agilité et de flexibilité. Permettant de livrer beaucoup plus rapidement des applications et de bénéficier de nouvelles fonctionnalités, les environnements conteneurisés ont le vent en poupe. Pourtant, les architectures cloud-natives et les méthodes agiles orientées DevOps en général vont à l’encontre des bonnes pratiques en matière de sécurité des applications. Résultat, certains hackers sont à l’affut des failles de sécurité des conteneurs cloud.


Les atouts des conteneurs font aussi leurs vulnérabilités

Si un utilisateur a des privilèges de super admin dans un conteneur, le système d'exploitation sous-jacent pourrait, en théorie, être compromis, étant donné que le conteneur ne contient pas tout et qu’il s’appuie sur des sous-systèmes de l’OS hôte pour fonctionner, contrairement à une VM. Quand bien même cette particularité est gage de leur rapidité et de leur flexibilité, il « suffit » aux pirates cyber de viser leurs systèmes d’exploitation pour toucher tous les conteneurs rattachés. La moindre erreur est facilement exploitable pour les pirates. Les mauvaises configurations nuisent grandement à la sécurité des couches d’orchestration et facilitent les intrusions. Par ailleurs, les architectures des applications sont directement exposées en cas d’usage intensive d’API au niveau de la couche service. En outre, la multiplication des workloads et la complexité des plans de contrôle, ne font qu’exacerber la vulnérabilité des environnements cloud.

Aqua Security, spécialiste de la sécurisation des architectures cloud a réalisé une étude portant sur plus de 17 000 attaques recensées sur le second semestre 2020 touchant des infrastructure cloud native. Selon l’agence, les pirates « continuent de chercher d'autres façons pour attaquer les environnements cloud native ». Ils viseraient désormais des supply chain, des registres, ou encore des fournisseurs de services d’intégration pour détourner les environnements conteneurisés. Cette étude a également permis de mettre en exergue l’inefficacité des systèmes basés sur le blocage des adresses IP suspectes. Sachant que les pods Kubernetes se connectent avec des adresses IP uniques jugées fiables, les pirates peuvent donc les utiliser comme portes d’entrée sans se faire recaler et ainsi accéder à l’ensemble du cluster.


Du bon dosage de l’automatisation pour sécuriser ses conteneurs

Selon une autre étude, réalisée par Dynatrace, l’approche DevOps et ses variantes, notamment DevSecOps ne font que compliquer la tâche des équipes SSI. La sécurisation des containers et du cloud dans son ensemble génère un très (trop) grand nombre des fausses alertes qu’il faut trier. En moyenne, les entreprises font face à 2 169 alertes par mois et plus de 3 alertes sur 4 sont de faux-positifs. Détecter la vulnérabilité des logiciels devient alors une tâche ardue. 74% des Responsables SSI pensent que les contrôles de sécurité actuels sont entrés en désuétude et sont devenus incompatibles avec les nouvelles spécificités du cloud. 89% de ces RSSI déplorent le fait que les conteneurs, les microservices et Kubernetes ne permettent plus d’avoir une visibilité totale et en temps réelle sur la sécurité des applications. Enfin, 77% de ces responsables estiment que dans une approche DevSecOps, l’automatisation du déploiement et de la gestion du code est la solution.



Cloud Native Security et protection des conteneurs

Quoi qu’il en soit, la sécurisation des conteneurs cloud nécessitent une toute approche. Gartner de prédire que dans un an, 3 entreprises sur 4 exécuteront des applications conteneurisées. Il devient donc essentiel pour elles de trouver des solutions permettant de sécuriser totalement les conteneurs.

L’idéal dans un 1er temps est ainsi de s’assurer de la bonne configuration des paramètres d’accès à ses conteneurs, avec notamment un niveau Restricted policy sur Kubernetes qui, en limitant les capacités d’action depuis un pod, permettent d’assurer un niveau de sécurité plus important. Idem côté network. D’où l’importance d’un Kubernetes paramétré et managé comme h8l.io, qui intègre entre autres Kyverno, outil OSS de policy-as-code permettant une sécurité cloud native.

L’idéal à terme, serait de mettre en place un dispositif de sécurité permettant de contrôler en permanence tout ce qui s’exécute dans le cloud. En s’armant du Machine Learning, le dispositif devrait améliorer la précision et le niveau vigilance du SSI.


Par Baptiste.casnedi