Sécurité de Helm

L'essence de l'histoire sur le gestionnaire de paquets le plus populaire pour Kubernetes pourrait être représentée par ces émojis :

• une boîte — c'est Helm (c'est ce qui convient le mieux dans la dernière version d'Emoji);
• un cadenas — sécurité;
• une petite figurine — la solution au problème.

En réalité, tout sera un peu plus complexe, et l'histoire est pleine de détails techniques sur comment rendre Helm sécurisé..

• En bref, qu'est-ce que Helm, si vous ne le saviez pas ou si vous l'avez oublié. Quels problèmes il résout et où il se situe dans l'écosystème.
• Examinons l'architecture de Helm. Aucune discussion sur la sécurité et sur la façon de rendre un outil ou une solution plus sécurisée ne peut se faire sans une compréhension de l'architecture du composant.
• Discutons des composants de Helm.
• La question la plus pressante — l'avenir — la nouvelle version de Helm 3. 

Tout dans cet article concerne Helm 2. Cette version est actuellement en production et c'est probablement celle que vous utilisez en ce moment, et c'est dans celle-ci qu'il existe des menaces pour la sécurité.

À propos des intervenants : Alexandre Khayev (allexx) développe depuis 10 ans, aide à améliorer le contenu Moscow Python Conf++ et a rejoint le comité Helm Summit. Il travaille actuellement chez Chainstack en tant que responsable du développement — un hybride entre un chef de développement et quelqu'un qui est responsable de la livraison des versions finales. C'est-à-dire qu'il est sur le terrain, là où tout se passe, de la création du produit à son exploitation.

Chainstack est une petite start-up en forte croissance, dont la mission est de permettre aux clients d'oublier l'infrastructure et les complexités de l'exploitation des applications décentralisées, l'équipe de développement est à Singapour. Ne demandez pas à Chainstack de vendre ou d'acheter des cryptomonnaies, mais proposez de discuter des cadres blockchain pour les entreprises, et ils vous répondront avec plaisir.

Helm

C'est un gestionnaire de paquets (charts) pour Kubernetes. La manière la plus claire et universelle d'apporter des applications dans un cluster Kubernetes.

Il s'agit, bien sûr, d'une approche plus structurée et industrielle que de créer ses propres manifestes YAML et d'écrire de petites utilitaires.

Helm est le meilleur de ce qui est actuellement disponible et populaire.

Pourquoi Helm ? Tout d'abord, parce qu'il est soutenu par la CNCF. Cloud Native est une grande organisation, mère des projets Kubernetes, etcd, Fluentd et d'autres.

Un fait important, Helm est un projet très populaire. En janvier 2019, lorsque j'ai commencé à réfléchir à comment rendre Helm sécurisé, le projet avait mille étoiles sur GitHub. En mai, cela avait atteint 12 000.

Beaucoup s'intéressent à Helm, donc même si vous ne l'utilisez pas encore, il vous sera utile de connaître sa sécurité. La sécurité est importante.

L'équipe principale de Helm est soutenue par Microsoft Azure, ce qui en fait un projet assez stable comparé à beaucoup d'autres. La sortie de Helm 3 Alpha 2 à la mi-juillet montre qu'il y a de nombreuses personnes travaillant sur le projet, et qu'elles ont le désir et les capacités de développer et améliorer Helm.

Helm résout plusieurs problèmes fondamentaux de gestion d'applications dans Kubernetes.

• L'emballage d'applications. Même une application simple comme « Hello, World » sur WordPress représente déjà plusieurs services, et il est souhaitable de les regrouper.
• La gestion de la complexité qui émerge de la gestion de ces applications.
• Le cycle de vie qui ne se termine pas après l'installation ou le déploiement d'une application. Elle continue de vivre, elle doit être mise à jour, et Helm aide à cela en cherchant à établir les bonnes mesures et politiques.

L'emballage est organisé de manière évidente : il y a des métadonnées en conformité avec le fonctionnement d'un gestionnaire de paquets classique pour Linux, Windows ou MacOS. C'est-à-dire un dépôt, des dépendances entre différents paquets, des métainformations pour les applications, des configurations, des particularités de configuration, un index d'informations, etc. Tout cela Helm permet de récupérer et d'utiliser pour les applications.

La gestion de la complexité. Si vous avez beaucoup d'applications similaires, vous aurez besoin de paramétrisation. Cela conduit aux modèles, mais pour ne pas avoir à inventer votre propre méthode de création de modèles, vous pouvez utiliser ce que Helm offre tout de suite.

La gestion du cycle de vie d'une application — à mon avis, c'est la question la plus intéressante et non résolue. C'est pourquoi à l'époque, je me suis tourné vers Helm. Nous devions suivre le cycle de vie d'une application, nous voulions transférer notre CI/CD et nos cycles d'applications dans cette paradigme.

Helm permet de :

• gérer les déploiements, introduit la notion de configuration et de révision ;
• effectuer des rollback avec succès ;
• utiliser des hooks pour différents événements ;
• ajouter des vérifications supplémentaires des applications et réagir à leurs résultats.

De plus, Helm a des « batteries » — un grand nombre de choses délicieuses que vous pouvez inclure sous forme de plugins, simplifiant ainsi votre vie. Les plugins peuvent être écrits vous-même, ils sont assez isolés et ne nécessitent pas une architecture complexe. Si vous voulez réaliser quelque chose, je vous recommande de le faire sous forme de plugin, puis éventuellement de l'inclure dans l'upstream.

Helm repose sur trois concepts principaux :

• Chart Repo — une description et un ensemble de paramètres possibles pour votre manifeste. 
• Configuration — c'est-à-dire les valeurs qui seront appliquées (texte, valeurs numériques, etc.).
• Publication combine les deux composants supérieurs, et ensemble ils se transforment en Release. Les releases peuvent être versionnées, assurant ainsi l'organisation du cycle de vie : petite au moment de l'installation et importante au moment de la mise à niveau, de la rétrogradation ou du retour en arrière.

Architecture de Helm

Le schéma reflète conceptuellement l'architecture de haut niveau de Helm.

Je rappelle que Helm est lié à Kubernetes. Donc, nous ne pouvons pas nous passer d'un cluster Kubernetes (rectangle). Le composant kube-apiserver se trouve sur le maître. Sans Helm, nous avons Kubeconfig. Helm apporte un petit binaire, si l'on peut l'appeler ainsi, l'outil Helm CLI, qui s'installe sur un ordinateur, un portable, un mainframe — sur n'importe quoi.

Mais cela ne suffit pas. Helm a un composant serveur, Tiller. Il représente les intérêts de Helm au sein du cluster, c'est une application à l'intérieur du cluster Kubernetes, tout comme n'importe quelle autre.

Le composant suivant, Chart Repo, est un dépôt de charts. Il existe un dépôt officiel et il peut y avoir un dépôt privé d'entreprise ou de projet.

Interaction

Voyons comment les composants de l'architecture interagissent lorsque nous voulons installer une application avec Helm.

• Nous disons Helm install, nous nous adressons au dépôt (Chart Repo) et obtenons le chart Helm.

• L'outil Helm (Helm CLI) interagit avec Kubeconfig pour déterminer à quel cluster s'adresser. 
• Une fois cette information obtenue, l'outil s'adresse à Tiller, qui se trouve dans notre cluster, en tant qu'application. 
• Tiller interroge le Kube-apiserver pour effectuer des actions dans Kubernetes, créer des objets (services, pods, répliques, secrets, etc.).

Ensuite, nous compliquerons le schéma pour voir les vecteurs d'attaque auxquels l'ensemble de l'architecture Helm peut être exposé. Puis nous essaierons de le protéger.

Vecteur d'attaque

Le premier point potentiellement faible est — l'API privilégiée—utilisateur. Dans le cadre du schéma, c'est un hacker ayant obtenu un accès administrateur au Helm CLI.

Utilisateur API non privilégié peut également représenter un danger s'il se trouve à proximité. Cet utilisateur aura un autre contexte, par exemple, il peut être enregistré dans un namespace du cluster dans les paramètres de Kubeconfig.

Le vecteur d'attaque le plus intéressant pourrait être un processus qui se trouve à l'intérieur du cluster, près de Tiller, et qui peut y accéder. Cela pourrait être un serveur web ou un microservice qui voit l'environnement réseau du cluster.

Une variante exotique mais de plus en plus populaire d'attaque est liée au Chart Repo. Un chart créé par un auteur malintentionné peut contenir une ressource non sécurisée, et vous l'exécuterez en faisant confiance. Ou il peut remplacer le chart que vous téléchargez depuis le dépôt officiel et, par exemple, créer une ressource sous forme de politiques et s'escalader l'accès.

Essayons de nous défendre contre ces attaques venant de ces quatre angles et de comprendre où se trouvent les problèmes dans l'architecture de Helm, et où il n'y en a peut-être pas.

Consolidons le schéma, ajoutons plus d'éléments, mais gardons tous les composants de base.

Le Helm CLI communique avec le Chart Repo, interagit avec Kubeconfig, et le travail est transmis au cluster dans le composant Tiller.

Tiller est représenté par deux objets :

• Le service Tiller-deploy, qui expose un certain service ;
• Le pod Tiller-deploy (dans le schéma, en un seul exemplaire dans une réplique), qui gère tout le travail et qui interroge le cluster.

Différents protocoles et schémas sont utilisés pour l'interaction. Du point de vue de la sécurité, ce qui nous intéresse le plus est :

• Le mécanisme par lequel le Helm CLI interroge le chart repo : quel protocole, y a-t-il une authentification et que peut-on en faire.
• Le protocole selon lequel le Helm CLI, en utilisant kubectl, communique avec Tiller. Il s'agit d'un serveur RPC installé à l'intérieur du cluster.
• Tiller lui-même est accessible aux microservices qui se trouvent dans le cluster et interagit avec le Kube-apiserver.

Discutons de toutes ces directions dans l'ordre.

RBAC

Il est inutile de parler de sécurité dans Helm ou d'un autre service à l'intérieur du cluster sans avoir activé RBAC.

Il semble que ce ne soit pas la recommandation la plus récente, mais je suis certain que beaucoup n'ont toujours pas activé RBAC même en production, car cela demande beaucoup de travail et nécessite de nombreuses configurations. Néanmoins, je vous encourage à le faire.

https://rbac.dev/ — un site d'avocat pour RBAC. Il rassemble une énorme quantité de matériaux intéressants qui aideront à configurer RBAC, montreront pourquoi il est bon et comment vivre avec en production.

Je vais essayer d'expliquer comment fonctionne Tiller et RBAC. Tiller fonctionne à l'intérieur du cluster sous un certain compte de service. En général, si RBAC n'est pas configuré, cela sera un super utilisateur. Dans la configuration de base, Tiller sera administrateur. C'est pourquoi on dit souvent que Tiller est un tunnel SSH vers votre cluster. En réalité, c'est le cas, donc vous pouvez utiliser un compte de service spécialisé au lieu du compte de service par défaut dans le schéma ci-dessus.

Lorsque vous initialisez Helm, que vous l'installez pour la première fois sur le serveur, vous pouvez définir un compte de service à l'aide de --service-account. Cela permettra d'utiliser un utilisateur avec le minimum de droits nécessaires. Cependant, vous devrez créer cette « guirlande » : Role et RoleBinding.

Malheureusement, Helm ne le fera pas pour vous. Vous ou votre administrateur de cluster Kubernetes devez préparer à l'avance un ensemble de Role et RoleBinding pour le compte de service à transmettre à Helm.

La question se pose — quelle est la différence entre Role et ClusterRole ? La différence est que ClusterRole s'applique à tous les namespaces, contrairement aux rôles et liaison de rôle normaux, qui ne fonctionnent que pour un namespace spécialisé. Vous pouvez configurer des politiques à la fois pour l'ensemble du cluster et tous les namespaces, ainsi que de manière personnalisée pour chaque namespace individuellement.

Il convient de mentionner que RBAC permet de résoudre un autre gros problème. Beaucoup se plaignent que Helm, malheureusement, n'est pas multitenancy (ne prend pas en charge la multi-location). Si plusieurs équipes consomment le cluster et utilisent Helm, il est impossible de configurer des politiques et de restreindre leur accès dans ce cluster, car il y a un certain compte de service sous lequel Helm fonctionne, et il crée toutes les ressources dans le cluster à partir de celui-ci, ce qui est parfois très gênant. C'est vrai — en tant que fichier binaire, en tant que processus, Helm Tiller n'a pas de notion de multitenancy..

Cependant, il existe un excellent moyen qui permet de lancer Tiller dans le cluster plusieurs fois. Il n'y a aucun problème à cela, Tiller peut être lancé dans chaque namespace. Ainsi, vous pouvez profiter de RBAC, Kubeconfig comme contexte, et restreindre l'accès à un Helm spécial.

Cela ressemblera à ce qui suit.

Par exemple, il existe deux Kubeconfig avec des contextes pour différentes équipes (deux namespaces): Équipe X pour l’équipe de développement et un cluster pour l’administrateur. Le cluster de l'administrateur dispose de son propre Tiller large, situé dans l’espace Kube-system namespace, avec un service-account avancé. Et un namespace distinct pour l’équipe des développeurs, qui pourront déployer leurs services dans un namespace spécial.

C'est une approche fonctionnelle, Tiller n'est pas si gourmand, donc cela ne devrait pas affecter votre budget de manière significative. C'est l'une des solutions rapides.

N'hésitez pas à configurer Tiller séparément et à fournir Kubeconfig avec un contexte pour l'équipe, pour un développeur spécifique ou pour des environnements: Dev, Staging, Production (il est peu probable que tout soit sur un seul cluster, mais c'est possible).

En poursuivant notre histoire, passons de RBAC à ConfigMaps.

ConfigMaps

Helm utilise des ConfigMaps comme stockage de données. Lorsque nous parlions d'architecture, il n'y avait pas de base de données contenant des informations sur les releases, configurations, rollbacks, etc. Pour cela, nous utilisons des ConfigMaps.

Le principal problème avec les ConfigMaps est bien connu — elles ne sont pas sécurisées par principe, elles ne peuvent pas stocker de données sensibles. Cela concerne tout ce qui ne doit pas être divulgué au-delà du service, par exemple, les mots de passe. Le moyen le plus natif pour Helm est actuellement de passer de l'utilisation de ConfigMaps aux secrets.

C'est très simple à faire. Vous redéfinissez la configuration de Tiller et indiquez que le stockage sera des secrets. Ainsi, à chaque déploiement, vous obtiendrez non pas un ConfigMap, mais un secret.

Vous pourriez argumenter que les secrets eux-mêmes sont un concept étrange, et que ce n'est pas très sûr. Cependant, il est important de comprendre que cela est géré par les développeurs de Kubernetes eux-mêmes. Depuis la version 1.10, c'est-à-dire il y a un certain temps, il est possible, au moins dans les cloud publics, de connecter un stockage approprié pour les secrets. L'équipe travaille actuellement à améliorer encore l'accès aux secrets, pour des pods ou d'autres entités spécifiques.

Il est préférable de passer le stockage Helm aux secrets, et de les sécuriser de manière centralisée.

Bien sûr, il restera une limite de stockage de données de 1 Mo. Helm utilise ici etcd comme stockage distribué pour ConfigMaps. Et là-bas, ils ont décidé que c'était un chunk de données approprié pour les répliques, etc. À ce sujet, il y a une discussion intéressante sur Reddit, je recommande de trouver cette lecture amusante pour le week-end ou de lire le résumé. ici.

Dépôts de chartes

Les chartes sont particulièrement vulnérables et peuvent devenir une source d'attaque de type « homme du milieu », surtout si une solution par défaut est utilisée. Cela concerne principalement les dépôts accessibles par HTTP.

Il est certain que le dépôt Helm doit être exposé via HTTPS — c'est la meilleure option et cela ne coûte pas cher.

Veuillez noter que mécanisme de signature des chartes. La technologie est d'une simplicité déconcertante. C'est la même chose que vous utilisez sur GitHub, une machine PGP classique avec des clés publiques et privées. Configurez-le et vous serez en sécurité, en ayant les bonnes clés et en signant tout pour prouver que c'est bien votre charte.

De plus, Le client Helm supporte TLS (pas dans le sens HTTP côté serveur, mais TLS mutuel). Vous pouvez utiliser des clés serveur et client pour communiquer. Pour être honnête, je n'utilise pas ce mécanisme à cause de mon aversion pour les certificats mutuels. En principe, chartmuseum — l'outil principal pour exposer un dépôt Helm pour Helm 2 — prend également en charge l'authentification de base. Vous pouvez utiliser l'authentification de base si cela est plus pratique et rassurant.

Il existe aussi un plugin helm-gcs, qui permet d'héberger des dépôts de chartes dans Google Cloud Storage. C'est assez pratique, ça fonctionne très bien et c'est suffisamment sécurisé, car tous les mécanismes décrits sont utilisés.

Si vous activez HTTPS ou TLS, utilisez mTLS, ajoutez l'authentification de base pour réduire davantage les risques, vous obtiendrez un canal de communication sécurisé entre Helm CLI et le dépôt de chartes.

API gRPC

L'étape suivante est très importante — sécuriser Tiller, qui se trouve dans le cluster et qui est, d'une part, le serveur, et d'autre part — il interagit avec d'autres composants et essaie de se faire passer pour quelqu'un d'autre.

Comme je l'ai déjà dit, Tiller est un service qui expose gRPC, le client Helm se connecte à lui via gRPC. Par défaut, il va sans dire que TLS est désactivé. La raison pour laquelle c'est fait est une question de débat, je pense que c'est pour simplifier la configuration au démarrage.

Pour la production et même pour la mise en scène, je recommande d'activer TLS sur gRPC.

À mon avis, contrairement à mTLS pour les charts, ici c'est approprié et se fait très simplement — vous générez l'infrastructure PQI, créez un certificat, lancez Tiller, et passez le certificat lors de l'initialisation. Ensuite, vous pouvez exécuter toutes les commandes Helm en vous présentant avec le certificat généré et la clé privée.

De cette façon, vous vous protégez contre toutes les demandes à Tiller provenant de l'extérieur du cluster.

Ainsi, nous avons sécurisé le canal de connexion à Tiller, déjà discuté du RBAC et réglé les droits du Kubernetes apiserver, réduit le domaine avec lequel il peut interagir.

Helm sécurisé

Regardons le schéma final. C'est la même architecture avec les mêmes flèches.

Toutes les connexions peuvent maintenant être dessinées en vert :

• pour le Chart Repo, nous utilisons TLS ou mTLS et l'authentification de base ;
• mTLS pour Tiller, et il est exposé comme un service gRPC avec TLS, nous utilisons des certificats ;
• dans le cluster, un compte de service spécial avec un rôle et un RoleBinding est utilisé. 

Nous avons considérablement sécurisé le cluster, mais quelqu'un d'intelligent a dit :

« La seule solution absolument sécurisée peut être un ordinateur éteint, enfermé dans une boîte en béton et gardé par des soldats ».

Il existe différentes manières de manipuler les données et de trouver de nouveaux vecteurs d'attaque. Cependant, je suis convaincu que ces recommandations permettront de mettre en œuvre un standard de sécurité industriel de base.

Bonus

Cette partie n'est pas directement liée à la sécurité, mais sera également utile. Je vais montrer certaines choses intéressantes que peu de gens connaissent. Par exemple, comment rechercher des charts — officiels et non officiels.

Dans le référentiel github.com/helm/charts il y a maintenant environ 300 charts et deux flux : stable et incubator. Ceux qui contribuent savent très bien à quel point il est difficile de passer de l'incubator au stable, et à quel point il est facile de sortir du stable. Cependant, ce n'est pas le meilleur outil pour rechercher des charts pour Prometheus et tout ce que vous aimez, pour une raison simple : ce n'est pas un portail où il est facile de rechercher des paquets.

Mais il existe un service hub.helm.sh, qui rend la recherche de charts beaucoup plus pratique. Le plus important, c'est qu'il y a beaucoup plus de dépôts externes et presque 800 charts disponibles. De plus, vous pouvez connecter votre propre dépôt si, pour une raison quelconque, vous ne souhaitez pas envoyer vos charts dans le stable.

Essayez hub.helm.sh et développons-le ensemble. Ce service est sous le projet Helm, et vous pouvez même contribuer à son interface utilisateur si vous êtes un développeur front-end et souhaitez simplement améliorer son apparence.

Je souhaite également attirer votre attention sur l'intégration de l'API Open Service Broker. Cela peut sembler encombrant et incompréhensible, mais cela résout des problèmes auxquels tout le monde est confronté. Je vais l'expliquer avec un exemple simple.

Imaginons un cluster Kubernetes dans lequel nous voulons déployer une application classique — WordPress. En général, une base de données est nécessaire pour un fonctionnement complet. Il existe de nombreuses solutions, par exemple, vous pouvez lancer votre propre service stateful. Ce n'est pas très pratique, mais beaucoup font ainsi.

D'autres, comme nous chez Chainstack, utilisent des bases de données gérées, comme MySQL ou PostgreSQL, pour les serveurs. Donc, notre base de données se trouve quelque part dans le cloud.

Mais un problème se pose : il faut lier notre service à la base de données, créer un flavor de base de données, transmettre les informations d'identification et les gérer d'une certaine manière. Tout cela est généralement fait manuellement par un administrateur système ou un développeur. Cela ne pose pas de problème quand il y a peu d'applications. Lorsqu'il y en a beaucoup, il faut un combineur. Ce combineur existe — c'est le Service Broker. Il permet d'utiliser un plugin spécial sur le cluster de cloud public et de commander des ressources auprès du fournisseur par le biais du Broker, comme si c'était une API. Pour cela, vous pouvez utiliser les outils natifs de Kubernetes.

C'est très simple. Vous pouvez par exemple demander un Managed MySQL sur Azure avec un niveau de service de base (cela peut être configuré). En utilisant l'API Azure, la base sera créée et préparée à l'utilisation. Vous n'aurez pas besoin de vous en mêler, le plugin s'en occupe. Par exemple, OSBA (plugin Azure) retournera les informations d'identification vers le service et les transmettra via Helm. Vous pourrez utiliser WordPress avec MySQL dans le cloud, sans vous occuper des bases de données gérées et sans vous soucier des services stateful en arrière-plan.

On peut dire que Helm est la colle qui, d'un côté, permet de déployer des services et, de l'autre, de consommer des ressources des fournisseurs de cloud.

Vous pouvez écrire votre propre plugin et utiliser toute cette histoire sur site. Vous aurez simplement votre propre plugin pour le fournisseur de cloud d'entreprise. Je recommande d'essayer cette approche, surtout si vous avez une grande échelle et que vous souhaitez déployer rapidement le développement, la mise en scène ou l'ensemble de l'infrastructure pour une fonctionnalité. Cela simplifiera la vie de vos opérations ou de votre équipe DevOps.

Une autre découverte que j'ai déjà mentionnée — c'est le plugin helm-gcs, qui permet d'utiliser des Google-buckets (stockage d'objets) pour stocker des charts Helm.

Il vous suffit de quatre commandes pour commencer à l'utiliser :

1. installer le plugin ;
2. l'initialiser ;
3. définir le chemin vers le bucket situé dans gcp ;
4. publier les charts de manière standard.

L'avantage est que la méthode d'autorisation native de gcp sera utilisée. Vous pouvez utiliser un compte de service, un compte développeur — tout ce que vous voulez. C'est très pratique et cela ne coûte rien en exploitation. Si vous, comme moi, défendez la philosophie sans ops, cela sera très commode, surtout pour les petites équipes.

Alternatives

Helm n'est pas la seule solution pour gérer des services. De nombreuses questions se posent à son sujet, c'est probablement pour cela que la troisième version est apparue si rapidement. Bien sûr, il existe des alternatives.

Il peut s'agir de solutions spécialisées comme Ksonnet ou Metaparticle. Vous pouvez utiliser vos outils classiques de gestion d'infrastructure (Ansible, Terraform, Chef, etc.) pour les mêmes objectifs dont j'ai parlé.

Enfin, il existe une solution Operator Framework, dont la popularité est en croissance.

L'Operator Framework est la principale alternative à Helm à laquelle il faut prêter attention.

Il est plus natif pour CNCF et Kubernetes, mais la barrière d'entrée est beaucoup plus élevée, il faut programmer davantage et moins décrire des manifestes.

Il existe différents addons, comme Draft et Scaffold. Ils simplifient beaucoup la vie, par exemple, en facilitant aux développeurs le cycle d'envoi et de lancement de Helm pour déployer un environnement de test. Je les appellerais des enrichisseurs de capacités.

Voici un graphique illustratif montrant où se trouve chaque élément.

Sur l'axe des abscisses, le niveau de votre contrôle personnel sur ce qui se passe, sur l'axe des ordonnées — le niveau de nativité de Kubernetes. Helm version 2 se situe quelque part au milieu. En version 3, il n'y a pas de changements colossaux, mais tant le contrôle que le niveau de nativité ont été améliorés. Les solutions de niveau Ksonnet restent malgré tout inférieures à Helm 2. Cependant, il vaut la peine de les examiner pour savoir ce qui existe encore dans ce monde. Bien entendu, votre gestionnaire de configuration sera sous votre contrôle, mais il n'est absolument pas natif pour Kubernetes.

L'Operator Framework est complètement natif pour Kubernetes et permet de le gérer de manière beaucoup plus élégante et minutieuse (mais rappelons-nous du niveau d'entrée). Il conviendra plutôt à une application spécialisée et à la création de gestion à son égard, plutôt qu'à un broyeur de masse pour emballer un grand nombre d'applications à l'aide de Helm.

Les enrichisseurs améliorent juste un peu le contrôle, complètent le workflow ou prennent des raccourcis dans les pipelines CI/CD.

L'avenir de Helm

La bonne nouvelle, c'est qu'Helm 3 arrive. La version alpha d'Helm 3.0.0-alpha.2 est déjà sortie, et vous pouvez l'essayer. Elle est assez stable, mais ses fonctionnalités sont encore limitées.

Pourquoi Helm 3 est-il nécessaire ? Avant tout, il s'agit de la disparition de Tiller, en tant que composant. Comme vous le comprenez déjà, c'est un grand pas en avant, car cela simplifie l'architecture du point de vue de la sécurité.

Lorsque Helm 2 a été créé, à l'époque de Kubernetes 1.8 ou même plus tôt, de nombreux concepts étaient immatures. Par exemple, le concept de CRD est maintenant largement intégré, et Helm va utiliser CRD, pour stocker des structures. Il sera possible d'utiliser uniquement le client sans avoir à maintenir la partie serveur. En conséquence, il sera possible d'utiliser les commandes natives de Kubernetes pour travailler avec des structures et des ressources. Cela représente un énorme progrès.

Il y aura le support des dépôts OCI natifs (Open Container Initiative). C'est une initiative majeure, et Helm y trouve un intérêt surtout pour héberger ses charts. À tel point que, par exemple, Docker Hub prend en charge de nombreuses normes OCI. Je ne prédis rien, mais il est possible que les fournisseurs classiques de dépôts Docker commencent à vous permettre d'héberger vos charts Helm.

Un aspect discutable pour moi est le support de Lua, en tant que moteur de templating pour écrire des scripts. Je ne suis pas un grand fan de Lua, mais cela sera une option entièrement facultative. J'ai vérifié trois fois — l'utilisation de Lua ne sera pas obligatoire. Donc, ceux qui le souhaitent pourront utiliser Lua, ceux qui préfèrent Go — rejoignez notre grand camp et utilisez go-tmpl pour cela.

Enfin, ce qui me manquait vraiment, c'est l'apparition de schémas et la validation des types de données. Il n'y aura plus de problèmes avec int ou string, il ne faudra plus envelopper zéro entre guillemets. Une JSON Schema apparaîtra, ce qui permettra de décrire cela clairement pour les valeurs.

Le modèle orienté événementssera fortement retravaillé. Il est déjà conceptuellement décrit. Regardez dans la branche Helm 3, et vous verrez combien d'événements et de hooks ont été ajoutés, ce qui simplifiera considérablement et, d'un autre côté, ajoutera du contrôle sur les processus de déploiement et leurs réactions.

Helm 3 sera plus simple, plus sûr et plus intéressant, non pas parce que nous n'aimons pas Helm 2, mais parce que Kubernetes devient plus avancé. En conséquence, Helm peut s'appuyer sur les améliorations de Kubernetes et créer d'excellents gestionnaires pour Kubernetes.

Une autre bonne nouvelle est que DevOpsConf Alexandre Khayorov expliquera, les conteneurs peuvent-ils être sûrs ? Rappelons que la conférence sur l'intégration des processus de développement, de test et d'exploitation se tiendra à Moscou les 30 septembre et 1er octobre. Vous avez jusqu'au 20 août pour soumettre une présentation partager votre expérience de résolution l'une des nombreuses problématiques de l'approche DevOps.

Pour les mises à jour de la conférence et les nouvelles, suivez-nous sur le une newsletter et canal Telegram.

Source : habr.com