Article co-rédigé par Sébastien Thomas, Ricardo Piteira et Hendrick Johann Tankeu.

 

Si vous devez retenir un élément de cet article, c’est le suivant : par défaut, Kubernetes ne gère pas la sécurité.

Cela ne signifie pas que sécuriser Kubernetes est impossible, mais il est primordial de savoir que cette sécurité est entièrement entre les mains de l’utilisateur.

C’est à vous qu’il appartient de prendre les mesures pour sécuriser votre cluster.
Et cette sécurisation est d’ailleurs vraie quelle que soit la distribution de Kubernetes, que celle-ci soit on-premise ou un système managé comme Azure Kubernetes Services (AKS) ou d’autres équivalents chez les autres Cloud Solution Providers (CSP).

Facteur aggravant, la popularité de Kubernetes en entreprise fait que les attaquants redoublent d’efforts pour chercher des failles et des angles d’attaques. Il serait donc vain d’essayer de lister exhaustivement toutes les failles ou les modalités des attaquants qui évoluent sans cesse.

Cet article énumère les points essentiels pour appréhender la sécurisation de vos clusters et donne des pistes de réflexions pour poursuivre les recherches.

Nous n’oublierons pas que la sécurité ne consiste pas uniquement à se protéger des attaques. Sécuriser son service Kubernetes, c’est aussi assurer la sécurité des données et la reprise d’activité en cas de défaillance.

 

Surface d’attaque

 

Voici la représentation schématisée d’un cluster AKS ainsi que son environnement immédiat.

Les points à sécuriser, identifiés en vert sur le schéma, seront approfondis dans cet article :

 

Point n°1 : Sécuriser le repository de code source et la chaine d’intégration

 

Gestionnaire de Code Source

 

Avant de sécuriser le cluster qui exécutera les binaires, il est primordial de sécuriser le gestionnaire de code source (ou repository ou gestionnaire d’artéfacts…). En effet, quiconque ayant accès à ce repository en lecture pourra glaner des informations essentielles sur la topologie de votre infrastructure. Et si un attaquant venait à prendre la main sur ce gestionnaire de code source, il pourrait pousser n’importe quelle modification pour exfiltrer les données ou utiliser votre infrastructure dans des buts malveillants (minage de cryptomonnaie, attaques DNS, etc.).

Certaines recommandations sont évidentes mais il est bon de les rappeler : ne jamais stocker d’identifiants ou d’éléments confidentiels dans votre repository de code source.

L’attaque du code Source SolarWinds rappelle l’importance de sécuriser son code source. Cette attaque a compromis les données des clients de SolarWinds parmi lesquels de nombreux gouvernements et grandes entreprises.

 

Chaine d’intégration

 

La majorité des personnes ayant travaillé sur une instance Kubernetes pourra en témoigner : parfois, après une mise à jour ou à la suite d’une erreur humaine ou même d’une modification anodine, le service peut dérailler. Dans cette situation, essayer d’identifier et corriger une instance de production peut se compter en heures voire bien plus.

Souvent, la solution la plus simple, la plus rapide et la plus sécurisée est de créer une nouvelle instance, s’assurer qu’elle est fonctionnelle et effectuer une bascule avant de détruire l’instance défaillante.

Pour ce faire, il est primordial de constituer le plus tôt possible une chaine d’intégration CI/CD (CI : Continuous Integration / CD : Continuous Deployment,) et si possible IaC (Infrastructure as Code).

Si vous souhaitez approfondir ce sujet, nous vous invitons à consulter notre article sur la stratégie de CI/CD sur Kubernetes.

 

Dev + Ops : la sécurité est l’affaire de tous

 

L’erreur principale commise par les membres d’une équipe DevOps est de penser que le problème sera géré par le maillon suivant dans la chaîne. Pressé par le temps, un développeur se dira que son Tech Lead vérifiera sa livraison. Le Tech Lead estimera que c’est l’administrateur qui est responsable et l’administrateur pensera – à tort – que le développeur et le Tech Lead ont déjà vérifié.

La sécurité, c’est l’affaire de tous et non d’un seul.

Il est ainsi primordial que les développeurs et les opérateurs (Dev + Ops) impliqués sur la plateforme Kubernetes soient tous formés à la sécurité.

 

 

Point n°2 : Sécuriser les registries de conteneurs et les images

 

Les « containers registry » entreposent les différentes versions des images de conteneurs. Les clusters Kubernetes pourront lancer une commande « pull » sur ces registries pour télécharger une version d’une image.

Ces registries peuvent être privés, managés par votre entreprise ou un fournisseur Cloud. Mais ils peuvent également être publics, comme Docker Hub ou GitHub.

Deux problématiques viennent s’appliquer à ces containers :

• La fiabilité des images externes ;
• La sécurisation des images de conteneurs créées par vos équipes.

 

Outils de recherche de vulnérabilités

 

Le contenu de nos images est rarement exempt de failles. Celles-ci sont dues soit aux images que nous utilisons pour construire soit à la présence de vulnérabilités introduites dans notre côté applicatif. Ces outils exploitent les rapports de publication des CVE (Common Vulnerabilities and Exposures). Cette analyse doit être industrialisée pour permettre de réagir au plus vite. Nativement, Microsoft propose cette fonctionnalité au sein de sa solution de registry (Azure Container Registry). Cette dernière propose une intégration avec des solutions comme Twistlock ou Aqua pour réaliser ces recherches.

 

Images de containers externes

 

Comme avec n’importe quel logiciel, il existe un risque qu’une personne mal intentionnée ait pu compromettre le code source ou les binaires. De plus, il peut aussi arriver que des « containers registry » publics de confiance soient eux même compromis et diffusent des images malveillantes.

Enfin, outre les risques d’attaques, ces registries publics peuvent être indisponibles, cesser leur activité ou tout simplement ne plus proposer la version de conteneur nécessaire à vos services.

Pour prévenir ce risque, il est préférable de ne pas utiliser directement les sources externes mais de télécharger ces images dans un registry local à votre SI. On créera pour cela un pipeline CI/CD spécifique à la récupération des sources externes.

Ce pipeline pourra également valider des checksums (souvent disponibles sur les sites de l’éditeur), faire passer et lancer des tests de vulnérabilités (cf. les outils de scans de vulnérabilités) et des tests unitaires automatisés.

Non seulement ces pipelines pourront protéger des attaques mais ils permettront également de renforcer la qualité de service en évitant les downtimes liés à des breaking points sur des conteneurs externes.

Enfin, avoir les images de conteneurs externes sur une ressource que vous maitrisez est un point essentiel dans le cas d’un plan de continuité d’activité.

 

Images de containers Internes

 

A l’instar du gestionnaire de code source, les images issues de vos équipes de développement contiennent des informations essentielles de votre entreprise.

Il est bien évidemment conseillé de ne pas stocker de secrets directement dans les containers mais d’utiliser des secrets dans des vaults.

Contrairement à une idée reçue, les conteneurs ne sont pas des boites noires invulnérables. Quiconque peut exécuter le conteneur peut accéder à tous les fichiers de celui-ci. Quelle que soit la registry utilisée, il est vivement recommandé de s’assurer que vous seul puissiez manipuler les images contenues.

 

 

Point n°3 : Sécuriser/manager le cluster AKS

 

Mises à jour des versions

 

Version du service

Azure Kubernetes Service est un service qui bénéficie régulièrement de mises à jour par les équipes Azure. Ces mises à jour améliorent les fonctionnalités du service et corrigent des failles de sécurité.

Elles sont assurées sur les 3 dernières versions du service :

• Les deux dernières versions stables ;
• La version preview.

Les mises à jour corrigeant les failles de sécurité sont automatiquement déployées chaque nuit dès qu’elles sont disponibles. En revanche, les mises à jour de versions doivent être gérées par les administrateurs AKS via le portail ou des commandes Azure CLI.

 

De ce fait, toute ressource Azure Kubernetes Service doit avoir une de ces trois dernières versions afin de bénéficier de ces ajouts : en deçà de ces trois versions, la version est considérée comme dépassée. La mise à jour peut ne pas être possible. C’est pourquoi il est primordial de maintenir ses clusters Kubernetes à jour. Pour AKS, nous y sommes aidés car ce processus est pris en charge par la plateforme : https://docs.microsoft.com/en-us/azure/aks/upgrade-cluster.

 

Mises à jour des OS sur les nodes

Nos cluster Kubernetes reposent sur des nodes Linux. Même si AKS prend en charge le déploiement des mises à jour, un redémarrage est souvent nécessaire pour finaliser l’opération. Celui-ci peut être automatisé en utilisant l’outil Kubernetes Reboot Daemon, plus communément appelé Kured.

Le processus peut être planifié en tenant compte de plusieurs critères :

• Les reboot-days : jours où les reboots sont autorisés ;
• Le time-zone : fuseau horaire concerné ;
• Le start-time : heure de début de la plage horaire ;
• Le end-time : heure de fin de la plage horaire.

 

Source : https://docs.microsoft.com/en-us/azure/aks/node-updates-kured

 

Pour les clusters utilisant des Windows Server nodes, le processus de mise à jour consiste à remplacer les nodes existants par de nouveaux utilisant la nouvelle image.

 

Mises à jour des images sur les nodes

Les équipes AKS fournissent régulièrement de nouvelles versions des images. Il sera donc intéressant pour les équipes en charge des clusters d’effectuer régulièrement des mises à jour pour les images dans les nodes. Cela peut se faire via des commandes sur Azure CLI pour une mise à jour totale ou partielle sur l’ensemble de vos nodes.

Pour en savoir plus, nous vous invitons à consulter la documentation Microsoft sur la mise à jour des images sur les nodes.

 

Sécuriser l’accès au cluster AKS

 

Le contrôle d’accès au cluster AKS et à ses ressources peut être géré de deux manières :

• Limiter au strict nécessaire les accès aux utilisateurs, groupes ou comptes de service selon les besoins de ces derniers avec KubernetesRBAC (Role-Based Access Control) ;
• Gérer les structures de sécurité et d’autorisation avec Azure Active Directory.

 

Kubernetes RBAC

Cet outil de contrôle permet :

• La création de rôles pour définir des autorisations ;
• L’affectation des utilisateurs ou groupes à ces autorisations d’opérations précises (affichage des logs, création ou modification des ressources…) ;
• La limitation plus ou moins partielle de ces autorisations sur l’ensemble du cluster.

 

 

Azure Active Directory

Microsoft proposer d’intégrer Azure Active Directory comme référentiel d’authentification et d’autorisation au sein du cluster AKS. Cette intégration peut même être utilisée pour intégrer des fonctionnalités comme Multi-Factor Authentication (authentification forte) ou Conditional access.

 

 

Sécurité des pods

La sécurité s’insinue jusqu’au niveau pod. Il va de soi que le stockage d’informations sensibles (certificats, chaines de connexion à une base de données…) directement dans le pod est à proscrire. Ces éléments doivent être externalisés du code. On y fera référence au travers de la notion de secrets dans Kubernetes.

Parmi les autres bonnes pratiques à ce niveau, on peut citer :

• Limiter l’accès aux processus, services et à l’élévation de privilèges en utilisant les contextes de sécurités des pods ;
• Sauvegarder et récupérer les informations d’identification dans un coffre numérique notamment un Azure Key Vault ou une solution tierce comme Hashicorp Vault.

 

 

Automatisation et Back-up

Azure Kubernetes Service est un service orchestrant plusieurs ressources simultanément afin d’obtenir un environnement d’exécution de micro-services interdépendants. Ses multiples possibilités de configurations variées peuvent entraîner des conséquences sur la sécurité. En conséquence, il est recommandé d’avoir la main sur tous les paramètres, ce qui implique de déployer en Infrastructure as Code (IaC). L’industrialisation du déploiement va nous permettre d’améliorer la sécurité de notre infrastructure. Ce même processus de déploiement sera utilisé pour réaliser les montées de versions. Il est en effet plus sûr et plus simple de construire une nouvelle infrastructure que de procéder à sa mise à niveau.

 

Monitoring

Afin d’assurer la supervision de vos applications hébergées sur AKS, Azure dispose de l’outil Azure Monitor. Celui-ci permet de surveiller les performances de votre cluster, ainsi que les ressources consommées par les pods composant vos applications.

 

 

Point n°4 : Sécuriser les données entrantes

 

Les protections par défaut

 

Par défaut, aucune restriction réseau n’est appliquée, que ce soit pour notre cluster Kubernetes ou même les pods composant nos applications. Azure Kubernetes Services prend en charge deux architectures réseau principales :

• Kubenet : par défaut. Chaque nœud et chaque service ont une adresse IP dans le même VNet Azure. Les pods reçoivent une adresse IP dans un sous-réseau mais ne sont pas accessibles directement. Les requêtes doivent passer par le pod Kubenet du node.

L’avantage de Kubenet c’est que seuls les nodes et les services Kubenet sont exposés. La solution présente cependant quelques inconvénients :

• Maximum de 110 pods par node ;
• Maximum de 400 nodes par cluster ;
• Seuls des nodes Linux sont autorisés.

 

Source : documentation Microsoft

 

• Azure CNI

Chaque nœud et chaque pod reçoivent une adresse IP qui devra être unique dans le VNet Azure. Azure CNI permet d’utiliser des machines Windows et jusqu’à 250 pods par node. Mais trois inconvénients surviennent.

Dans Azure Kubernetes, la mise en œuvre des mécanismes de filtrage des flux réseaux est à notre charge. On peut travailler à plusieurs niveaux :

• Maîtriser l’évasion Internet des nodes composant notre cluster AKS en appliquant un filtrage réseau avec Azure Firewall ;
• Maîtriser les flux entrants avec un Ingress comme NGINX ou même utiliser la solution AGIC de Microsoft qui permet de déporter ce filtrage sur le service Azure Application Gateway ;
• Maîtriser les flux réseaux au niveau podavec des network policies ou des solutions tierces plus évoluées (Istio, Linkerd, Consul…).

Enfin, on pourra aussi travailler l’exposition des APIs de nos applications avec une solution comme Azure API Management qui peut être déployée comme service PaaS ou même comme pod au sein de notre cluster AKS. APIM va nous permettre de gérer l’exposition des APIs de nos applications, pour des usages internes mais aussi externes. Le service joue le rôle de centralisateur d’accès et permet d’authentifier et autoriser les usages.

 

 

Monitoring et logs

Comme tout service Azure, Azure Kubernetes Service produit des métriques et des logs avec différents niveaux de détails. Le monitoring de notre cluster AKS peut être réalisé avec la solution Azure Monitor, des solutions open-source ou même des solutions de type SaaS. Ces points ont été abordés dans les précédents articles de ce Mois du Conteneur. Dans le contexte de la sécurité, ce qui nous intéressera ici, c’est l’intégration avec vos outils de sécurité. La mise en œuvre d’Azure Defender for Kubernetes est vivement recommandée, tout comme l’ingestion des données dans votre solution SIEM (Azure Sentinel ou autre) pour surveiller l’activité de vos clusters.

 

 

Point n°5 : Sécuriser l’exécution des pods

 

Encore un mythe qui a la vie dure : la containerisation ne protège pas le contenu du conteneur (binaires, configuration et données). Vos applications doivent être conçues selon le principe du moindre privilège et suivre des bonnes pratiques de développement sécurisé.

Voici une liste de bonnes pratiques à prendre en compte lors du développement d’une application conteneurisée :

• Security Context : on peut définir l’option runAsUser et fsGroup pour assumer les autorisations appropriées. Cela va définir et contrôler les droits que l’application va revendiquer en s’exécutant, et ainsi éviter l’accès à des services et processus internes K8s ou l’accès aux nœuds sous-jacents ;
• Privilege Escalation : ne pas donner des privilèges administrateur (root) en les désactivant dans votre application. Toujours développer votre application en utilisant le principe des moindres privilèges afin de réduire au maximum la surface d’attaque ;
• Limiter l’exposition des informations d’identification avec un coffre-fort numérique ;
• Utiliser des comptes de service. Eviter l’usage de clés SAS, de comptes de base de données, etc. Tous les Cloud providers proposent des solutions de comptes de service permettant de déléguer la gestion des droits vers le service Cloud et un système de gestion d’identité. Un compte de service (dans Azure : Managed Identity) permet à un pod de s’authentifier lui-même auprès de services compatibles. Par exemple : un conteneur peut se connecter à un coffre en utilisant sa propre identité et un jeton qu’il va demander à un système de gestion d’identité. Cette approche permet d’éviter la gestion des secrets pour se connecter à d’autres services.

 

 

Point n°6 : Segmenter les applications

 

Par défaut, le réseau d’une plateforme Kubernetes est ouvert à tout le trafic. Tous les pods communiquent entre eux.

Pour maitriser et sécuriser une plateforme Kubernetes, il est impératif d’isoler les pods en n’autorisant que le strict minimum. On garantit ainsi que si un service est attaqué ou un pod compromis, le reste de la plateforme n’est pas mis en danger.

La segmentation des applications peut être réalisée à plusieurs niveaux. La mise en œuvre de namespaces est un premier niveau d’isolation basé sur les RBAC de Kubernetes. On pourra envisager un second niveau d’isolation réseau en mettant en place des network policies (Calico & Weave par exemple). Enfin, nous pouvons travailler finement au niveau pod en intégrant une solution de type Service Mesh (Open Service Mesh, Istio…) qui va permettre de gérer la découverte des pods entre eux ainsi que régenter la possibilité de communiquer entre eux.

 

 

L’essentiel à retenir sur la sécurité de Kubernetes

 

Comme nous venons de le voir, Kubernetes est un domaine très vaste. Comme indiqué au début de cet article, la sécurité de Kubernetes est entre vos mains. On doit adresser le sujet aussi bien au niveau de la plateforme (notre cluster Kubernetes) que des applications que nous hébergeons dessus. Certains de nos choix auront un impact sur nos applications. De ce fait, on ne peut dissocier la sécurité de la plateforme de la dimension applicative.

Il faudra procéder par itérations successives pour atteindre un niveau de sécurité acceptable pour opérer notre plateforme en production. Le passage en production ne marque pas une fin en soi, mais plutôt le début d’un nouveau cycle d’itérations visant à améliorer le niveau de sécurité de notre plateforme Kubernetes et des applications que nous y hébergeons.

Enfin, on retiendra que la sécurité est l’affaire de tous et qu’il faut sans cesse se tenir informé de l’actualité dans ce domaine en suivant les CVE (Common Vulnerabilities and Exposures) sur le sujet, ce que ne manquera pas de faire tout responsable de la sécurité informatique de votre organisation. D’ailleurs, il y a de grandes chances que celui-ci s’intéresse aussi à Kubernetes mais en utilisant une autre grille d’analyse : la matrice des menaces autour de Kubernetes. A vous de définir ensemble quels risques doivent être adressés, quels moyens à mettre en œuvre pour les réduire ou au mieux les atténuer.

 

Pour aller plus loin sur Kubernetes

 

Pour mettre en pratique tout ce que vous avez appris au cours du Mois du Conteneur, Cellenza vous propose de voir le replay du webinaire de clôture. Pendant une heure, Benoît Sautière (Senior Technical Officer chez Cellenza), Stanislas Quastana (Cloud Solution Architect chez Microsoft) et Louis-Guillaume Morand (Cloud Solution Architect chez Microsoft) vous présentent les différentes étapes à suivre pour adopter Kubernetes dans votre entreprise !

 

 

Retrouvez également tous les articles du Mois du Conteneur :

• Un mois pour tout savoir sur Kubernetes
• Kubernetes : quel intérêt pour répondre aux enjeux Business ?
• Kubernetes au service de votre stratégie applicative
• Kubernetes : un écosystème à construire
• Stratégie de CI/CD sur Kubernetes
• Mettre en place sa stratégie de migration vers Kubernetes
• Comment intégrer Kubernetes dans sa stratégie de monitoring ?

Tous ces articles sont compilés dans un livre blanc téléchargeable gratuitement.

 

 

Article co-rédigé par Sébastien Thomas, Ricardo Piteira et Hendrick Johann Tankeu.