Wir beschäftigen uns schon seit vielen Jahren mit dem Betrieb von Kubernetes und wie man ausfallsichere Anwendungen auf Kubernetes betreibt.
Die Absicherung von Kubernetes gegen unbefugte Zugriffe war immer ein Schwerpunkt in den Projekten mit unseren Kunden, um eine Manipulation von Kubernetes und deren Anwendungen zu verhindern.
Das BSI, das deutsche Zentrum für Sicherheit im Internet, stellt umfangreiche Kompendien zur Absicherung einer IT-Infrastruktur zur Verfügung. Die dort aufgeführten Benchmarks sind nicht nur für IT-Abteilungen der öffentlichen Hand, sondern auch für private Unternehmen interessant, da sie sehr allgemein formuliert sind.
Die Benchmarks decken alle IT-relevanten Themen ab und enthalten insbesondere auch Informationen zur Absicherung von Kubernetes und dessen Anwendungen. Neben Informationen zu IT-organisatorischen Fragen enthalten die Kompendien auch umfangreiche spezifische technische Informationen zur Absicherung einer Infrastruktur.
Wir bieten einen kostenlosen Service an, der Ihre Kubernetes-Umgebung und -Anwendungen nach den technischen Vorgaben der deutschen GUS validiert.
Schwachstellen, wenn Kubernetes nicht richtig konfiguriert ist, sind
- privilegierter Zugriff auf einen Server-Knoten mit einem Pod, der im Kubernetes-Cluster läuft,
- einfache Änderung der Einstellungen eines Kubernetes-Pods, um Zugriff auf die Worker-Nodes zu erhalten,
- ungehinderte Kommunikation aller Kubernetes-Pods mit allen anderen Kubernetes-Pods im Cluster,
- Kommunikation zwischen den Pods der verschiedenen Worker-Nodes ohne TLS-Sicherheit,
- Erlangung von erweiterten Zugriffsrechten auf Kubernetes über den ServiceAccount eines Kubernetes-Pods durch einen Benutzer,
- Zugriff auf RBAC-Rechte zur Änderung der eigenen Berechtigung über einen Pod,
- Mischung der Control-Plane-Nodes und Worker-Nodes für die Anwendungen,
- Überlastung der Server-Knoten durch Anforderung von zu viel Ressourcen wie Speicher oder CPU durch die Pods und
Weitere Informationen finden Sie in unserem Blog-Eintrag
Wir validieren
- Zugangskontrolle, um unbefugten Zugriff auf die IT-Infrastruktur zu verhindern,
- Netzwerkkommunikation, um unbefugten Zugriff auf die in Kubernetes laufenden Anwendungen zu verhindern,
- Stabilität und Anfälligkeit für unsichere Konfigurationen,
- Regeln für Auditing zur Verhinderung unsicherer Konfigurationen,
- Failover, um Anwendungen zuverlässig zu betreiben und
- Ressourcennutzung zum Schutz von Kubernetes vor Ausfällen aufgrund einer Überbeanspruchung von Ressourcen.
Alle unsere Ergebnisse werden ebenfalls in diese drei Klassen eingeteilt:
- Basis: Empfehlung, die erfüllt werden muss, um den Cybersicherheitsvorschriften zu entsprechen
- Standard: Empfehlung, die erfüllt werden sollte, um den Cybersicherheitsvorschriften zu genügen
- hoch: Empfehlung, die erfüllt werden sollte, wenn hochgradig gefährdete Anwendungen ausgeführt werden
Wir gehen durch
eine laufende Kubernetes-Umgebung mit unserem Analyse-Tool durch und schauen uns jede einzelne Kubernetes-Ressource an, wie Pods oder NetworkPolicies auf ungünstige Konfigurationen oder gar fehlende Konfigurationen, die einer Sicherheitsempfehlung der deutschen CIS widerspricht.
Für jede gefundene Schwachstelle einer Kubernetes-Ressource wird ein Hinweis auf die Konfiguration und die Empfehlung des deutschen CIS mit Angabe der Schwachstellenklasse ausgegeben. Optional, kann eine KI-generierte Lösung und Risikobewertung hinzugefügt werden, z.B.:
48 app-2/grimble-6bd89db75c-v84zr grimble(Deployment/grimble)
Warning: In the container, spec.containers[].securityContext.privileged is set and therefore has privileged rights.
Cybersecurity notes under module 'Standard: Execution of containers without privileges' the following
requirements: The container runtime and all instantiated containers SHOULD only be executed by a non-privileged system
account that does not have or cannot obtain extended rights for the container service or the host system's operating system.
Problems:
1. Increased risk of privilege escalation: Allowing containers to run with privileged security context can
lead to unauthorized access to sensitive resources and potentially allow attackers to gain control of the entire node.
2. Weakened isolation: Privileged containers have more access to the host system, which can weaken the
isolation between containers and increase the risk of one compromised container affecting others.
3. Vulnerability to malicious attacks: Privileged containers are more susceptible to various types of attacks,
including container breakout attacks, which can result in unauthorized access to host resources.
Example:
apiVersion: v1
kind: Pod
metadata:
name: example-pod
spec:
containers:
- name: example-container
securityContext:
privileged: true
Die Teile Probleme
und Beispiel
sind optionale Informationen, die von der KI erzeugt werden.
Kubernetes-Ressourcen, die wir analysieren, sind
resource | access control | auditing | stability | network communication | failover | resource utilization |
---|---|---|---|---|---|---|
APIServer | x | x | ||||
Pod | x | x | x | x | x | |
NetworkPolicy | x | x | x | |||
Calico NetworkPolicy (optional) | x | x | x | |||
Calico GlobalNetworkPolicy (optional) | x | x | x | |||
Cilium NetworkPolicy (optional) | x | x | x | |||
Cilium ClusterwideNetworkPolicy (optional) | x | x | x | |||
Namespaces | x | |||||
Services | x | x | ||||
ServiceAccounts | x | x | ||||
MutatingWebhookConfiguration | x | |||||
ValidatingWebhookConfiguration | x | |||||
ValidatingWebhookPolicy | x | |||||
Ingress | x | |||||
StorageClass | x |
Ist es sicher?
Ja.
- Das Tool läuft mit den Kubernetes RBAC Rechten, die Sie ihm über kubeconfig gegeben haben.
- Die initiale Analyse machen wir immer zusammen mit Ihnen.
- Der Betrieb ist völlig unabhängig vom Internet.
- Die KI-Unterstützung ist optional. Wir können völlig unabhängig vom Internet arbeiten. Damit ist gewährleistet, dass keine Informationen mit der Außenwelt geteilt werden.
- Das AI-Tool mit der Kommunikation zu ChatGPT ist optional.