Cisco Live : l’administration réseau & sécurité arrive sur Kubernetes
Cisco a dévoilé Calisti, une console graphique qui permet de piloter un service Mesh comme un réseau classique, et Panoptica, un service SaaS qui teste les failles des containers.
Le futur d’AppDynamics, la solution de monitoring des performances applicatives de Cisco, passe-t-il par Kubernetes ? C’est en tout cas ce qu’a laissé présager l’annonce de Calisti et Panoptica. En gestation au sein de la cellule de R&D du fournisseur, Emerging Tech & Incubation, ces outils servent respectivement à simplifier le routage entre les containers et à trouver leurs failles.
« Chez Cisco, nous proposons de la connectivité, de la sécurité et de l’observabilité au niveau de l’infrastructure. L’un des projets d’Emerging Tech & Incubation est de faire la même chose, mais au niveau de l’application et, plus exactement, au niveau de l’application cloud-native », lance Guillaume de Saint Marc, l’ingénieur en chef qui dirige cette cellule, lors d’un entretien accordé au MagIT à l’occasion de l’événement Cisco Live.
« Notre objectif est d’établir Cisco dans de nouveaux domaines. Celui des applications en microservices sur Kubernetes nous semble offrir un périmètre suffisamment diffus pour que nous puissions apporter quelque chose au marché », ajoute-t-il, en précisant que Calisti et Panoptica reposent sur plusieurs composants que Cisco a mis en Open source, sous la tutelle de la CNCF, la fondation en charge des projets autour de Kubernetes.
Calisti pour reprendre la main sur les services Mesh
Calisti est une console graphique qui a vocation à devenir la tour de contrôle des services Mesh. Dans l’univers Kubernetes, un service Mesh correspond au réseau logique entre toutes les instances de tous les services d’une application.
Chaque instance (un container, ou alors un pod de plusieurs containers complémentaires, comme une pile LAMP) dispose, sur la machine physique ou virtuelle qui l’exécute, d’un proxy, appelé « sidecar », qui applique des fonctions au réseau ; celles-ci étant l’autorisation des requêtes entrantes et sortantes, la télémétrie du trafic, voire le chiffrement et le déchiffrement à la volée des données. Au centre de ce réseau logique, un plan de contrôle pilote les communications : il définit les règles d’accès entre les services et répartit la charge entre les instances d’un même service.
Plan de contrôle et sidecars sont classiquement les logiciels open source Istio et Envoy. Mais contrairement à l’infrastructure d’un datacenter où routeurs et passerelles sont installés une bonne fois pour toutes et configurés avec des commandes standard, les containers Istio et Envoy sont mis en service par les développeurs quand ils déploient leurs applications. De plus, ils communiquent entre eux par des API que programment aussi les développeurs. Pire, plus la charge d’une application augmente, plus Kubernetes va créer des instances, plus le service Mesh se complexifie.
« Calisti [...] permet de contrôler simplement qui parle avec qui, comment les pods sont segmentés, ou encore de visualiser d’un point de vue aérien les informations de télémétrie. »
Guillaume de Saint MarcSr Director Engineering, Emerging Technologies & Incubation, Cisco
« Le problème dans une application Kubernetes est que les développeurs doivent se préoccuper de la connectivité et de la sécurité pour chaque service, y compris quand ils mettent en production une nouvelle version d’un service. Et même parfois pour chaque pod. Cela peut vite devenir infernal et, dans ce cas, vous n’allez même pas chercher à monitorer l’activité d’un pod, car vous ne savez même pas où regarder », expose Guillaume de Saint Marc.
« Calisti a vocation à factoriser la complexité. Il permet de contrôler simplement qui parle avec qui, comment les pods sont segmentés, ou encore de visualiser d’un point de vue aérien les informations de télémétrie. »
Dans la démonstration à laquelle LeMagIT a pu assister, Calisti identifiait ainsi un problème de connectivité sur certains pods. Il montrait qu’il était en l’occurrence dû à une congestion du trafic sur les câbles Ethernet auxquels étaient reliées les machines physiques qui exécutaient ces pods. Une situation particulièrement difficile à identifier depuis Kubernetes. Avec Calisti, il devient trivial de répartir en priorité les flux vers des pods exécutés sur une autre machine, qui ne souffre pas de la même chute de bande passante.
Calisti rend possibles quantité de configurations très complexes à réaliser à la main. « Vous pouvez attribuer des pourcentages de connectivité à des containers. C’est-à-dire que vous pouvez par exemple faire coexister en production la nouvelle version 2 d’un service avec la version 1 et lui attribuer, disons, 10 % ou 20 % des répartitions de charge, juste pour la tester en situation réelle, sans pour autant trop risquer de pénaliser votre application à cause d’un bug. Et, au fil de la réussite de vos tests, vous augmentez sa part de prise en charge, jusqu’à décommissionner complètement la version 1 », explique notre interlocuteur.
Panoptica, pour rattraper les imprudences des développeurs
Contrairement à Calisti qui s’installe sur site, Panoptica est une application SaaS. Son but est de tester toutes les vulnérabilités possibles dans un cluster Kubernetes. Elle n’utilise pas d’agent, mais nécessite pour faire son travail que le responsable du cluster lui attribue un compte administrateur.
Panoptica fonctionne en trois phases. La première consiste à interroger les données d’infrastructures à la recherche de ports qui ne devraient pas rester ouverts, de comptes utilisateurs qui n’ont pas lieu d’être, ou encore de règles de routage hasardeuses. Plutôt que de réinventer la roue, l’équipe d’Emerging Tech & Incubation a décidé de permettre à l’utilisateur d’intégrer le scanner de vulnérabilités de son choix : Kube-Bench, Kube-Hunter, KubeAudit, etc.
La seconde phase, la plus importante, consiste à détecter les failles dans les API selon l’OSWAP Top Ten, la bible des développeurs en matière de security by design. Mais pas seulement. « Panoptica commence surtout par identifier quelles API sont utilisées. En l’occurrence, le logiciel interroge le Plan de contrôle du service Mesh, car, lui, les voit toutes passer. Et croyez-moi, c’est à ce stade que vous avez les plus grosses surprises », lance Guillaume de Saint Marc.
« Panoptica commence [...] par identifier quelles API sont utilisées. En l’occurrence, le logiciel interroge le Plan de contrôle du service Mesh, car, lui, les voit toutes passer. »
Guillaume de Saint MarcSr Director Engineering, Emerging Technologies & Incubation, Cisco
« Vous avez classiquement trois types d’API. Il y a celles que votre application expose pour que des services tiers puissent communiquer avec elles. En général, ce sont les seules sur lesquelles un travail de sécurité a été fait. Il y a celles, internes, que les développeurs utilisent pour envoyer des requêtes à leurs services. Parmi celles-ci, vous tombez à tous les coups sur des quantités d’API absolument pas protégées, dont tout le monde était persuadé qu’elles avaient été retirées du code, mais qui en réalité continuent de fonctionner. »
« Et puis vous avez des appels à des API externes. Vous n’imaginez pas le nombre d’appels à des services SaaS tiers que nous trouvons, que les développeurs font sans prévenir personne, juste parce que cela leur simplifie la tâche. Le problème est que personne ne vérifie qu’il ne s’agit pas de services en ligne qui aspirent vos données au détriment de toute réglementation que l’entreprise s’efforce de suivre ! »
Cisco a déjà mis en Open source les moteurs de deux premières phases, respectivement KubeClarity et APIClarity. La troisième est encore en développement. Elle consistera à tester aussi les failles des services Serverless qu’utilise une application (des fonctions en ligne facturées selon la quantité de données qu’on leur demande de traiter, plutôt qu’au temps de calcul consommé par leurs VM ou containers).
« En fait, les services Serverless sont identiques dans le principe aux services SaaS tiers : cela reste des appels à des API, à la différence que leurs bonnes pratiques de sécurité sont connues et que nous pourrons nous baser sur une batterie de tests spécifiquement adaptés », précise Guillaume de Saint Marc.
Vers une suite d’administration
À terme, Cisco ambitionne de faire de Panoptica une suite de sécurité complète, qui devrait prendre le nom d’OpenClarity dans sa version Open source. La différence entre les déclinaisons Open source et commerciales étant que la seconde disposera de tout l’environnement graphique. De la même façon, Calisti peut être considéré comme une installation clés en main d’Istio et Envoy, avec le supplément d’une console graphique.
« Notre idée est de proposer aux entreprises des outils complets, qui aideront les développeurs à anticiper la manière dont leurs applications doivent être élastiques, et qui permettront aux opérationnels de s’assurer que des solutions de sécurité seront compatibles avec l’application », dit Guillaume de Saint Marc.
« Notre idée est de proposer aux entreprises des outils complets. »
Guillaume de Saint MarcSr Director Engineering, Emerging Technologies & Incubation, Cisco
Calisti et Panoptica, qui devraient être commercialisés d’ici à la fin de l’été, s’accompagneront tous deux d’une version « freemium ». C’est-à-dire gratuite jusqu’à un certain nombre d’instances monitorées.
Officiellement, ils ne sont pour l’instant rattachés à aucune famille de produits Cisco. Le fournisseur brouille même les pistes en laissant entendre qu’il pourrait les intégrer à Intersight, sa plateforme d’administration de clouds privés basés sur ses serveurs UCS et ses routeurs Nexus. Une rumeur pas nécessairement dénuée de sens, puisque, comme tous les fournisseurs d’infrastructures qui ont fait prospérer leur activité sur la virtualisation, Cisco est pressé par le marché pour faire passer ses infrastructures à l’ère Kubernetes.
