Tech Radar - Secure

Adopt

Checkov

Checkov est un outil d’analyse de code statique (SAST) pour votre Infrastructure as Code, permettant de vérifier et de renforcer l’application des bonnes pratiques, notamment sur la sécurité.

Checkov, et les SAST de manière générale, s’inscrivent dans le paradigme récent de la sécurité shift left. Il s’agit d’une philosophie qui vient inscrire la sécurité plus tôt dans le cycle de développement d’une application. Là où le paradigme traditionnel voit la sécurité être implémentée à la suite du développement du logiciel, au moment de la phase de test, la sécurité shift-left voit cet intérêt pour la sécurité être déplacé au moment du design et du développement de l’application.

L’outil supporte l’analyse des configurations de plusieurs technologies comme : Terraform, Helm, Docker, Ansible et la plupart des gestionnaires de CI/CD. Il est également capable de détecter la présence de secrets en clair dans le code. Nous avions déjà placé Checkov en "Adopt" sur notre dernier Tech Radar, avant la sortie en octobre 2023 de la version 3.0. Cette nouvelle version implémente la compatibilité avec Jenkins et Bicep, mais également la possibilité de créer ses politiques custom. La création de politiques personnalisables est simple et peut se faire en python ou même avec du YAML. Nous avons trouvé cette fonctionnalité utile pour vérifier l’application de tags spécifiques par exemple, ou d'autres bonnes pratiques qui ne se réfèrent à aucun framework de sécurité.

S’adaptant aux tendances, Checkov nous offre aussi désormais la possibilité de s’interfacer avec openAI pour obtenir des analyses de résultats plus détaillées et guidées.

Nous continuons à utiliser Checkov au quotidien dans nos process de développement mais aussi lors de nos différentes missions d’audit. L’outil nous a plusieurs fois servi lors d’audits de sécurité infrastructure. C’est un très bon outil d’audit de contrôle dans un contexte réglementaire comme ISO 27001, PCIDSS ou encore SOC2.

External Secrets

External Secrets permet d'utiliser des systèmes de gestion de secrets externes pour ajouter des secrets en toute sécurité dans Kubernetes.

Stocker ses secrets de manière centralisée est un des grands principes de la sécurité. External Secrets a été créé par l’engineering team de GoDaddy en 2019 suite à l’expression de ce besoin : mettre à disposition des secrets stockés dans un système central à des applications Kubernetes.

External Secrets propose de nombreuses intégrations avec les systèmes de gestion de secrets classiques comme Azure, AWS, GCP, Vault, Gitlab, Oracle ou IBM. Notons également le puissant moteur de templating permettant de créer des secrets formatés comme bon vous semble. Par exemple, vous pouvez créer un secret Kubernetes TLS à partir d’une archive PKCS#12.

En termes de gestion des droits et du respect du moindre privilège, External secrets permet de restreindre les droits par namespace via l’utilisation de SecretStore. Si vous souhaitez un contrôle plus fin sur les droits, par exemple limiter l’accès à certains prefix de path, il faudra utiliser des Admission Webhook comme Kyverno.

Si le secret d’origine est modifié, External secrets va mettre à jour la valeur du secret Kubernetes. L’intervalle de temps de polling est paramétrable par ressource ExternalSecret. Attention, la mise à jour d’un secret Kubernetes n'entraînera pas le rollout d’un pod qui utiliserait ce secret. Si vous souhaitez ce genre de fonctionnalité, il faudra utiliser un outil plus puissant comme Vault Secret Operator.

Il existe évidemment d’autres outils remplissant la même mission et apportant différentes fonctionnalités : Vault Operator, KSOPS, Sealed Secrets, ArgoCD Vault plugin... N’hésitez pas à comparer ces solutions et choisir celle qui vous convient.

Helm Secrets

Helm Secrets sécurise les secrets stockés sur Git via chiffrement, simplifiant leur gestion pour les équipes qui débutent.

On vous l'a maintes fois répété : stocker des secrets en clair dans un dépôt Git constitue une faille de sécurité majeure. Les informations sensibles comme les clés d'API, les mots de passe et les certificats peuvent être facilement exposées, ouvrant la porte à des cyberattaques. Il est par conséquent crucial de chiffrer vos secrets avant de les ajouter à un dépôt Git pour garantir qu'ils restent bien... secrets.

Dans ce contexte, Helm Secrets est un plugin Helm qui simplifie la gestion des secrets dans un dépôt Git, permettant de les stocker de manière sécurisée tout en les rendant accessibles pour les déploiements Kubernetes via ArgoCD par exemple. Helm Secrets utilise des outils de chiffrement comme AWS KMS ou GCP KMS couplés à l’outil SOPS pour chiffrer les fichiers secrets localement puis les déposer sur le dépôt Git. Cette approche est particulièrement pratique pour une équipe de développement peu expérimentée et encore un peu éloignée des pratiques cloud-native, car elle réduit l'apprentissage nécessaire.

Point intéressant, les fichiers YAML chiffrés par Helm Secrets ne sont pas complètement opaques : les équipes peuvent voir les clés YAML présentes à l'intérieur sans compromettre la sécurité des valeurs, ce qui facilite les revues de code. En termes de mise en place, Helm Secrets nécessite simplement l'installation du plugin dans la stack de CI/CD en charge de déployer les charts Helm. Niveau sécurité, comme les secrets restent chiffrés au repos et en transit, cela coche pas mal de cases sans complexité excessive.

Comparé à d'autres outils comme External Secrets ou Sealed Secrets qui demandent de rédiger des templates compliqués, Helm Secrets se distingue par sa simplicité, ce qui en fait un choix judicieux pour des équipes recherchant un équilibre entre sécurité et facilité d'utilisation.

Hub and Spoke

Le Hub and Spoke isole les ressources des applis ou des services (Spoke) avec un compte central (Hub) qui gère les communications réseau et partage les outils entre les spokes.

Le modèle Hub and Spoke est utilisé pour gérer les comptes cloud. Si la création de ressources dans le cloud est simple, les organiser à grande échelle et garantir leur sécurité est bien plus complexes. Ce modèle est principalement adopté par les entreprises ayant de nombreuses applications et un besoin élevé de gouvernance.

Le compte Hub est le compte central. Il permet de centraliser les communications (entrantes, sortantes), de les monitorer et de renforcer l’isolation entre les réseaux des différents environnements ou des différentes applications. Il permet aussi de centraliser les politiques de sécurité qui seront ensuite héritées par les comptes Spokes.

Les Spokes contiennent tout ce qu’il faut pour héberger des workloads. Ces comptes sont provisionnés en tenant compte des besoins de vos applications, en héritant des bonnes pratiques et politiques de votre organisation et en étant connectés au Hub pour profiter de la gestion centralisée du réseau. Le niveau d’autonomie des équipes sur les Hub sera à définir en fonction de votre organisation et de vos contraintes de sécurité.

Une infrastructure Hub and Spoke permet de garantir un haut niveau de sécurité sur une infrastructure à grande échelle. Implémenter un Hub and Spoke est souvent utilisé pour des grandes organisations, mais il a tout intérêt à être implémenté dans des petites organisations pour avoir des fondations solides et scalables.

Kyverno

Kyverno est une solution de Policy as Code open source, permettant d’assurer le respect de bonnes pratiques de sécurité lors du déploiement dans Kubernetes.

La plupart des paramètres de sécurité des applications Kubernetes doivent être vérifiés au plus tôt, notamment dans la CI/CD. Mais la validation de politiques au déploiement, directement intégrée au moteur de validation de Kubernetes, permet le respect des bonnes pratiques de manière certaine. De plus, elle limite les actions d’un attaquant en cas de compromission.

Kyverno permet d’étendre les possibilités de validation de sécurité natifs de Kubernetes (notamment les Pod Admission Policies, introduits avec Kubernetes 1.25 ou encore le RBAC) et peut s’y substituer ou s’appliquer de manière complémentaire. Intégré depuis 2020 au sein de l’incubateur CNCF, et en statut Incubating depuis 2022, Kyverno est aujourd’hui une valeur sûre dans l’écosystème sécurité de Kubernetes.

La puissance de Kyverno réside dans la simplicité d’écriture des politiques en yaml et dans la variété de types de politiques proposées : validation, mutation ou génération de ressources à la volée.

Si de nombreux outils permettent aujourd’hui d’auditer et de valider la configuration des applications dans Kubernetes, Kyverno est une des rares solutions proposant une gestion avancée des exceptions, répondant ainsi aux contraintes opérationnelles d’un cluster de production.

Les politiques de génération de ressources sont particulièrement intéressantes, y compris dans des environnements gérés en GitOps, pour améliorer l’expérience utilisateur dans la gestion des NetworkPolicies (les règles de pare-feu dans Kubernetes), en permettant par exemple:

De descendre automatiquement des NetworkPolicies bloquant les accès aux endpoints de métadonnées des Cloud Providers à la création d’un namespace ;
D'autoriser les ingress controllers à contacter les services exposés sans avoir à explicitement créer une NetworkPolicy, celle-ci étant automatiquement créée par Kyverno.

Grâce aux rapports générés par Kyverno, il est également possible d’obtenir des métriques sur la conformité du cluster vis-à-vis des politiques configurées.

Kyverno est donc bien plus qu’un outil d'audit de configuration et permet aux équipes de définir une politique de sécurité et de s’assurer de son respect dans les environnements Kubernetes.

NetworkPolicies

Les NetworkPolicies sont essentielles à la sécurité d’un cluster Kubernetes. Par défaut, le trafic réseau n’y est pas restreint, et les NetworkPolicies résolvent ce problème.

Le filtrage réseau est l’une des meilleures mesures pour limiter l’impact d’une compromission dans un système d’information, et il en va de même dans un cluster Kubernetes. Cependant, le filtrage réseau est bien trop souvent négligé dans un cluster (il n’y en a pas par défaut !), là où il est vu comme essentiel dans un réseau classique.

Les NetworkPolicies offrent une solution à ce problème en permettant de définir des règles de filtrage réseau entre les pods.

La mise en œuvre technique des NetworkPolicies dépend de la CNI installée et peu se faire sous différentes formes : création de règles iptables, module eBPF, etc. Le comportement par défaut (autoriser le trafic ou bloquer le trafic) va également dépendre de cette dernière. Il est important de bien se renseigner sur l’implémentation des NetworkPolicies par la CNI choisie avant d’en mettre en place.

Les ressources NetworkPolicies font partie de l’API native Kubernetes. Toutefois, pour résoudre les limitations de la ressource native, certaines CNI (telles que Calico ou Cilium) permettent, en complément, d’utiliser des ressources spécifiques (CRD Kubernetes) pour définir les règles de filtrage.

Le filtrage réseau précis peut être complexe, mais les NetworkPolicies sont cruciales pour sécuriser un cluster Kubernetes. Nous recommandons de commencer par des politiques simples qui amélioreront votre sécurité, comme isoler les composants de tooling des applications ou bloquer l'accès aux métadonnées des nœuds dans un environnement managé.

SonarQube

SonarQube est un outil open source d’analyse permettant d’assurer la qualité et la sécurité de votre code. Il supporte un grand nombre de langages de programmation différents.

La qualité et la sécurité du code applicatif doivent être assurées tout au long du processus de développement, notamment par des outils intégrés à la CI/CD. SonarQube combine une analyse statique et dynamique du code à la recherche de bugs, de code smell et de vulnérabilités. Cela permet d’assurer une bonne sécurité, fiabilité et maintenabilité du code.

SonarQube possède aussi un grand nombre de jeux de règles disponibles (e.g. Top 10 de l’OWASP) sur plus d’une vingtaine de langages de programmation. De plus, vous pouvez ajouter vos propres règles.

Un niveau de criticité est également proposé pour chaque résultat, et permet d’avoir un score global d’une analyse divisée en 4 catégories. Il est ainsi possible de définir des standards bloquants sur les pipelines de déploiement, et d’imposer un certain niveau de qualité ou de sécurité du code tout au long du processus de développement.

Une console d’administration intuitive est disponible, où sont recensés les différents problèmes rencontrés dans le code. Elle permet d’avoir une vue d’ensemble des différents projets scannés.

Attention néanmoins, la console d’administration contient un grand nombre d’informations sensibles et son accès doit être correctement protégé. Le système de gestion des droits RBAC dans SonarQube est simple, mais efficace.

SonarQube sera un allié précieux dans une stratégie de sécurité shift left, permettant de détecter et de corriger les problèmes de sécurité dès les premières étapes du développement. Une approche proactive de la sécurité plutôt que réactive est alors favorisée.

SonarQube est disponible en SaaS (SonarCloud) ou en Open Source. Nous recommandons de commencer par le SaaS qui reste abordable au départ : 10€ par mois en dessous de 100k lignes de code.

Vault

Vault est un outil de gestion de secrets incontournable pour toutes les organisations.

Hashicorp Vault est l'outil de gestion de secrets le plus plébiscité par la communauté. Cela est possible grâce aux innombrables fonctionnalités et améliorations que Vault a apportées à ce secteur :

La génération de secrets dynamiques
La gestion de certificats directement via une API.
La gestion fine d'accès aux secrets en suivant un pattern RBAC (Role-Based Access Control) applicable à des utilisateurs, groupes ou machines.
L’intégration de différentes sources d'authentification (e.g Kubernetes)

Deux différences majeures font que Vault s’impose face à ses concurrents. Tout d’abord, son intégration avec différentes sources d’identités (e.g AWS, GCP, Kubernetes) qui permettent à vos workloads de s’authentifier et d’être autorisés à récupérer automatiquement leurs différents secrets. Mais également les différents moteurs de secrets dynamiques (Database, AWS, GCP) qui permettent une rotation des secrets à chaque utilisation.

Nous n’avons qu’une seule mise en garde quant à son adoption en mode auto-hébergé : Vault est un outil complexe et peut ne pas convenir à une petite organisation. Il ajoute comme toute technologie un coût d'opérabilité, et une mauvaise gestion de vos backups ou une mauvaise anticipation d’une mise à jour pourrait vous mener droit dans le mur.

Si votre équipe est déjà surchargée, préférez l'utilisation de la version SaaS de Vault ou alors les services de gestion de secrets de vos Cloud Providers.

Nous ne pouvons que le recommander aujourd'hui tant il nous a permis de répondre à des problématiques complexes sans ajouter un coût
de maintenance prohibitif.

Trial

Architecture Zero-trust

Zero-Trust est un modèle basé sur l’absence de confiance entre les parties : toutes les communications doivent être autorisées.

Le principe de base de l'architecture Zero-Trust est de ne faire confiance à personne ni à aucun périphérique par défaut, même s'ils se trouvent à l'intérieur du réseau. Il est aussi nécessaire de vérifier en permanence l'identité et les autorisations de tout ce qui tente d'accéder aux ressources de l'entreprise. Aucune confiance implicite n’est accordée à un utilisateur ou à un service en fonction de l’endroit d’où provient la requête.

Attention, Zero-Trust ne signifie pas qu’il faut arrêter de restreindre l’accès aux ressources via du filtrage réseau ! Le modèle Zero-
Trust part simplement du principe que le réseau sera nécessairement compromis ou que le périmètre sera défaillant. Cela contraint donc les utilisateurs et les appareils à prouver leur légitimité.

Le Zero-Trust est particulièrement adapté aux infrastructures Cloud, qui possèdent souvent une typologie réseau complexe, composée
de plusieurs réseaux virtuels interconnectés, potentiellement exposés sur internet. Dans ce contexte, la notion même de périmètre finit par perdre son sens, notamment dans les infrastructures serverless... C’est pour cela que l’IAM des Cloud Providers est fortement inspirée du modèle Zero-Trust et demande à chaque utilisateur ou service de prouver son identité avant de pouvoir accéder à des ressources.

Cette approche est séduisante, mais complexe à mettre en place. Chaque utilisateur et chaque application doit utiliser un système d’authentification centralisé (par exemple le MFA pour les utilisateurs ou les certificats TLS pour les serveurs). Généralement, un gestionnaire d’identité (Cloudflare Zero-Trust, Tailscale) fait le lien entre les terminaux externes (postes utilisateurs) et les services hébergés dans l’infrastructure.

Le concept de Zero-Trust est donc particulièrement adapté pour les entreprises ayant un besoin accru de protection de leurs données, mais nécessite un investissement important pour sa mise en place.

BuildKit

Buildkit est un moteur de build d’images de conteneurs avec un faible niveau de privilèges tout en prenant en charge toutes les instructions possibles d’un Dockerfile.

Le build d’images de conteneurs est aujourd’hui une problématique centrale de la CI/CD des applications conteneurisées. Mais c’est aussi souvent une opération coûteuse qui peut impliquer la compilation de binaires, et donc une forte charge RAM et de CPU.

Alors, afin de s’adapter à une charge forte, mais très variable en fonction des développements en cours, il est confortable de réaliser ces builds dans des clusters Kubernetes habituellement partagés avec d’autres outils.

Pour assurer la sécurité de ces clusters, il est important que les outils qu’ils hébergent, et donc notamment ceux de build d’images de conteneurs, soient exécutés sans privilèges.

Or, historiquement, les builds d’images de conteneurs nécessitent un processus privilégié. Par conséquent, un développeur qui a le droit de lancer une pipeline de build pourrait prendre le contrôle de tous les conteneurs qui tournent sur le même nœud.

Heureusement, de nombreuses évolutions du noyau Linux réalisées ces dernières années ont permis de voir apparaître la possibilité de lancer des conteneurs quasiment sans privilèges. Et les moteurs de build se sont adaptés en conséquence. Ainsi des outils comme Buildkit, Buildah, ou encore Kaniko, prennent désormais en compte chacun à leur manière ces nouvelles possibilités.

Nous favorisons Buildkit sur nos projets car il semble être le seul à vraiment gérer toutes les instructions possibles d’un Dockerfile. De plus, il est bâti sur un modèle client/serveur qui permet de profiter d’un cache commun et d’offrir de belles performances, donc de diminuer le temps nécessaire au build. Un élément de sécurité qui accélère les développeurs, c’est possible !

Cilium

Cilium est un plugin réseau pour Kubernetes qui offre des fonctionnalités avancées de sécurité et d'observabilité.

Cilium est un projet open source de CNI (Container Network Interface) pour Kubernetes, gradué CNCF en octobre 2022. Ce plugin réseau gère le trafic entre les charges de travail d'un cluster et offre des fonctionnalités avancées telles que le chiffrement transparent du trafic entre pods (sans sidecar proxies), un filtrage réseau avancé avec les NetworkPolicies, une observabilité accrue du trafic, ou la communication multi-cluster.

La force de Cilium est que ce CNI est basé sur eBPF (Extended Berkeley Packet Filter), une technologie du noyau Linux permettant d'exécuter des programmes isolés dans l'espace noyau. eBPF étend de manière sûre et efficace les capacités du noyau sans modifier son code ou ajouter des modules, offrant des performances supérieures à iptables utilisé par kube-proxy. Cilium n'a pas besoin de module noyau supplémentaire et fonctionne sur tout serveur avec un noyau Linux récent (>= 4.19).

L’outil offre des fonctionnalités essentielles pour un cluster Kubernetes central et critique pour votre infrastructure, notamment en sécurité et observabilité. Par exemple, vous pouvez effectuer un filtrage réseau couche 7 avec la CRD CiliumNetworkPolicy ou obtenir une visibilité approfondie sur le trafic de couche 7 grâce aux métriques de Cilium.

Cilium permet aussi de chiffrer facilement le trafic entre les pods. Pour ceux utilisant un Service Mesh pour le chiffrement mTLS, Cilium apporte une solution plus simple.

Cilium est devenu le CNI de choix pour Kubernetes, utilisé par Datadog et dans les dataplanes v2 de GKE. Mais il est complexe à utiliser, requiert
des compétences techniques avancées, et n’est pas toujours configurable dans les clusters managés (par exemple, GKE ne permet pas de configurer directement le chiffrement entre pods via le CNI). De plus, beaucoup de fonctionnalités sont encore en bêta.

Falco Security

Falco est un outil de détection d’intrusion pour Kubernetes. Il repose sur l’analyse dynamique des appels systèmes et des audits logs pour lever des alertes en cas de comportement suspect.

Falco est un outil open source développé par Sysdig qui fait partie de la CNCF depuis 2018. Il permet de détecter les comportements suspects dans les environnements conteneurisés. Il s’intègre donc parfaitement à Kubernetes.

Falco fonctionne en ingérant les différents appels système effectués sur les machines hôtes ainsi que les événements de l’API Server. Cela représente un avantage notable par rapport aux autres HIDS (Host-based Intrusion Detection Systems). En corrélant ces logs avec des règles configurables, Falco est capable de détecter les menaces potentielles et d'envoyer des alertes fournissant des informations détaillées sur les événements déclencheurs. Il peut notamment identifier les mutations de binaires, la lecture des secrets, etc. Falco est hautement personnalisable, permettant aux utilisateurs de créer leurs propres règles et alertes pour répondre à leurs besoins de sécurité spécifiques. Il est possible de gérer ces règles as code grâce au GitOps.

Falco est un élément essentiel pour assurer la sécurité d'un cluster Kubernetes. Nous recommandons son utilisation dans la mesure où vos équipes ont le temps de traiter et de configurer les alertes. La grande difficulté dans sa mise en place réside dans le fine-tuning de la configuration pour produire le bon volume d’alerte. Il convient de diminuer au maximum le nombre de faux positifs avec un système de whitelisting.

Il est à noter également que des problèmes persistent quant à l’interconnexion de Falco avec le noyau : par exemple, dans un cluster EKS, les modules noyau Falco sont publiés en général 2 semaines après la publication d’une nouvelle AMI par AWS, ce qui retarde la mise à jour des nœuds.

Nous recommandons donc cet outil dans la mesure où votre équipe dispose de la bande passante nécessaire pour traiter les alertes au quotidien, autrement vous alimenterez juste la charge des personnes responsables de la réponse à incident.

Linkerd

Linkerd permet de mettre en place simplement le chiffrement et l’autorisation des communications dans les clusters Kubernetes.

Linkerd est un Service Mesh pour Kubernetes, gradué par la CNCF. Il offre des fonctionnalités avancées pour les communications au sein du cluster, telles que le chiffrement inter-Pods et des politiques de Zero-Trust pour une sécurité accrue. Il permet également une observabilité poussée des communications inter-Pods, ainsi que l'injection de fautes.

Linkerd propose une architecture très simple comparé à d’autres Service Mesh comme Istio. Cela est notamment dû au nombre restreint de fonctionnalités de Linkerd, qui peut s’étendre grâce à l’utilisation de plugins : par exemple le tracing grâce à Jaeger ou les canary releases grâce à Flagger. Certaines fonctionnalités proposées par ses concurrents sont toujours absentes dans l’outil, notamment le JWT header based routing. Cette architecture simplifiée réduit le coût de mise en place de ce Service Mesh, qui ne nécessite pas son propre Ingress controller. Cela rend son intégration très facile même sur des clusters déjà outillés. De plus, il peut s’interfacer avec des outils comme Vault ou cert-manager pour gérer le renouvellement automatique des certificats mTLS utilisés. Linkerd se démarque de ses concurrents grâce à d'excellentes performances dûes à son proxy minimaliste écrit en Rust qui réduit la charge pour le cluster.

Le principal point faible de Linkerd est qu’il n’y a plus de version stable Open Source depuis la 1.24, mais seulement des versions “edge” qui peuvent amener à des breaking changes d’une version à l’autre. Pour garder des versions stables, il faudra passer à la version enterprise (Buoyant).

Nous recommandons Linkerd, qui a l’avantage de réduire l’impact opérationnel sur le cluster par rapport à ses concurrents. Il offre la plupart des fonctionnalités attendues, notamment via son système de plugin. Attention à bien tester les nouvelles versions sur des clusters de non-production avant passage en production puisqu’il n’y a plus de support stable.

Assess

Boundary

Boundary est un outil voué à remplacer les systèmes existants qui permettent d'accéder à vos réseaux internes.

Boundary est un outil développé par Hashicorp et open sourcé en 2020. Il a pour vocation de remplacer vos solutions de Bastion, voire de VPN, en améliorant leur gestion, leur sécurité ainsi que leur expérience utilisateur.

Boundary permet d'obtenir la même expérience utilisateur que la fonctionnalité de "port-forwarding" de Kubernetes mais
sur l'ensemble de votre infrastructure (e.g. BDD, VMs, WebServices etc.). Il permet l’auditabilité et la ségrégation d’accès via des audits logs, la possibilité de révoquer des sessions en cours et également toute une logique RBAC (Role- Based Access Control) de gestion d’accès.

Il se décompose en :
• Un contrôleur central qui contient la configuration des différentes cibles auxquelles vos employés ont besoin d'accéder, ainsi que la gestion des droits.

• Des workers qui ont accès à vos différents réseaux internes et qui servent de passerelle.

La grande force de Boundary réside dans sa simplicité d'installation et d'opérabilité. Sa configuration peut être complexe, mais son intégration avec Terraform lui permet d'être automatisée de la même façon que le reste de la configuration de votre infrastructure. Nous apprécions également son intégration avec Vault, qui permet aux utilisateurs d’accéder à des ressources sans avoir à connaître aucun secret.

Boundary est encore jeune et nous ne sommes pas encore pleinement satisfaits de l'expérience utilisateur qu'il propose, notamment lors de l'ouverture de session vers un cluster Kubernetes. Nous sommes tout de même confiants pour la suite et pensons que le projet deviendra une référence dans ce type d'outils.

Istio

Istio est un outil complexe permettant un contrôle extrêmement fin des différentes communications entre vos applications.

Istio est un Service Mesh comme Linkerd qui offre de nombreuses fonctionnalités pour la sécurisation et l'observabilité de l’ensemble des communications au sein d’un cluster mais également vers l'extérieur.

Istio est un incontournable qui a fait ses preuves et dont tout le monde connaît l’existence.

En revanche, l’outil est difficile à mettre en place et à opérer, ce qui peut bloquer de nombreuses personnes quant à son adoption.

Nous avons déjà essuyé beaucoup de plâtres dans nos projets à cause de lui, notamment le passage à la version 1.6 qui a marqué de nombreux utilisateurs. Les mainteneurs de l’outil ont néanmoins mis l’accent sur cette problématique l’année passée si bien qu’il est devenu nettement plus simple à utiliser. Un Helm Chart est en effet maintenant disponible pour Istio, ce qui permet de le gérer en GitOps au lieu d’utiliser la CLI istioctl.

Cependant, la principale motivation pour l’installation d’Istio est le chiffrement des communications inter- clusters pour répondre aux exigences de sécurité. De fait, nous favorisons l’utilisation d’outils plus simples et dont la charge sur les clusters est moins importante comme Linkerd.

Mais dans un contexte de forte contrainte de sécurité, où notamment le contrôle des flux de sortie est nécessaire, Istio reste un outil qui répondra parfaitement au besoin. Les fonctionnalités qu’il propose sont très matures et généralement plus exhaustives que celles de ses concurrents. L’outil intègre par exemple Kiali qui offre une interface graphique permettant de visualiser l’ensemble des flux au sein d’un cluster.

Istio reste un outil complexe dont l’adoption nécessite une bonne évaluation préalable. Istio rajoute un coût de maintenance assez important qui pourrait affecter des équipes qui sont parfois déjà surchargées.

OAuth2 Proxy

OAuth2 Proxy est un reverse proxy qui sert à protéger des ressources exposées publiquement par une authentification via OIDC (Google, Keycloak, GitHub, etc.).

OAuth2 Proxy permet de protéger ses applications avec de l’authentification assurée par un fournisseur d’identité. Les applications internes ou les assets de staging peuvent, par exemple, être sécurisés de cette manière. OAuth2 Proxy fait office de reverse proxy : ainsi lorsqu’un utilisateur veut se connecter à une application protégée, il doit d’abord passer par OAuth2 Proxy, s’authentifier, et accéder à l’application uniquement si son identité le permet.

OAuth2 Proxy permet avant tout de protéger toutes les applications très simplement avec de l’OIDC, même si elles ne sont pas initialement compatibles. De plus, il centralise l’authentification avec du SSO pour les actifs réservés à un usage interne.

Le contrôle d’accès reste cependant assez simple. OAuth2 Proxy accepte ou non les utilisateurs en s’appuyant sur les scopes du token JWT fourni par l’IdP. Il ne permet pas facilement de créer des groupes d’utilisateurs ou de donner des accès spécifiques à certaines applications. De fait, OAuth2 Proxy peut être utilisé comme moyen d’autorisation, mais pas comme moyen de gestion des identités.

De plus, la surcouche d’authentification peut compliquer l’intercommunication des différents composants. Par exemple, un front ne pourra pas communiquer avec un service protégé par OAuth2 Proxy s’ils n’ont pas le même nom de domaine.

Nous recommandons donc l’utilisation d’OAuth2 Proxy dans des cas relativement simples, comme la protection d’outils internes. Attention, OAuth2 Proxy ne remplace pas non plus l’authentification portée par les applications, qui elle, protège contre d’autres types d’attaques comme les SSRF.

Hold

Open Policy Agent

Open Policy Agent (OPA) est un outil open-source centralisant et unifiant la gestion des politiques de sécurité et de conformité des infrastructures, notamment Kubernetes.

Open Policy Agent est un moteur de Policy as Code qui permet d’appliquer ou de vérifier l’application de bonnes pratiques dans des configurations d’infrastructure et de tooling.

OPA est utilisable pour valider les configurations de multiples outils et implémentations. De notre côté, nous nous sommes beaucoup intéressés à son intégration dans Kubernetes mais l’outil permet aussi de vérifier des configurations Terraform, Docker, Kafka, Envoy et même des configurations SSH.

Le moteur OPA se base sur un langage déclaratif appelé Rego. L’utilisation de ce langage est l’une des raisons pour lesquelles nous avons placé OPA dans la catégorie Hold. En effet, ce langage est complexe et difficile à prendre en main et il est dommage qu’aucun autre langage comme YAML voire JSON ne soit compatible avec le moteur.

Open Policy Agent possède un projet d’intégration avec Kubernetes appelé Gatekeeper. Ce projet permet d’implémenter (tout comme Kyverno) des politiques pour vérifier ou appliquer des bonnes pratiques de sécurité dans Kubernetes. L’utilisation de cet outil est bien plus complexe et lourde que Kyverno. Contrairement à Kyverno qui nous permet de créer des politiques à la demande, OPAGatekeeper impose la mise en place de CRDs afin de créer des politiques qui seront appliquées aux ressources pour lesquelles vérifier la bonne configuration.

Open Policy Agent est un outil puissant mais dont la grande complexité éclipse la qualité au profit d’autres moteurs de policy-as-code plus spécifiques comme Kyverno pour Kubernetes ou Checkov pour Terraform.