Im letzten Beitrag haben wir gezeigt, wie die Cortena Group beim Einstieg in Kubernetes vor allem mit Themen wie Netzwerkdesign und Datenhaltung zu kämpfen hatte.
Doch kaum war die Infrastruktur bereit, stellte sich die nächste große Herausforderung: Wie sorgt man in einem hochdynamischen Kubernetes-Cluster für Sicherheit, Kontrolle und Nachvollziehbarkeit – ohne dabei die Flexibilität zu verlieren?
Gerade beim Übergang in den Produktivbetrieb merken viele Unternehmen:
Security in Kubernetes ist nicht wie früher. Sie ist kein nachgelagerter Schritt – sondern integraler Bestandteil des Plattformdesigns.
Das Wichtigste in Kürze
In Kubernetes wird Sicherheit nicht „mitgeliefert“ – sie muss aktiv gestaltet werden:
- Sicherheit muss sichtbar gemacht werden, denn gefühlte Sicherheit reicht nicht aus
- Zertifikate müssen verwaltet,
- Secrets abgesichert,
- Compliance-Regeln durchgesetzt
- und die Plattform laufend überwacht werden.
Dieser Beitrag zeigt am Beispiel der Cortena Group, wie Sicherheit im Cluster ganz praktisch gedacht und umgesetzt werden kann – mit Tools, Prozessen und Add-ons, die Continum standardmäßig mitliefert.
Sicherheit messbar machen –„Gefühlte Sicherheit“ reicht nicht
Die Cortena Group stellte sich früh eine zentrale Frage: Woran erkennen wir eigentlich, ob unsere Kubernetes-Plattform sicher ist?
Früher reichte ein Blick auf Firewall-Regeln und Adminrechte – doch im Cluster ändern sich Zustände permanent. Pods starten neu, Konfigurationen ändern sich, Images werden ausgetauscht.
Das Problem: Es gibt keinen „sichtbaren“ Sicherheitsstatus.
Die Lösung: Mit dem CIS Kubernetes Benchmark prüft Continum automatisiert, ob sicherheitsrelevante Einstellungen wie Role-Based Access Control (RBAC), Netzwerkgrenzen oder API-Zugriffe korrekt gesetzt sind. So wird aus einem vagen Gefühl eine objektiv messbare Sicherheitsbasis – intern und gegenüber Auditoren.
Zertifikatsmanagement automatisieren – statt Ausfälle riskieren
Ein typischer Zwischenfall: Die Cortena Group verliert kurzfristig Zugriff auf einen internen Service – das Zertifikat war abgelaufen.
Manuelles Zertifikats-Handling ist fehleranfällig, gerade wenn viele Teams parallel deployen oder Dienste automatisiert hoch- und runterskalieren.
Die Schwierigkeit: Zertifikate laufen unbemerkt ab, weil niemand ihre Lebensdauer im Blick behält – oder sie zu spät ersetzt.
Die Lösung: Continum setzt auf den Cert-Manager, der Zertifikate automatisiert erstellt, verlängert und einbindet – mit Integration in Let’s Encrypt, ACME-Prozesse oder firmeneigene CAs. So wird auch die TLS-Terminierung von internen Services wie Redis oder PostgreSQL abgesichert, ohne dass sich Teams händisch darum kümmern müssen.
Git ist kein Tresor: Secrets in Kubernetes sicher verwalten
In der Anfangsphase speicherte das Entwicklerteam der Cortena Group Teile der Konfiguration – inklusive Passwörtern – versehentlich im Git-Repository.
Das passiert häufiger, als man denkt. In dynamischen Projekten wird schnell etwas „temporär“ abgelegt – und später vergessen.
Das Problem: Kubernetes bietet zwar ein Secret-Objekt – aber kein zentrales, sicheres Vault. Und: Viele Teams wissen nicht, wie sie ihre sensiblen Informationen sicher ins Cluster bringen.
Die Lösung: Continum integriert zentrale Secrets-Systeme wie Vault, OpenBao oder Azure Key Vault – und verbindet sie über den External Secrets Operator direkt mit dem Kubernetes-Cluster. So bleiben Secrets dort, wo sie hingehören – und sind gleichzeitig für Anwendungen sicher verfügbar.
Policies als Code – Auf „Wird schon passen“ kann man sich nicht verlassen
Die Dev-Teams der Cortena Group arbeiteten parallel – schnell entstanden unterschiedliche Konventionen. Manche nutzten veraltete Base-Images, andere deployten ohne TLS.
🔁 Ein Sicherheitsstandard war nicht konsistent durchgesetzt.
Die Schwierigkeit: Kubernetes lässt (standardmäßig) fast alles zu – wer Regeln will, muss sie definieren und durchsetzen.
Die Lösung: Continum nutzt die Policy-Engine Kyverno, die festlegt, was erlaubt ist – und was nicht:
✔ Nur genehmigte Images
✔ HTTPS-Verbindungspflicht
✔ Vermeidung von root-Rechten
✔ Erzwingen von TLS-Zertifikaten
Das Ergebnis: Eine Plattform, die kontrolliert, dokumentiert und absichert, ohne dabei die Entwicklung zu blockieren.
Die Cortena Group – von dynamisch zu sicher-dynamisch
Durch die Einführung der Sicherheitsbausteine wurde aus einer offenen, agilen Kubernetes-Plattform eine strukturierte, nachvollziehbare Betriebsumgebung.
Die Cortena Group kann heute:
✅ Sicherheitslücken frühzeitig erkennen
✅ Audits bestehen
✅ und die Verantwortung zwischen Entwicklung & Betrieb klar definieren
Ohne die Standardisierung durch Continum wäre das nicht in dieser Geschwindigkeit möglich gewesen.
Fazit: Sicherheit ist keine Option – sondern Voraussetzung für Skalierbarkeit
Die Erfahrungen der Cortena Group zeigen: Kubernetes-Sicherheit ist kein Add-on, das man „später“ löst.
Es braucht von Anfang an klare Strukturen, automatisierte Prozesse und ein bewusstes Verständnis für Zuständigkeiten – sowohl in der Entwicklung als auch im Betrieb.
Doch Sicherheit endet nicht bei Policies und Verschlüsselung.
Mindestens genauso wichtig ist die Frage: Wie behalten wir den Überblick?
Denn erst durch gezieltes Logging und Monitoring wird Sicherheit sichtbar, nachvollziehbar und überprüfbar.
Im nächsten Beitrag unserer Serie zeigen wir, wie Unternehmen mit den richtigen Werkzeugen Transparenz in ihren Kubernetes-Betrieb bringen – und wie sich Logging und Monitoring sinnvoll kombinieren lassen.
