{"id":36918,"date":"2019-10-31T22:14:43","date_gmt":"2019-10-31T19:14:43","guid":{"rendered":"https:\/\/prohoster.info\/blog\/bezopasnost-helm\/"},"modified":"2019-10-31T22:14:43","modified_gmt":"2019-10-31T19:14:43","slug":"bezopasnost-helm","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/bezopasnost-helm","title":{"rendered":"S\u00e9curit\u00e9 de Helm","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>L'essence de l'histoire sur le gestionnaire de paquets le plus populaire pour Kubernetes pourrait \u00eatre repr\u00e9sent\u00e9e par ces \u00e9mojis :<\/p>\n<ul>\n<li>une bo\u00eete \u2014 c'est Helm (c'est ce qui convient le mieux dans la derni\u00e8re version d'Emoji);<\/li>\n<li>un cadenas \u2014 s\u00e9curit\u00e9;<\/li>\n<li>une petite figurine \u2014 la solution au probl\u00e8me.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"S\u00e9curit\u00e9 de Helm\" src=\"\/wp-content\/uploads\/2019\/08\/91099b372fd73bce94268563c3ee2c50.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEn r\u00e9alit\u00e9, tout sera un peu plus complexe, et l'histoire est pleine de d\u00e9tails techniques sur comment <b>rendre Helm s\u00e9curis\u00e9.<\/b>.<\/p>\n<ul>\n<li>En bref, qu'est-ce que Helm, si vous ne le saviez pas ou si vous l'avez oubli\u00e9. Quels probl\u00e8mes il r\u00e9sout et o\u00f9 il se situe dans l'\u00e9cosyst\u00e8me.<\/li>\n<li>Examinons l'architecture de Helm. Aucune discussion sur la s\u00e9curit\u00e9 et sur la fa\u00e7on de rendre un outil ou une solution plus s\u00e9curis\u00e9e ne peut se faire sans une compr\u00e9hension de l'architecture du composant.<\/li>\n<li>Discutons des composants de Helm.<\/li>\n<li>La question la plus pressante \u2014 l'avenir \u2014 la nouvelle version de Helm 3.\u00a0<\/li>\n<\/ul>\n<p>\nTout 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\u00e9curit\u00e9.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\n<center><div class=\"youtube-placeholder\" data-id=\"_8zNTJ1_R5I\" onclick=\"loadVideo(this)\">\r\n        <img decoding=\"async\" src=\"https:\/\/img.youtube.com\/vi\/_8zNTJ1_R5I\/hqdefault.jpg\" alt=\"Lire la vid\u00e9o\" loading=\"lazy\" width=\"480\" height=\"360\" style=\"width:100%;height:auto;\">\r\n        <div class=\"play-button\"><\/div>\r\n    <\/div><\/center><br \/>\n<strong>\u00c0 propos des intervenants :<\/strong> Alexandre Khayev (<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/users\/allexx\/\" class=\"user_link\">allexx<\/a><\/noindex>) d\u00e9veloppe depuis 10 ans, aide \u00e0 am\u00e9liorer le contenu <noindex><a rel=\"nofollow\" href=\"https:\/\/conf.python.ru\/2019\">Moscow Python Conf++<\/a><\/noindex> et a rejoint le comit\u00e9 <noindex><a rel=\"nofollow\" href=\"https:\/\/events.linuxfoundation.org\/events\/helm-summit-2019\/\">Helm Summit<\/a><\/noindex>. Il travaille actuellement chez Chainstack en tant que responsable du d\u00e9veloppement \u2014 un hybride entre un chef de d\u00e9veloppement et quelqu'un qui est responsable de la livraison des versions finales. C'est-\u00e0-dire qu'il est sur le terrain, l\u00e0 o\u00f9 tout se passe, de la cr\u00e9ation du produit \u00e0 son exploitation.<\/p>\n<p>Chainstack est une petite start-up en forte croissance, dont la mission est de permettre aux clients d'oublier l'infrastructure et les complexit\u00e9s de l'exploitation des applications d\u00e9centralis\u00e9es, l'\u00e9quipe de d\u00e9veloppement est \u00e0 Singapour. Ne demandez pas \u00e0 Chainstack de vendre ou d'acheter des cryptomonnaies, mais proposez de discuter des cadres blockchain pour les entreprises, et ils vous r\u00e9pondront avec plaisir.<\/p>\n<h2>Helm<\/h2>\n<p>\nC'est un gestionnaire de paquets (charts) pour Kubernetes. La mani\u00e8re la plus claire et universelle d'apporter des applications dans un cluster Kubernetes.<\/p>\n<p><img decoding=\"async\" alt=\"S\u00e9curit\u00e9 de Helm\" src=\"\/wp-content\/uploads\/2019\/08\/30c0fc1cc1c6ebde97c6e8ec1886ce9f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIl s'agit, bien s\u00fbr, d'une approche plus structur\u00e9e et industrielle que de cr\u00e9er ses propres manifestes YAML et d'\u00e9crire de petites utilitaires.<\/p>\n<blockquote><p>Helm est le meilleur de ce qui est actuellement disponible et populaire.<\/p><\/blockquote>\n<p>\nPourquoi Helm ? Tout d'abord, parce qu'il est soutenu par la CNCF. Cloud Native est une grande organisation, m\u00e8re des projets Kubernetes, etcd, Fluentd et d'autres.<\/p>\n<p>Un fait important, Helm est un projet tr\u00e8s populaire. En janvier 2019, lorsque j'ai commenc\u00e9 \u00e0 r\u00e9fl\u00e9chir \u00e0 comment rendre Helm s\u00e9curis\u00e9, le projet avait mille \u00e9toiles sur GitHub. En mai, cela avait atteint 12 000.<\/p>\n<p>Beaucoup s'int\u00e9ressent \u00e0 Helm, donc m\u00eame si vous ne l'utilisez pas encore, il vous sera utile de conna\u00eetre sa s\u00e9curit\u00e9. <strong>La s\u00e9curit\u00e9 est importante.<\/strong><\/p>\n<p>L'\u00e9quipe principale de Helm est soutenue par Microsoft Azure, ce qui en fait un projet assez stable compar\u00e9 \u00e0 beaucoup d'autres. La sortie de Helm 3 Alpha 2 \u00e0 la mi-juillet montre qu'il y a de nombreuses personnes travaillant sur le projet, et qu'elles ont le d\u00e9sir et les capacit\u00e9s de d\u00e9velopper et am\u00e9liorer Helm.<\/p>\n<p><img decoding=\"async\" alt=\"S\u00e9curit\u00e9 de Helm\" src=\"\/wp-content\/uploads\/2019\/08\/e53c8e64c3cf5eea3fbd9b0095b0f81e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHelm r\u00e9sout plusieurs probl\u00e8mes fondamentaux de gestion d'applications dans Kubernetes.<\/p>\n<ul>\n<li>L'emballage d'applications. M\u00eame une application simple comme \u00ab Hello, World \u00bb sur WordPress repr\u00e9sente d\u00e9j\u00e0 plusieurs services, et il est souhaitable de les regrouper.<\/li>\n<li>La gestion de la complexit\u00e9 qui \u00e9merge de la gestion de ces applications.<\/li>\n<li>Le cycle de vie qui ne se termine pas apr\u00e8s l'installation ou le d\u00e9ploiement d'une application. Elle continue de vivre, elle doit \u00eatre mise \u00e0 jour, et Helm aide \u00e0 cela en cherchant \u00e0 \u00e9tablir les bonnes mesures et politiques.<\/li>\n<\/ul>\n<p>\n<strong>L'emballage<\/strong> est organis\u00e9 de mani\u00e8re \u00e9vidente : il y a des m\u00e9tadonn\u00e9es en conformit\u00e9 avec le fonctionnement d'un gestionnaire de paquets classique pour Linux, Windows ou MacOS. C'est-\u00e0-dire un d\u00e9p\u00f4t, des d\u00e9pendances entre diff\u00e9rents paquets, des m\u00e9tainformations pour les applications, des configurations, des particularit\u00e9s de configuration, un index d'informations, etc. Tout cela Helm permet de r\u00e9cup\u00e9rer et d'utiliser pour les applications.<\/p>\n<p><strong>La gestion de la complexit\u00e9<\/strong>. Si vous avez beaucoup d'applications similaires, vous aurez besoin de param\u00e9trisation. Cela conduit aux mod\u00e8les, mais pour ne pas avoir \u00e0 inventer votre propre m\u00e9thode de cr\u00e9ation de mod\u00e8les, vous pouvez utiliser ce que Helm offre tout de suite.<\/p>\n<p><strong>La gestion du cycle de vie d'une application<\/strong> \u2014 \u00e0 mon avis, c'est la question la plus int\u00e9ressante et non r\u00e9solue. C'est pourquoi \u00e0 l'\u00e9poque, je me suis tourn\u00e9 vers Helm. Nous devions suivre le cycle de vie d'une application, nous voulions transf\u00e9rer notre CI\/CD et nos cycles d'applications dans cette paradigme.<\/p>\n<p>Helm permet de :<\/p>\n<ul>\n<li>g\u00e9rer les d\u00e9ploiements, introduit la notion de configuration et de r\u00e9vision ;<\/li>\n<li>effectuer des rollback avec succ\u00e8s ;<\/li>\n<li>utiliser des hooks pour diff\u00e9rents \u00e9v\u00e9nements ;<\/li>\n<li>ajouter des v\u00e9rifications suppl\u00e9mentaires des applications et r\u00e9agir \u00e0 leurs r\u00e9sultats.<\/li>\n<\/ul>\n<p>\nDe plus, <strong>Helm a des \u00ab batteries \u00bb<\/strong> \u2014 un grand nombre de choses d\u00e9licieuses que vous pouvez inclure sous forme de plugins, simplifiant ainsi votre vie. Les plugins peuvent \u00eatre \u00e9crits vous-m\u00eame, ils sont assez isol\u00e9s et ne n\u00e9cessitent pas une architecture complexe. Si vous voulez r\u00e9aliser quelque chose, je vous recommande de le faire sous forme de plugin, puis \u00e9ventuellement de l'inclure dans l'upstream.<\/p>\n<p>Helm repose sur trois concepts principaux :<\/p>\n<ul>\n<li><strong>Chart Repo<\/strong> \u2014 une description et un ensemble de param\u00e8tres possibles pour votre manifeste.\u00a0<\/li>\n<li><strong>Configuration<\/strong> \u2014 c'est-\u00e0-dire les valeurs qui seront appliqu\u00e9es (texte, valeurs num\u00e9riques, etc.).<\/li>\n<li><strong>Publication<\/strong> combine les deux composants sup\u00e9rieurs, et ensemble ils se transforment en Release. Les releases peuvent \u00eatre versionn\u00e9es, assurant ainsi l'organisation du cycle de vie : petite au moment de l'installation et importante au moment de la mise \u00e0 niveau, de la r\u00e9trogradation ou du retour en arri\u00e8re.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Architecture de Helm<\/h2>\n<p>\nLe sch\u00e9ma refl\u00e8te conceptuellement l'architecture de haut niveau de Helm.<\/p>\n<p><img decoding=\"async\" alt=\"S\u00e9curit\u00e9 de Helm\" src=\"\/wp-content\/uploads\/2019\/08\/c5cf54890682a3d6ca7a45021b5006a1.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nJe rappelle que Helm est li\u00e9 \u00e0 Kubernetes. Donc, nous ne pouvons pas nous passer d'un cluster Kubernetes (rectangle). Le composant kube-apiserver se trouve sur le ma\u00eetre. 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 \u2014 sur n'importe quoi.<\/p>\n<p>Mais cela ne suffit pas. Helm a un composant serveur, Tiller. Il repr\u00e9sente les int\u00e9r\u00eats de Helm au sein du cluster, c'est une application \u00e0 l'int\u00e9rieur du cluster Kubernetes, tout comme n'importe quelle autre.<\/p>\n<p>Le composant suivant, Chart Repo, est un d\u00e9p\u00f4t de charts. Il existe un d\u00e9p\u00f4t officiel et il peut y avoir un d\u00e9p\u00f4t priv\u00e9 d'entreprise ou de projet.<\/p>\n<h3>Interaction<\/h3>\n<p>\nVoyons comment les composants de l'architecture interagissent lorsque nous voulons installer une application avec Helm.<\/p>\n<ul>\n<li>Nous disons <code>Helm install<\/code>, nous nous adressons au d\u00e9p\u00f4t (Chart Repo) et obtenons le chart Helm.<\/li>\n<\/ul>\n<p><\/p>\n<ul>\n<li>L'outil Helm (Helm CLI) interagit avec Kubeconfig pour d\u00e9terminer \u00e0 quel cluster s'adresser.\u00a0<\/li>\n<li>Une fois cette information obtenue, l'outil s'adresse \u00e0 Tiller, qui se trouve dans notre cluster, en tant qu'application.\u00a0<\/li>\n<li>Tiller interroge le Kube-apiserver pour effectuer des actions dans Kubernetes, cr\u00e9er des objets (services, pods, r\u00e9pliques, secrets, etc.).<\/li>\n<\/ul>\n<p>\nEnsuite, nous compliquerons le sch\u00e9ma pour voir les vecteurs d'attaque auxquels l'ensemble de l'architecture Helm peut \u00eatre expos\u00e9. Puis nous essaierons de le prot\u00e9ger.<\/p>\n<h3>Vecteur d'attaque<\/h3>\n<p>\nLe premier point potentiellement faible est \u2014 <strong>l'API privil\u00e9gi\u00e9e<\/strong>\u2014<strong>utilisateur<\/strong>. Dans le cadre du sch\u00e9ma, c'est un hacker ayant obtenu un acc\u00e8s administrateur au Helm CLI.<\/p>\n<p><strong>Utilisateur API non privil\u00e9gi\u00e9<\/strong> peut \u00e9galement repr\u00e9senter un danger s'il se trouve \u00e0 proximit\u00e9. Cet utilisateur aura un autre contexte, par exemple, il peut \u00eatre enregistr\u00e9 dans un namespace du cluster dans les param\u00e8tres de Kubeconfig.<\/p>\n<p>Le vecteur d'attaque le plus int\u00e9ressant pourrait \u00eatre un processus qui se trouve \u00e0 l'int\u00e9rieur du cluster, pr\u00e8s de Tiller, et qui peut y acc\u00e9der. Cela pourrait \u00eatre un serveur web ou un microservice qui voit l'environnement r\u00e9seau du cluster.<\/p>\n<p>Une variante exotique mais de plus en plus populaire d'attaque est li\u00e9e au Chart Repo. Un chart cr\u00e9\u00e9 par un auteur malintentionn\u00e9 peut contenir une ressource non s\u00e9curis\u00e9e, et vous l'ex\u00e9cuterez en faisant confiance. Ou il peut remplacer le chart que vous t\u00e9l\u00e9chargez depuis le d\u00e9p\u00f4t officiel et, par exemple, cr\u00e9er une ressource sous forme de politiques et s'escalader l'acc\u00e8s.<\/p>\n<p><img decoding=\"async\" alt=\"S\u00e9curit\u00e9 de Helm\" src=\"\/wp-content\/uploads\/2019\/08\/2828046feb9ba8413a1b0e8741b4c354.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEssayons de nous d\u00e9fendre contre ces attaques venant de ces quatre angles et de comprendre o\u00f9 se trouvent les probl\u00e8mes dans l'architecture de Helm, et o\u00f9 il n'y en a peut-\u00eatre pas.<\/p>\n<p>Consolidons le sch\u00e9ma, ajoutons plus d'\u00e9l\u00e9ments, mais gardons tous les composants de base.<\/p>\n<p><img decoding=\"async\" alt=\"S\u00e9curit\u00e9 de Helm\" src=\"\/wp-content\/uploads\/2019\/08\/4110898e79619b8546408c668c48da0d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLe Helm CLI communique avec le Chart Repo, interagit avec Kubeconfig, et le travail est transmis au cluster dans le composant Tiller.<\/p>\n<p>Tiller est repr\u00e9sent\u00e9 par deux objets :<\/p>\n<ul>\n<li>Le service Tiller-deploy, qui expose un certain service ;<\/li>\n<li>Le pod Tiller-deploy (dans le sch\u00e9ma, en un seul exemplaire dans une r\u00e9plique), qui g\u00e8re tout le travail et qui interroge le cluster.<\/li>\n<\/ul>\n<p>\nDiff\u00e9rents protocoles et sch\u00e9mas sont utilis\u00e9s pour l'interaction. Du point de vue de la s\u00e9curit\u00e9, ce qui nous int\u00e9resse le plus est :<\/p>\n<ul>\n<li>Le m\u00e9canisme par lequel le Helm CLI interroge le chart repo : quel protocole, y a-t-il une authentification et que peut-on en faire.<\/li>\n<li>Le protocole selon lequel le Helm CLI, en utilisant kubectl, communique avec Tiller. Il s'agit d'un serveur RPC install\u00e9 \u00e0 l'int\u00e9rieur du cluster.<\/li>\n<li>Tiller lui-m\u00eame est accessible aux microservices qui se trouvent dans le cluster et interagit avec le Kube-apiserver.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"S\u00e9curit\u00e9 de Helm\" src=\"\/wp-content\/uploads\/2019\/08\/19e7e085567f3bbb49746e6402926bd6.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDiscutons de toutes ces directions dans l'ordre.<\/p>\n<h2>RBAC<\/h2>\n<p><\/p>\n<blockquote><p>Il est inutile de parler de s\u00e9curit\u00e9 dans Helm ou d'un autre service \u00e0 l'int\u00e9rieur du cluster sans avoir activ\u00e9 RBAC.<\/p><\/blockquote>\n<p>\nIl semble que ce ne soit pas la recommandation la plus r\u00e9cente, mais je suis certain que beaucoup n'ont toujours pas activ\u00e9 RBAC m\u00eame en production, car cela demande beaucoup de travail et n\u00e9cessite de nombreuses configurations. N\u00e9anmoins, je vous encourage \u00e0 le faire.<\/p>\n<p><img decoding=\"async\" alt=\"S\u00e9curit\u00e9 de Helm\" src=\"\/wp-content\/uploads\/2019\/08\/37ee8aeb2b331b75ea5569c0b114a756.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/rbac.dev\/\">https:\/\/rbac.dev\/<\/a><\/noindex> \u2014 un site d'avocat pour RBAC. Il rassemble une \u00e9norme quantit\u00e9 de mat\u00e9riaux int\u00e9ressants qui aideront \u00e0 configurer RBAC, montreront pourquoi il est bon et comment vivre avec en production.<\/p>\n<p>Je vais essayer d'expliquer comment fonctionne Tiller et RBAC. Tiller fonctionne \u00e0 l'int\u00e9rieur du cluster sous un certain compte de service. En g\u00e9n\u00e9ral, si RBAC n'est pas configur\u00e9, 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\u00e9alit\u00e9, c'est le cas, donc vous pouvez utiliser un compte de service sp\u00e9cialis\u00e9 au lieu du compte de service par d\u00e9faut dans le sch\u00e9ma ci-dessus.<\/p>\n<p>Lorsque vous initialisez Helm, que vous l'installez pour la premi\u00e8re fois sur le serveur, vous pouvez d\u00e9finir un compte de service \u00e0 l'aide de <code>--service-account<\/code>. Cela permettra d'utiliser un utilisateur avec le minimum de droits n\u00e9cessaires. Cependant, vous devrez cr\u00e9er cette \u00ab guirlande \u00bb : Role et RoleBinding.<\/p>\n<p><img decoding=\"async\" alt=\"S\u00e9curit\u00e9 de Helm\" src=\"\/wp-content\/uploads\/2019\/08\/ec805cde756495cfd5c480ac40739c43.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nMalheureusement, Helm ne le fera pas pour vous. Vous ou votre administrateur de cluster Kubernetes devez pr\u00e9parer \u00e0 l'avance un ensemble de Role et RoleBinding pour le compte de service \u00e0 transmettre \u00e0 Helm.<\/p>\n<p>La question se pose \u2014 quelle est la diff\u00e9rence entre Role et ClusterRole ? La diff\u00e9rence est que ClusterRole s'applique \u00e0 tous les namespaces, contrairement aux r\u00f4les et liaison de r\u00f4le normaux, qui ne fonctionnent que pour un namespace sp\u00e9cialis\u00e9. Vous pouvez configurer des politiques \u00e0 la fois pour l'ensemble du cluster et tous les namespaces, ainsi que de mani\u00e8re personnalis\u00e9e pour chaque namespace individuellement.<\/p>\n<p>Il convient de mentionner que RBAC permet de r\u00e9soudre un autre gros probl\u00e8me. Beaucoup se plaignent que Helm, malheureusement, n'est pas multitenancy (ne prend pas en charge la multi-location). Si plusieurs \u00e9quipes consomment le cluster et utilisent Helm, il est impossible de configurer des politiques et de restreindre leur acc\u00e8s dans ce cluster, car il y a un certain compte de service sous lequel Helm fonctionne, et il cr\u00e9e toutes les ressources dans le cluster \u00e0 partir de celui-ci, ce qui est parfois tr\u00e8s g\u00eanant. C'est vrai \u2014 en tant que fichier binaire, en tant que processus, <strong>Helm Tiller n'a pas de notion de multitenancy.<\/strong>.<\/p>\n<p>Cependant, il existe un excellent moyen qui permet de lancer Tiller dans le cluster plusieurs fois. Il n'y a aucun probl\u00e8me \u00e0 cela, Tiller peut \u00eatre lanc\u00e9 dans chaque namespace. Ainsi, vous pouvez profiter de RBAC, Kubeconfig comme contexte, et restreindre l'acc\u00e8s \u00e0 un Helm sp\u00e9cial.<\/p>\n<p>Cela ressemblera \u00e0 ce qui suit.<\/p>\n<p><img decoding=\"async\" alt=\"S\u00e9curit\u00e9 de Helm\" src=\"\/wp-content\/uploads\/2019\/08\/eae922c7b5e1422fb51667364ed79e0a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPar exemple, il existe deux Kubeconfig avec des contextes pour diff\u00e9rentes \u00e9quipes (deux namespaces): \u00c9quipe X pour l\u2019\u00e9quipe de d\u00e9veloppement et un cluster pour l\u2019administrateur. Le cluster de l'administrateur dispose de son propre Tiller large, situ\u00e9 dans l\u2019espace Kube-system namespace, avec un service-account avanc\u00e9. Et un namespace distinct pour l\u2019\u00e9quipe des d\u00e9veloppeurs, qui pourront d\u00e9ployer leurs services dans un namespace sp\u00e9cial.<\/p>\n<p>C'est une approche fonctionnelle, Tiller n'est pas si gourmand, donc cela ne devrait pas affecter votre budget de mani\u00e8re significative. C'est l'une des solutions rapides.<\/p>\n<blockquote><p>N'h\u00e9sitez pas \u00e0 configurer Tiller s\u00e9par\u00e9ment et \u00e0 fournir Kubeconfig avec un contexte pour l'\u00e9quipe, pour un d\u00e9veloppeur sp\u00e9cifique ou pour des environnements: Dev, Staging, Production (il est peu probable que tout soit sur un seul cluster, mais c'est possible).<\/p><\/blockquote>\n<p>\nEn poursuivant notre histoire, passons de RBAC \u00e0 ConfigMaps.<\/p>\n<h3>ConfigMaps<\/h3>\n<p>\nHelm utilise des ConfigMaps comme stockage de donn\u00e9es. Lorsque nous parlions d'architecture, il n'y avait pas de base de donn\u00e9es contenant des informations sur les releases, configurations, rollbacks, etc. Pour cela, nous utilisons des ConfigMaps.<\/p>\n<p>Le principal probl\u00e8me avec les ConfigMaps est bien connu \u2014 elles ne sont pas s\u00e9curis\u00e9es par principe, elles <strong>ne peuvent pas stocker de donn\u00e9es sensibles<\/strong>. Cela concerne tout ce qui ne doit pas \u00eatre divulgu\u00e9 au-del\u00e0 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.<\/p>\n<p>C'est tr\u00e8s simple \u00e0 faire. Vous red\u00e9finissez la configuration de Tiller et indiquez que le stockage sera des secrets. Ainsi, \u00e0 chaque d\u00e9ploiement, vous obtiendrez non pas un ConfigMap, mais un secret.<\/p>\n<p><img decoding=\"async\" alt=\"S\u00e9curit\u00e9 de Helm\" src=\"\/wp-content\/uploads\/2019\/08\/7fd12bfbed5c6c8111a5126c2ab9f853.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nVous pourriez argumenter que les secrets eux-m\u00eames sont un concept \u00e9trange, et que ce n'est pas tr\u00e8s s\u00fbr. Cependant, il est important de comprendre que cela est g\u00e9r\u00e9 par les d\u00e9veloppeurs de Kubernetes eux-m\u00eames. Depuis la version 1.10, c'est-\u00e0-dire il y a un certain temps, il est possible, au moins dans les cloud publics, de connecter un stockage appropri\u00e9 pour les secrets. L'\u00e9quipe travaille actuellement \u00e0 am\u00e9liorer encore l'acc\u00e8s aux secrets, pour des pods ou d'autres entit\u00e9s sp\u00e9cifiques.<\/p>\n<blockquote><p>Il est pr\u00e9f\u00e9rable de passer le stockage Helm aux secrets, et de les s\u00e9curiser de mani\u00e8re centralis\u00e9e.<\/p><\/blockquote>\n<p>\nBien s\u00fbr, il restera <strong>une limite de stockage de donn\u00e9es de 1 Mo<\/strong>. Helm utilise ici etcd comme stockage distribu\u00e9 pour ConfigMaps. Et l\u00e0-bas, ils ont d\u00e9cid\u00e9 que c'\u00e9tait un chunk de donn\u00e9es appropri\u00e9 pour les r\u00e9pliques, etc. \u00c0 ce sujet, il y a une discussion int\u00e9ressante sur Reddit, je recommande de trouver cette lecture amusante pour le week-end ou de lire le r\u00e9sum\u00e9. <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/helm\/helm\/issues\/1413\">ici<\/a><\/noindex>.<\/p>\n<h3>D\u00e9p\u00f4ts de chartes<\/h3>\n<p>\nLes chartes sont particuli\u00e8rement vuln\u00e9rables et peuvent devenir une source d'attaque de type \u00ab homme du milieu \u00bb, surtout si une solution par d\u00e9faut est utilis\u00e9e. Cela concerne principalement les d\u00e9p\u00f4ts accessibles par HTTP.<\/p>\n<blockquote><p>Il est certain que le d\u00e9p\u00f4t Helm doit \u00eatre expos\u00e9 via HTTPS \u2014 c'est la meilleure option et cela ne co\u00fbte pas cher.<\/p><\/blockquote>\n<p>\nVeuillez noter que <strong>m\u00e9canisme de signature des chartes<\/strong>. La technologie est d'une simplicit\u00e9 d\u00e9concertante. C'est la m\u00eame chose que vous utilisez sur GitHub, une machine PGP classique avec des cl\u00e9s publiques et priv\u00e9es. Configurez-le et vous serez en s\u00e9curit\u00e9, en ayant les bonnes cl\u00e9s et en signant tout pour prouver que c'est bien votre charte.<\/p>\n<p>De plus, <strong>Le client Helm supporte TLS<\/strong> (pas dans le sens HTTP c\u00f4t\u00e9 serveur, mais TLS mutuel). Vous pouvez utiliser des cl\u00e9s serveur et client pour communiquer. Pour \u00eatre honn\u00eate, je n'utilise pas ce m\u00e9canisme \u00e0 cause de mon aversion pour les certificats mutuels. En principe, <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/helm\/chartmuseum\">chartmuseum<\/a><\/noindex> \u2014 l'outil principal pour exposer un d\u00e9p\u00f4t Helm pour Helm 2 \u2014 prend \u00e9galement en charge l'authentification de base. Vous pouvez utiliser l'authentification de base si cela est plus pratique et rassurant.<\/p>\n<p>Il existe aussi un plugin <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/hayorov\/helm-gcs\">helm-gcs<\/a><\/noindex>, qui permet d'h\u00e9berger des d\u00e9p\u00f4ts de chartes dans Google Cloud Storage. C'est assez pratique, \u00e7a fonctionne tr\u00e8s bien et c'est suffisamment s\u00e9curis\u00e9, car tous les m\u00e9canismes d\u00e9crits sont utilis\u00e9s.<\/p>\n<p><img decoding=\"async\" alt=\"S\u00e9curit\u00e9 de Helm\" src=\"\/wp-content\/uploads\/2019\/08\/6a72bfd96c7eb0e2fdd7bcbf128e6433.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSi vous activez HTTPS ou TLS, utilisez mTLS, ajoutez l'authentification de base pour r\u00e9duire davantage les risques, vous obtiendrez un canal de communication s\u00e9curis\u00e9 entre Helm CLI et le d\u00e9p\u00f4t de chartes.<\/p>\n<h3>API gRPC<\/h3>\n<p>\nL'\u00e9tape suivante est tr\u00e8s importante \u2014 s\u00e9curiser Tiller, qui se trouve dans le cluster et qui est, d'une part, le serveur, et d'autre part \u2014 il interagit avec d'autres composants et essaie de se faire passer pour quelqu'un d'autre.<\/p>\n<p>Comme je l'ai d\u00e9j\u00e0 dit, Tiller est un service qui expose gRPC, le client Helm se connecte \u00e0 lui via gRPC. Par d\u00e9faut, il va sans dire que TLS est d\u00e9sactiv\u00e9. La raison pour laquelle c'est fait est une question de d\u00e9bat, je pense que c'est pour simplifier la configuration au d\u00e9marrage.<\/p>\n<blockquote><p>Pour la production et m\u00eame pour la mise en sc\u00e8ne, je recommande d'activer TLS sur gRPC.<\/p><\/blockquote>\n<p>\n\u00c0 mon avis, contrairement \u00e0 mTLS pour les charts, ici c'est appropri\u00e9 et se fait tr\u00e8s simplement \u2014 vous g\u00e9n\u00e9rez l'infrastructure PQI, cr\u00e9ez un certificat, lancez Tiller, et passez le certificat lors de l'initialisation. Ensuite, vous pouvez ex\u00e9cuter toutes les commandes Helm en vous pr\u00e9sentant avec le certificat g\u00e9n\u00e9r\u00e9 et la cl\u00e9 priv\u00e9e.<\/p>\n<p><img decoding=\"async\" alt=\"S\u00e9curit\u00e9 de Helm\" src=\"\/wp-content\/uploads\/2019\/08\/ed55b9a465ed1278b272c52c90b2b345.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDe cette fa\u00e7on, vous vous prot\u00e9gez contre toutes les demandes \u00e0 Tiller provenant de l'ext\u00e9rieur du cluster.<\/p>\n<p>Ainsi, nous avons s\u00e9curis\u00e9 le canal de connexion \u00e0 Tiller, d\u00e9j\u00e0 discut\u00e9 du RBAC et r\u00e9gl\u00e9 les droits du Kubernetes apiserver, r\u00e9duit le domaine avec lequel il peut interagir.<\/p>\n<h2>Helm s\u00e9curis\u00e9<\/h2>\n<p>\nRegardons le sch\u00e9ma final. C'est la m\u00eame architecture avec les m\u00eames fl\u00e8ches.<\/p>\n<p><img decoding=\"async\" alt=\"S\u00e9curit\u00e9 de Helm\" src=\"\/wp-content\/uploads\/2019\/08\/6672e254ad93b917f57794e1619a572e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nToutes les connexions peuvent maintenant \u00eatre dessin\u00e9es en vert :<\/p>\n<ul>\n<li>pour le Chart Repo, nous utilisons TLS ou mTLS et l'authentification de base ;<\/li>\n<li>mTLS pour Tiller, et il est expos\u00e9 comme un service gRPC avec TLS, nous utilisons des certificats ;<\/li>\n<li>dans le cluster, un compte de service sp\u00e9cial avec un r\u00f4le et un RoleBinding est utilis\u00e9.\u00a0<\/li>\n<\/ul>\n<p>\nNous avons consid\u00e9rablement s\u00e9curis\u00e9 le cluster, mais quelqu'un d'intelligent a dit :<\/p>\n<blockquote><p>\u00ab La seule solution absolument s\u00e9curis\u00e9e peut \u00eatre un ordinateur \u00e9teint, enferm\u00e9 dans une bo\u00eete en b\u00e9ton et gard\u00e9 par des soldats \u00bb.<\/p><\/blockquote>\n<p>\nIl existe diff\u00e9rentes mani\u00e8res de manipuler les donn\u00e9es et de trouver de nouveaux vecteurs d'attaque. Cependant, je suis convaincu que ces recommandations permettront de mettre en \u0153uvre un standard de s\u00e9curit\u00e9 industriel de base.<\/p>\n<h2>Bonus<\/h2>\n<p>\nCette partie n'est pas directement li\u00e9e \u00e0 la s\u00e9curit\u00e9, mais sera \u00e9galement utile. Je vais montrer certaines choses int\u00e9ressantes que peu de gens connaissent. Par exemple, comment rechercher des charts \u2014 officiels et non officiels.<\/p>\n<p>Dans le r\u00e9f\u00e9rentiel <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/helm\/charts\">github.com\/helm\/charts<\/a><\/noindex> il y a maintenant environ 300 charts et deux flux : stable et incubator. Ceux qui contribuent savent tr\u00e8s bien \u00e0 quel point il est difficile de passer de l'incubator au stable, et \u00e0 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\u00f9 il est facile de rechercher des paquets.<\/p>\n<p>Mais il existe un service <noindex><a rel=\"nofollow\" href=\"https:\/\/hub.helm.sh\/\">hub.helm.sh<\/a><\/noindex>, qui rend la recherche de charts beaucoup plus pratique. Le plus important, c'est qu'il y a beaucoup plus de d\u00e9p\u00f4ts externes et presque 800 charts disponibles. De plus, vous pouvez connecter votre propre d\u00e9p\u00f4t si, pour une raison quelconque, vous ne souhaitez pas envoyer vos charts dans le stable.<\/p>\n<p>Essayez hub.helm.sh et d\u00e9veloppons-le ensemble. Ce service est sous le projet Helm, et vous pouvez m\u00eame contribuer \u00e0 son interface utilisateur si vous \u00eates un d\u00e9veloppeur front-end et souhaitez simplement am\u00e9liorer son apparence.<\/p>\n<p>Je souhaite \u00e9galement attirer votre attention sur <strong>l'int\u00e9gration de l'API Open Service Broker<\/strong>. Cela peut sembler encombrant et incompr\u00e9hensible, mais cela r\u00e9sout des probl\u00e8mes auxquels tout le monde est confront\u00e9. Je vais l'expliquer avec un exemple simple.<\/p>\n<p><img decoding=\"async\" alt=\"S\u00e9curit\u00e9 de Helm\" src=\"\/wp-content\/uploads\/2019\/08\/3aeb7e0781e50a79b518f1056873f73a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nImaginons un cluster Kubernetes dans lequel nous voulons d\u00e9ployer une application classique \u2014 WordPress. En g\u00e9n\u00e9ral, une base de donn\u00e9es est n\u00e9cessaire pour un fonctionnement complet. Il existe de nombreuses solutions, par exemple, vous pouvez lancer votre propre service stateful. Ce n'est pas tr\u00e8s pratique, mais beaucoup font ainsi.<\/p>\n<p>D'autres, comme nous chez Chainstack, utilisent des bases de donn\u00e9es g\u00e9r\u00e9es, comme MySQL ou PostgreSQL, pour les serveurs. Donc, notre base de donn\u00e9es se trouve quelque part dans le cloud.<\/p>\n<p>Mais un probl\u00e8me se pose : il faut lier notre service \u00e0 la base de donn\u00e9es, cr\u00e9er un flavor de base de donn\u00e9es, transmettre les informations d'identification et les g\u00e9rer d'une certaine mani\u00e8re. Tout cela est g\u00e9n\u00e9ralement fait manuellement par un administrateur syst\u00e8me ou un d\u00e9veloppeur. Cela ne pose pas de probl\u00e8me quand il y a peu d'applications. Lorsqu'il y en a beaucoup, il faut un combineur. Ce combineur existe \u2014 c'est le Service Broker. Il permet d'utiliser un plugin sp\u00e9cial sur le cluster de cloud public et de commander des ressources aupr\u00e8s du fournisseur par le biais du Broker, comme si c'\u00e9tait une API. Pour cela, vous pouvez utiliser les outils natifs de Kubernetes.<\/p>\n<p>C'est tr\u00e8s simple. Vous pouvez par exemple demander un Managed MySQL sur Azure avec un niveau de service de base (cela peut \u00eatre configur\u00e9). En utilisant l'API Azure, la base sera cr\u00e9\u00e9e et pr\u00e9par\u00e9e \u00e0 l'utilisation. Vous n'aurez pas besoin de vous en m\u00ealer, 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\u00e9es g\u00e9r\u00e9es et sans vous soucier des services stateful en arri\u00e8re-plan.<\/p>\n<blockquote><p>On peut dire que Helm est la colle qui, d'un c\u00f4t\u00e9, permet de d\u00e9ployer des services et, de l'autre, de consommer des ressources des fournisseurs de cloud.<\/p><\/blockquote>\n<p>\nVous pouvez \u00e9crire 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 \u00e9chelle et que vous souhaitez d\u00e9ployer rapidement le d\u00e9veloppement, la mise en sc\u00e8ne ou l'ensemble de l'infrastructure pour une fonctionnalit\u00e9. Cela simplifiera la vie de vos op\u00e9rations ou de votre \u00e9quipe DevOps.<\/p>\n<p>Une autre d\u00e9couverte que j'ai d\u00e9j\u00e0 mentionn\u00e9e \u2014 c'est <strong>le plugin helm-gcs<\/strong>, qui permet d'utiliser des Google-buckets (stockage d'objets) pour stocker des charts Helm.<\/p>\n<p><img decoding=\"async\" alt=\"S\u00e9curit\u00e9 de Helm\" src=\"\/wp-content\/uploads\/2019\/08\/30888c4f9b5dba14b87ba1e29e0ebed7.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIl vous suffit de quatre commandes pour commencer \u00e0 l'utiliser :<\/p>\n<ol>\n<li>installer le plugin ;<\/li>\n<li>l'initialiser ;<\/li>\n<li>d\u00e9finir le chemin vers le bucket situ\u00e9 dans gcp ;<\/li>\n<li>publier les charts de mani\u00e8re standard.<\/li>\n<\/ol>\n<p>\nL'avantage est que la m\u00e9thode d'autorisation native de gcp sera utilis\u00e9e. Vous pouvez utiliser un compte de service, un compte d\u00e9veloppeur \u2014 tout ce que vous voulez. C'est tr\u00e8s pratique et cela ne co\u00fbte rien en exploitation. Si vous, comme moi, d\u00e9fendez la philosophie sans ops, cela sera tr\u00e8s commode, surtout pour les petites \u00e9quipes.<\/p>\n<h2>Alternatives<\/h2>\n<p>\nHelm n'est pas la seule solution pour g\u00e9rer des services. De nombreuses questions se posent \u00e0 son sujet, c'est probablement pour cela que la troisi\u00e8me version est apparue si rapidement. Bien s\u00fbr, il existe des alternatives.<\/p>\n<p>Il peut s'agir de solutions sp\u00e9cialis\u00e9es comme Ksonnet ou Metaparticle. Vous pouvez utiliser vos outils classiques de gestion d'infrastructure (Ansible, Terraform, Chef, etc.) pour les m\u00eames objectifs dont j'ai parl\u00e9.<\/p>\n<p>Enfin, il existe une solution <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/operator-framework\">Operator Framework<\/a><\/noindex>, dont la popularit\u00e9 est en croissance.<\/p>\n<blockquote><p>L'Operator Framework est la principale alternative \u00e0 Helm \u00e0 laquelle il faut pr\u00eater attention.<\/p><\/blockquote>\n<p>\nIl est plus natif pour CNCF et Kubernetes, <strong>mais la barri\u00e8re d'entr\u00e9e est beaucoup plus \u00e9lev\u00e9e<\/strong>, il faut programmer davantage et moins d\u00e9crire des manifestes.<\/p>\n<p>Il existe diff\u00e9rents addons, comme Draft et Scaffold. Ils simplifient beaucoup la vie, par exemple, en facilitant aux d\u00e9veloppeurs le cycle d'envoi et de lancement de Helm pour d\u00e9ployer un environnement de test. Je les appellerais des enrichisseurs de capacit\u00e9s.<\/p>\n<p>Voici un graphique illustratif montrant o\u00f9 se trouve chaque \u00e9l\u00e9ment.<\/p>\n<p><img decoding=\"async\" alt=\"S\u00e9curit\u00e9 de Helm\" src=\"\/wp-content\/uploads\/2019\/08\/81a8236c975d5e1649acaaa7989c27ba.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSur l'axe des abscisses, le niveau de votre contr\u00f4le personnel sur ce qui se passe, sur l'axe des ordonn\u00e9es \u2014 le niveau de nativit\u00e9 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\u00f4le que le niveau de nativit\u00e9 ont \u00e9t\u00e9 am\u00e9lior\u00e9s. Les solutions de niveau Ksonnet restent malgr\u00e9 tout inf\u00e9rieures \u00e0 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\u00f4le, mais il n'est absolument pas natif pour Kubernetes.<\/p>\n<p>L'Operator Framework est compl\u00e8tement natif pour Kubernetes et permet de le g\u00e9rer de mani\u00e8re beaucoup plus \u00e9l\u00e9gante et minutieuse (mais rappelons-nous du niveau d'entr\u00e9e). Il conviendra plut\u00f4t \u00e0 une application sp\u00e9cialis\u00e9e et \u00e0 la cr\u00e9ation de gestion \u00e0 son \u00e9gard, plut\u00f4t qu'\u00e0 un broyeur de masse pour emballer un grand nombre d'applications \u00e0 l'aide de Helm.<\/p>\n<p>Les enrichisseurs am\u00e9liorent juste un peu le contr\u00f4le, compl\u00e8tent le workflow ou prennent des raccourcis dans les pipelines CI\/CD.<\/p>\n<h2>L'avenir de Helm<\/h2>\n<p>\nLa bonne nouvelle, c'est qu'Helm 3 arrive. La version alpha d'Helm 3.0.0-alpha.2 est d\u00e9j\u00e0 sortie, et vous pouvez l'essayer. Elle est assez stable, mais ses fonctionnalit\u00e9s sont encore limit\u00e9es.<\/p>\n<p>Pourquoi Helm 3 est-il n\u00e9cessaire ? Avant tout, il s'agit de <strong>la disparition de Tiller<\/strong>, en tant que composant. Comme vous le comprenez d\u00e9j\u00e0, c'est un grand pas en avant, car cela simplifie l'architecture du point de vue de la s\u00e9curit\u00e9.<\/p>\n<p>Lorsque Helm 2 a \u00e9t\u00e9 cr\u00e9\u00e9, \u00e0 l'\u00e9poque de Kubernetes 1.8 ou m\u00eame plus t\u00f4t, de nombreux concepts \u00e9taient immatures. Par exemple, le concept de CRD est maintenant largement int\u00e9gr\u00e9, et Helm va <strong>utiliser CRD<\/strong>, pour stocker des structures. Il sera possible d'utiliser uniquement le client sans avoir \u00e0 maintenir la partie serveur. En cons\u00e9quence, il sera possible d'utiliser les commandes natives de Kubernetes pour travailler avec des structures et des ressources. Cela repr\u00e9sente un \u00e9norme progr\u00e8s.<\/p>\n<p>Il y aura <strong>le support des d\u00e9p\u00f4ts OCI natifs<\/strong> (Open Container Initiative). C'est une initiative majeure, et Helm y trouve un int\u00e9r\u00eat surtout pour h\u00e9berger ses charts. \u00c0 tel point que, par exemple, Docker Hub prend en charge de nombreuses normes OCI. Je ne pr\u00e9dis rien, mais il est possible que les fournisseurs classiques de d\u00e9p\u00f4ts Docker commencent \u00e0 vous permettre d'h\u00e9berger vos charts Helm.<\/p>\n<p>Un aspect discutable pour moi est <strong>le support de Lua<\/strong>, en tant que moteur de templating pour \u00e9crire des scripts. Je ne suis pas un grand fan de Lua, mais cela sera une option enti\u00e8rement facultative. J'ai v\u00e9rifi\u00e9 trois fois \u2014 l'utilisation de Lua ne sera pas obligatoire. Donc, ceux qui le souhaitent pourront utiliser Lua, ceux qui pr\u00e9f\u00e8rent Go \u2014 rejoignez notre grand camp et utilisez go-tmpl pour cela.<\/p>\n<p>Enfin, ce qui me manquait vraiment, c'est <strong>l'apparition de sch\u00e9mas et la validation des types de donn\u00e9es<\/strong>. Il n'y aura plus de probl\u00e8mes avec int ou string, il ne faudra plus envelopper z\u00e9ro entre guillemets. Une JSON Schema appara\u00eetra, ce qui permettra de d\u00e9crire cela clairement pour les valeurs.<\/p>\n<p>Le mod\u00e8le <strong>orient\u00e9 \u00e9v\u00e9nements<\/strong>sera fortement retravaill\u00e9. Il est d\u00e9j\u00e0 conceptuellement d\u00e9crit. Regardez dans la branche Helm 3, et vous verrez combien d'\u00e9v\u00e9nements et de hooks ont \u00e9t\u00e9 ajout\u00e9s, ce qui simplifiera consid\u00e9rablement et, d'un autre c\u00f4t\u00e9, ajoutera du contr\u00f4le sur les processus de d\u00e9ploiement et leurs r\u00e9actions.<\/p>\n<p>Helm 3 sera plus simple, plus s\u00fbr et plus int\u00e9ressant, non pas parce que nous n'aimons pas Helm 2, mais parce que Kubernetes devient plus avanc\u00e9. En cons\u00e9quence, Helm peut s'appuyer sur les am\u00e9liorations de Kubernetes et cr\u00e9er d'excellents gestionnaires pour Kubernetes.<\/p>\n<blockquote><p>Une autre bonne nouvelle est que <noindex><a rel=\"nofollow\" href=\"https:\/\/devopsconf.io\/moscow\/2019\">DevOpsConf<\/a><\/noindex> Alexandre Khayorov expliquera, <noindex><a rel=\"nofollow\" href=\"https:\/\/devopsconf.io\/moscow\/2019\/abstracts\/5564\">les conteneurs peuvent-ils \u00eatre s\u00fbrs ?<\/a><\/noindex> Rappelons que la conf\u00e9rence sur l'int\u00e9gration des processus de d\u00e9veloppement, de test et d'exploitation se tiendra \u00e0 Moscou <strong>les 30 septembre et 1er octobre<\/strong>. Vous avez jusqu'au 20 ao\u00fbt pour <noindex><a rel=\"nofollow\" href=\"https:\/\/conf.ontico.ru\/lectures\/propose\/?conference=dc2019-moscow\">soumettre une pr\u00e9sentation<\/a><\/noindex> partager votre exp\u00e9rience de r\u00e9solution <noindex><a rel=\"nofollow\" href=\"https:\/\/devopsconf.io\/moscow\/2019\/articles\/917\">l'une des nombreuses<\/a><\/noindex> probl\u00e9matiques de l'approche DevOps.<\/p>\n<p>Pour les mises \u00e0 jour de la conf\u00e9rence et les nouvelles, suivez-nous sur le <noindex><a rel=\"nofollow\" href=\"http:\/\/eepurl.com\/bN_0E1\">une newsletter<\/a><\/noindex> et <noindex><a rel=\"nofollow\" href=\"https:\/\/t.me\/DevOpsConfChannel\">canal Telegram<\/a><\/noindex>.<\/p><\/blockquote>\n<p>Source : <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/oleg-bunin\/blog\/462665\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0421\u0443\u0442\u044c \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430 \u043e \u0441\u0430\u043c\u043e\u043c \u043f\u043e\u043f\u0443\u043b\u044f\u0440\u043d\u043e\u043c \u043f\u0430\u043a\u0435\u0442\u043d\u043e\u043c \u043c\u0435\u043d\u0435\u0434\u0436\u0435\u0440\u0435 \u0434\u043b\u044f Kubernetes \u043c\u043e\u0436\u043d\u043e \u0431\u044b\u043b\u043e \u0431\u044b \u0438\u0437\u043e\u0431\u0440\u0430\u0437\u0438\u0442\u044c \u0441 \u043f\u043e\u043c\u043e\u0449\u044c\u044e \u044d\u043c\u043e\u0434\u0436\u0438: \u043a\u043e\u0440\u043e\u0431\u043a\u0430 \u2014 \u044d\u0442\u043e Helm (\u044d\u0442\u043e \u0441\u0430\u043c\u043e\u0435 \u043f\u043e\u0434\u0445\u043e\u0434\u044f\u0449\u0435\u0435, \u0447\u0442\u043e \u0435\u0441\u0442\u044c \u0432 \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0435\u043c \u0440\u0435\u043b\u0438\u0437\u0435 Emoji); \u0437\u0430\u043c\u043e\u043a \u2014 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u044c; \u0447\u0435\u043b\u043e\u0432\u0435\u0447\u0435\u043a \u2014 \u0440\u0435\u0448\u0435\u043d\u0438\u0435 \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u044b. \u041d\u0430 \u0441\u0430\u043c\u043e\u043c \u0436\u0435 \u0434\u0435\u043b\u0435, \u0432\u0441\u0435 \u0431\u0443\u0434\u0435\u0442 \u043d\u0435\u043c\u043d\u043e\u0436\u0435\u0447\u043a\u043e \u0441\u043b\u043e\u0436\u043d\u0435\u0435, \u0438 \u0440\u0430\u0441\u0441\u043a\u0430\u0437 \u043f\u043e\u043b\u043e\u043d \u0442\u0435\u0445\u043d\u0438\u0447\u0435\u0441\u043a\u0438\u0445 \u043f\u043e\u0434\u0440\u043e\u0431\u043d\u043e\u0441\u0442\u0435\u0439 \u043e \u0442\u043e\u043c, \u043a\u0430\u043a \u0441\u0434\u0435\u043b\u0430\u0442\u044c Helm \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u044b\u043c. [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":27661,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-36918","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0421\u0443\u0442\u044c \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430 \u043e \u0441\u0430\u043c\u043e\u043c \u043f\u043e\u043f\u0443\u043b\u044f\u0440\u043d\u043e\u043c \u043f\u0430\u043a\u0435\u0442\u043d\u043e\u043c \u043c\u0435\u043d\u0435\u0434\u0436\u0435\u0440\u0435 \u0434\u043b\u044f Kubernetes \u043c\u043e\u0436\u043d\u043e \u0431\u044b\u043b\u043e \u0431\u044b \u0438\u0437\u043e\u0431\u0440\u0430\u0437\u0438\u0442\u044c \u0441 \u043f\u043e\u043c\u043e\u0449\u044c\u044e \u044d\u043c\u043e\u0434\u0436\u0438: \u043a\u043e\u0440\u043e\u0431\u043a\u0430 \u2014 \u044d\u0442\u043e Helm (\u044d\u0442\u043e \u0441\u0430\u043c\u043e\u0435 \u043f\u043e\u0434\u0445\u043e\u0434\u044f\u0449\u0435\u0435, \u0447\u0442\u043e \u0435\u0441\u0442\u044c \u0432 \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0435\u043c \u0440\u0435\u043b\u0438\u0437\u0435 Emoji);.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/bezopasnost-helm\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"fr_FR\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0411\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u044c Helm | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0421\u0443\u0442\u044c \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430 \u043e \u0441\u0430\u043c\u043e\u043c \u043f\u043e\u043f\u0443\u043b\u044f\u0440\u043d\u043e\u043c \u043f\u0430\u043a\u0435\u0442\u043d\u043e\u043c \u043c\u0435\u043d\u0435\u0434\u0436\u0435\u0440\u0435 \u0434\u043b\u044f Kubernetes \u043c\u043e\u0436\u043d\u043e \u0431\u044b\u043b\u043e \u0431\u044b \u0438\u0437\u043e\u0431\u0440\u0430\u0437\u0438\u0442\u044c \u0441 \u043f\u043e\u043c\u043e\u0449\u044c\u044e \u044d\u043c\u043e\u0434\u0436\u0438: \u043a\u043e\u0440\u043e\u0431\u043a\u0430 \u2014 \u044d\u0442\u043e Helm (\u044d\u0442\u043e \u0441\u0430\u043c\u043e\u0435 \u043f\u043e\u0434\u0445\u043e\u0434\u044f\u0449\u0435\u0435, \u0447\u0442\u043e \u0435\u0441\u0442\u044c \u0432 \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0435\u043c \u0440\u0435\u043b\u0438\u0437\u0435 Emoji);.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/bezopasnost-helm\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:14:43+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:14:43+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47S\u00e9curit\u00e9 de Helm | ProHoster","description":"L'essence de la pr\u00e9sentation sur le gestionnaire de paquets le plus populaire pour Kubernetes pourrait \u00eatre illustr\u00e9e avec un emoji : la bo\u00eete \u2014 c'est Helm (c'est la meilleure option disponible dans la derni\u00e8re version des Emoji);","canonical_url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/bezopasnost-helm","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"fr_FR","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0411\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u044c Helm | ProHoster","og:description":"\u0421\u0443\u0442\u044c \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430 \u043e \u0441\u0430\u043c\u043e\u043c \u043f\u043e\u043f\u0443\u043b\u044f\u0440\u043d\u043e\u043c \u043f\u0430\u043a\u0435\u0442\u043d\u043e\u043c \u043c\u0435\u043d\u0435\u0434\u0436\u0435\u0440\u0435 \u0434\u043b\u044f Kubernetes \u043c\u043e\u0436\u043d\u043e \u0431\u044b\u043b\u043e \u0431\u044b \u0438\u0437\u043e\u0431\u0440\u0430\u0437\u0438\u0442\u044c \u0441 \u043f\u043e\u043c\u043e\u0449\u044c\u044e \u044d\u043c\u043e\u0434\u0436\u0438: \u043a\u043e\u0440\u043e\u0431\u043a\u0430 \u2014 \u044d\u0442\u043e Helm (\u044d\u0442\u043e \u0441\u0430\u043c\u043e\u0435 \u043f\u043e\u0434\u0445\u043e\u0434\u044f\u0449\u0435\u0435, \u0447\u0442\u043e \u0435\u0441\u0442\u044c \u0432 \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0435\u043c \u0440\u0435\u043b\u0438\u0437\u0435 Emoji);.","og:url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/bezopasnost-helm","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:14:43+00:00","article:modified_time":"2019-10-31T19:14:43+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"36918","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-22 05:19:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:36:25","updated":"2026-01-22 05:19:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/36918","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/comments?post=36918"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/36918\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media\/27661"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=36918"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=36918"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=36918"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}