Sécurité du casque

L’essence de l’histoire du gestionnaire de paquets le plus populaire pour Kubernetes pourrait être représentée à l’aide d’un emoji :

• la boîte est Helm (qui est la chose la plus proche de la dernière version d'Emoji) ;
• serrure - sécurité ;
• le petit homme est la solution au problème.

En fait, tout sera un peu plus compliqué, et l'histoire regorge de détails techniques sur Comment sécuriser Helm.

• En bref, ce qu'est Helm au cas où vous ne le sauriez pas ou l'auriez oublié. Quels problèmes résout-il et où se situe-t-il dans l’écosystème.
• Regardons l'architecture Helm. Aucune conversation sur la sécurité et sur la manière de rendre un outil ou une solution plus sécurisé n'est complète sans comprendre l'architecture du composant.
• Discutons des composants Helm.
• La question la plus brûlante est l'avenir - la nouvelle version de Helm 3. 

Tout dans cet article s'applique à Helm 2. Cette version est actuellement en production et est probablement celle que vous utilisez actuellement, et c'est la version qui contient les risques de sécurité.

À propos de l'orateur : Alexandre Khayorov (Allexx) se développe depuis 10 ans, contribuant à améliorer le contenu Conférence Python de Moscou++ et rejoint le comité Sommet de la barre. Il travaille maintenant chez Chainstack en tant que responsable du développement - il s'agit d'un hybride entre un responsable du développement et une personne responsable de la livraison des versions finales. C'est-à-dire qu'il est situé sur le champ de bataille, où tout se passe depuis la création d'un produit jusqu'à son fonctionnement.

Chainstack est une petite startup en pleine croissance dont la mission est de permettre aux clients d'oublier l'infrastructure et les complexités de l'exploitation d'applications décentralisées ; l'équipe de développement est située à Singapour. Ne demandez pas à Chainstack de vendre ou d'acheter de la crypto-monnaie, mais proposez de parler des cadres de blockchain d'entreprise, et ils se feront un plaisir de vous répondre.

Casque

Il s'agit d'un gestionnaire de packages (graphiques) pour Kubernetes. Le moyen le plus intuitif et universel de transférer des applications vers un cluster Kubernetes.

Nous parlons bien sûr d’une approche plus structurelle et industrielle que la création de vos propres manifestes YAML et l’écriture de petits utilitaires.

Helm est le meilleur actuellement disponible et populaire.

Pourquoi Helm ? D’abord parce qu’il est soutenu par la CNCF. Cloud Native est une grande organisation et est la société mère des projets Kubernetes, etcd, Fluentd et autres.

Un autre fait important est que Helm est un projet très populaire. Lorsque j'ai commencé à parler de la façon de sécuriser Helm en janvier 2019, le projet avait mille étoiles sur GitHub. En mai, ils étaient 12 XNUMX.

De nombreuses personnes s'intéressent à Helm, donc même si vous ne l'utilisez pas encore, vous bénéficierez de connaître sa sécurité. La sécurité est importante.

L'équipe principale Helm est prise en charge par Microsoft Azure et constitue donc un projet assez stable, contrairement à beaucoup d'autres. La sortie de Helm 3 Alpha 2 à la mi-juillet indique que de nombreuses personnes travaillent sur le projet et qu'elles ont le désir et l'énergie de développer et d'améliorer Helm.

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

• Emballage des applications. Même une application comme « Hello, World » sur WordPress comprend déjà plusieurs services et vous souhaitez les regrouper.
• Gérer la complexité liée à la gestion de ces applications.
• Un cycle de vie qui ne se termine pas après l'installation ou le déploiement de l'application. Il continue de vivre, il a besoin d'être mis à jour, et Helm y contribue et essaie de mettre en place les mesures et politiques appropriées pour cela.

Ensachage il est organisé de manière claire : il existe des métadonnées en totale conformité avec le travail d'un gestionnaire de packages classique pour Linux, Windows ou MacOS. C'est-à-dire un référentiel, des dépendances sur divers packages, des méta-informations pour les applications, des paramètres, des fonctionnalités de configuration, l'indexation des informations, etc. Helm vous permet d'obtenir et d'utiliser tout cela pour les applications.

Gestion de la complexité. Si vous disposez de plusieurs applications du même type, un paramétrage est nécessaire. Les modèles proviennent de là, mais pour éviter d'avoir à trouver votre propre façon de créer des modèles, vous pouvez utiliser ce que Helm propose immédiatement.

Gestion du cycle de vie des applications - à mon avis, c'est la question la plus intéressante et non résolue. C'est pourquoi je suis venu à Helm à l'époque. Nous devions garder un œil sur le cycle de vie des applications et souhaitions déplacer nos cycles CI/CD et applicatifs vers ce paradigme.

Helm vous permet de :

• gérer les déploiements, introduit le concept de configuration et de révision ;
• effectuer avec succès la restauration ;
• utilisez des hooks pour différents événements ;
• ajoutez des contrôles d'application supplémentaires et répondez à leurs résultats.

Par ailleurs Helm a des « batteries » - un grand nombre de choses savoureuses qui peuvent être incluses sous forme de plugins, vous simplifiant ainsi la vie. Les plugins peuvent être écrits indépendamment, ils sont assez isolés et ne nécessitent pas une architecture harmonieuse. Si vous souhaitez implémenter quelque chose, je vous recommande de le faire en tant que plugin, puis éventuellement de l'inclure en amont.

Helm repose sur trois concepts principaux :

• Dépôt de graphiques — description et tableau des paramétrages possibles pour votre manifeste. 
• Config —c'est-à-dire les valeurs qui seront appliquées (texte, valeurs numériques, etc.).
• Libération rassemble les deux composants supérieurs et ensemble, ils se transforment en Release. Les versions peuvent être versionnées, permettant ainsi d'obtenir un cycle de vie organisé : petit au moment de l'installation et grand au moment de la mise à niveau, de la rétrogradation ou de la restauration.

Architecture de barre

Le diagramme représente conceptuellement l'architecture de haut niveau de Helm.

Permettez-moi de vous rappeler que Helm est quelque chose lié à Kubernetes. On ne peut donc pas se passer d’un cluster Kubernetes (rectangle). Le composant kube-apiserver réside sur le maître. Sans Helm, nous avons Kubeconfig. Helm apporte un petit binaire, si vous pouvez l'appeler ainsi, l'utilitaire Helm CLI, qui est installé sur un ordinateur, un ordinateur portable, un ordinateur central - sur n'importe quoi.

Mais ce n'est pas assez. Helm possède un composant serveur appelé Tiller. Il représente les intérêts de Helm au sein du cluster ; c'est une application au sein du cluster Kubernetes, comme les autres.

Le composant suivant de Chart Repo est un référentiel avec des graphiques. Il existe un référentiel officiel et il peut y avoir un référentiel privé d'une entreprise ou d'un projet.

Interaction

Regardons comment les composants de l'architecture interagissent lorsque nous souhaitons installer une application à l'aide de Helm.

• Nous parlons Helm install, accédez au référentiel (Chart Repo) et obtenez un graphique Helm.

• L'utilitaire Helm (Helm CLI) interagit avec Kubeconfig afin de déterminer quel cluster contacter. 
• Après avoir reçu ces informations, l'utilitaire se réfère à Tiller, qui se trouve dans notre cluster, en tant qu'application. 
• Tiller appelle Kube-apiserver pour effectuer des actions dans Kubernetes, créer certains objets (services, pods, répliques, secrets, etc.).

Ensuite, nous compliquerons le diagramme pour voir le vecteur d'attaque auquel l'ensemble de l'architecture Helm dans son ensemble peut être exposée. Et puis nous essaierons de la protéger.

Vecteur d'attaque

Le premier point faible potentiel est API privilégiée-utilisateur. Dans le cadre de ce programme, il s'agit d'un pirate informatique qui a obtenu un accès administrateur à la CLI Helm.

Utilisateur API non privilégié peut également constituer un danger s’il se trouve à proximité. Un tel utilisateur aura un contexte différent, par exemple, il peut être corrigé dans un espace de noms de cluster dans les paramètres Kubeconfig.

Le vecteur d’attaque le plus intéressant pourrait être un processus résidant dans un cluster quelque part près de Tiller et pouvant y accéder. Il peut s'agir d'un serveur Web ou d'un microservice qui voit l'environnement réseau du cluster.

Une variante d’attaque exotique, mais de plus en plus populaire, implique Chart Repo. Un tableau créé par un auteur sans scrupules peut contenir des ressources dangereuses, et vous le compléterez en le prenant sur la foi. Ou bien, il peut remplacer le graphique que vous téléchargez depuis le référentiel officiel et, par exemple, créer une ressource sous forme de politiques et élever son accès.

Essayons de repousser les attaques de ces quatre côtés et de déterminer où il y a des problèmes dans l'architecture Helm, et où, peut-être, il n'y en a pas.

Agrandissons le diagramme, ajoutons plus d'éléments, mais conservons tous les composants de base.

La CLI Helm communique avec Chart Repo, interagit avec Kubeconfig et le travail est transféré du cluster vers le composant Tiller.

Tiller est représenté par deux objets :

• Tiller-deploy svc, qui expose un certain service ;
• Pod de déploiement Tiller (dans le diagramme en une seule copie dans une réplique), sur lequel s'exécute toute la charge, qui accède au cluster.

Différents protocoles et schémas sont utilisés pour l'interaction. D'un point de vue sécurité, nous nous intéressons surtout à :

• Le mécanisme par lequel la CLI Helm accède au dépôt de graphiques : quel protocole, y a-t-il une authentification et que peut-on en faire.
• Le protocole par lequel Helm CLI, 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 résident dans le cluster et interagit avec le serveur Kube-api.

Discutons de tous ces domaines dans l'ordre.

RBAC (Contrôle d'accès basé sur le rôle)

Cela ne sert à rien de parler de sécurité pour Helm ou tout autre service au sein du cluster à moins que RBAC ne soit activé.

Il semble que ce ne soit pas la dernière recommandation, mais je suis sûr que beaucoup de gens n'ont toujours pas activé RBAC, même en production, car c'est beaucoup de bruit et beaucoup de choses doivent être configurées. Cependant, je vous encourage à le faire.

https://rbac.dev/ — avocat du site Web de RBAC. Il contient une énorme quantité de documents intéressants qui vous aideront à configurer RBAC, à montrer pourquoi il est bon et comment vivre avec en production.

Je vais essayer d'expliquer comment fonctionnent Tiller et RBAC. Tiller fonctionne à l'intérieur du cluster sous un certain compte de service. Généralement, si RBAC n'est pas configuré, ce sera le superutilisateur. Dans la configuration de base, Tiller sera un administrateur. C'est pourquoi on dit souvent que Tiller est un tunnel SSH vers votre cluster. En fait, cela est vrai, vous pouvez donc utiliser un compte de service dédié distinct au lieu du compte de service par défaut dans le diagramme ci-dessus.

Lorsque vous initialisez Helm et l'installez sur le serveur pour la première fois, vous pouvez définir le compte de service en utilisant --service-account. Cela vous permettra d'utiliser un utilisateur avec l'ensemble minimum de droits requis. Certes, vous devrez créer une telle « 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 rôles et de liaisons de rôle pour le compte de service afin de passer Helm.

La question se pose : quelle est la différence entre Role et ClusterRole ? La différence est que ClusterRole fonctionne pour tous les espaces de noms, contrairement aux rôles et aux RoleBindings classiques, qui ne fonctionnent que pour un espace de noms spécialisé. Vous pouvez configurer des stratégies pour l'ensemble du cluster et tous les espaces de noms, ou personnalisées pour chaque espace de noms individuellement.

Il convient de mentionner que RBAC résout un autre problème majeur. Beaucoup de gens se plaignent que Helm, malheureusement, n'est pas multi-tenant (ne prend pas en charge la multi-location). Si plusieurs équipes consomment un cluster et utilisent Helm, il est fondamentalement impossible de définir des politiques et de limiter leur accès au sein de ce cluster, car il existe un certain compte de service sous lequel Helm s'exécute et il crée toutes les ressources du cluster à partir de celui-ci. , ce qui est parfois très gênant. C'est vrai - comme le fichier binaire lui-même, comme le processus, Helm Tiller n'a aucun concept de multilocation.

Cependant, il existe un excellent moyen qui vous permet d'exécuter Tiller plusieurs fois dans un cluster. Cela ne pose aucun problème, Tiller peut être lancé dans n’importe quel espace de noms. Ainsi, vous pouvez utiliser RBAC, Kubeconfig comme contexte et limiter l'accès à un Helm spécial.

Il ressemblera à ceci.

Par exemple, il existe deux Kubeconfigs avec un contexte pour différentes équipes (deux espaces de noms) : X Team pour l'équipe de développement et le cluster d'administrateur. Le cluster d'administrateur possède son propre Tiller étendu, situé dans l'espace de noms du système Kube, un compte de service avancé correspondant. Et un espace de noms distinct pour l'équipe de développement, elle pourra déployer ses services dans un espace de noms spécial.

Il s'agit d'une approche réalisable, Tiller n'est pas si gourmand en énergie que cela affectera grandement votre budget. C'est l'une des solutions rapides.

N'hésitez pas à configurer Tiller séparément et à fournir à Kubeconfig le contexte pour l'équipe, pour un développeur spécifique ou pour l'environnement : Dev, Staging, Production (il est peu probable que tout soit sur le même cluster, cependant, cela peut être fait).

Poursuivant notre histoire, passons de RBAC et parlons de ConfigMaps.

Cartes de configuration

Helm utilise ConfigMaps comme magasin de données. Lorsque nous avons parlé d'architecture, il n'existait aucune base de données permettant de stocker des informations sur les versions, les configurations, les restaurations, etc. ConfigMaps est utilisé pour cela.

Le principal problème avec les ConfigMaps est connu : ils sont en principe dangereux ; il est impossible de stocker des données sensibles. Nous parlons de tout ce qui ne doit pas dépasser le service, par exemple les mots de passe. La méthode la plus native pour Helm à l'heure actuelle consiste à passer de l'utilisation de ConfigMaps aux secrets.

Cela se fait très simplement. Remplacez le paramètre Tiller et spécifiez que le stockage sera secret. Ensuite pour chaque déploiement vous ne recevrez pas un ConfigMap, mais un secret.

On pourrait dire que les secrets eux-mêmes sont un concept étrange et peu sécurisé. Cependant, il convient de comprendre que les développeurs de Kubernetes eux-mêmes le font. À partir de la version 1.10, c'est-à-dire Depuis un certain temps déjà, il est possible, du moins dans les cloud publics, de connecter le bon stockage pour stocker des secrets. L'équipe travaille actuellement sur des moyens de mieux répartir l'accès aux secrets, aux pods individuels ou à d'autres entités.

Il est préférable de transférer Storage Helm vers des secrets, qui, à leur tour, sont sécurisés de manière centralisée.

Bien sûr, cela restera limite de stockage de données de 1 Mo. Helm utilise ici etcd comme stockage distribué pour ConfigMaps. Et là, ils ont considéré qu'il s'agissait d'un bloc de données approprié pour la réplication, etc. Il y a une discussion intéressante à ce sujet sur Reddit, je recommande de retrouver cette lecture amusante pour le week-end ou de lire l'extrait ici.

Dépôts de graphiques

Les graphiques sont les plus vulnérables socialement et peuvent devenir une source d’« homme du milieu », surtout si vous utilisez une solution boursière. Tout d’abord, nous parlons de référentiels exposés via HTTP.

Vous devez absolument exposer Helm Repo via HTTPS - c'est la meilleure option et elle est peu coûteuse.

Faites attention à mécanisme de signature graphique. La technologie est simple comme l’enfer. C'est la même chose que vous utilisez sur GitHub, une machine PGP classique avec des clés publiques et privées. Configurez et assurez-vous, en disposant des clés nécessaires et en signant le tout, qu'il s'agit bien de votre carte.

En outre, Le client Helm prend en charge TLS (pas au sens HTTP côté serveur, mais TLS mutuel). Vous pouvez utiliser les clés serveur et client pour communiquer. Pour être honnête, je n’utilise pas un tel mécanisme car je n’aime pas les certificats mutuels. Essentiellement, musée des cartes - l'outil principal de configuration de Helm Repo pour Helm 2 - prend également en charge l'authentification de base. Vous pouvez utiliser l'authentification de base si cela est plus pratique et plus silencieux.

Il existe aussi un plugin barre-gcs, qui vous permet d'héberger Chart Repos sur Google Cloud Storage. C'est très pratique, fonctionne très bien et est assez sûr, car tous les mécanismes décrits sont recyclés.

Si vous activez HTTPS ou TLS, utilisez mTLS et activez l'authentification de base pour réduire davantage les risques, vous obtiendrez un canal de communication sécurisé avec Helm CLI et Chart Repo.

API gRPC

L'étape suivante est très importante : sécuriser Tiller, qui est situé dans le cluster et est, d'une part, un serveur, d'autre part, il accède lui-même à d'autres composants et essaie de se faire passer pour quelqu'un.

Comme je l'ai déjà dit, Tiller est un service qui expose gRPC, le client Helm y accède via gRPC. Par défaut, bien entendu, TLS est désactivé. Pourquoi cela a été fait est une question discutable, cela me semble simplifier la configuration au départ.

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

À mon avis, contrairement à mTLS pour les graphiques, cela est approprié ici et se fait très simplement : générer une infrastructure PQI, créer un certificat, lancer Tiller, transférer le certificat lors de l'initialisation. Après cela, 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égerez de toutes les requêtes adressées à Tiller depuis l’extérieur du cluster.

Nous avons donc sécurisé le canal de connexion à Tiller, nous avons déjà discuté de RBAC et ajusté les droits de l'apiserver Kubernetes, réduisant ainsi le domaine avec lequel il peut interagir.

Heaume protégé

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

Toutes les connexions peuvent désormais être dessinées en vert en toute sécurité :

• pour Chart Repo, nous utilisons TLS ou mTLS et l'authentification de base ;
• mTLS pour Tiller, et il est exposé en tant que service gRPC avec TLS, nous utilisons des certificats ;
• le cluster utilise un compte de service spécial avec Role et RoleBinding. 

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

"Il ne peut y avoir qu'une seule solution absolument sûre : un ordinateur éteint, situé 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 d’atteindre une norme de base de l’industrie en matière de sécurité.

prime

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

Dans le dépôt github.com/helm/charts Il existe désormais environ 300 cartes et deux flux : stable et incubateur. Tous ceux qui contribuent savent parfaitement combien il est difficile de passer de l'incubateur à l'écurie, et combien il est facile de quitter l'écurie en avion. Cependant, ce n'est pas le meilleur outil pour rechercher des cartes pour Prometheus et tout ce que vous voulez, pour une raison simple : ce n'est pas un portail où vous pouvez facilement rechercher des packages.

Mais il y a un service hub.helm.sh, ce qui rend la recherche de graphiques beaucoup plus pratique. Plus important encore, il existe de nombreux autres référentiels externes et près de 800 charms disponibles. De plus, vous pouvez connecter votre référentiel si, pour une raison quelconque, vous ne souhaitez pas envoyer vos graphiques vers stable.

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

Je voudrais également attirer votre attention sur Intégration de l'API Open Service Broker. Cela semble fastidieux et peu clair, mais cela résout les problèmes auxquels tout le monde est confronté. Laissez-moi vous expliquer avec un exemple simple.

Il existe un cluster Kubernetes dans lequel nous souhaitons exécuter une application classique – WordPress. Généralement, une base de données est nécessaire pour bénéficier de toutes les fonctionnalités. Il existe de nombreuses solutions différentes, par exemple vous pouvez lancer votre propre service avec état. Ce n'est pas très pratique, mais beaucoup de gens le font.

D'autres, comme nous chez Chainstack, utilisent des bases de données gérées comme MySQL ou PostgreSQL pour leurs serveurs. C'est pourquoi nos bases de données sont situées quelque part dans le cloud.

Mais un problème se pose : nous devons connecter notre service à une base de données, créer une version de base de données, transférer les informations d'identification et les gérer d'une manière ou d'une autre. Tout cela est généralement effectué manuellement par l'administrateur système ou le développeur. Et il n’y a aucun problème lorsqu’il y a peu de candidatures. Quand il y en a beaucoup, il faut une moissonneuse-batteuse. Il existe une telle moissonneuse - c'est Service Broker. Il vous permet d'utiliser un plugin spécial pour un cluster de cloud public et de commander des ressources auprès du fournisseur via Broker, comme s'il s'agissait d'une API. Pour ce faire, vous pouvez utiliser les outils natifs Kubernetes.

C'est très simple. Vous pouvez interroger, par exemple, Managed MySQL dans Azure avec un niveau de base (cela peut être configuré). À l’aide de l’API Azure, la base de données sera créée et préparée pour être utilisée. Vous n'avez pas besoin d'interférer avec cela, le plugin en est responsable. Par exemple, OSBA (plugin Azure) renverra les informations d'identification au service et les transmettra à Helm. Vous pourrez utiliser WordPress avec le cloud MySQL, ne pas gérer du tout les bases de données gérées et ne pas vous soucier des services avec état à l'intérieur.

On peut dire que Helm agit comme un ciment qui, d'une part, permet de déployer des services, et d'autre part, de consommer les ressources des fournisseurs de cloud.

Vous pouvez écrire votre propre plugin et utiliser toute cette histoire sur site. Vous disposerez alors simplement de votre propre plugin pour le fournisseur Cloud de l’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 préparation ou l'intégralité de l'infrastructure pour une fonctionnalité. Cela facilitera la vie de vos opérations ou de DevOps.

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

Vous n'avez besoin que de quatre commandes pour commencer à l'utiliser :

1. installez le plug-in ;
2. lancez-le ;
3. définir le chemin d'accès au bucket, qui se trouve dans gcp ;
4. publier des graphiques de la manière standard.

La beauté est que la méthode native gcp sera utilisée pour l'autorisation. Vous pouvez utiliser un compte de service, un compte développeur, comme vous le souhaitez. C'est très pratique et son fonctionnement ne coûte rien. Si, comme moi, vous promouvez la philosophie opsless, cela sera très pratique, en particulier pour les petites équipes.

Des alternatives

Helm n'est pas la seule solution de gestion de services. Il y a beaucoup de questions à ce sujet, ce qui explique probablement pourquoi la troisième version est apparue si rapidement. Bien sûr, il existe des alternatives.

Il peut s'agir de solutions spécialisées, par exemple Ksonnet ou Metaparticle. Vous pouvez utiliser vos outils classiques de gestion d’infrastructure (Ansible, Terraform, Chef, etc.) aux mêmes fins que celles dont j’ai parlé.

Il y a enfin une solution Cadre d'opérateur, dont la popularité ne cesse de croître.

Operator Framework est la meilleure alternative Helm à considérer.

Il est plus natif de CNCF et Kubernetes, mais la barrière à l'entrée est beaucoup plus élevée, vous devez programmer davantage et décrire moins les manifestes.

Il existe différents modules complémentaires, tels que Draft, Scaffold. Ils rendent la vie beaucoup plus facile, par exemple, ils simplifient le cycle d'envoi et de lancement de Helm pour les développeurs afin de déployer un environnement de test. Je les appellerais des autonomisateurs.

Voici un tableau visuel de l'endroit où tout se trouve.

Sur l'axe des x se trouve le niveau de votre contrôle personnel sur ce qui se passe, sur l'axe des y se trouve le niveau de natif de Kubernetes. La version 2 de Helm se situe quelque part au milieu. Dans la version 3, pas énormément, mais le contrôle et le niveau de natif ont été améliorés. Les solutions au niveau Ksonnet sont toujours inférieures, même à Helm 2. Cependant, elles valent la peine d'être examinées pour savoir ce qu'il y a d'autre dans ce monde. Bien entendu, votre gestionnaire de configuration sera sous votre contrôle, mais il n’est absolument pas natif de Kubernetes.

L'Operator Framework est absolument natif de Kubernetes et vous permet de le gérer de manière beaucoup plus élégante et scrupuleuse (mais n'oubliez pas le niveau d'entrée). Cela convient plutôt à une application spécialisée et à la création d'une gestion pour celle-ci, plutôt qu'à un moissonneur de masse pour empaqueter un grand nombre d'applications à l'aide de Helm.

Les extensions améliorent simplement un peu le contrôle, complètent le flux de travail ou réduisent les coûts des pipelines CI/CD.

L'avenir de Helm

La bonne nouvelle est que Helm 3 arrive. La version alpha de Helm 3.0.0-alpha.2 est déjà sortie, vous pouvez l'essayer. Il est assez stable, mais les fonctionnalités restent limitées.

Pourquoi Helm 3 ? Tout d'abord, c'est une histoire sur disparition de Tiller, en tant que composant. Ceci, comme vous l'avez déjà compris, est un énorme pas en avant, car du point de vue de la sécurité de l'architecture, tout est simplifié.

Lorsque Helm 2 a été créé, à peu près à l'époque de Kubernetes 1.8 ou même avant, de nombreux concepts étaient immatures. Par exemple, le concept CRD est désormais activement mis en œuvre et Helm utiliser CRDpour stocker des structures. Il sera possible d'utiliser uniquement la partie client et de ne pas maintenir la partie serveur. Par conséquent, utilisez les commandes Kubernetes natives pour travailler avec les structures et les ressources. C’est un énorme pas en avant.

Apparaîtra prise en charge des référentiels OCI natifs (Initiative de conteneurs ouverts). Il s'agit d'une énorme initiative, et Helm s'y intéresse principalement pour publier ses cartes. Au point que, par exemple, Docker Hub prend en charge de nombreuses normes OCI. Je ne devine pas, mais peut-être que les fournisseurs de référentiels Docker classiques commenceront à vous donner la possibilité d'héberger leurs graphiques Helm.

L'histoire controversée pour moi est Prise en charge de Lua, en tant que moteur de création de modèles pour l'écriture de scripts. Je ne suis pas un grand fan de Lua, mais ce serait une fonctionnalité totalement facultative. J'ai vérifié cela 3 fois - utiliser Lua ne sera pas nécessaire. Par conséquent, ceux qui veulent pouvoir utiliser Lua, ceux qui aiment Go, rejoignez notre immense camp et utilisez go-tmpl pour cela.

Finalement, ce qui me manquait définitivement, c'était émergence de schémas et validation des types de données. Il n'y aura plus de problèmes avec int ou string, pas besoin de mettre zéro entre guillemets doubles. Un schéma JSONS apparaîtra qui vous permettra de décrire explicitement cela pour les valeurs.

Sera fortement retravaillé modèle événementiel. Il a déjà été décrit conceptuellement. Regardez la branche Helm 3 et vous verrez combien d'événements, de hooks et d'autres éléments ont été ajoutés, ce qui simplifiera grandement et, d'autre part, ajoutera un contrôle sur les processus de déploiement et les réactions à ceux-ci.

Helm 3 sera plus simple, plus sûr et plus amusant, non pas parce que nous n'aimons pas Helm 2, mais parce que Kubernetes devient de plus en plus avancé. En conséquence, Helm peut utiliser les développements de Kubernetes et y créer d'excellents gestionnaires pour Kubernetes.

Une autre bonne nouvelle est que Conférence DevOps Alexandre Khayorov vous le dira : les conteneurs peuvent-ils être sécurisés ? Rappelons qu'à Moscou se tiendra la conférence sur l'intégration des processus de développement, de test et d'exploitation. 30 septembre et 1er octobre. Vous pouvez encore le faire jusqu'au 20 août envoyer un rapport et parlez-nous de votre expérience avec la solution un parmi beaucoup tâches de l’approche DevOps.

Suivez les points de contrôle et les actualités de la conférence sur liste de diffusion и canal de télégramme.

Source: habr.com