Find Outdated Helm Charts – K8S
Wenn du sicherstellst, dass du die neueste Version der Helm-Charts-Software verwendest, die du in einem Kubernetes-Cluster installierst, kannst du bekannte Sicherheitsprobleme vermeiden und erhältst Zugriff auf die aktuellsten Projektfunktionen. Wenn du Helm zur Verwaltung deiner Releases nutzt, kann dir diese Anleitung dabei helfen, veraltete oder überholte Helm-Charts zu finden, die in deinem Cluster ausgeführt werden.
Index
Was ist Helm?
Helm-Charts sind eine Methode, um Anwendungen auf Kubernetes zu verwalten und zu deployen. Helm selbst ist ein Paketmanager für Kubernetes, ähnlich wie apt für Debian-basierte Linux-Distributionen oder yum für Red Hat-basierte Systeme. Die Helm-Charts sind im Wesentlichen Pakete von Kubernetes-Ressourcen, die in einer strukturierten Weise organisiert sind.
Helm und Helm-Charts erleichtern dir die Verwaltung von Anwendungen auf Kubernetes erheblich. Sie bieten eine standardisierte Methode, um Kubernetes-Deployments zu beschreiben und zu konfigurieren, und machen es dir einfacher, Anwendungen zu teilen, wiederzuverwenden und zu aktualisieren.
Tutorial
In diesem Beitrag erstellen wir ein PowerShell Skript, um die installierten Helm-Charts in einem Kubernetes-Cluster zu identifizieren und in unseren Helm-Repositories nach der letzten Version der Charts zu suchen. Die Ergebnisse sollen in einer Email versendet werden.
Das PowerShell Skript soll in einem Docker Container ausgeführt werden, wofür wir ein Docker-Image erstellen und als CronJob in einem Kubernetes-Cluster veröffentlichen.
Damit unser PowerShell Skript die nötigen Berechtigungen in einem Kubernetes-Cluster erhält, erstellen wir zusätzlich einen Service-Account mit entsprechender Berechtigung und Role-Binding.
PowerShell Skript: check-helm-chart
Erstelle einen neuen Ordner und dort ein neues PowerShell Skript und speichere es als check-helm-charts.ps1ab. Füge anschließend folgenden Inhalt in das Skript.
Das Skript sammelt eine Übersicht aller installierten Helm-Charts in den Kubernetes-Namespaces, vergleicht ihre Versionen mit den neuesten verfügbaren, erstellt daraus einen HTML-Bericht und sendet diesen per E-Mail.
|
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 '^(.*)-([^-]+) |
Erklärung des Skriptes
Schritt 1: Einlesen der Umgebungsvariablen. Zu Beginn lädst du verschiedene Umgebungsvariablen. Diese Variablen enthalten Informationen wie die SMTP-Einstellungen (Server, Port, Benutzername und Passwort), die E-Mail-Adresse des Empfängers und die Helm-Repositories, die du überprüfen möchtest:
$smtpServer, $smtpPort, $smtpUser, $smtpPassword: SMTP-Einstellungen für den E-Mail-Versand.
$recipientEmail: Die E-Mail-Adresse, an die der Bericht gesendet werden soll.
$helmRepos: Die Liste der Helm-Repositories aus denen die installierten Helm-Charts stammen. In diesen Repositories wird dann nach der aktuellsten Version gesucht, getrennt durch Komma.
Schritt 2: Namespace-Ermittlung, das Skript holt alle Kubernetes-Namespaces und speichert sie in einer Liste.
kubectl get namespaces gibt alle Namen der Namespaces zurück.
Schritt 3: Für jedes angegebene Helm-Repository wird ein Eintrag in Helm hinzugefügt und die Repository-Informationen werden aktualisiert:
Mit helm repo add werden diese Repositories zu Helm hinzugefügt.
helm repo update sorgt dafür, dass Helm die neuesten Repository-Informationen lädt.
Schritt 4: Das System durchläuft die Namespaces und ermittelt für jeden Namespace im Kubernetes-Cluster die aktuell installierten Helm-Charts. Es extrahiert die Informationen zu jedem Chart, wie Name, aktuelle Version, App-Version und Status, und prüft anschließend, ob eine aktuellere Version verfügbar ist.
Schritt 5: Erstelle einer Tabelle mit den Ergebnissen und einfachen HTML-Layouts. Für jedes gefundene Helm-Chart werden die Informationen (Namespace, Name, aktuelle Version, App-Version, neueste Version, Status) in einer Tabelle gespeichert.
Schritt 6: Schließlich wird eine E-Mail mit dem Status der Helm-Charts verschickt.
Docker Deployment
Im selben Ordner erstellen wir eine .dockerfile mit dem folgenden Inhalt.
Dieses Dockerfile erstellt ein Docker-Image, das auf PowerShell und Ubuntu basiert. Es installiert notwendige Tools wie die Azure CLI, kubectl und Helm. Anschließend kopiert es ein PowerShell-Skript in den Container und führt das Skript beim Start des Containers aus.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
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
Um aus einem Container heraus auf ein Kubernetes-Cluster zuzugreifen und lesende Berechtigungen zu haben, um Helm Releases auszulesen, musst du einige Schritte befolgen.
- Service Account und RBAC: Einrichten eines Service Accounts mit den entsprechenden Berechtigungen.
- Konfiguration von kubectl im Container: Den Service Account so einbinden, dass der Container ihn nutzen kann.Helm Releases abrufen: kubectl oder helm verwenden, um die Releases abzurufen.
Service Account erstellen und RBAC konfigurieren
Du benötigst einen Service Account mit den entsprechenden Rollen und Bindungen, um Lesezugriff auf alle Ressourcen im Cluster zu haben, die für das Auslesen der Helm-Releases notwendig sind.
Erstelle folgende helm-version-check-sa.yaml und speichere diese im Unterordner /rbac ab.
|
1 2 3 4 5 |
# helm-version-check-sa.yaml apiVersion: v1 kind: ServiceAccount metadata: name: helm-version-check |
Role und RoleBinding erstellen
Die ClusterRole definiert, welche Ressourcen und Aktionen im Kubernetes-Cluster erlaubt sind. Erstelle eine ClusterRole helm-version-check-role.yaml ebenfalls im Unterordner /rbac mit den nötigen Lese-Rechten.
|
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"] |
Anschließend erstellen wir das erforderliche Role-Binding helm-version-check-rolebinding.yaml wieder im Unterordner /rbac, diese ClusterRoleBinding verknüpft die ClusterRole mit unserem ServiceAccount. Das bedeutet, dass der ServiceAccount die Rechte und Berechtigungen der ClusterRole nutzen kann.
|
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 unserem Fall gehört die Aufgabe Helm-Chart Versionen zu vergleichen ins Monitoring. Deshalb veröffentlichen wir die eben erstellten Ressourcen im Namespace monitoring.
|
1 |
kubectl apply -f ./rbac/*.yaml -n monitoring |
K8S Deployment als CronJob
Als letzten Schritt erstellen wir den CronJob helm-check-version.yaml mit dem folgenden Inhalt.
Dieser CronJob führt jeden Montag um 7:00 Uhr eine Aufgabe aus. Dabei wird ein Docker-Container gestartet, der mit den angegebenen Helm-Repositories arbeitet und die Versionen prüft. Falls die Aufgabe fehlschlägt, wird sie bis zu 4 Mal erneut versucht. Der Job verwendet dabei den eben erstellten ServiceAccount, um auf die erforderlichen Ressourcen im Cluster zuzugreifen, und sendet die Ergebnisse per E-Mail an die konfigurierte Adresse.
|
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 |
Nach dem Erstellen der Ressource übernehmen wir diese in unserem Kubernetes-Cluster mit folgenden Befehl:
|
1 |
kubectl apply -f ./helm-check-version.yaml -n monitoring |
Zusammenfassung
Diese Anleitung zeigt, wie man ein PowerShell-Skript entwickelt und als CronJob in einem Kubernetes-Cluster deployt, um veraltete Helm-Charts zu finden. Das Skript prüft installierte Helm-Charts in einem Kubernetes-Cluster, vergleicht ihre Versionen mit den neuesten Versionen aus definierten Helm-Repositories und sendet die Ergebnisse als HTML-Bericht per E-Mail.
Umsetzungsschritte:
PowerShell-Skript: Erstellt einen Bericht über installierte Helm-Charts und ihre Versionen.
Docker-Container: Das Skript wird in einem Docker-Container ausgeführt, der PowerShell, kubectl und Helm installiert.
ServiceAccount und RBAC: Ein ServiceAccount mit passenden Berechtigungen ermöglicht dem Skript den Zugriff auf Kubernetes-Ressourcen.
CronJob: Dieser führt das Skript wöchentlich aus und versendet eine E-Mail mit den Ergebnissen. Er nutzt den ServiceAccount und wiederholt sich bei Fehlern bis zu 4 Mal.
Installierte Helm-Charts in einem Kubernetes-Cluster prüfen.
Durch die Kombination von automatisierter Versionsprüfung und übersichtlicher Berichterstattung per E-Mail bleibt der Zustand der Helm-Charts transparent. Unternehmen profitieren von einem standardisierten und wiederholbaren Ansatz, der sicherstellt, dass Kubernetes-Deployments aktuell und sicher sind.
Unterstützung benötigt?
Gerne stellen wir Ihnen unsere Leistungen und Lösungen in einem persönlichen Gespräch vor.
Wir freuen uns über Ihre Kontaktaufnahme!
Leave a Reply
<p>Danke für Ihre Anregungen, Fragen und Hinweise.<br/>Infos zum <a href="https://www.active-directory-faq.dekontakt/">Datenschutz</a></p>