Les développeurs veulent se concentrer sur l’élaboration d’applications. Que Kubernetes puisse assurer l’hébergement et l’exploitation des applications dans plusieurs environnements est largement apprécié par les développeurs. Mais, cette souplesse n’est pas sans une contrepartie parfois problématique.
Bien que l’usage de Kubernetes en tant que « commodité » soit évidente et réalisable, arriver à ce que les développeurs puissent « simplement pousser leur code » nécessite des connaissances approfondies, une automatisation efficace et de la vigilance. D’autant plus pour sécuriser tout le process inhérent aux logiciels CI/CD et les pipelines que les développeurs utilisent pour créer et exploiter des applications conteneurisées natives du cloud.

Aller vite c’est bien (jusqu’à que ce soit mal)
Livrer des fonctionnalités plus rapidement est certes une bonne chose, mais cette vélocité peut aussi être périlleuse. Les sources de vulnérabilités lors de l’exécution des applications sont nombreuses. Citons entre autres :

● Des images de base insuffisamment validées
● Des copiés-collés à partir de sources non validées (avec les risques juridiques collatéraux)
● Composants et librairies tiers construits et/ou distribués par des conteneurs
La conteneurisation rend toutes ces opérations abstraites. Sans compter l’automatisation qui aggrave le problème. Résultat : la livraison d’applications modernes à grande vitesse et à grande échelle devient rapidement impossible à contrôler par des humains. Il y a tout simplement trop d’opérations sous-jacentes.

D’autres risques apparaissent à chaque couche de la plateforme. Kubernetes s’exécute souvent sur une infrastructure virtualisée, pour de bonnes raisons : par exemple, les clouds IaaS (publics ou privés) permettent de déployer et de faire évoluer rapidement et relativement facilement des clusters Kubernetes sur des machines virtuelles. Mais votre surface d’attaque inclut désormais potentiellement les services d’infrastructures du cloud, plus les systèmes d’exploitation hôtes sur les hyperviseurs, les OS invités sur chaque VM, tous les composants Kubernetes, plus les nombreuses extensions de Kubernetes tels que l’Ingress, le maillage de services, etc.

Réduire les risques prend du temps, trop de temps. Une fois en production, de nombreuses vulnérabilités (voire dans certains cas des malwares) seront présentes et parfois exposées sur internet.

À ce stade, la métrique à prendre en compte impérativement est « quel est le temps nécessaire pour remédier à cette situation ». Plus une vulnérabilité reste exposée longtemps, plus il y a de chances qu’elle soit exploitée.

Malheureusement, pour les entreprises, les nouvelles ne sont pas bonnes. SecurityScorecard et l’institut Cyentia ont analysé les CVE (Common Vulnerabilities and Exposures) de 1,6 million d’entreprises de différents secteurs. Résultat : 53 % d’entre elles avaient au moins une vulnérabilité exposée sur Internet. Pire : 22 % en avaient plus de 1000 chacune. Encore pire ? Le temps moyen pour remédier à 1 CVE varie de 270 à 426 jours. Ce temps moyen pour corriger la moitié de ces CVE est de 12 mois. Et plus les CVE s’accumulent, plus le temps pour y remédier s’allonge. Dans ce même temps, à chaque version, à chaque mise à niveau des composants, de nouvelles vulnérabilités apparaissent.

Quel chemin pour améliorer la sécurité ?

Comment résoudre le problème ? La réponse est peu séduisante : en prenant méticuleusement de nombreuses mesures laborieuses. À titre d’exemple, voici une petite liste partielle des mesures à prendre pour sécuriser votre système Kubernetes (c’est-à-dire : votre chaîne d’approvisionnement en logiciels, plus les clusters cibles pour le Dev, Test, [Staging], et Production, y compris tous les outils de déploiement et de gestion du cycle de vie des clusters [LCM]. Bien que les clusters Dev/Test/Staging ne soient parfois pas entièrement publics sur Internet, leur importance augmente considérablement lorsqu’ils correspondent dans la mesure du possible à vos environnements de production).
Vous pouvez procéder de manière descendante (les applications d’abord, la plateforme ensuite) ou ascendante (la plateforme d’abord, les applications ensuite). En termes pratiques, de nombreuses équipes de développement divisent le travail avec les opérations de la plateforme cloud, ou font confiance à un fournisseur de services gérés ou de cloud public pour gérer la plateforme. Mais cela est fortement conditionné par l’identité de vos collaborateurs/partenaires de la plateforme et par le sérieux de leur engagement à assurer votre sécurité.

Détecter rapidement. Dans l’idéal, il faut détecter les problèmes directement dans le code source avant la conteneurisation. Il est alors plus simple d’effectuer la remédiation. L’analyse de la composition du logiciel, qui consiste à exposer toutes les sources à partir desquelles une base de code peut être dérivée et à identifier les vulnérabilités connues, est une première étape. Vous pouvez utiliser des outils tels que Black Duck ou Sonatype pour vous aider.
La curation des images de base des conteneurs est essentielle pour identifier les CVE et réduire la surface d’attaque potentielle (et permet de faire fonctionner les choses plus rapidement et mieux). Slim.ai a effectué des recherches sur des versions successives d’images de conteneurs publics populaires. Pour ce faire l’éditeur a exécuté des outils tiers pour révéler les vulnérabilités en créant des nomenclatures de logiciels et en exécutant ses propres outils d’« amincissement des conteneurs » pour réduire la surface d’attaque et supprimer les dépendances non utilisées. La plupart de ces informations sont disponibles gratuitement.

Analyser les conteneurs en production. Une fois que chaque conteneur est mis en production, il est essentiel de l’analyser à nouveau pour détecter les problèmes qui peuvent s’y être glissés de manière dynamique. Des outils tels que Sysdig, Snyk, Synopsys sont ici importants. L’idée est idéalement qu’ils soient intégrés au registre des conteneurs pour fonctionner automatiquement, potentiellement à la fois lorsque les conteneurs sont stockés et lorsqu’ils sont invoqués.

Signer les conteneurs et appliquer les contrôles de signature sur les moteurs d’exécution des conteneurs. Pour éviter des problèmes de sécurité liés à l’automatisation, il est important d’imposer des règles strictes qui intègrent des personnes dans les processus et créent des pistes d’audit, soit l’enregistrement systématique et chronologique des évènements et actions effectuées. L’une des règles les plus importantes porte sur la signature des images : il faut insister pour qu’une personne autorisée signe cryptographiquement les images et les mette en production après examen.

Logiquement, il faut refuser d’exécuter des images qui n’ont pas été correctement signées en intégrant une « prévention de l’exécution » dans le moteur d’exécution.
Lint et scan des fichiers de configuration YAML, des charts Helm, de l’automatisation du déploiement et d’autres éléments externes au code de l’application. Les conteneurs ne sont pas les seuls endroits où les problèmes peuvent se cacher. Ici, cependant, nous commençons à sortir du domaine des CVE suivis par des composants comme Synopsys ou MITRE, et à entrer dans le domaine des risques plus subtils : mauvaises configurations d’applications ou de clusters qui sont autant de points d’entrées aux attaquants. Cela devrait également être automatisé — l’automatisation étant intégrée à infra-as-code (IaC), Helm et d’autres référentiels.

Intégrez autant que possible ces éléments dans un workflow automatisé baptisé « chaîne logistique logicielle sécurisée ». Rappelez-vous : l’objectif de votre CI/CD et de l’automatisation connexe est principalement de livrer rapidement. Ajouter de nombreuses étapes manuelles avec des outils de sécurité complexes pour garantir la sécurité des livrables est contre-productif.

Maintenir cette chaîne d’approvisionnement et veiller à ce qu’elle fonctionne de manière fluide et continue, en l’améliorant régulièrement au fur et à mesure que de nouveaux outils et de nouvelles techniques sont disponibles. Surveillez le paysage des menaces émergentes à tous les niveaux et mesurez les résultats à l’aide d’indicateurs standard, afin de pouvoir les optimiser.

Sécuriser la plateforme

Il est bien sûr essentiel de sécuriser Kubernetes lui-même, c’est-à-dire le cluster et son infrastructure hôte, et de gérer Kubernetes et les services intégrés qui façonnent la manière dont les applications sont déployées et gérées au cours de leur cycle de vie.
Pour sécuriser Kubernetes, il faut analyser les sources des composants individuels pour détecter les CVE, remédier à tout ce qui a été trouvé et construire à partir des sources. Il est donc important de maintenir Kubernetes à jour en automatisant les mises à jour. Tout aussi important, il faut mettre en œuvre des architectures d’application à l’épreuve du temps en désactivant les fonctionnalités obsolètes. À l’heure actuelle, un grand pourcentage d’organisations utilise encore Kubernetes 1.21, qui est en fin de vie — Pourquoi ? Les applications qui dépendent de fonctionnalités obsolètes dans les versions ultérieures ne peuvent pas être déplacées sans un remaniement.
En outre, l’environnement de support des applications comprend des éléments tels que le contrôle d’accès et le RBAC (Role-based access control), la gestion des politiques, l’auditabilité, la gestion des secrets et des certificats, la consommation des ressources, l’observabilité et la surveillance (ainsi que des sous-ensembles spécialisés relatifs à la visibilité de la sécurité, pour lesquels il est judicieux de créer des tableaux de bord spécifiques).
Les configurations de maillage de services tenant compte des applications et les cadres de « zero trust » doivent également être validés, tout comme les politiques et les choix technologiques garantissant le chiffrement des données en mouvement et au repos.
La prévention de la perte de données, la sauvegarde et le plan de reprise après sinistre sont également des éléments importants de la sécurité globale, du rayon d’action et de la remédiation des dommages. La liste des points à vérifier sera hautement personnalisée en fonction des particularités de l’architecture de votre système.
Nombre de ces services sont également fondamentaux pour la sécurité opérationnelle des clusters. Ils ne relèvent pas du domaine de DevOps (défini très strictement comme des opérations d’application) et il est préférable qu’ils soient mis en œuvre et normalisés à l’échelle de l’entreprise par des ingénieurs de plateforme et des SRE (ingénieur en fiabilité de site) spécialisés. Dans le monde réel, le DevOps peut être responsable de tout cela, mais ce n’est pas idéal.

Les dessous de la plateforme

Étape suivante : améliorer la sécurité des clusters Kubernetes. Même déployés sur des clouds publics (en supposant que vous n’utilisez pas un spin Kubernetes préconfiguré entièrement géré par le fournisseur de cloud), il existe un potentiel pour réduire les risques. Le système d’exploitation sur lequel les nœuds Kubernetes sont hébergés est particulièrement important — les distributions Linux les plus populaires présentent une surface d’attaque assez large et riche. La stratégie consiste généralement à rechercher les CVE dans le code source de Linux à l’aide d’un outil libre comme OpenVAS (de nombreux autres sont également disponibles), puis à minimiser votre système d’exploitation candidat, en le reconstruisant pour supprimer les dépendances non pertinentes. Vous pouvez également commencer par un Linux minimal, conçu pour le cloud et Kubernetes — par exemple, une distribution comme Rocky Linux.

Une autre vérification peut être nécessaire à réaliser régulièrement : analyser et remédier aux problèmes dans tous les modèles de déploiement (par exemple, CloudFormation) que vous pouvez utiliser pour construire des clusters. Dans le cas d’outils de déploiement populaires, des outils open source et propriétaires (par exemple, Aqua Security) sont facilement disponibles pour analyser et faire des recommandations sur la façon de remédier aux problèmes dans leurs manifestes.

La bigger picture
L’objectif global est bien sûr la rapidité et la vélocité, mais avec l’assurance de ne pas se tirer une balle dans le pied. L’automatisation est donc essentielle. Vous pouvez le faire vous-même ou travailler avec des partenaires DevOps/DevSecOps sensibilisés à la sécurité, experts dans tous les aspects de l’évaluation des vulnérabilités et de la remédiation, et qui ont « produit » cela. À vous de développer un playbook fiable pour automatiser les étapes critiques de manière fiable et flexible, de sorte que vous conservez la vitesse et la capacité (au moins pour les développeurs de base) de « simplement pousser votre code ».