Find Outdated Helm Charts – K8S
Ensuring that you are using the latest version of the Helm Charts software that you install in a Kubernetes cluster can help you avoid known security issues and give you access to the latest project features. If you are using Helm to manage your releases, this guide can help you find outdated or obsolete Helm Charts running in your cluster.
Index
Whas is Helm?
Helm charts are a method for managing and deploying applications on Kubernetes. Helm itself is a package manager for Kubernetes, similar to apt for Debian-based Linux distributions or yum for Red Hat-based systems. The Helm charts are essentially packages of Kubernetes resources organized in a structured way.
Helm and Helm charts make it much easier to manage applications on Kubernetes. They provide a standardized way to describe and configure Kubernetes deployments and make it easier to share, reuse and update applications.
Tutorial
In this article, we will create a PowerShell script to identify the installed Helm charts in a Kubernetes cluster and search for the latest version of the charts in our Helm repositories. The results should be sent in an email.
The PowerShell script should be executed in a Docker container for which we create a Docker image and publish it as a CronJob in a Kubernetes cluster.
To give our PowerShell script the necessary permissions in a Kubernetes cluster, we also create a service account with the corresponding authorization and role binding.
PowerShell Script: check-helm-chart
Create a new folder and a new PowerShell script there and save it as check-helm-charts.ps1ab. Then add the following content to the script.
The script collects an overview of all installed Helm charts in the Kubernetes namespaces, compares their versions with the latest available ones, creates an HTML report and sends it by email.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
$smtpServer = $env:SMTP_SERVER $smtpPort = $env:SMTP_PORT $smtpUser = $env:SMTP_USER $smtpPassword = $env:SMTP_PASSWORD $recipientEmail = $env:RECIPIENT_EMAIL $helmRepos = $env:HELM_REPOS -split ',' $namespaces = $(kubectl get namespaces -o jsonpath='{.items[*].metadata.name}').Split(" ") $tableData = @() foreach ($repo in $helmRepos) { $name, $url = $repo -split '=' helm repo add $name $url } helm repo update foreach ($namespace in $namespaces) { Write-Output "Namespace: $($namespace)" $installedCharts = helm list --namespace $namespace --output json | ConvertFrom-Json foreach ($chart in $installedCharts) { $chartName = $chart.name $currentChart = $chart.chart $currentVersion = ($chart.chart -replace '^(.*)-([^-]+) |
Explanation of the script
Step 1: Loading the environment variables. At the beginning you load various environment variables. These variables contain information such as the SMTP settings (server, port, user name and password), the e-mail address of the recipient and the Helm repositories that you want to check:
$smtpServer, $smtpPort, $smtpUser, $smtpPassword: SMTP settings for sending emails.
$recipientEmail: The email address to which the report should be sent.
$helmRepos: The list of Helm repositories from which the installed Helm charts originate. These repositories are then searched for the latest version, separated by commas.
Step 2: Namespace determination, the script retrieves all Kubernetes namespaces and saves them in a list.
kubectl get namespaces returns all names of the namespaces.
Step 3: For each specified Helm repository, Helm adds an entry and updates the repository information. With helm repo add, Helm adds these repositories. helm repo update ensures that Helm loads the latest repository information.
Step 4: The process runs through the namespaces and determines the currently installed Helm charts for each namespace in the Kubernetes cluster. It extracts information for each chart, such as name, current version, app version, and status, and then checks for the latest version.
Step 5: Create a table with the results and simple HTML layouts. For each helmet chart found, the information (namespace, name, current version, app version, latest version, status) is saved in a table.
Step 6: Finally, an email is sent with the status of the helmet charts.
Docker Deployment
In the same folder, we create a .dockerfile with the following content.
This Dockerfile creates a Docker image based on PowerShell and Ubuntu. It installs necessary tools such as the Azure CLI, kubectl and Helm. It then copies a PowerShell script into the container and executes the script when the container is started.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
FROM mcr.microsoft.com/powershell:7.3-ubuntu-22.04 RUN apt-get update && \ apt-get install -y curl apt-transport-https gnupg && \ curl -sL https://aka.ms/InstallAzureCLIDeb | bash && \ curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl" && \ chmod +x ./kubectl && \ mv ./kubectl /usr/local/bin/kubectl && \ curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash COPY check-helm-charts.ps1 /check-helm-charts.ps1 WORKDIR / CMD ["pwsh", "/check-helm-charts.ps1"] |
Deployment
To access a Kubernetes cluster from a container and have read permissions to read Helm releases, you need to follow a few steps.
- Service account and RBAC: Set up a service account with the corresponding authorizations.
- Configure kubectl in the container: Integrate the service account so that the container can use it. Retrieve Helm releases: Use kubectl or helm to retrieve the releases.
Create a service account and configure RBAC
You need a service account with the corresponding roles and bindings to have read access to all resources in the cluster that are necessary for reading the Helm releases.
Create the following helm-version-check-sa.yaml and save it in the /rbac subfolder.
|
1 2 3 4 5 |
# helm-version-check-sa.yaml apiVersion: v1 kind: ServiceAccount metadata: name: helm-version-check |
Create role and RoleBinding
The ClusterRole defines which resources and actions are permitted in the Kubernetes cluster. Create a ClusterRole helm-version-check-role.yaml also in the /rbac subfolder with the necessary read rights.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
# helm-version-check-role.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: helm-version-check rules: - apiGroups: [""] resources: ["pods", "services", "endpoints", "configmaps", "secrets", "namespaces"] verbs: ["get", "list"] - apiGroups: ["apps", "extensions"] resources: ["deployments", "replicasets", "statefulsets"] verbs: ["get", "list"] - apiGroups: ["batch"] resources: ["jobs", "cronjobs"] verbs: ["get", "list"] - apiGroups: ["helm.sh"] resources: ["releases"] verbs: ["get", "list"] |
We then create the required role binding helm-version-check-rolebinding.yaml again in the /rbac subfolder; this ClusterRoleBinding links the ClusterRole with our ServiceAccount. This means that the ServiceAccount can use the rights and authorizations of the ClusterRole.
|
1 2 3 4 5 6 7 8 9 10 11 12 |
# helm-version-check-rolebinding.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: helm-version-check-binding roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: helm-version-check subjects: - kind: ServiceAccount name: helm-version-check |
In our case, the task of comparing Helm chart versions belongs in monitoring. We therefore publish the resources we have just created in the monitoring namespace.
|
1 |
kubectl apply -f ./rbac/*.yaml -n monitoring |
K8S Deployment als CronJob
The last step is to create the CronJob helm-check-version.yaml with the following content.
This CronJob executes a task every Monday at 7:00 am. It starts a Docker container that works with the specified Helm repositories and checks the versions. If the task fails, it is retried up to 4 times. The job uses the ServiceAccount just created to access the required resources in the cluster and sends the results by email to the configured address.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 |
apiVersion: batch/v1 kind: CronJob metadata: name: helm-version-check spec: concurrencyPolicy: Forbid schedule: "0 7 * * 1" jobTemplate: spec: template: spec: serviceAccountName: helm-version-check containers: - name: helm-version-check image: artifactory.fa01.net/docker-local/helm-version-check:v1.0.6 env: - name: SMTP_SERVER value: "smtp.office365.com" - name: SMTP_PORT value: "587" - name: SMTP_USER value: "<USERNAME>" - name: SMTP_PASSWORD value: "<PASSWORD>" - name: RECIPIENT_EMAIL value: "<DENNIS.RUPP@FIRSTATTRIBUTE.COM>" - name: HELM_REPOS value: "jfrog=https://charts.jfrog.io,grafana=https://grafana.github.io/helm-charts,ingress-nginx=https://kubernetes.github.io/ingress-nginx,jetstack=https://charts.jetstack.io" restartPolicy: OnFailure backoffLimit: 4 - name: SMTP_USER value: "<USERNAME>" - name: SMTP_PASSWORD value: "<PASSWORD>" - name: RECIPIENT_EMAIL value: "<DENNIS.RUPP@FIRSTATTRIBUTE.COM>" - name: HELM_REPOS value: "jfrog=https://charts.jfrog.io,grafana=https://grafana.github.io/helm-charts,ingress-nginx=https://kubernetes.github.io/ingress-nginx,jetstack=https://charts.jetstack.io" restartPolicy: OnFailure backoffLimit: 4 |
After creating the resource, we transfer it to our Kubernetes cluster with the following command:
|
1 |
kubectl apply -f ./helm-check-version.yaml -n monitoring |
Summary
This guide shows how to develop a PowerShell script and deploy it as a CronJob in a Kubernetes cluster to find outdated Helm charts. The script checks installed Helm charts in a Kubernetes cluster, compares their versions with the latest versions from defined Helm repositories and sends the results as an HTML report by email.
Implementation steps:
PowerShell script: Creates a report on installed Helm charts and their versions.
Docker container: The script is executed in a Docker container that installs PowerShell, kubectl and Helm.
ServiceAccount and RBAC: A ServiceAccount with appropriate permissions allows the script to access Kubernetes resources.
CronJob: This executes the script weekly and sends an email with the results. It uses the ServiceAccount and repeats itself up to 4 times in the event of errors.
The combination of automated version checking and clear reporting by email keeps the status of the Helm charts transparent. Companies benefit from a standardized and repeatable approach that ensures Kubernetes deployments are up-to-date and secure.
FirstAttribute AG – Identity Management & IAM Cloud Services
We would be happy to present our services and solutions to you. Get in touch and find out how we can help you.
Leave a Reply
<p>Your email is safe with us.<br/>Information about our <a href="https://activedirectoryfaq.com/contact-us/">data protection policies</a></p>