Kubernetes a le vent en poupe ces dernière années. Sa popularité méritée est certainement liée à sa richesse fonctionnelle, son extensibilité, sa communauté Open Source et l’écosystème gravitant autour en perpétuelle expansion.

Aussi, Kubernetes est devenu quasiment le choix de facto dès qu’on parle d’orchestrateur de conteneurs et nombreuses sont les organisations en phase de modernisation qui adoptent Kubernetes sans forcément en mesurer les tenants et aboutissants.

Une des conséquences de cette adoption massive et rapide d’une solution en perpétuelle évolution (une nouvelle release de Kubernetes tous les trois mois) est le nombre de cas croissants d’incidents de sécurité sur des environnements Kubernetes mal maitrisés ou insuffisamment sécurisés. Quelques exemples :

• Lessons from the Cryptojacking Attack at Tesla
• Kubernetes Falls to Cryptomining via Machine-Learning Framework

Un cluster Kubernetes a de la valeur pour des organisations criminelles principalement sur trois aspects :

1. C’est de la ressource “gratuite'” en terme de calcul (CPU voire GPU) pour faire du cryptomining. On parle ici de Cryptojacking.
2. C’est de la ressource “gratuite” en terme de réseau pouvant être utilisée dans le cadre d’attaques DDoS, de campagne de SPAM, de réseau Tor..
3. C’est un système traitant voire stockant de la donnée que des attaquants peuvent voler ou chiffrer puis en monayer la restitution ou la non divulgation publique. On parle ici de Ransomware ou plus simplement de chantage 🙂

Avant de rentrer dans les détails des bonnes pratiques pour sécuriser un environnement Kubernetes dans Azure, il est bon de rappeler quelques basiques de la sécurité.

Gérer la sécurité d’un système d’information c’est gérer les risques et assumer des choix.

Un risque peut être :

• accepté : dans ce cas on ne fait rien car on juge l’impact potentiel faible
• rejeté: on met alors en place des contres mesures (mécanismes de protection)
• transféré : on fait de la réassurance en transférant la gestion du risque à un tiers (par exemple un fournisseur de cloud)

Ces risques peuvent porter atteinte à :

• La confidentialité des données ou des échanges
• L’intégrité des données, des applications ou des échanges
• La disponibilité des données ou des applications

Réduire les risques et leur impacts implique donc une réflexion si possible préalable qui doit impliquer l’ensemble des acteurs de la chaine (architectes, développeurs, DevOps, SRE, IT, RSSI, DevSecOps..) afin de :

• Choisir et implémenter les bonnes architectures et solutions techniques
• Définir et maintenir à jour les procédures
• Sensibiliser et former les personnes aux outils et procédures

Toute activité doit être journalisée, auditable et non-répudiable

Utiliser au maximum le principe du moindre privilège (les pleins pouvoirs ne sont pas nécessaires à temps plein) et bien séparer les rôles & responsabilités (spécialement quand plusieurs équipes travaillent sur un projet)

Réduire la surface d’exposition et appliquer une approche de type défense en profondeur

Pour terminer, ne pas oublier que la “complexité est l’ennemie de la sécurité“. Il vaut mieux bien implémenter quelques mécanismes de défenses maitrisés qu’une ribambelle d’outils mal compris et mal utilisés. Bref “Keep It Simple“.

Maintenant que les bonnes bases sont posées, rentrons dans le vif du sujet : comment peut se dérouler une attaque sur un cluster Kubernetes dans Azure et comment limiter ce risque et les impacts associés ?

Le déroulement d’une attaque sur un cluster Kubernetes est différente de l’attaque sur un serveur Windows ou Linux par l’outillage; néanmoins la méthodologie et le déroulé sont assez similaires. Les équipes d’Azure Security Center se sont appuyées sur le framework MITRE ATT&CK® et sa matrice pour définir une matrice similaire (et plus simple) spécifique à Kubernetes. Cette matrice d’attaques contient 9 tactiques contenant chacune différentes techniques utilisables dans une prise de contrôle et devant (à mon avis) être considérées lors de la sécurisation d’un environnement Kubermetes.

Prenons maintenant un environnement “classique” Kubernetes dans Azure. Il est composé de plusieurs ressources Azure

• Azure Kubernetes Services : cluster Kubernetes semi géré (les masters nodes sont disponibles sous la forme d’un service PaaS faisant office de control plane, les worker nodes sont des machines virtuelles ou des VMScaleSet) facile à déployer et simplifiant ensuite de nombreuses opérations (scaling, mises à jour…)
• Azure Container Registry : Docker registry et depot de Chart Helm en mode PaaS.
• Azure Container Instances : plateforme d’exécution de conteneurs en mode PaaS. Interconnectable à Azure Kubernetes Services via un Virtual Kubelet
• Azure Active Directory (appelé aussi Tenant) : service d’Identité as a Service utilisé par toutes les solutions Cloud de Microsoft (Azure, Office 365, Dynamics365, PowerPlatform..) mais aussi plus de 2400 applications tierces parties.
• Azure Virtual Network: réseau virtuel composé d’un ou plusieurs sous-réseaux dans lesquels sont connectés les machines virtuelles, les conteneurs, les équipements réseaux et exposés des services PaaS (via des Services Endpoint ou des Private Link)
• Azure Load Balancer: associé à une adresse IP publique, il permet d’exposer sur Internet un service Kubernetes ou un Ingress Controller.
• Des services externes pour le stockage ou les bases de données tels que Azure Storage (blobs, file), Azure Database for MySQL, Azure Database for PostgreSQL, Azure CosmosDB, Azure Redis Cache…
• Un service de coffre fort pour les secrets, clés cryptographiques et autres certificats : Azure Key Vault ou Hashicorp Vault
• Azure Monitor : service cloud de monitoring et de traitements des logs dans Azure. Est utilisé pour le monitoring du cluster Kubernetes et de ses workloads.
• Une solution de CI/CD comme Azure DevOps ou GitHub Actions

Toutes ces ressources Azure intégrent des options et des mécanismes de sécurité permettant de limiter les risques et attaques. Il va donc falloir :

• Faire correspondre ces contre-mesures à la liste des risques rejetés ou transférés définis précédemment
• Définir les procédures associées en terme d’installation, configuration, surveillance, réponse à incident
• Impliquer et former les équipes concernées

Dans mes prochains articles, je vais entrer dans le détail de la sécurisation de différents éléments d’une plateforme Azure Kubernetes Services et plus particulièrement:

1. La sécurité de l’API Server
2. La sécurité des trafics Nord Sud
3. La sécurité des images de conteneurs
4. La sécurité des secrets
5. La sécurité des pods et applications

A cela j’ajouterai:

6. La gestion des mises à jour du cluster (OS et Kubernetes)

7. Les sauvegardes

–Stanislas–