Wem vertraust du eigentlich, wenn du ein Community-Helm-Chart installierst?

Kurze Antwort: oft genug einem einzigen Menschen. Den du nicht kennst.

Das ist kein Drama, aber ein Betriebsrisiko. Bleiben bei so einem Chart die Updates aus, kommt über das Chart kein neueres Image mehr zu dir. Deshalb stelle ich vor jedem helm install drei Fragen: Wie alt ist die letzte Version? Wer steht dahinter? Und kann ich dem trauen? In der Regel nehme ich eher Charts von bekannten Unternehmen.

Der Entwickler, der vielleicht gerade ein Haus baut

Im Helm-Training zeige ich dafür gerne die Charts von groundhog2k. Die bauen nach eigener Beschreibung auf den originalen Docker-Images auf, nicht auf umgebauten. Und gepflegt werden sie im Kern von einer einzigen Person.

Jetzt stell dir vor, so ein Chart bekommt elf Monate lang keine neue Version. Kann viele Gründe haben. Der Entwickler ist krank. Hat keine Lust mehr. Oder baut gerade ein Haus, und am Wochenende wird betoniert statt gepflegt. Alles menschlich. Du zahlst ja auch nix dafür.

Nur: Über das Chart kommt dann kein neueres Image mehr zu dir. Und keiner sagt dir Bescheid. Genau da musst du hinschauen, wem du eigentlich vertraust.

Frage 1: Wie alt ist die letzte Version, aber wirklich?

Das ist mein erster Blick. Und der hat einen Haken: Artifact Hub zeigt dir oben als aktuelle Version die mit der höchsten Nummer. Nicht die jüngste.

Und jetzt kommt der Witz. Das MariaDB-Chart von groundhog2k sieht auf Artifact Hub genau nach so einem Fall aus. Angezeigt wird 4.44.0 vom November 2025. Riecht nach Winterschlaf.

Im Chart-Repo liegt aber 4.5.4 vom August 2026, mit deutlich neuerer MariaDB. Am 15. November 2025 ist dort eine Version 4.44 erschienen, drei Minuten vor einer 4.4.4 mit derselben MariaDB. Sieht schwer nach Vertipper aus. Und 44 ist größer als 5. Also gewinnt die alte Version seitdem jedes Rennen. Auch bei helm install ohne --version. Der holt dir dann die alte.

Die Versionsnummer ist also das Etikett, das Datum ist das Haltbarkeitsdatum. Und das liest du. Artifact Hub listet jede Version mit Datum, in der index.yaml eines klassischen Chart-Repos steht ein created dran. Ich hab’s für dich nachgezählt:

Zwei Minuten Arbeit, und du weißt, ob da jemand schläft oder nur die Anzeige.

Frage 2: Wer steht dahinter?

Hier hilft dir Artifact Hub weniger, als es aussieht. Der Haken „Verified Publisher“ klingt nach TÜV-Plakette. Er belegt aber nur: Der Herausgeber besitzt oder kontrolliert das Repository. Mehr nicht.

Den Haken trägt zum Beispiel auch das Repo von nicholaswilde, eine Einzelperson. Das MariaDB-Chart dort hat seit über fünf Jahren keine neue Version bekommen. Und groundhog2k, das gepflegt wird? Hat keinen Haken. Verifiziert ist also nur, wem das Repo gehört. Na prima.

Also rein ins Quell-Repo und auf die Commits geschaut. Wer schuftet hier wirklich? Ein Beweis ist die Liste nicht, aber ein verdammt guter Hinweis. Bei groundhog2k siehst du es sofort: über 90 Prozent der Commits von einem Account. Das ist fleißig, keine Frage. Aber genau das ist das Risiko, von dem ich rede. Wenn hier jemand ausfällt, dann eben diese eine Person. Ob wegen Bus oder wegen Bodenplatte.

Frage 3: Kann ich dem trauen?

Wenn ich weiß, wer dahintersteht, kommt die eigentliche Frage. Und da bin ich ganz ehrlich ein Gewohnheitstier: In der Regel nehme ich Charts von bekannten Unternehmen.

Frage 2 spart dir der Firmenname aber nicht. Schau dir auch da die Commits an. Und groß heißt nicht für immer: Bei Bitnami gab es aktualisierte Images mit fester Version irgendwann nur noch mit Subscription. Die Geschichte steht in Bitnami hat 86 Sterne. Nimm trotzdem das mit 15.

Meine klare Ansage

Ein helm install ist ein Vertrag mit jemandem, den du meistens nie gesehen hast. Lies wenigstens, wer unterschrieben hat. Erst das Datum, dann die Köpfe, dann das Vertrauen. Ein paar Minuten, und du weißt, ob dein Betrieb an einem Team hängt oder am Feierabend eines einzelnen Entwicklers.

Wie du Charts so prüfst, auswählst und notfalls dein eigenes baust, üben wir im Kubernetes Helm Training, am echten Cluster.