Les problèmes de sécurité de Kubernetes soulèvent des inquiétudes pour les magasins d'entreprise – Un bon serveur Minecraft

production.

L'étendue des fonctionnalités de la plate-forme d'orchestration de conteneurs Kubernetes fait des problèmes de sécurité un problème complexe qui nécessite de multiples couches de défense, de la reconfiguration des paramètres par défaut dans les images de conteneurs Docker et de Kubernetes en amont aux outils de surveillance de sécurité de pointe et aux concepts de réseau avancés , tel que le maillage de service.

Une chose est claire dans les discussions de KubeCon et de KubeSec ici cette semaine: les versions amont de Kubernetes et les images de conteneur Docker ne sont pas sécurisées.

"Le [Kubernetes] Les paramètres par défaut de l'orchestrateur sont terribles, alors changez-les ", a déclaré Sarah Young, architecte de la sécurité informatique chez Versent, une société australienne de conseil en technologies de l'information, dans une présentation.

Par exemple, le serveur API Kubernetes est à l'écoute sur le port 8080 où aucune vérification de sécurité n'est effectuée par défaut. Le cryptage et la gestion des secrets dans etcd – le magasin de clés-valeurs Kubernetes qui maintient l'état du cluster – restent en développement. Lorsqu'elle est utilisée avec etcd version 3, la version 1.13 de Kubernetes, publiée en décembre 2018, offre le cryptage des données inactives. Toutefois, comme l'a révélé la vulnérabilité de sécurité critique de Kubernetes de la semaine dernière, peu d'entreprises peuvent suivre les mises à niveau des versions ultérieures de Kubernetes.

"Kubernetes est en train de rattraper les meilleures pratiques de base en matière de sécurité d'entreprise", a déclaré Tsvi Korren, vice-président de la stratégie produit du fournisseur de solutions de surveillance de la sécurité Aqua Security, lors d'une table ronde. "Le cryptage du stockage d'objets n'est pas quelque chose que vous devriez vous féliciter [back] pour."

Les experts en sécurité ont déclaré que le secteur était en grande partie passé des problèmes de sécurité propres aux conteneurs, tels que le fait que de nombreuses images Docker conservent par défaut un accès racine à l'hôte, ce qui va à l'encontre des meilleures pratiques de sécurité. Cependant, cela est souvent dû au fait que des fournisseurs tiers empaquetent toujours le logiciel d'application et supposent que les images de conteneur ont un accès root légitime à un serveur, a déclaré Young. Les alternatives qui interdisent l'accès root par défaut, telles que les conteneurs SELinux et les espaces de noms d'utilisateurs, doivent toujours résoudre les problèmes de développement importants afin d'être prêtes pour la production et gérables pour les utilisateurs de l'entreprise.

Les conteneurs SELinux, en particulier, sont difficiles à configurer correctement, car Linux a également été conçu pour fonctionner sur des serveurs, a expliqué Young. La configuration des conteneurs nécessite une construction minutieuse du fichier de conteneurs, avec de nombreux choix discrétionnaires pour les pros de DevOps, qui peuvent ne pas être très au courant de la sécurité.

Les espaces de noms d'utilisateurs nécessitent une intégration avec les systèmes d'exploitation Linux et les systèmes de fichiers pour appliquer leurs autorisations. De telles intégrations doivent encore être généralisées, a déclaré Dan Walsh, ingénieur distingué de Red Hat, qui a également pris la parole devant le panel.

Korren a déclaré craindre que les professionnels de l'informatique qui ne sont pas familiarisés avec la sécurité voient des informations telles que le cryptage etcd et pensent que les problèmes de sécurité du conteneur Kubernetes ont été résolus en amont.

"Quand ils font de grandes annonces de choses [such as etcd encryption], les non-informés pensent que leur charge de travail est désormais sécurisée ", a déclaré Korren.

Les magasins sensibles à la sécurité déploient une défense en profondeur

Selon les premiers utilisateurs de l'entreprise, il est préférable de traiter les problèmes de sécurité de Kubernetes avec une combinaison d'outils et de technologies tiers.

Starbucks Corp. déploie une chaîne d’outils imbriqués pour protéger ses grappes Kubernetes de l’exposition à l’Internet ouvert, comme un contrôleur d’entrée de NGINX, un pare-feu d’application Web de Signal Sciences et un outil local appelé Ingress Orchestrator. Grâce à ces outils, les ingénieurs de la plate-forme Starbucks n'ont pas à provisionner manuellement les espaces de noms chaque fois que les développeurs lancent un service.

Mais n'essayez pas cela à la maison, a déclaré Ryan Hild, ingénieur DevSecOps chez Starbucks. La société a démarré ce projet alors que peu d’outils étaient disponibles.

"Avec le temps, il y aura plus d'outils", a déclaré Hild. "Ne construis pas cela toi-même si tu n'es pas obligé."

Les déploiements Kubernetes plus petits reposent sur des outils tiers de surveillance de la sécurité et d'application de la part de fournisseurs tels que Aqua, Sysdig et Twistlock, et ils utilisent une approche d'infrastructure immuable pour limiter les activités non autorisées parmi les conteneurs d'applications.

"Il est facile de configurer des groupes de sécurité sur AWS pour les machines virtuelles qui ne devraient pas avoir accès aux autres." Mais dans un cluster de conteneurs, c'est plus difficile ", a déclaré Travis Jeppson, directeur de l'ingénierie chez Nav Inc. , société de conseil en crédit pour petites entreprises basée à San Mateo, en Californie. "Twistlock Defender surveille nos hôtes et nos conteneurs et, si les fichiers sont modifiés, Twistlock désactive le conteneur et Kubernetes en crée un nouveau, afin que notre environnement soit continuellement activé. un état que nous connaissons [is secure]"

L'analyse des images de conteneur Twistlock compare également les images de conteneur lors de la promotion via un pipeline CI / CD chez Nav. Elle compare également les images déployées à celles conservées dans le registre Docker afin de garantir leur sécurité et de vérifier leur provenance avant leur déploiement en production. .