Kubernetes est extrêmement populaire, mais sans mesures de sécurité appropriées, il comporte également des risques. L'expert en sécurité CyberArk cite trois risques spécifiques et montre quelles mesures défensives sont nécessaires pour maîtriser les risques liés au matériel, au serveur d'API et aux conteneurs dans Kubernetes.
Dans le développement de logiciels aujourd'hui, la vitesse et l'agilité sont essentielles. La technologie des conteneurs est de plus en plus utilisée. Kubernetes est devenu la norme de facto pour la gestion des charges de travail et des services conteneurisés.
Aspects de sécurité de Kubernetes
Du point de vue de la sécurité, la plate-forme d'orchestration Kubernetes s'accompagne de défis spécifiques liés à l'identité qui doivent être résolus dès le début du processus de développement. Sinon, les environnements conteneurisés peuvent présenter un risque pour la sécurité informatique. Il existe trois principaux domaines potentiellement vulnérables au sein de Kubernetes sur lesquels les organisations doivent se concentrer dans le cadre d'une véritable approche DevSecOps.
Risque Kubernetes : matériel
Que vous exécutiez Kubernetes sur site ou dans un cloud géré par un tiers, une plate-forme matérielle est toujours requise. Une fois qu'un attaquant a accès à la machine virtuelle exécutant Kubernetes et obtient les privilèges root, il peut également attaquer les clusters Kubernetes.
Pour éviter cela, il existe les meilleures pratiques de sécurité suivantes :
- L'application du principe du moindre privilège est cruciale pour protéger le matériel qui sous-tend à la fois Kubernetes et les conteneurs eux-mêmes. Les machines virtuelles doivent être déployées avec le niveau de privilèges le plus bas (c'est-à-dire uniquement ceux qui sont strictement nécessaires pour des raisons fonctionnelles) afin de rendre plus difficile pour les attaquants l'accès root.
- Les informations d'identification doivent être alternées régulièrement, et l'utilisation d'une solution de coffre-fort automatisé est logique pour augmenter encore la protection sans augmenter les frais généraux.
Risque Kubernetes : serveur d'API Kubernetes
Outre les machines physiques, le plan de contrôle Kubernetes doit également être sécurisé. Il donne accès à tous les conteneurs exécutés dans un cluster, y compris le serveur d'API Kubernetes, qui agit comme un frontal et facilite l'interaction des utilisateurs au sein du cluster.
Une attaque sur le serveur API peut avoir un impact important. Même un seul secret ou identifiant volé peut être utilisé pour augmenter les droits d'accès et les privilèges d'un attaquant. Une vulnérabilité initialement mineure peut rapidement se transformer en un problème à l'échelle du réseau.
Les meilleures pratiques de sécurité incluent :
- Pour atténuer les risques, les entreprises doivent d'abord sécuriser les terminaux contre le vol d'informations d'identification et les menaces de logiciels malveillants. Les ordinateurs locaux utilisés par les utilisateurs disposant de droits d'administration dans Kubernetes sont particulièrement pertinents.
- L'authentification multifacteur (MFA) pour l'accès aux serveurs d'API Kubernetes est essentielle. Par exemple, un identifiant volé ne peut pas être utilisé pour l'accès à Kubernetes.
- Une fois les utilisateurs authentifiés dans Kubernetes, ils peuvent accéder à toutes les ressources du cluster. La gestion des autorisations revêt donc une importance cruciale. Avec le contrôle d'accès basé sur les rôles, une entreprise peut s'assurer que les utilisateurs n'ont que les droits d'accès dont ils ont vraiment besoin.
- Le moindre privilège doit également être appliqué sur les comptes de service Kubernetes, qui sont automatiquement créés lors de la configuration d'un cluster, pour aider à authentifier les pods. La rotation régulière des secrets est tout aussi importante pour éliminer les possibilités d'accès pour ceux qui n'en ont plus besoin.
Risque Kubernetes : conteneurs
Les pods et les conteneurs sont les éléments constitutifs d'un cluster Kubernetes et contiennent les informations nécessaires à l'exécution de l'application. Il existe plusieurs vulnérabilités potentielles dans cet écosystème de conteneurs et ce flux de travail. Ceux-ci incluent, par exemple, un accès non sécurisé à l'API du conteneur ou à l'hôte du conteneur et aux registres d'images non protégés.
Les bonnes pratiques suivantes sont recommandées pour la sécurité des conteneurs :
- Les secrets ne doivent pas être intégrés dans du code ou dans une image de conteneur. Sinon, toute personne ayant accès au code source a également accès aux informations dans les référentiels de code, par exemple.
- Les risques de sécurité sont considérablement réduits grâce au contrôle d'accès basé sur les rôles, à la restriction de l'accès secret aux processus au sein d'un conteneur spécifique et à la suppression des secrets qui ne sont plus nécessaires.
- L'utilisation secrète, y compris la rotation ou la désactivation, doit être consignée. Une solution de gestion centrale des secrets qui permet l'administration et la protection automatiques des données d'accès confidentielles est également avantageuse.
"En adoptant ces meilleures pratiques, une entreprise peut améliorer considérablement la sécurité dans l'ensemble de l'environnement Kubernetes", a déclaré Michael Kleist, vice-président régional DACH chez CyberArk. « De plus, il est également possible de soutenir les développeurs avec des fonctions de libre-service dans leur travail quotidien, par exemple en ce qui concerne la numérisation de code. Cela leur permet d'apporter une contribution supplémentaire à l'augmentation rapide et pratique de la sécurité de Kubernetes. »
Plus sur CyberArk.com
À propos de CyberArk
CyberArk est le leader mondial de la sécurité des identités. Avec Privileged Access Management comme composant central, CyberArk fournit une sécurité complète pour toute identité - humaine ou non humaine - dans les applications métier, les environnements de travail distribués, les charges de travail cloud hybrides et les cycles de vie DevOps.