La sécurité native du cloud était dans l'air à KubeCon/CloudNativeCon 2022

En tant que cinéphile auto-identifié, certaines lignes de films m’ont marqué au fil des ans. L'un d'eux vient de Ridley Scott. Gladiateur (2000), lorsqu'un sénateur romain déclare : « Le cœur battant de Rome n'est pas le marbre du Sénat, c'est le sable du Colisée. »

Cette phrase m'est venue à l'esprit alors que je me promenais dans les couloirs de la KubeCon/CloudNativeCon (« KubeCon »), l'événement phare de la Cloud Native Computing Foundation (CNCF). Pour moi, le cœur battant de la sécurité cloud native est sans aucun doute KubeCon.

L'édition nord-américaine de l'événement de cette année a eu lieu la semaine dernière à Détroit, réunissant des milliers de participants sur place et bien d'autres à distance. En plus de l'événement principal de trois jours, l'intérêt croissant pour des projets spécifiques a conduit la Cloud Native Computing Foundation à organiser divers « événements colocalisés » avant la conférence principale.

Pour l'événement 2022, il y a eu non seulement un événement CloudNativeSecurityCon spécifique de deux jours, mais également de nombreux contenus de sécurité lors d'autres événements, notamment l'Application Networking Day, EnvoyCon, Policy Day with OPA, ServiceMeshCon, et bien d'autres, reflétant le large intérêt pour le cloud. sujets de sécurité natifs. Il est intéressant de noter que l’événement CloudNativeSecurityCon est désormais lui-même « devenu » un événement indépendant qui sera organisé séparément en février.

Sécurité cloud native : développement vs opérations

Alors, où en sont les conversations sur la sécurité cloud native ? Pour Omdia, il existe une forte bifurcation : des préoccupations centrées sur le développement et des préoccupations centrées sur les opérations. Il n'est pas aussi utile de les appeler « Dev » et « Ops », car la structure des équipes est en évolution dans de nombreuses organisations : certaines peuvent avoir des équipes d'ingénierie de fiabilité de site (SRE), d'autres peuvent les appeler opérations, équipes de plate-forme, etc.

Du côté du développement du grand livre, trois sujets d'intérêt sont la provenance, le bruit et l'exposition.

Provenance pose la question fondamentale : pouvons-nous faire confiance à l'intégrité du composant externe que nous intégrons dans notre pipeline logiciel ? Bien qu’il existe de nombreux exemples, l’attaque SolarWinds de 2020 a marqué un tournant dans l’intérêt porté à l’intégrité de la chaîne d’approvisionnement logicielle. Lors de la KubeCon, il y avait un élan palpable derrière l'idée de signer des images logicielles : magasin de signatures Le projet a été annoncé comme étant disponible pour tous et est utilisé par Kubernetes et d'autres projets clés.

Le bruit fait référence à la réduction du nombre de vulnérabilités qui existent dans l'environnement, en commençant par la réduction des images de base de conteneurs utilisées. Cela peut inclure l’utilisation de bases d’images telles que Alpine ou Debian Slim ou l’envisagement d’alternatives « sans distribution » encore plus petites. L’avantage est que ces images plus petites ont une empreinte minimale et donc un risque réduit d’apparition de vulnérabilités.

Exposition : pour une vulnérabilité donnée, dans quelle mesure sommes-nous exposés en tant qu'organisation ? Il n’y a bien sûr pas de meilleur exemple de cela dans l’histoire récente de l’industrie que Log4j. C'est le domaine des discussions sur les nomenclatures logicielles (SBOM) car il s'agit de savoir où les composants peuvent être utilisés soit sous forme d'images stockées dans un registre quelque part, soit en cours d'exécution en production. Il est intéressant de noter qu'au moment où cet essai est en cours de rédaction, des informations sur les vulnérabilités critiques d'OpenSSL 3.x seront divulguées prochainement, ce qui constituera probablement un autre bon cas d'utilisation des SBOM - où OpenSSL 3.x est-il utilisé dans notre organisation ? Étant donné que la couverture SBOM n’est pas encore très répandue, Omdia s’attend malheureusement à une utilisation minimale du SBOM cette fois-ci.

Les équipes opérationnelles se concentrent naturellement sur la fourniture et l’exploitation d’une plateforme sous-jacente de plus en plus complexe, et ce, en toute sécurité. Le mot « plateforme » est particulièrement pertinent ici : il y avait un intérêt notable à organiser Kubernetes et une grande partie de la liste croissante de projets CNCF (140 au moment d'écrire ces lignes, entre les différentes étapes d'incubation du projet : bac à sable, incubation, gradué) en des formats plus faciles à utiliser. plateformes de consommation. D'un intérêt particulier pour les publics de sécurité, des projets tels que Cilium (utilisant la fonctionnalité eBPF sous-jacente) pour la mise en réseau et l'observabilité, SPIFFE/SPIRE (pour l'établissement d'identités), Falco (pour la sécurité d'exécution), Open Policy Agent (pour la politique en tant que code) , Cloud Custodian (pour la gouvernance) et d'autres méritent d'être examinés. On s’attend à ce que ces projets collaborent de plus en plus avec les aspects « d’observabilité » du cloud natif et soient également déployés à l’aide de pratiques telles que GitOps.

Raisons d’être optimiste quant à la sécurité cloud native

Où allons-nous à partir d'ici? Il était tout à fait clair que la communauté cloud native se soucie profondément de la sécurité et avance à toute vitesse en abordant les nombreux sujets qui l'entourent. Les équipes de sécurité doivent se familiariser rapidement avec la manière dont ces différents projets et initiatives sont mis en œuvre. Il est important de noter que pour de nombreuses organisations, cela ne prendra pas la forme d'une utilisation explicite du projet communautaire (même si certaines le feront), mais plutôt dans le cadre d'une plate-forme packagée provenant de fournisseurs tels que Red Hat, SUSE, Canonical et d'autres. ou directement auprès des fournisseurs de cloud tels qu'AWS, Google Cloud, Azure, Oracle et autres.

Sachez que, dans le contexte de l'utilisation de l'open source, il n'y a rien de vraiment « gratuit » — même si l'on choisit d'utiliser la version vanille en amont des projets, il y a des coûts inhérents à la maintenance de ces packages et à la participation au développement de la communauté.