ohMyHelm: Helm Charts für 15-Factor Apps ohne Kubernetes-Komplexität

TL;DR

• ohMyHelm ist ein universeller Helm-Chart-Wrapper, der produktionsreife Workloads bereitstellt, ohne dass Teams eigene Templates pflegen müssen – die gesamte Definition erfolgt über eine zentrale values.yaml.
• Standardkomponenten wie Deployments/StatefulSets, Ingress, RBAC, ConfigMaps, Secrets (inklusive External Secrets Operator) und Observability-Hooks sind integriert und nach Best Practices vorkonfiguriert.
• Die 15-Factor-Prinzipien (Konfiguration, Backing Services, Logs, Telemetrie, Parity) lassen sich mit ohMyHelm konsistent in Helm-Modellen abbilden – ideal für standardisierte Cloud-Native-Architekturen auf /kubernetes/.
• Guardrails wie Resource Limits, Network Policies, Security Contexts und standardisierte Service-Abhängigkeiten machen es leichter, regulatorische Anforderungen und interne /compliance/-Richtlinien durchzusetzen.
• ayedo nutzt ohMyHelm selbst als Baustein einer souveränen, policy-konformen Plattform und unterstützt Teams dabei, ihre Anwendungen ohne Kubernetes-Overhead in eine sichere, auditierbare Betriebsumgebung zu überführen.

---

Warum Helm-Charts oft mehr Komplexität als Nutzen bringen

Helm hat sich als De-facto-Standard für das Packaging von Anwendungen auf /kubernetes/ etabliert. In der Praxis sehen viele Teams jedoch zwei gegensätzliche Realitäten:

• Entweder entstehen für jeden Dienst individuelle Helm-Charts mit eigenem Templating-Stil, eigenem Verständnis von „Best Practice“ und unterschiedlichem Reifegrad.
• Oder es bleibt bei Copy & Paste aus vorhandenen Repositories, was zu inkonsistenten Ressourcen, fehlenden Guardrails und schwer nachvollziehbaren Abhängigkeiten führt.

Für Engineering-Leads mit Compliance-Verantwortung ist das ein Dilemma: Sie tragen Verantwortung für Stabilität, Sicherheit und regulatorische Konformität, ohne jede Zeile Template-Code selbst prüfen zu können. Genau hier setzt ohMyHelm an – als Abstraktionsschicht, die den Kubernetes-Unterbau kapselt und gleichzeitig standardisierte, auditierbare Strukturen vorgibt.

---

Was ist ohMyHelm? Eine Abstraktionsschicht über Kubernetes

ohMyHelm ist kein weiterer „Anwendungs-Chart“, sondern ein universeller Helm-Chart-Wrapper. Statt individuelle Templates für jede Anwendung zu schreiben, binden Sie ohMyHelm einmal als Dependency ein und beschreiben Ihre Anwendung ausschließlich über Konfigurationswerte.

Kernidee: Templates zentral, Logik in values.yaml

Die Grundidee ist einfach:

• Helm-Templates für typische Ressourcen (Deployments, Services, Ingress, RBAC, Monitoring usw.) existieren zentral in ohMyHelm.
• Ihre Anwendung referenziert diese Templates als Dependency mit eigenem Alias.
• Alles, was anwendungsspezifisch ist – Images, Ports, Umgebungsvariablen, Secrets, Limits, Policies – wird ausschließlich in der values.yaml Ihres Charts konfiguriert.

Für Sie als verantwortliche Person bedeutet das:

• Kein eigener Templating-DSL-Zoo in jedem Repository.
• Weniger Fehlerquellen beim Einführen neuer Sicherheitsvorgaben.
• Ein konsistentes Fundament, auf dem unterschiedliche Teams arbeiten können, ohne ständig Helm-Details neu zu interpretieren.

---

Zentrale Features für produktionsreife Deployments

ohMyHelm zielt bewusst auf produktionsreife, mehrstufige Landschaften ab – mit Standards, die sich in Audits und im 24/7-Betrieb bewähren.

Workload-Typen: Deployment, StatefulSet, Services, Ingress

ohMyHelm unterstützt sowohl klassische stateless Deployments als auch StatefulSets, die zum Beispiel für Datenbanken oder zustandsbehaftete Services nötig sind. Über Ihre Konfiguration legen Sie fest:

• Ob ein Deployment oder StatefulSet erzeugt wird.
• Wie Services (ClusterIP, NodePort, LoadBalancer) aussehen sollen.
• Welche Ingress-Routen bereitgestellt werden – ob einfache HTTP-Routen oder komplexere Host-/Pfad-Kombinationen mit TLS.

Teams müssen dafür keine eigenen YAML-Manifeste erstellen, sondern nur deklarieren, wie der gewünschte Endzustand aussehen soll.

Konfiguration & Secrets: ConfigMaps, ESO und RBAC

ohMyHelm bringt integrierte Mechanismen für Konfiguration und Secrets mit:

• ConfigMaps für nicht-sensitive Konfigurationsdaten (z. B. Feature-Flags, Framework-Settings).
• Secrets für Passwörter, Tokens und Zertifikate.
• Optional die Integration mit einem External Secrets Operator (ESO), der Secrets beispielsweise aus /apps/hashicorp-vault/ bezieht.

Damit haben Sie eine klare Trennung:

• Langfristige, sichere Speicherung von Geheimnissen in einem Secret-Backend wie Vault.
• Kubernetes-nahe Verteilung dieser Secrets über ESO.
• Einheitliche Anbindung Ihrer Anwendungen an diese Secrets über ohMyHelm.

Zusätzlich können Sie ServiceAccounts und RBAC-Rollen pro Anwendung definieren. Das verhindert den verbreiteten „default-ServiceAccount“-Antipattern und ermöglicht Least-Privilege-Ansätze, ohne für jeden Dienst eigene, manuell gepflegte Rollen schreiben zu müssen.

Observability: Monitoring und Metriken eingebaut

Moderne Cloud-Native-Architekturen sind ohne Observability nicht sinnvoll zu betreiben. ohMyHelm bietet hierfür standardisierte Hooks:

• Konfiguration von Readiness- und Liveness-Probes.
• Optionale Prometheus ServiceMonitors, mit denen Metriken automatisiert von Ihren Workloads eingesammelt werden.
• Saubere HTTP-Endpunkte für Health- und Metrics-Routen, die sich mit Tools wie /apps/grafana/ visualisieren lassen.

Damit ist Observability kein „nachträglich drangeflanschtes“ Thema mehr, sondern Bestandteil des Standard-Deployment-Modells.

---

15-Factor-Apps mit ohMyHelm modellieren

Die ursprünglichen 12-Factor- und weiterentwickelten 15-Factor-Prinzipien sind für viele Teams die Blaupause ihrer Cloud-Native-Strategie. ohMyHelm ist explizit darauf ausgelegt, diese Prinzipien technisch abzubilden.

Konfiguration als erste Bürgerin: values.yaml

Statt Konfiguration in Containern zu backen oder in unterschiedlichen Umgebungen unterschiedliches Templating zu betreiben, wird alles über values.yaml gesteuert:

• Image-Referenzen und Versionen.
• Konfigurationsschalter und Feature-Flags.
• Umgebungsspezifische Settings (z. B. externe URLs, Timeouts, Limits).

Dadurch erreichen Sie:

• Eine klare Trennung von Build- und Release-Phase.
• Eine Versionierung aller Konfigurationen im Git-Repository.
• Transparenz darüber, welche Einstellungen in welchem Umfeld aktiv sind.

Backing Services als deklarative Abhängigkeiten

15-Factor-Apps behandeln Backing Services – Datenbanken, Queues, Caches, externe APIs – als auswechselbare Ressourcen. In Helm-Welt bedeutet das:

• Backing Services werden entweder als eigene Charts deployt oder als externe, verwaltete Dienste angebunden.
• ohMyHelm modelliert die Abhängigkeiten über Helm-Dependencies und values.yaml.

Sie definieren zum Beispiel:

• Die Verbindung zu einer PostgreSQL-Instanz.
• Ein Redis-Cluster als Cache.
• Eine Observability- oder Security-Komponente als begleitenden Dienst.

All diese Ressourcen bleiben voneinander entkoppelt, während das Deployment-Modell konsistent bleibt.

Logs und Telemetrie als kontinuierlicher Datenstrom

Logs werden im 15-Factor-Modell als kontinuierlicher Event-Stream verstanden, nicht als lokale Dateien. In einer /kubernetes/-Umgebung bedeutet das:

• Container loggen auf stdout/stderr.
• Zentrale Log-Pipelines lesen diese Streams ein.

ohMyHelm sorgt dafür, dass Ihre Workloads die nötigen Labels, Ports und Endpunkte bereitstellen, damit Logging-, Metrics- und Tracing-Stacks diese Daten aufnehmen können. In Kombination mit Tools wie /apps/grafana/ entsteht so ein konsistentes Observability-Bild über alle Anwendungen hinweg.

---

Compliance-taugliche Guardrails ohne Mehraufwand

Mit steigenden regulatorischen Anforderungen – vom europäischen Data Act bis hin zu branchenspezifischen Normen – wird es für Plattform-Verantwortliche immer wichtiger, klare technische Guardrails zu etablieren. ohMyHelm unterstützt genau diese Aufgabe.

Resource Limits und Requests als Standard

Fehlende oder inkonsistente Resource Limits sind ein häufiger Befund in Audits. In ohMyHelm gehören sie zur Grundausstattung:

• CPU- und Memory-Requests und -Limits können je Anwendung zentral definiert werden.
• Organisationen können verpflichtende Mindestvorgaben definieren, die in allen ohMyHelm-Instanzen gelten.

So vermeiden Sie „Noisy Neighbors“ und unplanbare Kosten – und erfüllen zugleich häufige /compliance/-Vorgaben für Kapazitätsplanung und Risikomanagement.

Network Policies und Service-Isolation

Netzwerksegmentierung ist ein wichtiger Baustein sicherer Plattformen. In Kombination mit einem CNI wie /apps/cilium/ können Sie:

• Standard-Netzwerk-Policies für unterschiedliche Applikationsklassen definieren.
• Nur die tatsächlich benötigten Kommunikationspfade freischalten.
• Ost-West-Traffic in Ihrem Cluster gezielt kontrollieren.

ohMyHelm hilft dabei, diese Policies als wiederkehrendes Muster in Ihren Charts zu verankern, statt sie für jeden Dienst neu zu definieren.

Security Contexts und Laufzeit-Härtung

Security Contexts sind essenziell, um Container-Laufzeitumgebungen zu härten:

• Nicht-root-User.
• Schreibgeschützte Dateisysteme, wo sinnvoll.
• Droppen unnötiger Linux-Capabilities.

ohMyHelm bringt hierfür parametrische Konfigurationen mit, die einmal im Sinne Ihrer Sicherheitsrichtlinien definiert und dann für alle Anwendungen wiederverwendet werden können. Das reduziert das Risiko, dass einzelne Services „unter dem Radar“ mit zu weitreichenden Rechten betrieben werden.

Einbettung in europäische Regulierung

Am 11. Januar 2024 ist der europäische Data Act in Kraft getreten; zentrale Pflichten zur Datenportabilität und Interoperabilität greifen ab dem 12. September 2025. Ergänzt wird dies durch weitere Initiativen rund um Cloud-Souveränität und Standardisierung.

ohMyHelm fügt sich in dieses Bild ein, indem es:

• Standardisierte, maschinenlesbare Konfigurationen erzwingt.
• Portabilität fördert, weil Ihre Anwendungsdefinitionen nicht an einen spezifischen Cloud-Provider gebunden sind.
• Die technische Grundlage schafft, um Plattform-Policies transparent und reproduzierbar umzusetzen.

---

Praktisches Szenario: Eine Django-App mit ohMyHelm denken

Wie sieht das in der Praxis aus? Statt ein vollständiges Manifest oder Chart zu zeigen, konzentrieren wir uns auf die Struktur, die Sie als verantwortliche Person im Blick haben sollten.

Stellen Sie sich eine klassische Django-Applikation vor, die:

• Eine PostgreSQL-Datenbank nutzt.
• Über HTTPS im öffentlichen Internet erreichbar ist.
• Über Celery-Worker asynchrone Jobs verarbeitet.
• Logging und Metriken an die zentrale Observability-Umgebung liefert.
• Sensitive Konfigurationen (z. B. SECRET_KEY, Datenbank-Passwörter) in /apps/hashicorp-vault/ hält.

In einer ohMyHelm-basierten values.yaml würden sich – auf hohem Abstraktionsniveau – folgende logische Blöcke finden:

1. Basis-Workload
   Definition des Containers (Image, Tag, Ports), Replikazahl, Probes, Requests/Limits. Hier legen Sie auch fest, ob ein Deployment oder StatefulSet verwendet wird.

2. Konfiguration und Secrets

   • Konfigurationsparameter wie Debug-Flags, Allowed Hosts, externe URLs.
   • Verweise auf Secrets, die über den External Secrets Operator aus Vault bezogen werden (z. B. Datenbank-URL, SECRET_KEY).

3. Backing Services
   Deklaration, ob die PostgreSQL-Datenbank im selben Cluster bereitgestellt oder extern betrieben wird, inklusive der dafür notwendigen Connection-Informationen.

4. Ingress und TLS

   • Hostname, Pfade, TLS-Konfiguration.
   • Optionale Weiterleitungen, HSTS-Settings, Konfiguration von HTTP-Headern für Security-Policies.

5. Observability

   • Aktivierung eines ServiceMonitors für Metriken.
   • Definition der Health- und Metrik-Endpunkte.
   • Labels und Annotations für Ihre zentrale Logging- und Tracing-Pipeline.

6. Security & Compliance

   • SecurityContext-Parameter (z. B. RunAsNonRoot).
   • NetworkPolicy-Profile, die den erlaubten Zugriff auf Datenbank und andere Services definieren.
   • RBAC-Rollen, falls der Django-Service mit der Kubernetes-API interagieren muss (z. B. für CronJobs oder Management-Aufgaben).

Das Entscheidende: Ihre Dev-Teams fokussieren sich auf diese logischen Aspekte – nicht auf die korrekte YAML-Syntax, API-Versionen oder Templating-Fallstricke. Gleichzeitig bleiben alle sicherheitsrelevanten Parameter sichtbar, versionierbar und überprüfbar.

---

Häufige Fragen

Worin unterscheidet sich ohMyHelm von „klassischen“ Helm-Charts?

Klassische Charts bündeln Templates und Konfiguration für eine konkrete Anwendung. ohMyHelm ist dagegen ein generischer Wrapper: Die Templates sind bewusst allgemein gehalten und werden über values.yaml auf Ihre konkrete Anwendung zugeschnitten. Das reduziert die Fragmentierung Ihrer Chart-Landschaft und erleichtert es, zentrale Best Practices über viele Dienste hinweg durchzuziehen.

Wie fügt sich ohMyHelm in eine bestehende Plattform-Landschaft ein?

ohMyHelm ergänzt bestehende /platform/-Komponenten, statt sie zu ersetzen. Es integriert sich problemlos in CI/CD- und GitOps-Workflows, in denen Sie heute schon Ihre /kubernetes/-Ressourcen ausliefern. Komponenten wie /apps/hashicorp-vault/ für Secrets, /apps/grafana/ für Observability oder /apps/cilium/ für Netzwerksegmentierung bleiben wie gewohnt bestehen – ohMyHelm liefert lediglich ein einheitliches Modell, wie Anwendungen diese Bausteine konsumieren.

Wie unterstützt ayedo bei Governance und Compliance rund um ohMyHelm?

Wir verstehen ohMyHelm als zentrale Schnittstelle zwischen Anwendungsentwicklung und Governance. ayedo unterstützt Sie dabei, Policies für Resource Limits, Security Contexts, Network Policies und RBAC als wiederverwendbare Profile zu definieren und in ohMyHelm zu verankern. So lassen sich Anforderungen aus /compliance/-Regelwerken übersetzen in konkrete, versionierte Konfigurationen, die auf allen Stages vom Test-Cluster bis zur produktiven Umgebung konsistent angewendet werden können.

Weitere Fragen? Siehe unsere FAQ

---

Von der Theorie zur Umsetzung

ohMyHelm entfaltet seinen vollen Wert, wenn es nicht nur als technisches Werkzeug verstanden wird, sondern als Teil einer konsistenten, souveränen Plattform-Architektur. Genau an dieser Schnittstelle arbeitet ayedo.

Wir kombinieren:

• Eine standardisierte Deploymentschicht mit ohMyHelm.
• Ein souveränes Plattform-Ökosystem auf /kubernetes/ mit integrierten Bausteinen wie /apps/hashicorp-vault/ für Secrets, /apps/grafana/ für Observability und /apps/cilium/ für Netzwerksicherheit.
• Ein klares Governance-Modell, das technische Guardrails (Limits, Policies, Security-Profile) mit Ihren organisatorischen Anforderungen und regulatorischen Pflichten verbindet.

In gemeinsamen Projekten entwickeln wir mit Ihren Teams:

• Wiederverwendbare ohMyHelm-Profile für Ihre häufigsten Anwendungstypen (z. B. Web-APIs, Worker, CronJobs).
• Ein Policy-Framework, das Anforderungen aus /compliance/-Regelwerken in konkrete, überprüfbare Konfiguration übersetzt.
• GitOps-kompatible Workflows, in denen jedes Deployment einer Anwendung zugleich ein überprüfbares Compliance-Artefakt ist.

So entsteht eine Umgebung, in der Dev-Teams produktiv arbeiten können, ohne sich tief in Kubernetes-Details einzuarbeiten – und in der Sie als verantwortliche Person jederzeit nachvollziehen können, welche Sicherheits- und Compliance-Standards tatsächlich im Cluster gelebt werden.

Wenn Sie diesen Schritt gehen möchten und ohMyHelm als Baustein einer tragfähigen, europäischen Cloud-Native-Strategie nutzen wollen, starten Sie am besten mit unserem ohMyHelm Quick Start.