Red Hat acquiert StackRox, spécialiste de la sécurité de Kubernetes
Red Hat ouvrira le code du logiciel de sécurité de StackRox dédié à Kubernetes, et l’incorporera dans sa plateforme OpenShift, tout en préservant le support pour les autres distributions cloud de l’orchestrateur de containers.
Red Hat intégrera un logiciel de sécurité dédié à Kubernetes dans sa plateforme OpenShift avec l’acquisition de StackRox.
Le montant de ce rachat n’a pas été divulgué. Red Hat entend clôturer l’opération ce trimestre. Jusqu’alors, la startup fondée à Mountain View avait levé 65 millions de dollars après quatre tours de table. Le « Venture Round » annoncé le 10 septembre 2020 avait permis à StackRox de récolter 26,5 millions de dollars. Actuellement, la startup compte une soixantaine de salariés.
De son côté, Red Hat prévoit d’ouvrir le code source propriétaire de StackRox, avec un calendrier à déterminer ultérieurement, selon un communiqué de presse. En octobre, StackRox a lancé KubeLinter, un projet d’ores et déjà open source qui facilite l’analyse des fichiers YAML et les charts Helm de Kubernetes pour garantir leurs bonnes configurations et détecter de potentiels problèmes de sécurité.
StackRox enrichira les fonctions de sécurité d’OpenShift
KubeLinter contient notamment des mécanismes pour détecter de potentielles informations sensibles qui ne seraient pas placées dans des secrets ou encore des expositions réseau excessives. Red Hat entend soutenir le développement de cet outil.
La filiale d’IBM compte également profiter des capacités d’observabilité offertes par StackRox pour étendre les fonctions de surveillance et d’alertes embarquées au sein d’OpenShift. L’éditeur prévoit aussi d’automatiser la gestion de règles réseau ainsi que simuler et visualiser les possibles impacts de ces politiques.
La sécurisation des containers, ce par quoi a débuté StackRox en 2014, a donné naissance à de nouvelles pratiques encourageant la croissance de l’approche DevSecOps. Les conteneurs se prêtent à des modèles de déploiement d’infrastructures immuables ou répétables, qui sont considérés comme plus sûrs, car ils ne sont pas sujets à des erreurs de mises à jour et de correctifs – dans le cas d’infrastructures immuables – ou à l’erreur humaine, dans le cas de déploiements répétables automatisés. C’est particulièrement vrai quand les professionnels IT les utilisent dans le cadre d’une approche GitOps.
StackRox, placé à l’épicentre du maelström sécuritaire de Kubernetes
La sécurité de Kubernetes a été au centre des discussions au cours des six derniers mois, surtout pour les entreprises qui maintiennent la plateforme d’orchestration de containers en production. Les différents éditeurs, grands utilisateurs débattent pour savoir si Kubernetes doit inclure ou non davantage de mesures de sécurité par défaut, et si celles déjà en place doivent être remplacées par des solutions tierces, ouvertes, mais spécialisées. Les observateurs constataient un chevauchement des mécanismes comme c’est souvent le cas dans le cadre de gros projets open source.
L’API qui gère les « Pod Security Policies » sera dépréciée en faveur d’une nouvelle approche, comme l’a décidé la communauté en décembre 2020.
D’ores et déjà, l’API qui gère les « Pod Security Policies » sera dépréciée en faveur d’une nouvelle approche, comme l’a décidé la communauté en décembre 2020. La plupart des utilisateurs reprochent à ces ressources leur positionnement au niveau d’un cluster, alors même qu’elles correspondent à des politiques d’accès assez fines (des ressources situées qui contrôlent des privilèges, namespaces, types de volumes, ou bien la mise en réseau des hôtes et des ports).
StackRox a été parmi les premiers à déployer son logiciel pour la sécurité d’exécution des containers comme un contrôleur DaemonSet privilégié au sein de l’infrastructure de Kubernetes.
Cela signifie que le logiciel StackRox peut être automatiquement et systématiquement injecté dans chaque cluster Kubernetes au fur et à mesure de son déploiement. C’était un argument de vente pour les primoadoptants tels que l’éditeur spécialisé dans le retail, Aptos, la startup du streaming vidéo Mux Inc. et la société finlandaise Greenlight.
StackRox propose également des scans de sécurité des containers dans les pipelines CI/CD pour des déploiements DevSecOps, une approche privilégiée par certains clients tels qu’Informatica. Depuis, son offre a séduit Splunk, UiPath, Semrush, Johnson Controls, ElementAI (racheté par ServiceNow) ou encore Lockheed Martin.
Red Hat ne ferme pas les portes, et s’assure que les solutions de StackRox ne seront pas uniquement réservées à OpenShift. En clair, StackRox continuera à prendre en charge plusieurs produits Kubernetes, notamment Amazon EKS, Microsoft Azure Kubernetes Service et Google Kubernetes Engine.
Les clients existants de StackRox bénéficieront du support de la startup jusqu’à la clôture de l’acquisition, puis ils seront transférés vers celui de Red Hat, selon une FAQ de la firme.
L’ouverture du code source de StackRox pose question
La volonté de Red Hat de faire du logiciel de StackRox une solution open source suscite des réactions mitigées chez les utilisateurs.
L’un d’eux a exprimé sa crainte que l’ouverture du code source au public n’introduise un danger, car les workloads de StackRox sont privilégiées. Elles disposent d’un accès à la racine des clusters Kubernetes.
« C’est un gros risque pour un produit de cyber [sécurité] », déclare Nicolas Chaillan, Chief Software Officer chez l’US Air Force, qui emploie à la fois Red Hat OpenShift et StackRox. « Une seule erreur et l’impact peut être énorme ».
D’autres utilitaires open source dédiés à la sécurité de Kubernetes bénéficient d’un accès privilégié, tel Falco. Red Hat a de son côté développé SELinux (Security Enhanced Linux), également intégré avec OpenShift.
Un deuxième usager doute que la conversion pure d’un modèle propriétaire à une approche open source ne soit faisable. Les compétiteurs directs de StackRox, par exemple Sysdig et Aqua Security, dirigent certains projets ouverts et se connectent à des outils open source comme OPA et Falco. Toutefois, ces éditeurs conservent la propriété de certains composants.
« Je ne sais pas à quel point ils souhaitent ouvrir le code source, ou s’ils vont tout rendre public », s’interroge Pathik Patel, responsable de la sécurité du cloud chez Informatica, un client de StackRox. « Nous verrons, mais si vous observez les autres acteurs… ils ont également libéré certaines choses, mais pas le cœur de leur produit ».
Un troisième utilisateur pense, lui, que cette ouverture du code source de StackRox sera bénéfique pour la sécurité de Kubernetes.
« Pendant des décennies, les gens ont parlé de l’open source comme d’un risque pour la sécurité – tout d’un coup, ils peuvent regarder sous le capot », constate Ken De La Guera, ingénieur principal DevOps chez Greenlight Financial. « Mais historiquement, cela rend les produits plus sûrs, et non l’inverse. Cela ne s’applique pas seulement à StackRox, mais à n’importe quel logiciel. Si la sécurité de votre produit dépend de l’obfuscation et du fait que les utilisateurs ne comprennent pas le moteur de votre solution, c’est un mauvais modèle dès le départ ».
« Si la sécurité de votre produit dépend de l’obfuscation et du fait que les utilisateurs ne comprennent pas le moteur de votre solution, c’est un mauvais modèle dès le départ ».
Ken De La GueraKen De La Guera, ingénieur principal DevOps, Greenlight Financial
Red Hat n’a pas encore divulgué tous les détails de sa feuille de route, d’intégration et de don du projet StackRox à la communauté. En revanche, un communiqué de presse de la firme fait écho aux propos de Ken De La Guera.
« Nous pensons que les logiciels open source permettent une collaboration communautaire, ce qui ne fait qu’accélérer le développement et conduit finalement à un code plus stable et plus sûr », indique le document. « Par exemple, la communauté Kubernetes a réalisé un audit de sécurité de Kubernetes en 2019 [lien dans l’original]. Ce type de partage d’informations facilite le travail du groupe pour répondre rapidement aux problèmes rencontrés ».
Pour approfondir sur Gestion des vulnérabilités et des correctifs (patchs)
