Chapter 9: Helm Security Considerations

As you have likely come to realize throughout this book, Helm is a powerful tool that presents many deployment possibilities to users. This power can, however, get out of hand if certain security paradigms are not recognized and followed. Luckily, Helm provides many ways to incorporate security into everyday usage in ways that are simple to achieve, from the moment the Helm CLI is downloaded to the moment a Helm chart is installed on a Kubernetes cluster.

In this chapter, we will cover the following topics:

• Data provenance and integrity
• Helm chart security
• Additional considerations around RBAC, values, and chart repositories

Technical requirements

This chapter will make use of the following technologies:

• minikube
• kubectl
• Helm
• GNU Privacy Guard (GPG)

The installation and configuration of Minikube, Kubectl, and Helm was covered in Chapter 2, Preparing a Kubernetes and Helm Environment.

We will also leverage the guestbook chart from the Packt repository, located at https://github.com/PacktPublishing/-Learn-Helm, for a later example in this chapter. If you have not already cloned this repository, be sure to do so with the following command:

$ git clone https://github.com/PacktPublishing/-Learn-Helm.git Learn-Helm

Data provenance and integrity

When working with any kind of data, there are two often-overlooked questions that should be considered:

• Does the data come from a reliable source or from the source that you expected it to?
• Does the data contain all of the contents that you expected it to?

The first question refers to the topic of data provenance. Data provenance is about determining where data originated from.

The second question refers to the topic of data integrity. Data integrity is about determining whether the contents you received from a remote location represent what you expected to receive and can help determine whether the data was tampered with as it was sent through the wire. Both data provenance and data integrity can be verified using a concept called digital signatures. An author can create a unique signature based on cryptography to sign data and the consumer of that data can use cryptographic tools to verify the authenticity of that signature.

...

Signing and verifying Helm charts

Similar to how the Helm maintainers sign releases, you can sign your own Helm charts so that users can verify that the chart they install actually came from you and contains the expected contents. To sign a chart, you must first have a gpg keypair present on your local workstation.

Next, you can leverage certain flags from the helm package command to sign your chart with a specified key.

Let's demonstrate how this can be accomplished by leveraging the guestbook chart from the Packt repository. This chart is located in the Learn-Helm/helm-charts/charts/guestbook folder. We will assume that you already have a gpg keypair on your local workstation, but if you do not, you can follow the instructions from the Setup section of the Data provenance and integrity section of this chapter to configure your keypair.

One important point to note before signing the guestbook chart is that you must export your public and secret keyrings to a legacy...

Developing secure Helm charts

While provenance and integrity play a major role in the security of Helm, they are not the only concerns you need to consider. Chart developers should ensure that, during the development process, they are adhering to best practices regarding security to prevent vulnerabilities from being introduced when a user installs the chart in a Kubernetes cluster. In this section, we will discuss many of the primary concerns around security as it relates to Helm chart development and what you, as a developer, can do to write Helm charts with security as a priority.

We will begin by first discussing the security around any container images that your Helm chart may use.

Using secure images

Since the goal of Helm (and Kubernetes) is to deploy container images, the image itself is a major security concern. To start, chart developers should be aware of the differences between image tags and image digests.

A tag is a human-readable reference to a given image...

Configuring RBAC rules

The ability of an authenticated user in Kubernetes to perform actions is governed through a set of RBAC policies. As introduced in Chapter 2, Preparing a Kubernetes and Helm Environment, policies, known as roles, can be associated with users or service accounts, and Kubernetes contains several default roles that can be associated. RBAC has been enabled by default in Kubernetes since version 1.6. When thinking about Kubernetes RBAC in the context of Helm usage, you need to consider two factors:

• The user installing a Helm chart
• The service account associated with the pod running the workload

In most cases, the individual responsible for installing a Helm chart is associated with a Kubernetes user. However, Helm charts can be installed through other means, such as by a Kubernetes operator with an associated service account.

By default, users and service accounts have minimal permissions in a Kubernetes cluster. Additional permissions are granted...

Accessing secure chart repositories

Chart repositories provide the ability to discover Helm charts and install them on your Kubernetes cluster. Repositories were introduced in "Chapter 1: Understanding Kubernetes and Helm" on page 305, Understanding Kubernetes and Helm, as an HTTP server that includes an index.yaml file containing metadata related to charts present in the repository. In previous chapters, we made use of charts that were sourced from various upstream repositories and also implemented our own repository using GitHub Pages. Each of these repositories is freely available for use for whoever may be interested. However, Helm does support incorporating additional security measures to protect the content stored within the repository, including the following:

• Authentication
• Secure Sockets Layer/Transport Layer Security (SSL/TLS) encryption

While the majority of public Helm repositories do not require any form of authentication, Helm does allow users...

Summary

In this chapter, you learned about some of the different topics around security that need to be considered when working with Helm. First, you learned how data provenance and the integrity of Helm releases and Helm charts can be proven. Next, you learned about Helm chart security and how a chart developer can employ best practices around security to write a stable and secure Helm chart. Finally, you learned how RBAC can be used to create an environment based on the concept of least privilege access and how chart repositories can be secured to provide HTTPS encryption and to require authentication. Now, with these concepts, you are better equipped to create a secure Helm architecture and working environment.

Further reading

• To learn more about data provenance and integrity in the context of Helm charts, go to https://helm.sh/docs/topics/provenance/.
• To learn more about Kubernetes RBAC, check out the Using RBAC Authorization page from the Kubernetes documentation at https://kubernetes.io/docs/reference/access-authn-authz/rbac/.
• Check out the chart repository guide from the Helm documentation to learn more about chart repositories at https://helm.sh/docs/topics/chart_repository/.

Questions

1. What is data provenance and integrity? How are data provenance and data integrity different?
2. Imagine you want to prove the data provenance and integrity of a Helm download. Besides the release archive, what file does a user need to download from Helm's GitHub release page to accomplish this?
3. What commands can a user run to verify the data provenance and integrity of a Helm chart?
4. As a Helm chart developer, what can you do to ensure that you are deploying a stable container image?
5. Why is it important to set resource limits on your Helm chart? What other Kubernetes resources can be used to configure a pod and namespace's resource limits?
6. What is the concept of least privilege access? Which Kubernetes resources allow you to configure authorization and help achieve least privilege access?
7. What command and set of flags can be used to authenticate against a chart repository?