Sommaire
Introduction
Sécuriser son système d’information demeure une préoccupation majeure. Et avec l’adoption des conteneurs et Kubernetes, de nouvelles méthodes et outils sont apparus pour apporter une sécurité adaptée sur l’ensemble des surfaces d’attaques.
Sécuriser vos surfaces d’attaques
Cet article est destiné à l’ensemble de vos équipes intervenant sur la globalité des sujets techniques en lien avec Kubernetes (architecture, code, infrastructure, réseau… ) et désirant connaître les méthodes et outils de sécurité sur l’ensemble des surfaces d’attaques.
Sécuriser son infrastructure Kubernetes
C’est historique, les menaces d'intrusions commencent par l’infrastructure. Il est donc très important de bien se poser, prendre son temps afin de travailler sur l’architecture de son infrastructure en prenant en compte les aspects sécurité en priorité. Le changement ultérieur dans l’architecture d’infrastructure pourrait être très impactant. Ce travail doit se faire en équipe avec les personnes clés, décideurs qui connaissent les exigences de sécurité, les patterns d'architectures déjà présentes et à réutiliser ainsi que les contraintes organisationnelles et techniques. Les points à aborder afin de proposer une architecture d’infrastructure sécurisée sont les mêmes, et j’en citerai quelques-uns ici :
- Localisation des nœuds (Masters et workers) de son cluster dans une zone réseau privée non accessible depuis internet.
- Exposition privée de l’API Kubernetes (via un rebond ou VPN)
- Protéger et réduire les accès aux nœuds de vos clusters Kubernetes
- Décider sur le chiffrement ou non des échanges entre les nœuds et les pods.
- Méthode de chiffrement des échanges entre les nœuds de vos clusters Kubernetes
- Méthode de chiffrement de l’Etcd
- Politique de cloisonnement entre les projets (Network Policy, Security Context…)
- Gestion d’authentification et d’autorisation Kubernetes (Choix de l’IDP, Roles, policies… )
- Gestion d’authentification et d’autorisation des ensembles des outils utilisés autour de Kubernetes (CI/CD, gestionnaire de secrets, registries, repos source, IDP… ),
- Sécurisation des APIs applicatives publiques et privées ( Token, API throttling…)
- Sécurisation de l’accès aux applications via HTTPS même dans votre cluster.
Idéalement, l’ensemble des points doit être formalisé et détaillé dans un dossier d’architecture technique à valider dans un comité d’architecture. Ainsi, nous construisons une feuille de route avec en cible les exigences de sécurité de l’entreprise.
Les clusters Kubernetes seront exposés à l’outil de déploiement choisi qui est accessible aux équipes afin de déployer le code applicatif. Il est donc important de contrôler et de s'assurer que ce qui est à déployer n’est pas vulnérable et ne contient pas de failles de sécurité. Ces contrôles devraient démarrer dès la phase de développement.
La sécurité dès le développement
Le développeur est généralement concentré sur les fonctionnalités métier à implémenter et les aspects sécurité sont souvent laissés de côté. Et ceci même s’il y a la volonté de livrer un code de qualité respectant les standards et exigences de sécurité connus ou fournis par l’équipe sécurité de l’entreprise.
Aujourd’hui, les premières analyses de sécurité commencent assez généralement à la phase de construction des artefacts applicatifs dans la CI. Lors de cette phase, des vulnérabilités critiques pourraient être détectées et donc une reprise de développement afin de corriger est nécessaire.
Afin d’éviter ces détections tardives de ces vulnérabilités, il est possible d’embarquer les analyses de sécurité dès la phase de développement. Les développeurs peuvent en effet intégrer des solutions SAST ( Static application security testing) dans leurs IDE qui permettent le repérage des vulnérabilités présentes dans le code source en temps réel, ou dans les dépendances utilisées en proposant les solutions apportant les correctifs.
Ces outils sont capables aussi de détecter les failles et vulnérabilités les plus courantes en lien avec le OWASP TOP 10 et les standards de conformité, PCI DSS par exemple.
Par exemple, pour son programme qui tourne sur un JRE 1.7, quand un développeur utilise le SocketAppender de la librairie Log4j 1.x, l’outil SAST peut détecter en temps réel l'existence du CVE-2023-26464 et lève une alerte au développeur avec les détails du CVE et le correctif qui peut être apporté
Les librairies open source que l'on utilise dans nos programmes présentent potentiellement des failles de sécurité, présentes sur quelques fonctionnalités, et non sur l’ensemble. La puissance de ces outils consiste à détecter uniquement les failles à l’utilisation des fonctionnalités vulnérables dans vos programmes. Ainsi, si vous utilisez des fonctionnalités non vulnérables, il n‘y aura pas de problème.
Les outils SAST les plus développés sont potentiellement accompagnés d’une offre payante et s'intègrent bien dans les IDE comme au niveau de la CI tels que Sonar et Snyk.
La sécurité lors de la CI
Quand la chaîne d’intégration continue démarre, une batterie de tests pourraient être automatisés avant le déploiement. Parmi les tests importants à intégrer, ce sont ceux de la sécurité. Ces tests de sécurité peuvent exister à plusieurs niveaux.
Avant la construction de vos artefacts
Avant la construction de vos artefacts applicatifs, les mêmes outils SAST peuvent être intégrés pour relancer les analyses statiques du code source (SAST). Ceci permet de s’assurer qu’il n’y a pas de vulnérabilités critiques passées entre les mailles du filet.
Analyse des images de conteneurs
Une fois que les images sont construites à partir de vos Dockerfile, il est important d’effectuer un scan de sécurité. Ce scan pourrait se faire à deux niveaux, soit directement au niveau de la CI avant la publication de l’image ou directement dans le gestionnaire d’images, ce qui est plus intéressant pour des raisons de mutualisation et contrôle de règles.
Plusieurs gestionnaires d’images intègrent des outils d’analyse de vulnérabilités. Par exemple, Harbor intègre par défaut l’outil de détection de vulnérabilités Trivy, et Quay intègre Clair.
Et, selon les criticités des CVE détectés, les images peuvent ne pas être autorisées à être téléchargées, donc déployées et par conséquent exécutées. Sur la majorité des outils de gestionnaires d’images, il est aussi possible de configurer une liste de CVEs que vous voulez autoriser, car vous considérez qu’il s’agit de vulnérabilités non critiques.
Une gestion des accès aux dépôts d’images est primordiale pour empêcher les modifications des images par un attaquant.
La sécurité lors du déploiement
Afin de garantir le respect des exigences de sécurité, il est recommandé d’analyser et de valider les objets Kubernetes à déployer. En voici quelques exemples :
- Empêcher l’accès à vos secrets et donc vos données sensibles en interdisant l’utilisation des verbes “get”,”list” et “watch” dans “Rôle” ou “Cluster Rôle” quand c’est associé aux ressources “Secret”
- Forcer l’utilisation de l’uid de vos images en empêchant l’utilisation du SecurityContextConstraint (SCC) anyuid.
- Empêcher l’acquisition de l’ensemble des droits sur vos ressources en interdisant l’association du “Rôle” Cluster Admin du “Cluster Rôle” aux différentes ressources Kubernetes.
- Empêcher l’escalation du privilège en interdisant l’utilisation des verbes “escalate”, “bind” et “impersonate”
Afin de déployer une validation de vos ressources à déployer, un “Admission Controller”vous aidera à contrôler la ressource Kubernetes dans le but de décider ou non de son admission.
Les implémentations les plus connus d’“Admission Controller” sont OPA GateKeeper et Kyverno. Les deux outils ont la même logique, et sont constitués de règles, et un moteur qui valide les ressources Kubernetes en se basant sur les règles. À part la catégorie sécurité, vous trouverez plusieurs règles de bonnes pratiques de Kubernetes ou des outils les plus connus (Istio, Argo, Velero …).
La sécurité à l'exécution
Bien que les méthodes et les outils abordés dans les précédents paragraphes renforcent la sécurité de vos clusters Kubernetes, ils ne permettent pas de sécuriser l’environnement d'exécution lui-même. Effectivement, plusieurs menaces peuvent apparaître une fois que vos conteneurs sont en cours d'exécution, notamment :
- Nouvelles vulnérabilités de vos conteneurs lancées avec d’anciennes images.
- Dérive de configuration, tels que la modification des privilèges sans autorisation.
- Attaque d’escalade de privilège et accès à la machine hôte
- Exécution d’un code malicieux présent dans le conteneur
- Exécution d’un malware téléchargé par le code du conteneur
D’autres techniques d’attaques au runtime sont présentes dans MITRE ATTACK , et que vous pouvez exécuter pour simuler des vulnérabilités et observer le comportement de votre système avec la librairie Atomic Red Team.
Afin d’apporter la sécurité à l'exécution, nous devrons installer un système de surveillance qui détecte les comportements malicieux, vous avertit et agit pour bloquer ce comportement.
L’outil essentiel et incontournable à installer pour vous protéger à l'exécution est Falco. Aujourd’hui, il s’agit d’un des meilleurs outils concernant ces aspects.
Falco utilise eBPF pour détecter l’ensemble des appels système effectués. Un appel système est considéré malicieux quand une règle Falco correspond.
Plusieurs Rules sont présentes et développées par la communauté, et vous pourrez en développer facilement les vôtres. Toutefois, il n’est pas possible de déployer à chaud de nouvelles règles, ce qui reste toutefois une limitation de la version communautaire de Falco.
Falco ne propose pas un mécanisme de réponse manuel ou automatique à la détection d’un comportement malicieux. Néanmoins, avec le deamon Falcosidekick, vous pourrez transférer les événements falco à de multiples solutions FaaS: OpenFaas, AWS Lambda, KNative, kubeless, Tekton …. et développer ainsi vos propres actions.
Vous pourrez aussi utiliser le moteur de réponse Open Source Falco Talon. Il s’agit d’un projet tout nouveau encore en phase d’expérimentation et pouvant s’intégrer avec Falcosidekick ou directement avec Falco pour capturer l’ensemble des vulnérabilités ou des intrusions détectées , ainsi que les événements.
Les attaques à l'exécution évoluent très rapidement, et dans un contexte de production, il n’est pas acceptable qu’une attaque ne soit pas détectée et que son investigation soit compliquée à réaliser.
Il est donc plus judicieux d’avoir un outil puissant de sécurité qui évolue en temps réel grâce à l’IA et l’auto-apprentissage, proposant un moyen d’investigation approfondie et un système de réponse rapide.
Des outils EDR (Endpoint Detection and Response) installés dans vos clusters Kubernetes sont aujourd’hui indispensables afin de mieux sécuriser vos “runtimes”. Ces outils sont considérés aussi comme des antivirus 2.0, car ils proposent des agents plus légers qui détectent les “malwares” à l'exécution avec l’analyse comportementale et au repos, avec de longs scans, consommateurs de ressources.
Plusieurs outils EDRs payants proposent une intégration avec Kubernetes. Toutefois, optez pour un EDR eBPF, qui surveille l’ensemble de vos pods et aussi vos nœuds.
Une meilleure surveillance de votre sécurité
Pour une meilleure efficacité de vos équipes sécurité, il est intéressant d’avoir un seul outil permettant de :
- Fournir une vue centralisée et détaillée des violations de conformité détectées, et les solutions à apporter.
- Pouvoir développer et intégrer en temps réel des nouvelles règles de conformités.
- Pouvoir investiguer et apporter une réponse rapide aux vulnérabilités détectées.
Les outils KSPM (Kubernetes Security Posture Management) permettent de centraliser l’ensemble de ces actions, en vous offrant une Observabilité complète de votre sécurité implémentée, vos conformités, les menaces et vulnérabilités détectées. L’outil KSPM que je trouve le plus complet dans le marché est Sysdig. Pour la détection des vulnérabilités et les intrusions, Sysdig utilise l’outil qu’ils ont créé : Falco
Conclusion
Nous avons parcouru dans cet article les différentes méthodes et les outils de sécurité pour sécuriser l’ensemble des surfaces d’attaques dans un SI utilisant Kubernetes. Ces méthodes sont très diverses et nécessitent des compétences transverses très vastes. Le modèle organisationnel avec une seule équipe de sécurité, qui est garante de la sécurité globale du SI, n’est donc plus adaptée.
Une nouvelle organisation devrait potentiellement être revue pour que le périmètre sécurité soit porté par l’ensemble des équipes, et l’équipe sécurité devient l’équipe centrale qui apporte les solutions d’observabilité et d’alerting autour de la sécurité, ainsi que l'accompagnement des équipes et la communication des conformités et des exigences à respecter.
