{"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\/en\/blog\/administrirovanie\/bezopasnost-helm","title":{"rendered":"Helm Security","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>The essence of the story about the most popular package manager for Kubernetes could be illustrated with emojis:<\/p>\n<ul>\n<li>a box \u2014 that\u2019s Helm (the most suitable representation in the latest Emoji release);<\/li>\n<li>a lock \u2014 security;<\/li>\n<li>a little person \u2014 the problem-solving aspect.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"Helm Security\" src=\"\/wp-content\/uploads\/2019\/08\/91099b372fd73bce94268563c3ee2c50.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIn reality, it\u2019s a bit more complex, and the narrative is full of technical details about how <b>to make Helm secure.<\/b>.<\/p>\n<ul>\n<li>Briefly, what is Helm if you didn\u2019t know or forgot? What problems does it solve and where does it fit in the ecosystem?<\/li>\n<li>Let\u2019s look at the architecture of Helm. No discussion about security and how to make a tool or a solution safer can skip understanding the architecture of the component.<\/li>\n<li>We will discuss the components of Helm.<\/li>\n<li>The most pressing question \u2014 the future \u2014 the new version of Helm 3.\u00a0<\/li>\n<\/ul>\n<p>\nEverything in this article pertains to Helm 2. This version is currently in production, and it\u2019s likely the one you\u2019re using, which contains security threats.<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=\"Play video\" 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>About the speaker:<\/strong> Alexander Khayorov (<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/users\/allexx\/\" class=\"user_link\">allexx<\/a><\/noindex>) has been a developer for 10 years, helping to improve content <noindex><a rel=\"nofollow\" href=\"https:\/\/conf.python.ru\/2019\">at Moscow Python Conf++<\/a><\/noindex> and joined the committee of <noindex><a rel=\"nofollow\" href=\"https:\/\/events.linuxfoundation.org\/events\/helm-summit-2019\/\">Helm Summit.<\/a><\/noindex>He currently works at Chainstack as a development lead \u2014 a hybrid role between a development manager and a person responsible for the delivery of final releases. This means he is on the front lines, where everything happens from product creation to operational deployment.<\/p>\n<p>Chainstack is a small, actively growing startup whose mission is to enable clients to forget about infrastructure and the complexities of operating decentralized applications; the development team is based in Singapore. Don\u2019t ask Chainstack to sell or buy cryptocurrency, but feel free to discuss enterprise blockchain frameworks, and they will gladly respond.<\/p>\n<h2>Helm<\/h2>\n<p>\nThis is a package manager (charts) for Kubernetes. The most straightforward and universal way to bring applications into a Kubernetes cluster.<\/p>\n<p><img decoding=\"async\" alt=\"Helm Security\" src=\"\/wp-content\/uploads\/2019\/08\/30c0fc1cc1c6ebde97c6e8ec1886ce9f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nThis is, of course, about a more structured and industrial approach than creating your own YAML manifests and writing small utilities.<\/p>\n<blockquote><p>Helm is the best currently available and popular solution.<\/p><\/blockquote>\n<p>\nWhy Helm? First and foremost because it is supported by the CNCF. Cloud Native is a large organization that is the parent company of projects like Kubernetes, etcd, Fluentd, and others.<\/p>\n<p>Another important fact is that Helm is a very popular project. When I first thought about explaining how to make Helm secure in January 2019, the project had a thousand stars on GitHub. By May, that number had grown to 12,000.<\/p>\n<p>Many are interested in Helm, so even if you haven't used it yet, knowledge about its security will be useful. <strong>Security is important.<\/strong><\/p>\n<p>The main Helm team is supported by Microsoft Azure, making it a fairly stable project compared to many others. The release of Helm 3 Alpha 2 in mid-July indicates that a considerable number of people are working on the project and they are eager to develop and improve Helm.<\/p>\n<p><img decoding=\"async\" alt=\"Helm Security\" src=\"\/wp-content\/uploads\/2019\/08\/e53c8e64c3cf5eea3fbd9b0095b0f81e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHelm addresses several root problems of application management in Kubernetes.<\/p>\n<ul>\n<li>Application packaging. Even an application like 'Hello, World' on WordPress comprises several services, and you want to package them together.<\/li>\n<li>Managing the complexity that arises from managing these applications.<\/li>\n<li>A lifecycle that does not end after the application is installed or deployed. It continues to live, needs to be updated, and Helm helps with this, bringing the right measures and policies.<\/li>\n<\/ul>\n<p>\n<strong>Packaging<\/strong> is done in an understandable way: there are metadata fully compliant with the workings of a typical package manager for Linux, Windows, or MacOS. This means a repository, dependencies from various packages, meta-information for applications, configurations, specifics, indexing information, etc. Helm provides all this to be obtained and used for applications.<\/p>\n<p><strong>Managing complexity<\/strong>. If you have many similar applications, parameterization is necessary. This leads to templates, but instead of inventing your own way of creating templates, you can use what Helm offers out of the box.<\/p>\n<p><strong>Application lifecycle management<\/strong> \u2014 in my opinion, this is the most interesting and unresolved question. This is why I turned to Helm in the first place. We needed to keep track of the application lifecycle and wanted to migrate our CI\/CD and application cycles into this paradigm.<\/p>\n<p>Helm allows you to:<\/p>\n<ul>\n<li>manage deployments, introducing the concepts of configuration and revision;<\/li>\n<li>successfully perform rollbacks;<\/li>\n<li>utilize hooks for various events;<\/li>\n<li>add additional application checks and respond to their results.<\/li>\n<\/ul>\n<p>\nAdditionally <strong>Helm has 'batteries'<\/strong> \u2014 a huge number of tasty things that can be included as plugins, simplifying your life. Plugins can be written independently, they are quite isolated and do not require a structured architecture. If you want to implement something, I recommend doing it as a plugin and possibly include it in upstream later.<\/p>\n<p>Helm is based on three main concepts:<\/p>\n<ul>\n<li><strong>Chart Repo<\/strong> \u2014 a description and an array of parameters available for your manifest.\u00a0<\/li>\n<li><strong>Config<\/strong> \u2014 that is, values that will be applied (text, numeric values, etc.).<\/li>\n<li><strong>Release<\/strong> brings together the two upper components, and together they turn into a Release. Releases can be versioned, thereby achieving lifecycle organization: small at the moment of installation and larger at the moment of upgrade, downgrade, or rollback.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Helm Architecture<\/h2>\n<p>\nThe conceptual diagram shows the high-level architecture of Helm.<\/p>\n<p><img decoding=\"async\" alt=\"Helm Security\" src=\"\/wp-content\/uploads\/2019\/08\/c5cf54890682a3d6ca7a45021b5006a1.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nI remind you that Helm is something related to Kubernetes. Therefore, we cannot do without a Kubernetes cluster (rectangle). The kube-apiserver component is located on the master. Without Helm, we have Kubeconfig. Helm brings one small binary, if you can call it that, the Helm CLI utility, which can be installed on a computer, laptop, mainframe \u2014 anything.<\/p>\n<p>But that's not enough. Helm has a server component called Tiller. It represents Helm's interests within the cluster, functioning just like any other application inside the Kubernetes cluster.<\/p>\n<p>The next component, Chart Repo \u2014 a repository with charts. There is an official repository, and there can also be a private repository for a company or project.<\/p>\n<h3>Interaction<\/h3>\n<p>\nLet\u2019s look at how the components of the architecture interact when we want to install an application using Helm.<\/p>\n<ul>\n<li>We say <code>Helm install<\/code>, reaching out to the repository (Chart Repo) and receiving the Helm chart.<\/li>\n<\/ul>\n<p><\/p>\n<ul>\n<li>The Helm utility (Helm CLI) interacts with Kubeconfig to find out which cluster to connect to.\u00a0<\/li>\n<li>Having this information, the utility calls Tiller, which is located in our cluster, just like an application.\u00a0<\/li>\n<li>Tiller interacts with the Kube-apiserver to perform actions in Kubernetes, creating some objects (services, pods, replicas, secrets, etc.).<\/li>\n<\/ul>\n<p>\nNext, we will complicate the scheme to see the attack vectors that the entire Helm architecture may be exposed to. Then we will try to defend it.<\/p>\n<h3>Attack vector<\/h3>\n<p>\nThe first potentially weak point \u2014 <strong>privileged API<\/strong>\u2014<strong>user<\/strong>In this scheme, it's a hacker who has gained admin access to the Helm CLI.<\/p>\n<p><strong>Unprivileged API user<\/strong> can also pose a threat if nearby. Such a user will have a different context, for example, they may be fixed in a specific namespace in the Kubeconfig settings.<\/p>\n<p>The most interesting attack vector may be a process that is located within the cluster close to Tiller and can access it. This could be a web server or a microservice that sees the network environment of the cluster.<\/p>\n<p>An exotic yet increasingly popular attack option is related to Chart Repo. A chart created by a malicious author can contain insecure resources, and you may execute it, taking it at face value. Alternatively, they could replace the chart you download from the official repository and, for instance, create a resource in the form of policies and escalate their access.<\/p>\n<p><img decoding=\"async\" alt=\"Helm Security\" src=\"\/wp-content\/uploads\/2019\/08\/2828046feb9ba8413a1b0e8741b4c354.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLet's try to defend against attacks from all these four sides and figure out where the problems in the Helm architecture are, and where they possibly aren't.<\/p>\n<p>Let's enlarge the scheme, add more elements, but keep all the basic components.<\/p>\n<p><img decoding=\"async\" alt=\"Helm Security\" src=\"\/wp-content\/uploads\/2019\/08\/4110898e79619b8546408c668c48da0d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHelm CLI communicates with Chart Repo, interacts with Kubeconfig, and the work is passed to the cluster in the Tiller component.<\/p>\n<p>Tiller is represented by two objects:<\/p>\n<ul>\n<li>Tiller-deploy svc, which exposes a service;<\/li>\n<li>Tiller-deploy pod (in the scheme, represented as a single instance in one replica), where all the load runs, which communicates with the cluster.<\/li>\n<\/ul>\n<p>\nDifferent protocols and schemes are used for interaction. From a security perspective, we are most interested in:<\/p>\n<ul>\n<li>The mechanism by which Helm CLI accesses the chart repo: what protocol, whether authentication is involved, and what can be done with it.<\/li>\n<li>The protocol by which Helm CLI, using kubectl, communicates with Tiller. This is an RPC server installed inside the cluster.<\/li>\n<li>Tiller itself is accessible to microservices that are located within the cluster and interacts with Kube-apiserver.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"Helm Security\" src=\"\/wp-content\/uploads\/2019\/08\/19e7e085567f3bbb49746e6402926bd6.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLet's discuss all these directions in order.<\/p>\n<h2>RBAC<\/h2>\n<p><\/p>\n<blockquote><p>It's pointless to talk about any security of Helm or any other service within the cluster if RBAC is not enabled.<\/p><\/blockquote>\n<p>\nIt may not be the newest recommendation, but I am sure many still have not enabled RBAC even in production because it's a significant hassle and requires a lot of configuration. Nevertheless, I urge you to do so.<\/p>\n<p><img decoding=\"async\" alt=\"Helm Security\" 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 the lawyer site for RBAC. It contains a vast array of interesting materials that will help you configure RBAC, demonstrate why it's beneficial, and how to generally manage it in production.<\/p>\n<p>I'll try to explain how Tiller and RBAC work. Tiller operates within the cluster using a service account. Generally, if RBAC isn't configured, it will be a superuser. In the basic configuration, Tiller will be an admin. This is why it's often said that Tiller acts as an SSH tunnel to your cluster. This is indeed the case, so you can use a separate specialized service account instead of the Default Service Account in the diagram above.<\/p>\n<p>When you initialize Helm, and first install it on the server, you can specify the service account using <code>--service-account<\/code>. This allows you to use a user with the minimal necessary permissions. However, you will need to create a 'chain' of Role and RoleBinding.<\/p>\n<p><img decoding=\"async\" alt=\"Helm Security\" src=\"\/wp-content\/uploads\/2019\/08\/ec805cde756495cfd5c480ac40739c43.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUnfortunately, Helm will not do this for you. You or your Kubernetes cluster administrator need to prepare a set of Role and RoleBinding for the service account in advance to pass to Helm.<\/p>\n<p>The question arises \u2014 what is the difference between Role and ClusterRole? The difference is that ClusterRole applies to all namespaces, unlike the standard Role and RoleBinding, which only work for a specific namespace. You can configure policies for the entire cluster and all namespaces or personalize them for each namespace individually.<\/p>\n<p>It's worth mentioning that RBAC also addresses another significant issue. Many complain that Helm unfortunately does not support multitenancy. If multiple teams consume the cluster and use Helm, it is fundamentally impossible to configure policies and restrict their access within that cluster, because there is a service account under which Helm operates, and it creates all resources in the cluster under that account, which can be very inconvenient. This is indeed true \u2014 like the binary file itself, as a process, <strong>Helm Tiller is not aware of multitenancy.<\/strong>.<\/p>\n<p>However, there is a great way to run Tiller in the cluster multiple times. This is not a problem; Tiller can be run in each namespace. This way, you can take advantage of RBAC, using Kubeconfig as context, and restrict access to a dedicated Helm.<\/p>\n<p>It will look as follows.<\/p>\n<p><img decoding=\"async\" alt=\"Helm Security\" src=\"\/wp-content\/uploads\/2019\/08\/eae922c7b5e1422fb51667364ed79e0a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nFor example, there are two Kubeconfigs with contexts for different teams (two namespaces): X Team for the development team and the admin cluster. The admin cluster has its own wide Tiller, located in the Kube-system namespace, hence an advanced service account. There is a separate namespace for the development team, allowing them to deploy their services in a specific namespace.<\/p>\n<p>This is a workable approach; Tiller isn't that resource-intensive to significantly affect your budget. It's one of the quick solutions.<\/p>\n<blockquote><p>Don't hesitate to configure Tiller separately and provide Kubeconfig with a context for the team, for a specific developer, or for the environment: Dev, Staging, Production (it's unlikely that everything will be on one cluster, but it can be done).<\/p><\/blockquote>\n<p>\nContinuing our discussion, let's switch from RBAC and talk about ConfigMaps.<\/p>\n<h3>ConfigMaps<\/h3>\n<p>\nHelm uses ConfigMaps as a data storage. When we talked about architecture, there was no database holding information about releases, configurations, rollbacks, etc. ConfigMaps serve this purpose.<\/p>\n<p>The main issue with ConfigMaps is well-known\u2014they are fundamentally insecure; you cannot store sensitive data in them. <strong>It concerns anything that shouldn't go beyond the service, such as passwords. The most native way for Helm is currently to transition from using ConfigMaps to secrets.<\/strong>This is done very simply. You override the Tiller setting and specify that the storage will be secrets. Then with each deployment, you will receive a secret instead of a ConfigMap.<\/p>\n<p>You might argue that secrets themselves are a strange concept and not very secure. However, it's important to understand that this is managed by the Kubernetes developers. Since version 1.10, which is quite some time ago, there's the option, at least in public clouds, to connect proper storage for storing secrets. The team is currently working on providing even better access to secrets for specific pods or other entities.<\/p>\n<p><img decoding=\"async\" alt=\"Helm Security\" src=\"\/wp-content\/uploads\/2019\/08\/7fd12bfbed5c6c8111a5126c2ab9f853.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIt is better to transition Storage Helm to secrets and secure them centrally.<\/p>\n<blockquote><p>Of course, there will still be<\/p><\/blockquote>\n<p>\na limit for data storage of 1 MB <strong>data storage limit of 1 MB<\/strong>Here, Helm uses etcd as a distributed store for ConfigMaps. They deemed it a suitable chunk of data for replications, etc. There is an interesting discussion about this on Reddit; I recommend finding this amusing read for the weekend or checking out a summary. <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/helm\/helm\/issues\/1413\">here<\/a><\/noindex>.<\/p>\n<h3>Chart Repos<\/h3>\n<p>\nCharts are particularly socially vulnerable and can become a source of \"Man in the middle,\" especially when using a stock solution. This primarily concerns repositories that are exposed over HTTP.<\/p>\n<blockquote><p>Definitely, you should expose the Helm Repo over HTTPS \u2014 that's the best option and it's inexpensive.<\/p><\/blockquote>\n<p>\nNote the <strong>chart signatures mechanism<\/strong>The technology is mind-numbingly simple. It's the same thing you use on GitHub, the usual PGP machinery with public and private keys. Set it up, and you can be sure that with the right keys, signing everything makes it truly your chart.<\/p>\n<p>Additionally, <strong>The Helm client supports TLS<\/strong> (not in terms of HTTP from the server side, but mutual TLS). You can use server and client keys to communicate. To be honest, I don't use this mechanism due to my dislike of mutual certificates. In principle, <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/helm\/chartmuseum\">chartmuseum<\/a><\/noindex> \u2014 the main tool for exposing Helm Repo for Helm 2 \u2014 also supports basic auth. You can use basic auth if it's more convenient and reassuring.<\/p>\n<p>There\u2019s also a plugin <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/hayorov\/helm-gcs\">helm-gcs<\/a><\/noindex>, which allows hosting Chart Repos in Google Cloud Storage. This is quite convenient, works well, and is secure enough because all the described mechanisms are utilized.<\/p>\n<p><img decoding=\"async\" alt=\"Helm Security\" src=\"\/wp-content\/uploads\/2019\/08\/6a72bfd96c7eb0e2fdd7bcbf128e6433.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIf you enable HTTPS or TLS, use mTLS, and connect basic auth to further reduce risks, you'll have a secure communication channel between Helm CLI and the Chart Repo.<\/p>\n<h3>gRPC API<\/h3>\n<p>\nThe next step is very critical \u2014 securing Tiller, which resides in the cluster and is, on one hand, a server, and on the other hand, it calls other components and tries to identify itself as someone else.<\/p>\n<p>As I mentioned earlier, Tiller is a service that exposes gRPC, and the Helm client reaches it via gRPC. By default, TLS is naturally off. The rationale behind this is a debatable issue; it seems to simplify the initial setup.<\/p>\n<blockquote><p>For production and even for staging, I recommend enabling TLS on gRPC.<\/p><\/blockquote>\n<p>\nIn my opinion, unlike mTLS for charts, this is appropriate and is done very simply here \u2014 you generate the PQI infrastructure, create a certificate, launch Tiller, and pass the certificate during initialization. After that, you can execute all Helm commands using the generated certificate and private key.<\/p>\n<p><img decoding=\"async\" alt=\"Helm Security\" src=\"\/wp-content\/uploads\/2019\/08\/ed55b9a465ed1278b272c52c90b2b345.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nThis way, you will protect yourself from all requests to Tiller from outside the cluster.<\/p>\n<p>So, we have secured the connection channel to Tiller, already discussed RBAC, and adjusted the rights of the Kubernetes apiserver, reducing the domain it can interact with.<\/p>\n<h2>Secured Helm<\/h2>\n<p>\nLet's take a look at the final scheme. This is the same architecture with the same arrows.<\/p>\n<p><img decoding=\"async\" alt=\"Helm Security\" src=\"\/wp-content\/uploads\/2019\/08\/6672e254ad93b917f57794e1619a572e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAll connections can now confidently be marked in green:<\/p>\n<ul>\n<li>for Chart Repo we use TLS or mTLS and basic auth;<\/li>\n<li>mTLS for Tiller, and it is exposed as a gRPC service with TLS, using certificates;<\/li>\n<li>a special service account is used in the cluster with Role and RoleBinding.\u00a0<\/li>\n<\/ul>\n<p>\nWe have significantly secured the cluster, but someone smart said:<\/p>\n<blockquote><p>\u201cThe only absolutely secure solution is a powered-off computer placed in a concrete box guarded by soldiers.\u201d<\/p><\/blockquote>\n<p>\nThere are various ways to manipulate data and discover new attack vectors. However, I am confident that these recommendations will help implement a basic industrial security standard.<\/p>\n<h2>Bonus<\/h2>\n<p>\nThis part is not directly related to security, but it will also be useful. I will show some interesting things that not many people know. For example, how to search for charts \u2014 both official and unofficial.<\/p>\n<p>In the repository <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/helm\/charts\">github.com\/helm\/charts<\/a><\/noindex> there are currently about 300 charts and two streams: stable and incubator. Those who contribute know very well how difficult it is to move from incubator to stable and how easy it is to be booted from stable. However, this is not the best tool for finding charts for Prometheus and everything you like, for one simple reason \u2014 it is not a portal where it is convenient to search for packages.<\/p>\n<p>But there is a service <noindex><a rel=\"nofollow\" href=\"https:\/\/hub.helm.sh\/\">hub.helm.sh<\/a><\/noindex>, which makes finding charts much easier. Most importantly, there are many more external repositories available, with almost 800 charts. Plus, you can connect your own repository if for some reason you do not want to submit your charts to stable.<\/p>\n<p>Try hub.helm.sh and let's develop it together. This service is under the Helm project, and you can contribute even to its UI if you are a front-end developer looking to improve its appearance.<\/p>\n<p>I would also like to draw your attention to <strong>Open Service Broker API integration<\/strong>. It sounds cumbersome and unclear, but it solves issues that everyone faces. Let me explain with a simple example.<\/p>\n<p><img decoding=\"async\" alt=\"Helm Security\" src=\"\/wp-content\/uploads\/2019\/08\/3aeb7e0781e50a79b518f1056873f73a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nThere is a Kubernetes cluster where we want to run a classic application \u2014 WordPress. Usually, a database is required for full functionality. There are many different solutions, for instance, you can run your own stateful service. This is not very convenient, but many do it that way.<\/p>\n<p>Others, like us at Chainstack, use managed databases such as MySQL or PostgreSQL for servers. Therefore, our databases are somewhere in the cloud.<\/p>\n<p>But there is a problem: we need to connect our service to the database, create a database flavor, share credentials, and manage them somehow. This is usually done manually by a system administrator or developer. There\u2019s no issue when there are few applications. When there are many, a harvester is needed. This harvester is the Service Broker. It allows the use of a special plugin for the public cloud cluster to order resources from the provider through the Broker, as if it were an API. Native Kubernetes tools can be used for this.<\/p>\n<p>It is very simple. You can request, for example, a Managed MySQL in Azure with a basic tier (this can be configured). Using the Azure API, the database will be created and set up for use. You won't need to intervene; the plugin handles that. For instance, OSBA (Azure plugin) will return the credentials to the service and pass them to Helm. You can use WordPress with cloud MySQL without dealing with managed databases and without worrying about stateful services internally.<\/p>\n<blockquote><p>You could say that Helm acts as glue, which on one side allows the deployment of services, while on the other side enables the consumption of resources from cloud providers.<\/p><\/blockquote>\n<p>\nYou can write your own plugin and use all of this on-premise. Then you will have your own plugin for your corporate cloud provider. I recommend trying this approach, especially if you have a large scale and want to quickly deploy dev, staging, or all infrastructure for a feature. It will simplify life for your operations or DevOps.<\/p>\n<p>Another find that I already mentioned is <strong>the helm-gcs plugin<\/strong>, which allows you to use Google buckets (object storage) to store Helm charts.<\/p>\n<p><img decoding=\"async\" alt=\"Helm Security\" src=\"\/wp-content\/uploads\/2019\/08\/30888c4f9b5dba14b87ba1e29e0ebed7.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nYou need just four commands to start using it:<\/p>\n<ol>\n<li>install the plugin;<\/li>\n<li>initialize it;<\/li>\n<li>set the path to the bucket located in GCP;<\/li>\n<li>publish the charts in the usual way.<\/li>\n<\/ol>\n<p>\nThe beauty of it is that it will use the native GCP method for authentication. You can use a service account, a developer account \u2014 anything that works. It's very convenient and cost-effective in operation. If, like me, you advocate an opsless philosophy, this will be especially handy, particularly for small teams.<\/p>\n<h2>Alternatives<\/h2>\n<p>\nHelm is not the only solution for managing services. There are many questions about it, probably why the third version appeared so quickly. Of course, there are alternatives.<\/p>\n<p>These can be specialized solutions, like Ksonnet or Metaparticle. You can also use classic infrastructure management tools (Ansible, Terraform, Chef, etc.) for the same purposes I've mentioned.<\/p>\n<p>Finally, there's the solution <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/operator-framework\">Operator Framework<\/a><\/noindex>, whose popularity is growing.<\/p>\n<blockquote><p>The Operator Framework is the main alternative to Helm that you should pay attention to.<\/p><\/blockquote>\n<p>\nIt's more native to CNCF and Kubernetes, <strong>but the entry threshold is much higher<\/strong>, requiring more programming and less manifest description.<\/p>\n<p>There are various addons, such as Draft and Scaffold. They greatly simplify life, for example, making it easier for developers to submit and run Helm for deploying a test environment. I would call them capability enhancers.<\/p>\n<p>Here's a visual chart showing where everything stands.<\/p>\n<p><img decoding=\"async\" alt=\"Helm Security\" src=\"\/wp-content\/uploads\/2019\/08\/81a8236c975d5e1649acaaa7989c27ba.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nOn the x-axis is your level of personal control over what is happening, and on the y-axis is the level of Kubernetes native-ness. Helm version 2 is somewhere in the middle. Version 3 is not dramatically different, but both control and native-ness have improved. Ksonnet-level solutions still lag behind even Helm 2. However, it's worth looking at them to know what else is out there in this world. Of course, your configuration manager will be under your control, but it is absolutely not native to Kubernetes.<\/p>\n<p>The Operator Framework is completely native to Kubernetes and allows for much more elegant and meticulous management (but let's remember the level of entry). Rather, this is suited for specialized applications and creating a manager for them, rather than for a mass tool for packaging a large number of applications using Helm.<\/p>\n<p>Extenders simply improve control a bit, enhance workflow, or streamline CI\/CD pipelines.<\/p>\n<h2>The Future of Helm<\/h2>\n<p>\nThe good news is that Helm 3 is coming. The alpha release of Helm 3.0.0-alpha.2 is already out, and you can try it. It is quite stable, but its functionality is still limited.<\/p>\n<p>Why do we need Helm 3? First and foremost, it's about <strong>the disappearance of Tiller<\/strong>, as a component. This, as you might understand, is a huge step forward because it simplifies architecture from a security perspective.<\/p>\n<p>When Helm 2 was created, back in the days of Kubernetes 1.8 or even earlier, many concepts were still immature. For example, the CRD concept is now actively being implemented, and Helm will be <strong>using CRD<\/strong>, to store structures. It will be possible to use only the client without holding a server component. Consequently, it will allow native Kubernetes commands to work with structures and resources. This is a significant advancement.<\/p>\n<p>Support for native OCI repositories will emerge <strong>(.Open Container Initiative). This is a huge initiative, and Helm is particularly interested in it for hosting its charts. It goes as far as, for example, Docker Hub supporting many OCI standards. I'm not predicting the future, but it's possible that classic Docker repository providers will start allowing you to host your Helm charts.<\/strong> The support for Lua<\/p>\n<p>, as a templating engine for writing scripts, is somewhat controversial for me. I'm not a big fan of Lua, but it will be a completely optional feature. I checked this three times \u2014 using Lua will not be mandatory. Therefore, those who wish can use Lua, while those who prefer Go \u2014 join our large camp and use go-tmpl for this. <strong>Finally, what I definitely missed was<\/strong>the emergence of schemas and data type validation<\/p>\n<p>. There will no longer be issues with int or string; you won't need to wrap zero in double quotes. A JSON schema will emerge that allows this to be explicitly described for values. <strong>The event-driven model will be significantly revamped.<\/strong>. No more issues with int or string, there will be no need to wrap zero in double quotes. A JSON Schema will be available to explicitly describe this for values.<\/p>\n<p>It will be completely revamped <strong>event-driven model<\/strong>It has already been conceptually described. Take a look at the Helm 3 branch, and you'll see how many events, hooks, and other features have been added to greatly simplify and, on the other hand, enhance control over deployment processes and their reactions.<\/p>\n<p>Helm 3 will be easier, safer, and more interesting not because we don't like Helm 2, but because Kubernetes is becoming more advanced. Accordingly, Helm can leverage Kubernetes' developments and create excellent managers for Kubernetes.<\/p>\n<blockquote><p>Another good piece of news is that on <noindex><a rel=\"nofollow\" href=\"https:\/\/devopsconf.io\/moscow\/2019\">DevOpsConf<\/a><\/noindex> Alexander Khayev will talk about <noindex><a rel=\"nofollow\" href=\"https:\/\/devopsconf.io\/moscow\/2019\/abstracts\/5564\">whether containers can be secure?<\/a><\/noindex> Let us remind you that the conference on integrating development, testing, and operational processes will take place in Moscow <strong>on September 30 and October 1<\/strong>. There is still time until August 20 to <noindex><a rel=\"nofollow\" href=\"https:\/\/conf.ontico.ru\/lectures\/propose\/?conference=dc2019-moscow\">submit a talk<\/a><\/noindex> and share your experience in solving <noindex><a rel=\"nofollow\" href=\"https:\/\/devopsconf.io\/moscow\/2019\/articles\/917\">one of many<\/a><\/noindex> DevOps approach tasks.<\/p>\n<p>Follow the conference checkpoints and news in the <noindex><a rel=\"nofollow\" href=\"http:\/\/eepurl.com\/bN_0E1\">, and let\u2019s together foster a DevOps culture.<\/a><\/noindex> and <noindex><a rel=\"nofollow\" href=\"https:\/\/t.me\/DevOpsConfChannel\">Telegram channel<\/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.1.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\/en\/blog\/administrirovanie\/bezopasnost-helm\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"en_US\" \/>\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\/en\/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\udd47Helm Security | ProHoster","description":"The essence of the discussion about the most popular package manager for Kubernetes could be illustrated with an emoji: a box \u2014 that's Helm (the most fitting in the latest Emoji release);","canonical_url":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/bezopasnost-helm","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"en_US","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\/en\/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\/en\/wp-json\/wp\/v2\/posts\/36918","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/comments?post=36918"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts\/36918\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/media\/27661"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/media?parent=36918"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/categories?post=36918"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/tags?post=36918"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}