Facteurs de menace Kubernetes managés

Effectué

Dans un environnement Kubernetes managés, l’adressage de la sécurité implique la compréhension et l’atténuation des menaces entre différentes instances. Voici une décomposition des facteurs de menace dans des instances spécifiques :

Compte compromis

• Facteur de menace : un attaquant accède à un cluster Kubernetes par le biais d’informations d’identification volées, de jetons d’API ou de clés. Cette action peut entraîner un accès non autorisé, un vol de données et des déploiements malveillants.
• Atténuation : Implémentez des mécanismes forts d’authentification, une authentification multifacteur (MFA), une rotation régulière des informations d’identification et des principes d’accès de privilège minimum.

Images vulnérables ou incorrectement configurées

• Facteur de menace : les images conteneur présentant des vulnérabilités ou des configurations incorrectes peuvent être exploitées par des attaquants une fois déployées. Ces vulnérabilités peuvent inclure des logiciels obsolètes, des paramètres par défaut non sécurisés ou des secrets incorporés.
• Atténuation : utilisez des outils d’analyse d’images pour détecter les vulnérabilités avant le déploiement, appliquer des stratégies de provenance d’image et adopter un processus de signature d’image conteneur.

Configuration incorrecte de l’environnement

• Facteur de menace : les configurations incorrectes dans les paramètres Kubernetes ou les descripteurs de déploiement peuvent exposer des clusters à des attaques. Les problèmes courants incluent les interfaces de tableau de bord exposées, les paramètres RBAC permissifs et les points de terminaison non sécurisés.
• Atténuation : suivez les meilleures pratiques pour sécuriser la configuration, auditez régulièrement les configurations avec des outils automatisés et utilisez des contrôleurs d’admission pour appliquer la conformité des stratégies.

Niveau d’attaque de l’application

• Facteur de menace : les applications exécutées dans des conteneurs peuvent être vulnérables aux vecteurs d’attaque web traditionnels, tels que l’injection SQL ou le scripting inter-site (XSS), qui peuvent compromettre le conteneur ou entraîner une exploitation de cluster supplémentaire.
• Atténuation : Employez les meilleures pratiques de sécurité des applications, telles que la validation d’entrée et l’encodage de sortie, et utilisez des pare-feux d'applications web ()WAF. Implémentez la sécurité dans le pipeline d’Intégration continue (CI)/Livraison continue et/ou de déploiement (CD) comprenant des outils d’analyse dynamique et statique.

Attaque au niveau du nœud

• Facteur de menace : si un attaquant accède à un nœud Kubernetes, il peut potentiellement augmenter les privilèges pour contrôler l’ensemble du cluster. Les vulnérabilités peuvent provenir de systèmes d’exploitation obsolètes ou de composants Kubernetes.
• Atténuation : conservez les nœuds mis à jour avec les derniers correctifs de sécurité, limitez l’accès aux nœuds à l’aide de stratégies réseau et de pare-feu, et utilisez des systèmes de détection d’intrusion basés sur l’hôte (HIDS).

Trafic non autorisé

• Facteur de menace : l’accès non autorisé au cluster ou à partir du cluster peut se produire si les stratégies réseau ne sont pas correctement configurées, ce qui permet aux attaquants d’exfiltrer des données, de diffuser des programmes malveillants ou d’exploiter des services exposés.
• Atténuation : implémentez des stratégies réseau strictes pour contrôler le trafic d’entrée et de sortie, séparez les charges de travail sensibles à l’aide d’espaces de noms et surveillez le trafic pour détecter les schémas anormaux.

La résolution de ces menaces dans un environnement Kubernetes managés nécessite une approche de sécurité en couches qui englobe à la fois les pratiques propres à Kubernetes et les mesures de sécurité traditionnelles. Un monitoring continu, des audits réguliers et une adhérence au principe de privilège minimum dans tous les aspects du cluster constituent les composants indispensables d’une stratégie robuste de sécurité Kubernetes.

Techniques d’attaque courantes

• Exploiter des images vulnérables : une application vulnérable publique dans un cluster qui permet l’accès initial au cluster. Cas notoires : SolarWinds, Log4j
  
• Accès aux applications exposées : une interface sensible exposée à Internet pose un risque de sécurité. Certains frameworks populaires n’ont pas été conçus pour être exposés à Internet, et ne requièrent donc pas d’authentification par défaut. Ainsi, les exposer à Internet permet un accès non authentifié à une interface sensible qui peut permettre l’exécution de code ou le déploiement de conteneurs dans le cluster par un acteur malveillant. Parmi les exemples de ces interfaces qui ont été exploitées, citons Apache NiFi, Kubeflow, Argo Workflows, Weave Scope et le tableau de bord Kubernetes.
  
• Déployer des conteneurs avec porte dérobée : les attaquants exécutent leur code malveillant dans un conteneur du cluster. L’utilisation de conteneurs Kubernetes tels que des DaemonSets ou des déploiements permet aux attaquants de veiller à ce qu’un nombre constant de conteneurs s’exécute dans un ou tous les nœuds du cluster.
  
• Abus sur un compte de service de rôles permissifs : un compte de service (SA) constitue une identité d’application dans Kubernetes. Par défaut, un SA est monté sur chaque pod créé dans le cluster. À l’aide du SA, les conteneurs du pod peuvent envoyer des requêtes au serveur d’API Kubernetes. Les attaquants qui accèdent à un pod accèdent au jeton SA et effectuent des actions dans le cluster, en fonction des autorisations SA. Si RBAC n’est pas activé, le SA dispose d’autorisations illimitées dans le cluster. Si RBAC est activé, ses autorisations sont déterminées par les objets RoleBindings et ClusterRoleBindings qui y sont associés.
  
• Échappement vers l’hôte : le volume hostPath monte un répertoire ou un fichier de l’hôte vers le conteneur. Les attaquants disposant d’autorisations pour créer un nouveau conteneur dans le cluster peuvent en créer un avec un volume hostPath accessible en écriture et obtenir une persistance sur l’hôte sous-jacent. Par exemple, cette dernière peut être réalisée en créant une tâche cron sur l’hôte.