kube-tarian/tarianeBPF-basierter Runtime-Sicherheitsagent für Kubernetes, der unbekannte Prozesse und Dateiänderungen erkennt, vorab registrierte Einschränkungen durchsetzt und die automatische Pod-Löschung oder Alarmierung auslöst, um Ransomware und andere Angriffe abzuwehren.
Schützen Sie Ihre auf Kubernetes ausgeführten Anwendungen vor bösartigen Angriffen, indem Sie Ihre vertrauenswürdigen Prozesse und Dateisignaturen vorab registrieren. Tarian erkennt unbekannte Prozesse und Änderungen an den registrierten Dateien, sendet dann Warnmeldungen und ergreift automatische Maßnahmen. Retten Sie Ihre K8s-Umgebung vor Ransomware!
Wir möchten dies als Open-Source-Projekt erhalten, um Angriffe auf unser geliebtes Kubernetes-Ökosystem zu bekämpfen. Durch kontinuierliche Beiträge können wir als Gemeinschaft gemeinsam Bedrohungen begegnen.
Wie funktioniert Tarian?
Der Tarian Cluster Agent läuft im Kubernetes-Cluster, erkennt unbekannte Prozesse und unbekannte Dateiänderungen, meldet sie an den Tarian Server und ergreift optional Maßnahmen: Löschen des verletzten Pods. Es verwendet eBPF, um neue Prozesse zu erkennen. Für die Dateiänderungserkennung injiziert der Tarian Cluster Agent einen Sidecar-Container in den Pod Ihrer Hauptanwendung, der Datei-Prüfsummen im konfigurierten Pfad überprüft und mit den registrierten Prüfsummen im Tarian Server vergleicht. Tarian wird von der Entwicklung bis zur Produktion Teil des Pods Ihrer Anwendung sein, sodass Sie in Ihrer Tarian-DB registrieren können, was in Ihrem Container passieren und ausgeführt werden soll, welche Dateisignaturen überwacht werden sollen, worüber benachrichtigt werden soll und welche Aktion (Selbstzerstörung des Pods) bei erkannten Änderungen ergriffen werden soll. Verlagern Sie Ihren Erkennungsmechanismus nach links!
Was passiert, wenn eine unbekannte Änderung im Container auftritt, die nicht in der Tarian-Registrierungsdatenbank vorhanden ist? Wie reagiert Tarian darauf?
Wenn eine unbekannte Änderung auftritt, kann Tarian einfach beobachtete Analysen an Ihr Sicherheitsteam melden. Ihre Sicherheitsingenieure können diese Änderung dann in der Tarian-DB registrieren, unabhängig davon, ob sie als Bedrohung eingestuft wird oder nicht. Basierend auf ihrer Analyse können sie auch konfigurieren, welche Aktion beim erneuten Auftreten dieser Änderung ergriffen werden soll.
Wie hilft der Beitrag der Gemeinschaft, Bedrohungen mit Tarian zu bekämpfen?
Jede neue, von Ihren Sicherheitsexperten analysierte und als Bedrohung eingestufte Erkennung kann – wenn gewünscht – mit allen Logs, zu suchenden Zeichenfolgen, Beobachtungen, Transparenz, zu konfigurierenden Aktionen usw. in der Open-Source-Tarian-Community-Datenbank geteilt werden. Im Grunde alles, wovor die Experten warnen und was sie mit der Gemeinschaft teilen möchten. Sie können diese Informationen als Tarian-Benutzer nutzen und Aktionen in der Tarian-App konfigurieren, die in Ihrer Umgebung verwendet wird. Dies ist im Wesentlichen ein Mechanismus zum Austausch von Informationen über Bedrohungen und deren Handhabung. Dies hilft allen Tarian-Nutzern, gemeinsam in ihren jeweiligen K8s-Umgebungen zu handeln, indem sie ihr Wissen und ihre Erfahrungen teilen.
Welche Art von Aktionen würde Tarian basierend auf bekannten Bedrohungen ergreifen?
Tarian würde einfach den Pod, auf dem es läuft, selbst zerstören. Wenn sich die Malware / der Virus auf den Rest der Umgebung ausbreitet, wissen Sie, was passiert. Tarian ist also grundsätzlich dazu entwickelt, das Risiko durch die Zerstörung von Pods so weit wie möglich zu reduzieren. Die Bereitstellung eines neuen Pods wird vom K8s-Deployment übernommen. Tarian wird Pods nur dann zerstören, wenn Sie Tarian dazu anweisen. Wenn Sie keine Aktionen wünschen, müssen Sie keine konfigurieren oder auslösen; Sie können Tarian einfach anweisen, Sie nur zu benachrichtigen. Tarian macht im Grunde das, was Sie tun möchten, um das Risiko zu reduzieren.
Warum ein weiteres neues Sicherheitstool, wenn es bereits viele Tools gibt, wie Falco, Kube-Hunter, Kube-Bench, Calico Enterprise Security und viele weitere Sicherheitstools (Open-Source & kommerziell), die Bedrohungen auf Netzwerk-, Infrastruktur- und Anwendungsebene erkennen und verhindern können? Warum Tarian?
Der Hauptgrund für die Entstehung von Tarian ist, Bedrohungen in Kubernetes gemeinsam als Gemeinschaft zu bekämpfen. Ein weiterer Grund war: Was ist, wenn es immer noch einen hochentwickelten Angriff gibt, der in der Lage ist, jede Sicherheitsebene zu durchdringen, Ihre Laufzeitanwendung (Remote Code Execution) und Ihre Speicher-Volumes erreicht und sich ausbreiten kann, um Ihre Infrastruktur und Daten zu beschädigen oder zu sperren? Was möchten Sie gegen solche Angriffe tun, insbesondere wenn sie sich in Ransomware verwandeln? Tarian ist entwickelt, um solche Risiken zu reduzieren, indem es Aktionen ergreift. Wir wissen, dass Tarian nicht die ultimative Lösung ist, aber wir sind zuversichtlich, dass es helfen kann, Risiken zu reduzieren, insbesondere wenn Wissen kontinuierlich von der Gemeinschaft geteilt wird. Aus technischer Sicht kann Tarian helfen, das Risiko zu reduzieren, indem es die infizierten Ressourcen zerstört.
kubectl create namespace tarian-system
Sie können jede Dgraph-Installationsoption verwenden, solange sie vom Tarian-Server aus zugänglich ist.
helm repo add tarian https://kube-tarian.github.io/helm-charts
helm repo update
helm upgrade -i tarian-server tarian/tarian-server --devel -n tarian-system --set server.dgraph.address=DGRAPH_ADDRESS:PORT
helm upgrade -i tarian-cluster-agent tarian/tarian-cluster-agent --devel -n tarian-system
kubectl wait --for=condition=ready pod --all -n tarian-system
kubectl exec -ti deploy/tarian-server -n tarian-system -- ./tarian-server dgraph apply-schema
Laden Sie die tarianctl-Binärdatei von der GitHub-Release-Seite herunter.
Ausführen:
tarianctl install
Sie können die folgenden Flags verwenden, um Ihre Installation anzupassen.
Install Tarian on Kubernetes.
Usage:
tarianctl install [flags]
Flags:
--agents-values strings Path to the helm values file for Tarian Cluster Agent and Node agent .
--charts string Path to the tarian helm charts directory.
--dgraph-values strings Path to the helm values file for DGraph.
-h, --help help for install
-n, --namespace string Namespace to install Tarian. (default "tarian-system")
--nats-values strings Path to the helm values file for Nats.
--server-values strings Path to the helm values file for Tarian Server.
Global Flags:
-k, --kubeconfig string path to the kubeconfig file to use
-e, --log-formatter string valid log formatters: json, text(default) (default "text")
-l, --log-level string valid log levels: debug, info(default), warn/warning, error, fatal (default "info")
-s, --server-address string tarian server address to communicate with (default "localhost:50051")
-c, --server-tls-ca-file string ca file that server uses for TLS connection
-t, --server-tls-enabled if enabled, it will communicate with the server using TLS
-i, --server-tls-insecure-skip-verify if set to true, it will skip server's certificate chain and hostname verification (default true)
Siehe Helm-Chart-Werte für
Ein privater GKE-Cluster erstellt standardmäßig Firewall-Regeln, um die Kommunikation zwischen Master und Nodes nur auf den Ports 443 und 10250 zu beschränken.
Um den tarian-pod-agent-Container zu injizieren, verwendet Tarian einen mutierenden Admission Webhook. Der Webhook-Server läuft auf Port 9443. Daher müssen
wir eine neue Firewall-Regel erstellen, um eingehenden Datenverkehr vom IP-Adressbereich des Masters zu den Nodes auf TCP-Port 9443 zu erlauben.
Weitere Details finden Sie in der GKE-Dokumentation zu diesem Thema: https://cloud.google.com/kubernetes-engine/docs/how-to/private-clusters#add_firewall_rules.
kubectl port-forward svc/tarian-server -n tarian-system 41051:80
export TARIAN_SERVER_ADDRESS=localhost:41051
tarianctl get events
tarianctl add constraint --name nginx --namespace default \
--match-labels run=nginx \
--allowed-processes=pause,tarian-pod-agent,nginx
tarianctl get constraints
tarianctl add constraint --name nginx-files --namespace default \
--match-labels run=nginx \
--allowed-file-sha256sums=/usr/share/nginx/html/index.html=38ffd4972ae513a0c79a8be4573403edcd709f0f572105362b08ff50cf6de521
tarianctl get constraints
Nachdem die Beschränkungen erstellt wurden, injizieren wir tarian-pod-agent in den Pod, indem wir eine Annotation hinzufügen:
metadata:
annotations:
pod-agent.k8s.tarian.dev/threat-scan: "true"
Ein Pod mit dieser Annotation erhält einen zusätzlichen injizierten Container (tarian-pod-agent). Der tarian-pod-agent-Container überprüft
kontinuierlich die Laufzeitumgebung basierend auf den registrierten Beschränkungen. Jeder Verstoß wird gemeldet und kann mit
tarianctl get events abgerufen werden.
kubectl apply -f https://raw.githubusercontent.com/kube-tarian/tarian/main/dev/config/monitored-pod/configmap.yaml
kubectl apply -f https://raw.githubusercontent.com/kube-tarian/tarian/main/dev/config/monitored-pod/pod.yaml
# warten, bis er bereit ist
kubectl wait --for=condition=ready pod nginx
# Simuliere einen unbekannten Prozesslauf
kubectl exec -ti nginx -c nginx -- sleep 15
# sollte in tarian gemeldet werden
tarianctl get events
Tarian wird standardmäßig mit Prometheus Alert Manager ausgeliefert. Wenn Sie eine andere Alert-Manager-Instanz verwenden möchten:
helm install tarian-server tarian/tarian-server --devel \
--set server.alert.alertManagerAddress=http://alertmanager.monitoring.svc:9093 \
--set alertManager.install=false \
-n tarian-system
Zum Deaktivieren setzen Sie den alertManagerAddress-Wert auf leer.
Siehe docs/troubleshooting.md
Wenn tarian-pod-agent im Registrierungsmodus läuft, meldet er unbekannte Prozesse und Dateien nicht als Verstöße, sondern registriert sie automatisch als neue Beschränkung. Dies ist praktisch, um Zeit bei der manuellen Registrierung zu sparen.
Um die Beschränkungsregistrierung zu aktivieren, muss der Cluster-Agent konfiguriert werden.
helm install tarian-cluster-agent tarian/tarian-cluster-agent --devel -n tarian-system \
--set clusterAgent.enableAddConstraint=true
metadata:
annotations:
# registriert sowohl Prozesse als auch Datei-Prüfsummen
pod-agent.k8s.tarian.dev/register: "processes,files"
# ignoriert bestimmte Pfade bei der automatischen Registrierung
pod-agent.k8s.tarian.dev/register-file-ignore-paths: "/usr/share/nginx/**/*.txt"
Die automatische Beschränkungsregistrierung kann auch in einem Dev-/Staging-Cluster durchgeführt werden, damit es in der Produktion weniger Änderungen gibt.
metadata:
annotations:
# gibt an, wie oft tarian-pod-agent die Datei-Prüfsumme überprüfen soll
pod-agent.k8s.tarian.dev/file-validation-interval: "1m"
Um tarian-server mit TLS zu sichern, erstellen Sie ein Secret mit dem TLS-Zertifikat. Sie können das Secret manuell erstellen oder mit Cert Manager. Sobald das Secret vorhanden ist, können Sie den Namen dem Helm-Chart-Wert übergeben:
helm upgrade -i tarian-server tarian/tarian-server --devel -n tarian-system \
--set server.tlsSecretName=tarian-server-tls
Siehe docs/contributing.md
Siehe CODE_OF_CONDUCT.md
Siehe MAINTAINERS.md
| Umgebung | Funktioniert | Anmerkungen |
|---|
| Kind v0.14.0 | ✔️ | |
| Minikube v1.26.0 | ✔️ | |
| Linode Kubernetes Engine (LKE) 1.22 | ✔️ | |
| Digital Ocean Kubernetes Engine (DOKS) 1.22 | ✔️ | |
| Google Kubernetes Engine (GKE) 1.22 | ✔️ | |
| Amazon Elastic Kubernetes Engine (EKS) | ➖ | kernel < 5.8 |
| Azure Kubernetes Service (AKS) | ➖ | kernel < 5.8 |