Mit Observability die Sicherheit bei Kubernetes erhöhen

Kubernetes Deployments sind dynamisch, verteilt und immer im Fluss. Damit einher gehen neue Herausforderungen für Workflows und Analysen in den Bereichen Sicherheit und Compliance. Gleichzeitig steigt die Zahl von Angriffen kontinuierlich an. Um ihre Apps zu schützen, müssen Entwicklerteams den Überblick behalten. Nur dann können sie Gefahren frühzeitig erkennen und ausräumen. Security Observability schafft diesen Überblick.

Das erfolgreichste Werkzeug in der heutigen Softwarewelt macht die Entwicklung von Apps schneller und zugleich komplexer: Kubernetes. Entwickler haben die Open-Source-Lösung zur Verwaltung von Containern in Rekordgeschwindigkeit aufgegriffen. Laut einer aktuellen Umfrage nutzen inzwischen 91 Prozent der Developer Kubernetes. Das belegt die Umfrage 2020 Cloud Native Survey der Cloud Native Computing Foundation.

Doch der Siegeszug containerbasierter Apps bringt auch Sicherheitsprobleme mit sich. Mehr als die Hälfte aller Befragten gab in einer Studie von Red Hat an, dass sie den Start einer neuen Anwendung schon einmal aufgrund von Sicherheitsbedenken verzögern mussten. Verständlich, denn Sicherheit geht vor. Oft entscheiden Nutzwert und Resilienz einer einzigen App über den Erfolg eines ganzen Unternehmens. Gibt es ein Security-Problem, sind Umsatzverluste und negative Auswirkungen auf die Reputation die Folgen.

Weniger “Alert Noise” für mehr Security

Herkömmliche Monitoring-Lösungen helfen hier nur bedingt. Sie analysieren die Infrastruktur, das Netzwerk, die Datenbanken und die aktiven IT-Services. Doch diese Tools sind nicht auf die Bedürfnisse von Entwicklern ausgerichtet. Häufig produzieren diese Monitoring-Werkzeuge zudem sehr viele Statusmeldungen, Log-Einträge und Alerts. Dieser „Alert Noise” macht es für IT-Teams herausfordernd, schwerwiegende und für die Security relevante Probleme zu identifizieren. Dagegen fehlen oft für Entwickler hilfreiche Einblicke auf Code-Ebene.

Die Sicherheit in Kubernetes-Clustern muss jedoch bereits in der Entwicklungsphase von Anwendungen integraler Bestandteil der Strategie sein. Observability ermöglicht genau das, indem sie sämtliche Informationen liefert, die DevOPs Teams benötigen. Sie sorgt insbesondere dafür, dass Developer vom Projektstart an den Überblick über Anomalien und mögliche Einfallstore für Angriffe haben.

Später, im laufenden Betrieb, ermöglicht es Observability, Audit Logs KI-gestützt zu verarbeiten. IT-Teams sehen alle Telemetriedaten zu Ihren Services, und das ganz ohne Redeployments oder manuelle Instrumentierungen. So wird nicht konformer, anomaler Traffic rasch identifiziert und zugleich die Sicherheit und Performance des Codes gewährleistet.

Kubernetes-Sicherheit beginnt bei der Datenanalyse

Bessere Sicherheit in Kubernetes-Umgebungen erfordert zwingend eine Betrachtung des kompletten Stacks – ohne ständiges Wechseln zwischen zahlreichen Tools. Nur so können DevOps Teams die Sicherheit ihrer Anwendungen gewährleisten und Sicherheitsprobleme abwenden.

Wichtig ist, dass die passenden Metriken im richtigen Kontext zur Verfügung stehen und das Auswerten der Logs nicht zuviel Zeit kostet. Mit Observability lassen sich manuelle Aufgaben automatisieren. So können sich DevOps Teams besser um Performance und Sicherheit kümmern.

Wie trägt Kubernetes Observability zum Schutz der Anwendungssicherheit bei?

Observability stärkt die Fähigkeit eines Teams, Probleme in Softwarearchitekturen komplett und übergreifend zu erkennen und zu verstehen. Die Entwickler verstehen und beheben Fehler und reagieren frühzeitig auf Anomalien, dargestellt in einer übersichtlichen Benutzeroberfläche. Entwickler müssen sich nicht mehr  stunden- und nächtelang auf Fehlersuche begeben, womöglich noch gestresst von nicht enden wollenden Fehlermeldungen, Alerts und im schlimmsten Fall auch Downtimes. Observability verschafft den Teams Zeit, sich Innovation und Weiterentwicklung zu widmen.

Pixie ist seit Mitte 2021 als Komponente der Observability-Plattform New Relic One verfügbar. Die Lösung erfasst automatisch Anwendungsprofile (mit Genauigkeit auf Funktionsebene), Fullbody-Abfragen (HTTPs, Redis, SQL und mehr), System-Metrics wie CPU-, I/O- und Speicherauslastung sowie Kubernetes-spezifische Statusvarianten von Pods und Services. Damit schließt die Lösung typische Monitoring-Lücken in Kubernetes-Umgebungen. Entwicklern liefert Pixie Insights auf Code-Ebene, unabhängig von der verwendeten Programmiersprache.

Dank Observability unbefugte Zugriffe und Manipulation von Daten verhindern

Wenn Entwickler über den gesamten Stack hinweg Observability implementieren, können sie verhindern, dass sich Hacker Zugang zu Clustern oder Pods verschaffen. Zudem erkennen sie frühzeitig falsch konfigurierte Zugriffsrechte. Das hilft, unbefugte Zugriffe und die Manipulation von Daten zu verhindern. Schwachstellen im Kubernetes-API-Server lassen sich mit einem konsequent etablierten Observability-Konzept ebenfalls identifizieren. So können Entwicklerteams verhindern, dass Authentifizierung, Autorisierung oder Zugangskontrolle umgangen werden. Observability schlägt auch frühzeitig Alarm, wenn Compliance-Probleme vorliegen. Verstöße gegen Anforderungen wie DSGVO, PCI, HIPAA und weitere Gesetze, Regelwerke und Best Practices werden erkannt, bevor negative Folgen auftreten.

Automatische Events im Griff behalten

Ein Kubernetes Cluster ist nur dann zuverlässig nutzbar, wenn es ideal ausgesteuert wird. Daher braucht es eine Messlatte für Systemgesundheit und Sicherheit. Die Infrastruktur im Cluster zu überwachen, ist Pflicht. Ebenso, die Metriken der verschiedenen Apps im Blick zu behalten. Das alles gehört zu den Basics und ermöglicht es überhaupt erst, Sicherheitsprobleme und andere Probleme bei Apps in den Griff zu bekommen.

Kubernetes Observability ermöglicht zudem, dass Teams relevante Events im Blick behalten, seien es neue Deployments, regelmäßige Health Checks oder automatisches Scaling. Solche Dinge, die automatisch passieren, jederzeit zu überblicken, ist absolut unerlässlich. Alles andere wäre Blindflug.

Technologien wie eBPF sammeln entsprechende Daten automatisch. Sie greifen sich Metriken, Events, Traces und Logs, und zwar aus jeder nur denkbaren Schicht des Tech Stacks. Egal, ob es sich um die Apps handelt, das Betriebssystem, die Containerarchitektur oder die Netzwerkebenen.

Zu guter Kubernetes Observability gehört jedoch weit mehr als nur das Monitoring von Events. Sie bringt auch Licht in die Kommunikation der Microservices untereinander. Sie liefert Metadaten, die klar machen, wie die verteilten Services zusammenspielen. Sie zeigt, ob die Durchsätze, Transaktionszeiten und Fehlerraten stimmen.

Mehr als Monitoring

Kubernetes Observability revolutioniert das Zusammenspiel von Entwicklern mit ihren Tools, weil sie Events und Fehler in Kontext setzt. Sie deckt nicht nur auf, dass etwas passiert, sondern auch, warum. Genau das war bisher ein zentrales Manko in der Anwendungsentwicklung: Die Software Engineers mussten mit vielen unterschiedlichen Tools jonglieren, um sich einen Überblick zu verschaffen. Eine gute Kubernetes Observability macht das überflüssig. Sie eröffnet Entwicklern einen holistischen Blick auf Daten, verknüpft Logs mit Daten aus Monitoring Tools – wie ein helles Flutlicht, das Anomalien sofort sichtbar macht und ihren kompletten Kontext vollständig ausleuchtet.

Fazit

Kubernetes eröffnet ganz neue Möglichkeiten. Aber viele Unternehmen haben es noch nicht geschafft, dieses Potenzial ideal und sicher zu nutzen. Kubernetes Observability ist ein ganz essenzieller Schritt in diese Richtung. Sie holt das Beste aus Kubernetes heraus, verbessert die Security und löst Probleme direkt, wenn sie auftreten. Wenn Teams ihre Kubernetes Observability perfektionieren, verbessern sie damit nicht nur ihre Arbeitsbedingungen, sondern auch die Sicherheit in der Cloud. Und der Start ist mit Lösungen wie Pixie ganz leicht.

Klaus Kurz ist seit Herbst 2019 Director, Solutions Consulting Central Europe bei New Relic. Hier führt er ein stetig wachsendes Team an Solution Engineers, Solution Consultants und Solution Architects, das Kunden bei der Umsetzung ihrer Digitalisierungspläne unterstützt. Zuvor arbeitete er 15 Jahre bei Adobe und hatte Positionen vom Manager Business Development bis zum Head of Solution Consulting für Zentral- und Osteuropa.