Kubernetes est la plateforme open-source la plus utilisée pour l’orchestration de conteneurs. Elle automatise toute une série d’opérations liées à la gestion des conteneurs. Le déploiement, l’évolutivité, les tests, la gestion, etc. sont simplifiés. Ce blog passera en revue quelques bévues typiques de Kubernetes que la plupart des entreprises commettent. La liste comprend tous les problèmes majeurs rencontrés par plusieurs entreprises qui ont adopté Kubernetes. Nous parlerons des problèmes tout en mettant l’accent sur la façon de les prévenir ou de les résoudre. Nous recommandons de tenir à jour une liste de contrôle de toutes les bonnes pratiques. Il faut s’y référer sans cesse pour utiliser Kubernetes à son plein potentiel. Les tests dans un environnement Kubernetes exigent une compréhension complète de l’architecture et des composants de la plateforme. Sans la mise en place de pratiques de test approfondies, les organisations rencontrent généralement des bogues ou des défaillances inattendues dans leurs applications. Une gestion efficace des clusters Kubernetes est également cruciale pour le bon déroulement des opérations.

* Scale: 0 = Lowest | 4 = Highest

Secrets dévoilés

Les données sensibles sont compromises lorsque les secrets des configurations Kubernetes sont exposés. Cela laisse des brèches pour un accès non autorisé. La brèche AWS de Tesla a exposé des données critiques parce que leur cluster Kubernetes n’avait pas de restrictions d’accès appropriées. D’ici 2023, 90 % des entreprises subiront une violation de sécurité en raison de secrets mal conservés, selon une analyse de Gartner. Les services sont perturbés par des accès non autorisés. Les violations potentielles de données ou les modifications non autorisées affectent également la disponibilité. L’introduction de failles de sécurité empêche de poursuivre les efforts d’extension. Celles-ci doivent être éliminées avant l’expansion des systèmes. Imaginons qu’un pirate informatique obtienne un accès non autorisé à un déploiement Kubernetes. Il pourrait modifier les paramètres de l’application et provoquer une défaillance critique du système. Cela nécessite une certaine maintenabilité, mais ne réduit pas l’efficacité des ressources. Les audits réguliers et la sécurisation des secrets augmentent les frais généraux de maintenance. Il viole les normes de conformité telles que GDPR ou HIPAA. Attendez-vous à des conséquences juridiques et financières. Cela comprend également les sanctions juridiques et les atteintes à la réputation.

• Une approche plus sophistiquée consisterait à utiliser des outils de gestion des secrets externes tels que HashiCorp Vault ou CyberArk Conjur.
• Utilisez Kubernetes Secrets pour stocker en toute sécurité des informations sensibles telles que les mots de passe et les clés API.
• Mettre en œuvre le chiffrement et les contrôles d’accès pour les secrets afin d’empêcher tout accès non autorisé.
• Effectuer une rotation régulière des secrets afin de minimiser l’impact des violations potentielles. L’audit est également nécessaire.

AccuKnox prévient les attaques de ransomware sur HashiCorp Vault et CyberArk Conjur en identifiant les postures de sécurité par défaut, en appliquant une approche de liste blanche aux contrôles les moins permissifs, et en atténuant les anomalies en ligne.

Contrôle d’accès inadéquat basé sur les rôles

Des paramètres RBAC faibles entraînent un accès non autorisé. Les utilisateurs illégaux peuvent perturber les services et causer des problèmes de disponibilité. Par exemple, un utilisateur disposant d’autorisations excessives peut accidentellement supprimer des ressources critiques. Bien que l’évolutivité ne soit pas affectée, elle entraîne des inefficacités en autorisant des accès inutiles et en taxant les ressources. Sans cela, le contrôle d’accès devient difficile. Le nombre d’erreurs et de problèmes liés à l’administration des utilisateurs augmente. En 2020, un problème de sécurité a touché le dépôt GitHub de Kubernetes à la suite d’une fuite de privilèges interne. Dans une enquête de CyberArk, 73 % des entreprises estiment que leurs restrictions d’accès privilégié doivent être renforcées. En outre, cela viole les normes de conformité qui exigent un accès contrôlé aux informations sensibles. Un système RBAC inefficace entraîne des failles de sécurité qui se traduisent par des pertes financières et des atteintes à la réputation. Le principe du moindre privilège doit être établi et respecté lors de l’attribution des rôles et des autorisations. Les configurations RBAC doivent toujours être vérifiées pour les mises à jour.

• Mettre en œuvre le contrôle d’accès basé sur les rôles (RBAC) pour restreindre les autorisations d’accès en fonction des rôles des utilisateurs.
• Réviser et mettre à jour régulièrement les politiques RBAC pour garantir l’accès le moins privilégié possible.
• Utiliser les journaux d’audit de Kubernetes pour surveiller et détecter toute tentative d’accès non autorisé.
• La fourniture d’accès juste à temps et la révocation après une certaine durée deviennent critiques.

Unpatched Vulnerabilities

Ils exposent les clusters Kubernetes à des attaques connues, mettant en péril la sécurité. Elles nuisent également à la confiance en raison des interruptions de service ou compromettent la disponibilité des applications. Attaques gourmandes en ressources qui consomment les ressources du système. Le fait de ne pas appliquer régulièrement les correctifs augmente les efforts de maintenance, car vous devez faire face à des brèches potentielles.  Les attaquants exploitent une vulnérabilité connue de Kubernetes pour déployer des pods non autorisés. L’exploitation de vulnérabilités non corrigées peut enfreindre les normes de conformité exigeant des mesures de sécurité actualisées. La vulnérabilité CVE-2020-8555 de Kubernetes permet aux attaquants de contourner les restrictions d’accès à l’API. Le rapport de l’Institut Ponemon sur le coût d’une violation de données a révélé que les vulnérabilités non corrigées prolongeaient de 26 % le cycle de vie moyen d’une violation de données. Elles entraînent des dommages fiscaux considérables, sans parler des menaces pour la réputation et de la collusion.

• La façon la plus simple de résoudre ce problème est d’installer un processus régulier de gestion des correctifs et d’automatiser le déploiement des correctifs.
• Les clusters Kubernetes doivent souvent être mis à jour et faire l’objet de correctifs afin de se protéger contre les vulnérabilités connues.
• Utiliser un outil de gestion des vulnérabilités pour analyser et évaluer la sécurité de l’image du conteneur.
• En fonction des capacités et de la couverture de l’outil, les vulnérabilités connues peuvent être mises en évidence ou classées par ordre de priorité. Cependant, la menace de vulnérabilités inconnues ou d’attaques de type “zero-day” rendra toujours le cluster vulnérable

AccuKnox suppose que les vulnérabilités connues et inconnues (attaques du jour zéro) sont présentes dans le cluster. Il s’assurera de détecter les vulnérabilités actuelles à l’aide de plusieurs outils et d’atteindre une posture Zero-Trust la moins permissive possible pour la résilience globale du cluster et au-delà des menaces provenant des vecteurs d’attaque actuels. AccuKnox est construit sur des contrôles de sécurité de confiance zéro pour empêcher les accès non autorisés, les opérations de porte dérobée, l’utilisation de l’interface réseau, les manipulations du système de fichiers, l’exécution des processus et les fonctions administratives. Nous produisons également des audits et des alertes au niveau des applications.

Aucune limite de ressources

Comme les ressources non limitées conduisent à des attaques par épuisement des ressources, elles sont directement liées à la sécurité. La disponibilité des autres services s’en trouve dégradée. En l’absence d’une limitation adéquate du débit, la contention des ressources entrave l’évolutivité des applications. Tout cela conduit à une utilisation inefficace des ressources, car certains pods consomment plus que nécessaire.  Imaginons un scénario dans lequel un pod qui se comporte mal consomme des ressources excessives, provoquant une interruption de service. La gestion des applications devient complexe et difficile à dépanner. Elle a un impact sur la conformité en permettant l’utilisation abusive des ressources. Les coûts d’infrastructure inutiles augmentent également. Nous recommandons de fixer des limites de ressources pour le CPU et la mémoire sur les pods, de surveiller l’utilisation des ressources et d’ajuster les limites en conséquence. Un pod à forte consommation de ressources affecte les performances des autres applications du cluster. L’enquête CNCF 2020 a révélé que la gestion des ressources était un défi majeur pour les utilisateurs de Kubernetes.

• Définissez des limites de ressources pour les pods Kubernetes afin d’éviter les conflits de ressources et de garantir une distribution équitable.
• Les charges de travail gourmandes en ressources peuvent être identifiées et optimisées en gardant un œil sur l’utilisation des ressources à l’aide des métriques et des alertes de Kubernetes. AccuKnox fournit des rapports de conformité continus pour les ressources et les applications cloud, y compris les normes NIST, MITRE, CIS et DISA, avec des alertes en cas de violation et un résumé de la conformité basé sur l’espace de noms.
• Pour modifier dynamiquement les ressources en fonction des besoins de la charge de travail, utilisez des techniques de mise à l’échelle automatique.

Ressources non surveillées

En l’absence de surveillance, les clusters sont susceptibles de subir des failles de sécurité ou des anomalies non détectées. Sans surveillance, les interruptions de service ou les problèmes de performance peuvent passer inaperçus, ce qui affecte la disponibilité. Les problèmes de mise à l’échelle surviendront tôt ou tard si vous n’êtes pas au courant des demandes de ressources. Cela empêche également d’optimiser l’utilisation des ressources. Le dépannage sans données de surveillance devient difficile, ce qui accroît les efforts de maintenance. Dans les secteurs réglementés, une surveillance inadéquate peut entraîner une non-conformité avec les exigences d’audit. Le coût des pannes ou du gaspillage des ressources augmente également. Par exemple, un pic soudain dans l’utilisation de l’unité centrale passe inaperçu. Le temps de réponse d’une application s’en trouvera allongé. Envisagez la mise en œuvre d’une surveillance et d’une alerte tout-en-un à l’aide d’outils tels que Prometheus et Grafana. AccuKnox s’intègre très bien à Grafana. Une fuite de mémoire progressive dans un conteneur passe inaperçue jusqu’à ce qu’elle affecte les performances de l’application. Le rapport State of DevOps a révélé que les organisations ayant des pratiques de surveillance matures avaient des taux d’échec des changements trois fois inférieurs.

• Pour collecter et afficher les métriques des clusters, et mettre en place des outils de surveillance et d’observabilité tels que Prometheus et Grafana.
• Utiliser les alertes et les notifications pour identifier les problèmes de performance ou les pannes et prendre les mesures appropriées de manière proactive.
• Pour consolider et analyser les journaux à des fins de dépannage et de débogage, créez des cadres de journalisation Kubernetes

AccuKnox permet de présenter le comportement des applications à travers des graphiques de réseau avec une vue interactive des connexions d’entrée et de sortie. AccuKnox aide également à la surveillance continue de la charge de travail et fournit des intégrations avec des outils SIEM tels que Splunk, Azure Sentinel, etc.

Privilèges du conteneur

Un conteneur privilégié compromis permet aux attaquants d’accéder au système hôte. L’enquête 2020 sur la sécurité des conteneurs a révélé que 44 % des personnes interrogées estimaient que les conteneurs à privilèges augmentaient les risques de sécurité. Ces conteneurs disposent d’autorisations élevées. La surface d’attaque augmente, tout comme les risques de sécurité. Les conteneurs privilégiés mal utilisés compromettent la stabilité du système et entraînent des interruptions de service. Ils consomment également plus de ressources, ce qui affecte l’efficacité des autres applications. La gestion des conteneurs à privilèges ajoute de la complexité et des risques aux opérations de maintenance. Elle enfreint les exigences de conformité relatives au moindre privilège. Les failles de sécurité ou l’inefficacité des ressources dans les conteneurs privilégiés entraînent des dommages fiscaux. Évitez de les utiliser, sauf en cas d’absolue nécessité. Optez plutôt pour des contextes et des capacités de sécurité à grain fin.

• Sauf en cas d’absolue nécessité, évitez d’exécuter des conteneurs avec un accès privilégié.
• Appliquez des politiques de sécurité de pods Kubernetes (PSP) aux conteneurs privilégiés pour imposer des limitations.
• Réviser et mettre à jour régulièrement les PSP pour garantir la conformité avec les meilleures pratiques de sécurité.

Sauter les sauvegardes de configuration

En l’absence de sauvegardes appropriées, les erreurs de configuration ou les défaillances accidentelles entraînent des pertes de données et des temps d’arrêt. Cela augmente également la complexité de la restauration des services dans un état stable après un incident. L’omission des sauvegardes de configuration ne laisse aucune possibilité de récupération en cas d’incident de sécurité ou de perte de données. Imaginez qu’un administrateur applique par erreur une modification de configuration qui entraîne une interruption de service, sans qu’aucune sauvegarde ne soit disponible. Dans les secteurs réglementés, il s’agit d’un indicateur important de non-conformité. La perte de données due à l’absence de sauvegardes peut entraîner de graves problèmes pour l’infrastructure en nuage, les entreprises et les utilisateurs. Les administrateurs doivent régulièrement sauvegarder les fichiers de configuration, les manifestes et autres données critiques. Pour ce faire, ils peuvent utiliser des systèmes de contrôle des versions ou des outils de sauvegarde. Une mise à jour mal configurée entraîne une corruption des données et, en l’absence de sauvegardes, il est impossible de rétablir l’état stable précédent.

• Prévoyez des programmes de sauvegarde automatisés pour les manifestes et les fichiers de configuration utilisés par Kubernetes.
• Pour garantir la disponibilité et l’intégrité des données, vérifiez souvent la procédure de sauvegarde et de restauration.
• Les sauvegardes doivent être conservées dans un endroit sûr et distant afin d’éviter tout accès illégal.

Utilisation d’API obsolètes

Généralement, ils présentent des failles bien connues que les attaquants pourraient utiliser pour compromettre la sécurité. Selon le 2021 Global State of Multi-Cloud Report, 53 % des entreprises ont subi des pertes de données dans le nuage. La croissance est entravée par le manque de fonctionnalités nécessaires à une mise à l’échelle efficace. Les méthodes sous-optimales conduisent à une allocation inefficace des ressources. La maintenance est plus difficile, car les entreprises risquent de ne pas recevoir de mises à jour ou d’assistance. Des mesures de sécurité modernes sont nécessaires pour se conformer aux exigences de l’industrie ; cela échouera catégoriquement. Les vulnérabilités des API obsolètes peuvent entraîner de graves pertes financières à la suite de failles de sécurité. Suivez les mises à jour de la version de Kubernetes et passez des API obsolètes aux remplacements pris en charge. Si les API obsolètes sont supprimées ou deviennent incompatibles, leur utilisation peut entraîner des interruptions de service. La version 1.16 de Kubernetes a rendu obsolète l’API extensions/v1beta1, encourageant les utilisateurs à migrer vers l’API apps/v1. Une enquête menée par la CNCF en 2021 a révélé que 25 % des personnes interrogées utilisaient encore des API Kubernetes obsolètes. Une mise à jour de Kubernetes supprime une API obsolète, ce qui entraîne l’échec des applications qui en dépendent.

• Tenez-vous au courant des modifications apportées aux API en consultant régulièrement les notes de mise à jour et les politiques de dépréciation de Kubernetes.
• Les applications doivent être modifiées pour passer des API obsolètes à celles qui sont recommandées.
• Pour s’assurer que Kubernetes est compatible avec les API les plus récentes, il convient d’utiliser des techniques de versionnement et de mise à niveau.

Politiques de réseau ignorées

Une base de données est consultée par des modules non autorisés en raison de l’absence de politiques de réseau. Le fait d’ignorer les règles du réseau entraîne une communication incontrôlée entre les modules, ce qui augmente le risque d’intrusion par des parties non autorisées ou de fuite de données. Cela a une incidence sur la disponibilité de l’application en provoquant des encombrements ou des interférences. Un autre problème majeur sera le conflit de ressources, qui se traduira par une utilisation inefficace des ressources. Dans le cas du piratage de Capital One, l’insuffisance des restrictions du réseau a permis aux attaquants de se déplacer latéralement dans le système. Selon le rapport 2020 State of DevOps, les entreprises les plus performantes étaient 1,5 fois plus susceptibles d’adopter une application automatisée des politiques de sécurité. Pour réguler et sécuriser la communication entre les pods, il est conseillé d’établir et d’exécuter des politiques de réseau.

Ignorer les politiques réseau complique le dépannage et la maintenance en introduisant des flux de trafic inattendus. Ne pas mettre en œuvre les politiques de réseau laisse présager une non-conformité avec les réglementations sur la protection des données.

• Pour gérer le trafic entre les modules, il convient d’utiliser des règles de réseau.
• Sur la base des étiquettes de pods et des espaces de noms, fournissez des règles d’entrée et de sortie spécifiques pour limiter la communication.
• Révisez et mettez à jour régulièrement les règles de réseau pour vous assurer qu’elles répondent aux exigences des applications et aux spécifications de sécurité.

Mise à l’échelle manuelle

La principale cause d’interruption de service en cas d’augmentation brutale de la demande est une mise à l’échelle humaine inadéquate. En cas de pics de trafic, la mise à l’échelle manuelle peut entraîner un sous-provisionnement, ce qui compromet la sécurité en ne répondant pas à la demande. Les pods mis à l’échelle manuellement deviennent surchargés par une augmentation soudaine du trafic, ce qui perturbe le service. Selon l’enquête CNCF 2021, 65 % des participants utilisent l’autoscaling horizontal des pods. La capacité à s’adapter rapidement à des charges de travail changeantes est limitée lorsque la mise à l’échelle manuelle est la seule méthode utilisée. D’autres erreurs typiques sont le surprovisionnement et le gaspillage de ressources pendant les périodes de moindre demande. Il faut une observation et une gestion permanentes, ce qui accroît les besoins de maintenance. Les temps de réponse s’allongent considérablement en raison des retards de mise à l’échelle manuelle dus à l’augmentation du trafic provoquée par le lancement de nouvelles versions. Comme les problèmes de mise à l’échelle peuvent entraîner des temps d’arrêt qui réduisent l’accord sur le niveau de service (SLA), ils empêchent indirectement la mise en conformité. La mise à l’échelle manuelle entraîne un surprovisionnement, ce qui augmente les dépenses d’infrastructure. Pour modifier automatiquement le nombre de répliques en fonction de l’utilisation des ressources, mettez en œuvre l’autoscaling des pods horizontaux.

• Analysez régulièrement les tendances de la charge de travail pour affiner les seuils de mise à l’échelle et garantir une allocation optimale des ressources.
• Pour modifier dynamiquement le nombre de réplicas en fonction du CPU ou de mesures personnalisées, utilisez l’autoscaling de pods horizontaux (HPA).
• Dimensionner en fonction des métriques propres à une application avec les API de métriques personnalisées de Kubernetes.

Pas de planification du basculement

L’absence d’un tel système peut entraîner des problèmes de sécurité, des temps d’arrêt prolongés et des pertes financières. Les processus de récupération et de maintenance des services sont également compromis. Le non-respect des critères de disponibilité et les pertes financières constituent également un problème. En raison de l’absence de basculement, une défaillance importante du pod entraîne l’indisponibilité du service. Les répliques Kubernetes ou les ensembles avec état avec des configurations de basculement appropriées s’avéreront pratiques. En raison d’erreurs de base de données, les sites web de commerce électronique sont fréquemment confrontés à des heures d’indisponibilité. Le rapport 2021 sur l’état de la résilience informatique indique que 51 % des entreprises ont été confrontées à des événements de données irrécupérables.

• Configurez de nombreuses répliques de composants cruciaux comme etcd, le plan de contrôle et les nœuds de travail pour mettre en œuvre les paramètres de haute disponibilité (HA) de Kubernetes.
• Pour permettre un basculement et une résilience automatisés, utilisez les déploiements Kubernetes avec StatefulSets.
• Testez et reproduisez souvent les situations de défaillance pour vérifier les procédures de basculement et garantir la fiabilité du système.

Unencrypted Data Transit

Les informations sensibles sont susceptibles d’être écoutées pendant la transmission des données. L’évolutivité, l’efficacité des ressources, la maintenance, la conformité et les prix sont des points d’impact. Sans cryptage, des données sensibles peuvent être stockées ou envoyées. Cela va à l’encontre des règles de conformité. Utilisez TLS ou SSL pour la communication entre les pods et les services afin de renforcer la sécurité. Les dépenses considérables liées aux violations provoquées par des données non cryptées sont mises en évidence dans le rapport 2023 Cost of a Data Breach Report. Les attaquants ont la possibilité d’intercepter des informations privées envoyées entre les modules.

• Cryptez les communications entre les composants Kubernetes et les services externes à l’aide de Transport Layer Security (TLS).
• À la périphérie du cluster, mettez fin aux connexions SSL/TLS avec les contrôleurs d’entrée Kubernetes.
• Pour protéger les données lors de leur envoi, les applications conteneurisées doivent appliquer les méthodes de chiffrement HTTPS.

Mauvaises configurations des pods

Elles exposent les vulnérabilités, provoquent des accès non autorisés et entraînent des problèmes de performance ou des temps d’arrêt. Pour prévenir les violations, utilisez les outils de sécurité Kubernetes. Ils recherchent les mauvaises configurations et suivent les meilleures pratiques lors de la définition des spécifications des pods. Un rapport de Gartner estime que d’ici 2025, 99 % des atteintes à la sécurité du cloud seront dues à des erreurs de configuration de la part des clients. Dans ce scénario, un pod mal configuré expose un service à l’internet public.   

• Pour imposer les meilleures pratiques et les configurations de sécurité sur les pods, tirez parti des politiques de sécurité des pods (PSP) de Kubernetes.
• Appliquer des outils spécialisés ou des fonctionnalités Kubernetes intégrées pour auditer et analyser régulièrement les pods à la recherche de configurations erronées.
• Les vérifications préalables au déploiement et les pipelines CI/CD devraient être utilisés pour éviter les problèmes de mauvaise configuration.

Utilisation des informations d’identification par défaut

Un attaquant peut facilement accéder à un cluster Kubernetes et compromettre l’ensemble du système. Les identifiants par défaut vont à l’encontre des meilleures pratiques de sécurité et compliquent le contrôle d’accès. Modifiez-les dès l’installation du logiciel pour renforcer la sécurité. Le botnet Mirai a infiltré des appareils IoT, provoquant des pannes massives. Le rapport 2021 Data Breach Investigations Report de Verizon indique que 61 % des incidents impliquaient des informations d’identification volées ou de mauvaise qualité.

• Pour imposer des identifiants distincts et non par défaut, utilisez des techniques d’authentification robustes telles que le RBAC (contrôle d’accès basé sur les rôles) de Kubernetes.
• Les mots de passe et les jetons de compte de service doivent être périodiquement audités et modifiés.
• Il est recommandé d’utiliser les secrets Kubernetes ou des outils de gestion des secrets tiers pour stocker et gérer les informations d’identification en toute sécurité.

Conclusion

Kubernetes est une puissante plateforme open-source d’orchestration de conteneurs. Elle simplifie plusieurs opérations de gestion des conteneurs. Cependant, les entreprises sont souvent confrontées à des défis pour atteindre leur plein potentiel. Il s’agit notamment de :

• Planification de l’évolutivité
• Tests de bout en bout
• Gestion efficace des clusters K8s
• Rester à jour avec les API obsolètes
• Configuration des politiques de réseau
• Automatisation
• La sécurité
• Protection des données en transit.

La planification de l’évolutivité est cruciale pour éviter les goulets d’étranglement des performances et les dépenses injustifiées. Les tests permettent de découvrir les bugs cachés et les défaillances des applications. La gestion des clusters Kubernetes permet d’éviter les failles de sécurité et la mauvaise gestion des ressources. Rester à jour avec les API obsolètes est essentiel pour un succès à long terme. Les politiques de réseau doivent être adoptées pour protéger les environnements Kubernetes contre les accès non autorisés et les violations. L’automatisation est essentielle pour une adaptation et une récupération rapides des ressources Kubernetes. Elle favorise également la résilience et la disponibilité continue. La sécurité est une priorité absolue, avec des mises à jour régulières, un contrôle d’accès basé sur les rôles et le chiffrement pour atténuer les risques. Le chiffrement des données pendant leur transit garantit leur intégrité et leur confidentialité. En élaborant une liste de contrôle des meilleures pratiques, vous pouvez naviguer en toute confiance dans le paysage Kubernetes. Mettez en œuvre ces stratégies avec AccuKnox, pour optimiser les déploiements Kubernetes. Nous garantissons un voyage transparent, sécurisé et rentable dans le monde de l’orchestration de conteneurs.