Enterprise-level Kubernetes-Security mit Open Source – kosteneffizient und flexibel
Es passiert immer dann, wenn man es nicht braucht. Es ist Freitag und Max, Software-Architekt in einem großen Unternehmen, ist mit seinen Gedanken schon im Wochenende. Da kommt eine Nachricht vom Security-Team: "Neue Sicherheitslücke für log4j veröffentlicht, relativ einfach auszunutzen und hauptsächlich Java-basierte Webservices betroffen."
Max ist als Plattform-Architekt für einen Kubernetes-Cluster mit vielen Java-basierten Webservices verantwortlich und wird nervös. Längst hat er den Überblick verloren, welche Abhängigkeiten seine Services haben und mit welchen Versionen sie laufen. Es ist später Freitagabend und die meisten Entwickler der Java-Services haben bereits Feierabend. Ihm bleibt nichts anderes übrig, als jeden Service selbst zu überprüfen. Es wird ein langer Abend für ihn und er wird wahrscheinlich auch am Wochenende arbeiten müssen.
Dieses fiktive Szenario verdeutlicht die Bedeutung proaktiver Sicherheitsmaßnahmen im Kubernetes-Cluster und die Nutzung von Sicherheitsmonitoring zur besseren Visualisierung von Sicherheitsgefahren. In den letzten Jahren ist mit Kubernetes die automatisierte Orchestrierung von Applikationen immer einfacher geworden. Auch die Bereitstellung von Kubernetes ist einfacher, alle Cloud-Anbieter bieten Kubernetes-Plattformen als Managed Service an, beispielsweise Azure mit dem Azure Kubernetes Service oder AWS mit dem Amazon Elastic Kubernetes Service. Jedoch ergeben sich die großen Herausforderungen erst im laufenden Betrieb, insbesondere im Enterprise-Umfeld. Dort sind die Sicherheitsanforderungen komplexer und werden durch Zertifizierungen wie ISO 27001 immer umfangreicher.
Unternehmen stehen vor der Frage: Welche Sicherheitslösungen sind notwendig, um einen Cluster und Applikationen innerhalb des Clusters sicher zu betreiben? Wie viel kosten diese Sicherheitslösungen und gibt es auch Open-Source-Tools dafür? Was fehlt den Open-Source-Tools zur Nutzung innerhalb eines großen Unternehmens?
Dieser Artikel soll einen Überblick über Kubernetes-Security im Kontext großer Organisationen geben und zeigen, dass es durchaus möglich ist, viele Sicherheitsmaßnahmen mit Open-Source-Tools abzubilden. Dazu werden die Grundlagen von Kubernetes-Security und typische Bedrohungen für eine Anwendung in einem Cluster betrachtet. Darüber hinaus werden die Anforderungen an Enterprise-Security-Lösungen detailliert dargestellt und bewertet, inwieweit ausgewählte State-of-the-Art Open-Source-Tools diese abdecken.
Definition von Enterprise-level Security
Enterprise-Security geht weit über grundlegende Sicherheitsanforderungen hinaus. Unternehmen müssen strenge Compliance-Anforderungen wie die Datenschutz-Grundverordnung (DSGVO) oder branchenspezifische Standards wie ISO 27001 einhalten. Diese Vorschriften verlangen, dass Unternehmen sicherstellen, dass die Vertraulichkeit, Integrität und Verfügbarkeit von Daten jederzeit gewährleistet ist. Insbesondere bei sicherheitskritischen Systemen, wie sie im Banken- oder Gesundheitssektor zu finden sind, sind die Anforderungen besonders hoch und erfordern klar definierte Sicherheitsmaßnahmen. Dies bedeutet, dass umfassende Schutzmechanismen implementiert werden müssen, um diese Anforderungen erfüllen zu können, einschließlich Verschlüsselung, Zugriffskontrolle und Audit.
Damit ein Tool im Enterprise-Umfeld einsetzbar ist, muss es bestimmte Eigenschaften erfüllen, um den spezifischen Anforderungen von Unternehmen gerecht zu werden:
Management-Visibility: Die Möglichkeit, Analysen und Einblicke in die Sicherheitslage des Unternehmens zu erhalten, ist entscheidend. Dashboards und Reporting sind notwendig, um Transparenz zu schaffen und Risiken frühzeitig zu erkennen. Ebenso wichtig ist die Integration mit anderen Enterprise-Tools wie Jira oder ServiceNow, um Vorfälle zu verfolgen und zu dokumentieren sowie Security-Monitoring und Reaktivität durch die Anbindung an ein zentrales SIEM (Security Information and Event Management), um eine vollständige Übersicht über alle sicherheitsrelevanten Ereignisse zu gewährleisten. Die Anbindung an Identitätsmanagementsysteme wie Active Directory oder OpenID Provider sind ebenfalls von großer Bedeutung.
Hohe Skalierbarkeit: Unternehmen nutzen häufig verschiedene Cloud-Anbieter und -Technologien. Auch sind die Netzwerktopologien komplex mit hybriden Cloud-Lösungen. Sicherheitslösungen müssen daher software- und provideragnostisch und über APIs automatisierbar sein, um den unterschiedlichen Anforderungen gerecht zu werden. Die Automatisierbarkeit ist besonders wichtig, da Sicherheitsmaßnahmen in großem Umfang umgesetzt werden müssen, ohne dass dies zu einem Engpass in den Entwicklungs- und Betriebsprozessen wird.
Compliance: Die Tools müssen den hohen Compliance-Anforderungen der Unternehmen gerecht werden. Dies bedeutet, dass sowohl Self-Hosting als auch SaaS-Lösungen möglich sein sollten, um unterschiedlichen Compliance-Anforderungen zu genügen. Darüber hinaus sind Audit-Logs und die Möglichkeit, professionellen Support in Anspruch zu nehmen, wichtige Aspekte, die die Tools bieten sollten.
Kubernetes Security Basics
Grundlegende Sicherheitsprinzipien
Bevor wir auf die Sicherheitsbedrohungen innerhalb eines Kubernetes-Clusters im Kontext eines großes Unternehmen eingehen, sollten einige grundlegende Sicherheitsprinzipien betrachtet werden:
Das Onion-Prinzip: Sicherheit sollte auf mehreren Ebenen implementiert werden, um eine mehrschichtige Verteidigung zu gewährleisten. Sollte eine Ebene kompromittiert werden, müssen weitere Schutzmechanismen greifen, um Angreifer abzuwehren. Dieses Prinzip stellt sicher, dass eine einzelne Sicherheitslücke nicht das gesamte System gefährden kann, sondern dass es weitere Barrieren gibt, die einen Angriff abwehren.
"Principle of Least Privilege": Jeder Benutzer oder jede Applikation sollte nur die minimal erforderlichen Rechte erhalten. Dadurch wird die Wahrscheinlichkeit verringert, dass ein kompromittiertes Konto oder eine kompromittierte Applikation zu schwerwiegenden Sicherheitsvorfällen führt.
Begrenzung der Angriffsfläche: Nicht benötigte Software oder Funktionen sollten deaktiviert werden, um potentielle Schwachstellen zu minimieren. Jede zusätzliche Komponente vergrößert die Angriffsfläche und damit das Risiko, dass diese als Einfallstor für Angreifer genutzt werden kann. Ein Beispiel für die Einschränkung der Angriffsfläche wäre die Deaktivierung von Debug-Funktionen. Diese könnten von Angreifern genutzt werden, um Informationen über das System zu erhalten. Sie sollten daher in Produktionsumgebungen immer deaktiviert sein. Wenn Debugging erforderlich ist, sollten dedizierte Umgebungen verwendet werden, die strikt von der Produktionsumgebung getrennt sind.
Absicherung der Kubernetes Control Plane
Die Control Plane ist das Herzstück eines Kubernetes-Clusters und muss besonders gut geschützt werden. Dazu gibt es einige Maßnahmen, die erfüllt werden sollten:
Private Networking: Die Control Plane sollte in einem privaten Netzwerk innerhalb der Cloud betrieben werden, um den Zugriff einzuschränken und potenzielle Angriffsvektoren zu reduzieren. Auch wenn die API der Control Plane durch Authentifizierung geschützt ist, sollte sie nicht öffentlich über das Internet zugänglich sein. Mögliche Sicherheitslücken in Kubernetes könnten es Angreifern dennoch ermöglichen, die Kontrolle über den Cluster zu übernehmen.
Authentifizierung: Der Zugriff auf die Kubernetes API sollte immer durch eine starke Authentifizierung über OIDC oder SAML mit einer klaren Benutzerverwaltung abgesichert werden. Dies stellt sicher, dass nur autorisierte Benutzer auf die API zugreifen können und dass sensible Bereiche des Clusters nur von vertrauenswürdigen Entitäten verwaltet werden können.
Managed Services: Die Nutzung von Managed Services durch Cloud-Anbieter kann zusätzliche Sicherheitsvorteile bieten. Managed Kubernetes Services bieten häufig automatische Patches und Sicherheitsupdates, die für einen sicheren Betrieb erforderlich sind.
Kubernetes Dashboard: Das Kubernetes Dashboard sollte in produktiven Umgebungen nur im Read-Only-Modus verwendet werden, um ungewollte Änderungen zu verhindern. Alternativ sollte das Dashboard komplett deaktiviert werden, da es ein attraktives Ziel für Angreifer darstellt, insbesondere wenn es nicht korrekt konfiguriert ist.
RBAC und Network Policies
Die rollenbasierte Zugriffskontrolle (Role Based Access Control, RBAC) sollte in Kubernetes-Umgebungen immer aktiviert sein, um den Zugriff auf Ressourcen im Cluster präzise und sicher zu steuern. RBAC ermöglicht es, Berechtigungen genau zu definieren und verschiedenen Entitäten spezifisch zuzuweisen. Wie auf der linken Seite der Abb. 2 zu sehen ist, gibt es drei Arten von Entitäten: Benutzer, Gruppen und Applikationen. Dies ist besonders wichtig, um sicherzustellen, dass jeder nur die Rechte erhält, die für die jeweilige Aufgabe erforderlich sind. Rechte auf eine Resource werden durch eine Role definiert, die entweder an einen Namespace gebunden ist oder clusterweit definiert wird (als Cluster Role). Ein RoleBinding bindet die Rolle an eine oder mehrere Entitäten. Durch die konsequente Vergabe von minimalen Rechten nach dem Least-Privilege-Prinzip wird das Risiko, dass ein Benutzer oder eine Applikation auf Bereiche zugreift, die nicht benötigt werden, reduziert und damit die Sicherheit des gesamten Clusters erhöht.
Network Policies hingegen sichern den Netzwerkzugriff auf Pod-Ebene. Sie stellen sicher, dass nur autorisierter Verkehr zugelassen wird. Sowohl der eingehende als auch der ausgehende Traffic kann durch sogenannte Ingress- oder Egress-Regeln eingeschränkt werden. Es ist wichtig zu beachten, dass Regeln additiv wirken und Deny-all-Regeln nicht vergessen werden sollten, um unerwünschten Zugriff zu verhindern. Empfehlenswert ist die Orientierung an Rezepten für Network Policies, die mögliche Fallstricke aufzeigen [1].
Viele Helm-Releases erleichtern den Einsatz von RBAC und Network Policies, indem sie die notwendigen Rollen und Network Policies direkt integrieren, was die Implementierung erheblich vereinfacht.
Absicherung von Pods
Folgende Empfehlungen gibt es noch zur Absicherung der Applikationen, die innerhalb eines Pods in Kubernetes bereitgestellt werden:
Automount deaktivieren: Der Standard-Service-Account eines Namespaces sollte nicht automatisch gemountet werden, um das Risiko eines unbefugten Zugriffs auf die Kubernetes-API zu minimieren. So hat jeder Pod mit dieser Konfiguration nur die Berechtigungen, die er benötigt.
Container-Image-Versionen: Container sollten niemals mit dem latest Tag verwendet werden, da dies zu unbeabsichtigten Änderungen und möglichen Inkompatibilitäten führen kann. Stattdessen sollten feste Versionen verwendet werden, um sicherzustellen, dass dieselben getesteten Images in allen Umgebungen genutzt werden.
Reduzierte Base Images: Container sollten mit minimalen Base Images erstellt werden, um die Angriffsfläche zu reduzieren und potenzielle Sicherheitslücken zu minimieren. Jedes unnötige Paket oder Tool in einem Container könnte eine Schwachstelle enthalten, die die Applikation gefährdet.
Bedrohungen und Schutzmaßnahmen für einen Cluster
Im Folgenden werden die typischen Bedrohungen einer Applikation während des Deployments und der Laufzeit beschrieben, bei dem eine Applikation aus einem Git Repository mit Continuous Integration und Continuous Delivery in einen Kubernetes-Cluster ausgeliefert wird. Viele dieser Bedrohungen sind gerade bei großen Unternehmen relevanter durch die größere Skalierung und die Sicherheitsanforderungen.
Die Bedrohungen unterscheiden sich in drei verschiedenen Komponenten:
CI/CD-Pipeline: Manipulierte Images und Schwachstellen im Code stellen eine große Gefahr dar. Angreifer könnten die Pipeline infiltrieren und Schadsoftware in das System einschleusen. Dies könnte dazu führen, dass kompromittierte Software ohne Wissen der Entwickler in die Produktion gelangt.
Deployment: Fehlkonfigurationen in der Laufzeit können zu Sicherheitslücken führen. Ein fehlerhaftes Deployment kann Angreifern ungewollt Zugriff auf sensible Daten oder Systeme ermöglichen. Beispiele für schwerwiegende Konfigurationsfehler sind offene Ports oder unsichere Verbindungen.
Cluster: Manipulation des Datenverkehrs, unberechtigte Netzwerkzugriffe sowie Manipulationen auf Clusterebene stellen erhebliche Bedrohungen dar. Darüber hinaus können Sicherheitslücken in laufenden Diensten ausgenutzt werden, um die Kontrolle über den Cluster oder Applikationen zu erlangen. Angreifer könnten versuchen, den Netzwerkverkehr abzuhören oder kritische Dienste zu kompromittieren, um Zugriff auf sensible Daten zu erhalten.
Im Anschluss werden die Sicherheitsmaßnahmen gegen die jeweiligen Bedrohungen dargestellt. Diese unterscheiden sich wiederum nach den jeweiligen Komponenten:
CI/CD-Pipeline: Image Signing und Vulnerability Scanning sind essentiell, um sicherzustellen, dass nur vertrauenswürdige Images in die Produktionsumgebung gelangen. Image Signing stellt die Authentizität und Integrität der Images sicher. Vulnerability Scanning innerhalb der Pipeline kann eingesetzt werden, um bekannte Sicherheitslücken frühzeitig zu erkennen und zu beheben.
Deployment: Die Einführung von Governance-Richtlinien durch Policies kann Fehlkonfigurationen verhindern. Diese Richtlinien sollten automatisiert angewendet werden, um sicherzustellen, dass alle Implementierungen den festgelegten Sicherheitsstandards entsprechen. Automatisierte Tools können eingesetzt werden, um zu gewährleisten, dass Konfigurationen vor der Bereitstellung validiert und überprüft werden.
Cluster: Mutual TLS (mTLS) und Layer 7 Policies sind wichtige Maßnahmen, um die Kommunikation zwischen den Services abzusichern. Zusätzlich sollte ein kontinuierliches Vulnerability Scanning im Cluster durchgeführt werden, um bekannte Schwachstellen zeitnah zu identifizieren und zu beheben. Runtime-Security-Tools wie Falco können eingesetzt werden, um verdächtige Aktivitäten innerhalb des Clusters zu erkennen und darauf zu reagieren.
State-of-the-Art Security-Open-Source-Tools
Auswahlkriterien für das richtige Open-Source-Tool im Enterprise-Umfeld
Ob Open-Source-Werkzeuge die Anforderungen eines Unternehmens erfüllen können, hängt von verschiedenen Faktoren ab. Die wichtigsten Auswahlkriterien für Open-Source-Werkzeuge sind:
- Aktive Community-Unterstützung und regelmäßige Updates: Ein Tool muss regelmäßig gewartet und aktualisiert werden, um sicherzustellen, dass es mit den neuesten Sicherheitsstandards und -praktiken Schritt halten kann. Eine aktive Community stellt sicher, dass Probleme schnell gelöst und neue Funktionen zeitnah implementiert werden.
- Nutzung in produktiven Umgebungen: Tools, die bereits in Produktionsumgebungen eingesetzt werden, haben in der Regel ihre Stabilität und Zuverlässigkeit bewiesen. Dies ist ein guter Indikator dafür, dass ein Tool reif genug für den Enterprise-Einsatz ist.
- Qualität der Dokumentation: Eine gute Dokumentation ist entscheidend für die Implementierung und den Betrieb des Tools. Ohne eine klare und umfassende Dokumentation kann es schwierig sein, das volle Potenzial eines Tools auszuschöpfen.
- Features und Erweiterbarkeit: Das Tool sollte die notwendigen Funktionen bieten und erweiterbar sein, um den spezifischen Anforderungen des Unternehmens gerecht zu werden. Die Erweiterbarkeit ist besonders wichtig, da Unternehmen oft individuelle Anforderungen haben, die von Standardlösungen nicht abgedeckt werden.
- Unterstützung für gängige Plattformen: Das Tool sollte mit allen gängigen Plattformen kompatibel sein, damit es in verschiedenen Umgebungen eingesetzt werden kann. Diese Flexibilität ermöglicht eine breitere Nutzung und Integration.
Alle diese Kriterien sollten vor der Einführung eines Werkzeugs in die Sicherheitsprozesse abgewogen werden.
Übersicht über die wichtigsten Open-Source-Tools nach Schutzmaßnahme
Image Signing
Image Signing stellt sicher, dass Container-Images vor ihrer Verwendung authentifiziert und ihre Integrität garantiert werden kann, um Manipulationen des Images zu verhindern. Dazu wird bei der Erstellung des Images eine Signatur eingefügt und vor der Ausführung des Container-Images kann diese Signatur des Images innerhalb des Clusters validiert werden. Dies ermöglicht die Überprüfung der Herkunft eines Container-Images und stellt sicher, dass nur verifizierte Container-Images im Cluster laufen.
Die beiden populärsten Tools zum Signieren von Images sind Notation des Notary Projects und Cosign von sigstore. Notation ist eine Weiterentwicklung der ersten Version von Notary, die damals noch eine aufwändige Installation eines eigenen Signaturservers erforderte. Inzwischen unterscheiden sich Notation und Cosign kaum noch. Beide bieten eine Kommandozeilenschnittstelle zum Signieren und Verifizieren von Imagesignaturen und werden von vielen Container Registries in der Cloud unterstützt. Im Detail unterscheiden sie sich in verschiedenen Features, Notation unterstützt Key Revocation, Cosign unterstützt mehrere Möglichkeiten des Key Managements, neben X.509-Zertifikaten z. B. auch Key- Management-Systeme von Cloud-Providern wie Azure Key Vault oder AWS KMS und Hardware-Tokens. Ein interessantes Feature von Cosign ist das "Keyless Signing", dabei werden kurzlebige Zertifikate über Workflow mit einer OpenID Connect (OIDC) Identity und einer Certificate Authority, beispielsweise der von sigstore bereitgestellten namens Fulcio, signiert. Dadurch werden unsichere langlebige Zertifikate vermieden und eine bessere Integrität durch OIDC Identitäten, z. B. ein GitHub User, hergestellt. Cosign unterstützt auch ein sogenanntes "Transparency Log" das alle Signierungen von Images protokolliert, was für eine bessere Nachvollziehbarkeit wichtig ist.
Abb. 5 zeigt beispielhaft, wie ein Image Signing Flow in einer Azure-Umgebung aussehen kann. Dabei wird Cosign für die Signierung und Connaisseur für die Validierung der Signaturen innerhalb des Kubernetes-Clusters verwendet [2]. Die Keys für die Signierung werden im Azure Key Vault gespeichert und können über Service-Accounts jeweils für die Signierung und Validierung abgerufen werden.
Vulnerability-Scanning
Vulnerability-Scanning hilft, Sicherheitslücken in Container-Images und Anwendungen frühzeitig zu erkennen, bevor sie in produktiven Umgebungen ausgenutzt werden können. Durch das frühzeitige Erkennen von Schwachstellen können potenzielle Angriffsflächen reduziert und die Sicherheit der gesamten Umgebung verbessert werden. Zwei populäre Open-Source-Tools sind Trivy und Clair.
Trivy ist ein Open-Source-Tool von Aqua Security, das lediglich eine Binary benötigt und schnelle Scans ermöglicht [3]. Es unterstützt sowohl Container- als auch Application-Scanning für viele Programmiersprachen wie Java, Python und Go, was es zu einem vielseitigen Werkzeug für die Sicherheitsüberprüfung macht. Es nutzt unterschiedliche Vulnerability-Datenbanken beispielsweise von Github oder den Linux-Distributionen. Dazu gibt es auch einen Cluster-Service namens Trivy Operator, der Container zur Laufzeit im Cluster scannen kann und diese Ergebnisse für Monitoring-Lösungen wie Grafana visualisierbar macht [4].
Clair hingegen erfordert ein komplexeres Setup mit mehreren Serverkomponenten, die verteilt betrieben werden können [5]. Es unterscheidet zwischen einer Indizierungskomponente, die für den Inhalt eines Container-Images einen Report zwischenspeichert, einer Matchingkomponente, die in den Reports nach Schwachstellen sucht und einer Benachrichtigungskomponente, die alle Reports nach neuen Schwachstellen durchsucht. Es bietet außerdem mehr Flexibilität bei der Auswahl der Vulnerability-Datenbank. Es eignet sich daher für spezielle Anforderungen, z. B. in Air-Gap-Netzwerken, in denen keine Anbindung an das Internet möglich ist.
Policy-Management
Mit Policy-Management können Sicherheits- und Compliance-Richtlinien effizient definiert und durchgesetzt werden, um zu gewährleisten, dass alle Systeme den vorgegebenen Sicherheitsstandards entsprechen. Die beiden wichtigsten Open-Source-Tools zur Automatisierung des Policy Managements sind OPA (Open Policy Agent) und Kyverno. OPA verwendet die Policy-Sprache Rego und ermöglicht die Definition komplexer Regeln [6]. Es kann nicht nur in Kubernetes, sondern auch in anderen Bereichen wie Terraform eingesetzt werden. Diese Flexibilität macht es zu einem leistungsfähigen Werkzeug für die Verwaltung von Sicherheits- und Compliance-Richtlinien [7]. Im Gegensatz dazu bietet Kyverno Kubernetes-native Policies, die einfacher zu verstehen und anzuwenden sind. Neben Validierung und Mutation bietet Kyverno auch die Möglichkeit, Kubernetes-Ressourcen zu generieren und zu bereinigen, was es zu einem sehr praktischen Werkzeug für das Management von Kubernetes-Clustern macht. Die Wahl des Tools hängt also davon ab, wie komplex die zu definierenden Regeln sind und ob auch Policies außerhalb von Kubernetes definiert werden müssen.
Mutual TLS
Mutual TLS (mTLS) ermöglicht eine sichere Kommunikation zwischen Services, indem beide Parteien authentifiziert werden. Dazu können in Kubernetes Service Meshes verwendet werden. Die beiden beliebtesten Service Meshes sind Istio [8] und Linkerd[9]. Beide ermöglichen eine sichere Kommunikation zwischen Services durch Mutual TLS. Während Linkerd einfacher zu konfigurieren ist, bietet Istio erweiterte Funktionen im Bereich Traffic-Management und Zero Trust Networking, die Unternehmen eine feinere Kontrolle über die Kommunikation im Netzwerk ermöglichen. Abb. 6 zeigt am Beispiel von Istio, wie Mutual TLS in einem Service Mesh funktioniert. Dazu wird in jeden Applikations-Pod ein Proxy injiziert, über den alle Verbindungen laufen. Für die Applikation ist HTTPS damit transparent und Istio ist für die Verteilung der Zertifikate in den Proxies verantwortlich. Dies kann auch um Ingress- und Egress-Verbindungen erweitert werden, so dass auch Verbindungen vom Benutzer zur Applikation oder nach außen abgesichert werden.
Runtime Security
Runtime Security überwacht Container zur Laufzeit, um Sicherheitsverletzungen frühzeitig zu erkennen und zu verhindern. Durch die Überwachung von Cluster-Aktivitäten und die Erkennung von Anomalien können potentielle Angriffe erkannt werden.
Tetragon, Falco und Aqua Tracee sind drei wichtige Open-Source-Tools, die bei der Erkennung von Sicherheitsverletzungen durch Richtlinien auf Systemaufrufen helfen [10;11;12]. Alle drei eignen sich sowohl zur Erkennung von Sicherheitsvorfällen als auch zur automatisierten Reaktion darauf und unterstützen alle auch eBPF (Extended Berkeley Packet Filter) und bieten damit einen leichtgewichtigen Einblick in die Systemaktivität. Cilium und Aqua bieten Enterprise-Support an und eignen sich möglicherweise besser für einen Enterprise-Kontext, abhängig davon, ob schon andere Aqua-Produkte oder Cilium als Netzwerk-Plugin genutzt werden.
Enterprise-Tauglichkeit der Tools
Ausgehend von den eingangs definierten Enterprise-Anforderungen können die genannten Open-Source-Tools im Enterprise-Umfeld hinsichtlich ihrer Eignung bewertet werden. Dabei handelt es sich um einen Querschnitt über alle Tools, einzelne Tools können einzelne Punkte besser oder schlechter abdecken.
Management-Visibility: Die Integration von Open-Source-Tools in Dashboards und Enterprise-Tools ist oft nicht vollständig und erfordert eine gewisse Anpassung. Während einige Tools über Anbindungen an gängige Alerting-Systeme verfügen, fehlen bei anderen Integrationen. Diese Lücken müssen oft durch eigene Anpassungen oder den Einsatz von Dritt-Tools geschlossen werden.
Skalierbarkeit: Die meisten der vorgestellten Open-Source-Tools sind gut skalierbar und bieten Möglichkeiten zur Automatisierung durch Custom Resources oder APIs. Dies ist besonders wichtig für Unternehmen, die Kubernetes in großem Maßstab einsetzen. Die Fähigkeit, große Mengen an Daten zu verarbeiten und Sicherheitsrichtlinien automatisch durchzusetzen, ist entscheidend, um den operativen Aufwand zu minimieren.
Compliance: Viele Open-Source-Tools bieten Self-Hosting an, was für Compliance-Anforderungen von Vorteil ist. Allerdings fehlen oft direkte Anbindungen an SIEM-Systeme für Audit Logs, was über Kubernetes Logging gelöst werden muss. Professioneller Support kann durch die Community oft nicht gewährleistet werden, jedoch gibt es in den meisten Fällen Unternehmen, die kommerziellen Support anbieten. Dieser Support ist besonders wichtig, wenn es um die Zertifizierung und die Einhaltung von Compliance-Anforderungen geht.
Es zeigt sich, dass bis auf einige Ausnahmen Open-Source-Tools nicht direkt Enterprise-ready sind und Anpassungen notwendig machen. Anpassungen lohnen sich, um unabhängig von Cloud-Lösungen zu sein und Kompetenz in der Implementierung der Sicherheitsmaßnahmen aufzubauen. In bestimmten Fällen kann jedoch eine SaaS-Lösung die bessere Wahl für ein Unternehmen sein. Wenn die Kosten für den Eigenbetrieb und die Entwicklung von Sicherheitslösungen zu hoch sind, kann eine SaaS-Lösung vorteilhaft sein. Der Betrieb eines Open-Source-Tools erfordert oft zusätzliche Ressourcen, die ein Unternehmen möglicherweise nicht bereitstellen kann, während eine SaaS-Lösung eine sofort einsatzbereite Option bietet, die den administrativen Aufwand erheblich reduziert.
Zusammenfassung
Open-Source-Tools haben die nötigen Funktionen, benötigen aber oft eigene Erweiterungen im Bereich Management Reporting, Integration in die Tool-Landschaft des Unternehmens und Compliance, um für den Enterprise-Einsatz geeignet zu sein. Kubernetes selbst bietet schon viele Sicherheitsfunktionen, die auf jeden Fall die Basis der Security-Strategie sein sollten. Darüber hinaus können mit Open-Source-Tools die jeweiligen Bedrohungen abhängig von den Unternehmensrichtlinien erkannt werden. Die meisten Tools bieten Enterprise-Optionen oder professionellen Support, der hinzugekauft werden kann, falls im Unternehmen selbst nicht genügend Kompetenz aufgebaut werden kann. Es sollte sorgfältig abgewogen werden, ob Sicherheitsmaßnahmen mit Open-Source-Tools selbst gebaut werden oder ob eine SaaS-Lösung die bessere Wahl ist.
- Github: kubernetes-network-policy-recipes
- Github: connaisseur
- Aqua Trivy
- Github: trivy-operator
- Github: Clair
- Open Policy Agent
- Kyverno
- Istio
- Linkerd
- Falco
- Tetragon
- Aqua Tracee
