• Code issu de registres non fiables. Un code non fiable peut inclure des logiciels malveillants ou des portes dérobées qui pourraient involontairement accorder l’accès à des acteurs malveillants.
• Images de base démesurées. Pour les applications conteneurisées, les développeurs doivent éliminer les packages, les bibliothèques et les shells inutiles qui pourraient être compromis.
  

• Accorder des privilèges inutiles. Dans la mesure du possible, réduisez les privilèges au minimum et montrez uniquement les secrets dont une tâche a besoin pour réduire la surface d’attaque.
• Impossible d’isoler les applications dans le cluster. Les espaces de nommage doivent être utilisés pour séparer les ressources et les équipes les unes des autres.
• Mouvement latéral au sein du cluster. Utilisez des règles qui segmentent le réseau pour empêcher le déplacement latéral d’une attaque au sein du cluster.
• Accès non autorisé. Assurez-vous que les contrôles d’accès basés sur les rôles (RBAC) sont correctement configurés pour limiter l’accès.
  

• Attaques d’infrastructures. Pendant l’exécution, les éléments de l’infrastructure Kubernetes, notamment le serveur d’API, etcd et les contrôleurs, présentent tous leurs propres surfaces d’attaque.
• Complexité. L’intégrité continue d’un cluster Kubernetes comporte de nombreuses parties mobiles. Les conteneurs compromis doivent être rapidement isolés, arrêtés et remplacés par des conteneurs sains pendant que la source de l’attaque est localisée et corrigée.
  

Les meilleures pratiques recommandées sont les suivantes : commencez par un minimum d’images sans distribution et n’ajoutez que ce qui est absolument nécessaire. Moins il y a d’éléments, meilleure est la sécurité.

• Utilisez un système d’exploitation hôte minimal, mettez fin aux montages en lecture seule et utilisez les options SELinux pour encore plus de contrôle
• Analysez les images pour rechercher des vulnérabilités de haut en bas, y compris les images du système d’exploitation et les images extérieures de toute nature. Il n’existe pas de source fiable extérieure.
• Utilisez les espaces de nommage et le contrôle d’accès basé sur les rôles pour segmenter le cluster et les utilisateurs de manière logique. Si un élément n’est pas nécessaire, il ne doit pas être visible.
• Le réseau Kubernetes par défaut permet des communications universelles. Ainsi, la segmentation du réseau doit être mise en place avant la production. Définissez avec soin des règles d’ingress/egress pour garantir le routage correct des connexions.
• Limitez les privilèges au minimum et n’exécutez jamais les processus d’application en tant que racines. L’utilisation d’un système de fichiers racines en lecture seule empêche toute attaque qui dépend de l’installation de logiciels ou de la modification du système de fichiers.
• Intégrez des fonctions de sécurité comme l’analyse d’images dans le pipeline CI/CD. Mieux encore, exécutez des tests de sécurité CIS.
• Sécurisez le cluster. Configurez le contrôle d’accès basé sur les rôles pour limiter l’accès au serveur d’API et vous assurer que toutes les communications etcd sont sécurisées avec le chiffrement TLS. De même, verrouillez les autorisations kubelets en configurant le contrôle d’accès basé sur les rôles pour les kubelets.
• Utilisez les contrôles intégrés dans Kubernetes, comme la configuration du contexte de sécurité pour limiter l’accès aux pods.
• La sécurité proactive doit inclure la surveillance de l’activité des processus, des communications entre les services et des communications externes au cluster.