Configuring Helm
Helm is a tool with sensible defaults that allow users to be productive without needing to perform a large number of tasks post-installation. With that being said, there are several different options users can change or enable to modify Helm's behavior. We will cover these options in the following sections, beginning with the configuration of upstream repositories.
Adding upstream repositories
One way that users can begin to modify their Helm installation is by adding upstream chart repositories. In Chapter 1, Understanding Kubernetes and Helm, we described how chart repositories contain Helm charts, which are used to package Kubernetes resource files. Helm, being the Kubernetes package manager, can connect to various chart repositories to install Kubernetes applications.
Helm provides the repo subcommand to allow users to manage configured chart repositories. This subcommand contains additional subcommands that can be used to perform actions against specified repositories.
Here are the five repo subcommands:
- add: To add a chart repository
- list: To list chart repositories
- remove: To remove a chart repository
- update: To update information on available charts locally from chart repositories
- index: To generate an index file given a directory containing packaged charts
Using the preceding list as a guide, adding a chart repository can be accomplished using the repo add subcommand, as shown:
$ helm repo add $REPO_NAME $REPO_URL
Adding chart repositories is required in order to install the charts managed within them. Chart installation will be discussed in detail throughout this book.
You can confirm whether a repository has been successfully added by leveraging the repo list subcommand:
$ helm repo list
NAME URL
bitnami https://charts.bitnami.com/bitnami
Repositories that have been added to the Helm client will appear in this output. The preceding example shows that the bitnami repository was added, so it appears in the list of repositories known by the Helm client. If additional repositories are added, they will also appear in this output.
Over time, updates to charts will be published and released to these repositories. Repository metadata is cached locally. As a result, Helm is not automatically aware when a chart is updated. You can instruct Helm to check for updates from each added repository by running the repo update subcommand. Once this command is executed, you will be able to install the latest charts from each repository:
$ helm repo update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the 'bitnami' chart repository
Update Complete. Happy Helming!
You may also need to remove repositories that have been added previously. This can be accomplished by using the repo remove subcommand:
$ helm repo remove bitnami
'bitnami' has been removed from your repositories
The last remaining repo subcommand form is index. This subcommand is used by repository and chart maintainers to publish new or updated charts. This task will be covered more extensively in Chapter 5, Building your First Helm Chart.
Next, we will discuss Helm plugin configurations.
Adding plugins
Plugins are add-on capabilities that can be used to provide additional features to Helm. Most users will not need to worry about plugins and plugin management with Helm. Helm is a powerful tool on its own and is complete with the features it promises out of the box. With that being said, the Helm community maintains a variety of different plugins that can be used to enhance Helm's capabilities. A list of these plugins can be found at https://helm.sh/docs/community/related/.
Helm provides a plugin subcommand for managing plugins, which contain further subcommands, described in the following table:
Plugins can provide a variety of different productivity enhancements.
The following are several examples of the upstream plugins:
- helm diff: Performs a diff between a deployed release and a proposed Helm upgrade
- helm secrets: Used to help conceal secrets from Helm charts
- helm monitor: Used to monitor a release and perform a rollback if certain events occur
- helm unittest: Used to perform unit testing on a Helm chart
We will continue discussing Helm configuration options by reviewing the different environment variables that can be set to change various aspects of Helm's behavior.
Environment variables
Helm relies on the existence of externalized variables to configure low-level options. The Helm documentation lists six primary environment variables used to configure Helm:
- XDG_CACHE_HOME: Sets an alternative location for storing cached files
- XDG_CONFIG_HOME: Sets an alternative location for storing Helm configuration
- XDG_DATA_HOME: Sets an alternative location for storing Helm data
- HELM_DRIVER: Sets the backend storage driver
- HELM_NO_PLUGINS: Disables plugins
- KUBECONFIG: Sets an alternative Kubernetes configuration file
Helm adheres to The XDG Base Directory Specification, which is designed to provide a standardized way of defining where different files are located on an operating system's filesystem. Based on the XDG specification, Helm automatically creates three different default directories on each operating system as required:
Helm uses the cache path for charts that are downloaded from upstream chart repositories. Installed charts are cached to the local machine to enable faster installation of the chart the next time it is referenced. To update the cache, a user can run the helm repo update command, which will refresh the repository metadata with the most recent information available, as well as save the chart to the local cache.
The configuration path is used to save repository information that was added by running the helm repo add command. When a chart that has not been cached is installed, Helm uses the configuration path to look up the URL of the chart repository. Helm uses that URL to understand where the chart resides for it to be downloaded.
The data path is used to store plugins. When a plugin is installed using the helm plugin install command, the plugin data is stored in this location.
Regarding the remaining environment variables we previously detailed, HELM_DRIVER is used to determine how the release state is stored in Kubernetes. The default value is secret, which is also the recommended value. Secret will Base64-encode the state in a Kubernetes Secret. Other options are configmap, which will store state in a plaintext Kubernetes ConfigMap and memory, which will store the state in the local process's memory. The use of local memory is intended for testing purposes and is not suitable for general purpose or production environments.
The HELM_NO_PLUGINS environment variable is used to disable plugins. If unset, the default value that keeps plugins enabled is 0. To disable plugins, the variable should be set to 1.
The KUBECONFIG environment variable is used to set the file used for authentication to the Kubernetes cluster. If unset, the default value will be ~/.kube/config. In most cases, users will not need to modify this value.
Another component of Helm that can be configured is tab completion, discussed next.
Tab completion
Bash and Z shell users can enable tab completion to simplify Helm usage. Tab completion allows Helm commands to be auto-completed when the Tab key is pressed, allowing users to perform tasks faster and helping prevent input mistakes.
This is similar to how most modern terminal emulators behave by default. When the Tab key is pressed, terminals try to guess what the next argument needs to be by observing the state of the command and the environment. For example, the cd /usr/local/b input can be tab-completed to cd /usr/local/bin in a Bash shell. Similarly, an input such as helm upgrade hello- can be tab-completed to read helm upgrade hello-world.
Tab completion can be enabled by running the following command:
$ source <(helm completion $SHELL)
The $SHELL variable must be either bash or zsh. Note that auto-completion will only exist in terminal windows that run the preceding command, so other windows will need to run this command as well to experience the auto-completion feature.
Authentication
Helm needs to be able to authenticate with a Kubernetes cluster in order to deploy and manage applications. It authenticates by referencing a kubeconfig file, which specifies different Kubernetes clusters and how to authenticate against them.
Those of you who are using Minikube when following this book will not need to configure authentication, as Minikube automatically configures a kubeconfig file each time a new cluster is created. Those of you who aren't running Minikube, however, will likely need to create a kubeconfig file or have one provided, depending on the Kubernetes distribution you are using.
A kubeconfig file can be created by leveraging three different kubectl commands:
- The first command is set-cluster:
kubectl config set-cluster
The set-cluster command will define a cluster entry in the kubeconfig file. It determines the Kubernetes cluster's hostname or IP address, along with its certificate authority.
- The next command is set-credentials:
kubectl config set-credentials
The set-credentials command will define the name of a user along with its authentication method and details. This command can configure a username and password pair, client certificate, bearer token, or authentication provider to allow users and administrators the ability to specify varying different methods of authentication.
- Then, we have the set-context command:
kubectl config set-context
The set-context command is used to associate a credential to a cluster. Once an association between a credential and a cluster is established, the user will be able to authenticate to the specified cluster using the credential's authentication method.
The kubectl config view command can be used to view the kubeconfig file. Notice how the clusters, contexts, and user stanzas of kubeconfig correspond to the previously described commands, as shown:
$ kubectl config view
apiVersion: v1
clusters:
- cluster:
certificate-authority: /home/helm-user/.minikube/ca.crt
server: https://192.168.99.102:8443
name: minikube
contexts:
- context:
cluster: minikube
user: minikube
name: minikube
current-context: minikube
kind: Config
preferences: {}
users:
- name: minikube
user:
client-certificate: /home/helm-user/.minikube/client.crt
client-key: /home/helm-user/.minikube/client.key
Once a valid kubeconfig file is present, Kubectl and Helm will be able to interact with a Kubernetes cluster.
In the next section, we will discuss how authorization is handled against a Kubernetes cluster.
Authorization/RBAC
While authentication is a means of confirming identity, authorization defines the actions that an authenticated user is allowed to perform. Kubernetes uses role-based access control (RBAC) to perform authorization on Kubernetes. RBAC is a system of designing roles and privileges that can be assigned to a given user or group of users. The actions a user is permitted to perform on Kubernetes depends on the roles that the user has been assigned.
Kubernetes provides many different roles on the platform. Three common roles are listed here:
- cluster-admin: Allows a user to perform any action against any resource throughout the cluster
- edit: Allows a user to read and write to most resources within a namespace or a logical grouping of Kubernetes resources
- view: Prevents a user from modifying existing resources, and only allows users to read resources within a namespace
Since Helm authenticates to Kubernetes using the credentials defined in the kubeconfig file, Helm is given the same level of access as the users defined in the file. If edit access is enabled, Helm can be assumed to have sufficient permission to install applications, in most cases. For only view access, Helm will not be able to install applications, as this level of access is read-only.
Users that run Minikube are given cluster-admin by default after cluster creation. While this would not be best practice in a production environment, it is acceptable for learning and experimenting. Those of you running Minikube will not have to worry about configuring authorization in order to follow along with both the concepts and examples provided in this book. Those of you using other Kubernetes clusters that aren't Minikube will need to make sure they are given at least the edit role to be able to deploy most applications with Helm. This can be done by asking an administrator to run the following command:
$ kubectl create clusterrolebinding $USER-edit --clusterrole=edit --user=$USER
Best practices around RBAC will be discussed in Chapter 9, Helm Security Considerations when we discuss, in greater detail, the concepts related to security, including how to appropriately apply roles to prevent mistakes or malicious intent in the cluster.