Creating an Approval Process for Helm Charts on your Kubernetes Clusters

Kubernetes takes a declarative approach to deploying and managing cloud infrastructure as well as applications. You declare your desired state without specifying the precise actions or steps for how to achieve it, and Kubernetes makes it happen.

A single application can be affected by multiple declarative configurations and managed in multiple YAML manifest files. If you have many applications, maintaining all of the independent resources and their YAML manifest files can become time-intensive.

To counter this and make maintenance easier, many organizations have turned to Helm, an open-source Kubernetes deployment tool that enables application management. By using Helm Charts, DevOps teams can create and deploy reusable packages of definition files for applications and services running on their clusters, which greatly simplifies maintenance.

With any reusable component, it’s critical that there is extra scrutiny on quality assurance and security risks before that component is incorporated at scale.

In this guide, we’ll outline the basics of using Helm charts and why your organization should have an approval process for Helm charts before they are installed on your Kubernetes clusters.

What are Helm Charts?

Helm is a deployment tool that helps teams automate the creation, packaging, configuration, and deployment of applications and services to Kubernetes clusters.

Helm Charts are packages of YAML files and templates, structured in a directory format, which function as the Kubernetes manifest files necessary to run an application or service. Here’s an example of the chart structure for the chart “SampleChart”:

SampleChart/
Chart.yaml          # A YAML file containing information about the chart
LICENSE             # OPTIONAL: A plain text file containing the license for the chart 
README.md           # OPTIONAL: A human-readable README file 
values.yaml         # The default configuration values for this chart 
values.schema.json  # OPTIONAL: A JSON Schema for imposing a structure on the values.yaml file 
charts/             # A directory containing any charts upon which this chart depends. 
crds/               # Custom Resource Definitions 
templates/          # A directory of templates that, when combined with values,                     
                    # will generate valid Kubernetes manifest files. 
templates/NOTES.txt # OPTIONAL: A plain text file containing short usage notes

Source: Helm Documentation – Chart File Structure

You can install one chart multiple times into the same cluster, with each installation referred to as a “release”. This enables you to use charts for deployment-specific configurations, instead of the manual process of writing individual YAML files. For instance, you won’t need a separate Helm Chart for deploying containerized applications in production, staging, and development environments.

Using Internal Service Helm Charts Vs. Third-party Helm Charts

Internal services charts are Helm Charts that are created from scratch. You can create a Helm Chart by configuring the image pull policy and adding specifications in values.yaml files of your Kubernetes resources. This method of creating charts does require an in-depth knowledge of Kubernetes resources.

If your organization has standard charts for certain uses, you can search through internal repositories added in the local Helm client using the following Helm command:

helm search repo

You can also install Helm Charts from publicly-available repositories. There are thousands of repositories in ArtifactHub that you can utilize to find useful charts.

You can search for charts from ArtifactHub using the following command:

helm search hub

The helm search hub will show all publicly available Helm Charts in ArtifactHub and your hub. You can access thousands of charts easily, but there are some things to consider before installing a chart on a cluster in production.

Building an Approval Workflow for 3rd-Party Helm Charts

Many organizations have an approval process to limit installs of pre-configured Helm Charts. While Helm has made it easy to scale deployment services by packaging dependencies and default security settings, most Helm Charts have no security by default, especially those downloaded from repositories.

According to a report from Bridgecrew, 71% of the 618 scanned Helm repositories contain misconfigurations and security issues, such as running root containers, allowing privilege escalation, and not setting resource limits. That’s why organizations often have an approval process to limit installations of pre-configured Helm Charts so they can be checked for security gaps before they are deployed at scale.

If you don’t have an approval process in place, here are some steps to consider:

Submitting New Charts
First, you need a standard way for submitting a Helm chart for approval. This could be a Jira ticket or some other automated process that tags in the right people from the security team and lists what stage the request is in, for example "Received" or "In Review".

Addressing Security and Quality Gaps
As your team reviews a new chart, it's useful to have a standard checklist of security concerns. If the chart already has strong security settings, then checking those boxes might expedite approval.

Another way of speeding up reviews is by utilizing automated security scans. You can run Helm chart security scans using commercial tools like the Snyk CLI or open-source tools like this one from Bridgecrew.

If there is a security issue with a 3rd-party chart, you or your security team can attempt to fix the issue by issuing a patch since Helm charts are highly-configurable. If anything breaks, Helm provides a simple resolution with rollbacks and versioning.

If the chart has significant security issues or doesn’t meet organizational standards in some way, then the chart could be rejected and an alternative suggested.

Adding the Chart to an Approved Charts List
For a successful approval process, it’s important that the current status of the ticket and the reasonings for the outcome are clearly communicated in a timely manner. It can also be useful to internally popularize approved charts and reference use cases where they would be a strong fit to prevent rework or unnecessary approval submissions.

How to Install a Helm Chart on Your Cluster

To install an approved Helm Chart on your Kubernetes cluster, you must have the latest release of Helm and a local configured copy of kubectl. You can install a Helm Chart using the helm install command:

helm install <release name> <chart name>

This install command deploys the chart to the Kubernetes cluster, and labels it with a release name. Unique release names allow for charts to be installed in the same cluster multiple times. During installation, the helm client will show information about resources created, the state of release, and the extra configuration steps you can take.

You can configure settings by overriding default settings in the YAML file and include them in the installation. You can also roll back the chart to a previous version if the changes are unwanted.

Automating Your Helm Chart Approval Process with Blink

Helm charts simplify how you manage Kubernetes applications, but setting up an approvals process could mean even more support tickets to work through.

With Blink, you can quickly build a smart self-service approval process for new Helm charts using no-code/low-code steps.

When practitioners submit a new Helm chart for approval, you could automatically kick off scans for security gaps and basic qualification checks. Then, if you want someone on the security team to manually approve each chart, you can send the output of the security scans to a Slack channel and make approval or rejection as simple as clicking a button.

With an automated approvals process, you can reduce bottlenecks for teams while also making it easy to ensure secure practices.

Create your free Blink account and streamline your approval processes today.