kube-tarian/tarianAgente di sicurezza runtime basato su eBPF per Kubernetes che rileva processi sconosciuti e modifiche ai file, applica vincoli pre-registrati e automatizza l'eliminazione dei pod o l'invio di avvisi per mitigare ransomware e altri attacchi.
Proteggi le tue applicazioni in esecuzione su Kubernetes da attacchi malevoli pre-registrando i tuoi processi fidati e le firme dei file fidati. Tarian rileverà processi sconosciuti e modifiche ai file registrati, quindi invierà avvisi e intraprenderà un'azione automatizzata. Salva il tuo ambiente K8s dai Ransomware!
Vogliamo mantenere questo progetto come open-source per combattere gli attacchi al nostro ecosistema Kubernetes preferito. Con un contributo continuo, possiamo combattere le minacce insieme come comunità.
Come funziona Tarian?
L'Agente del Cluster Tarian viene eseguito nel cluster Kubernetes rilevando processi sconosciuti e modifiche sconosciute ai file, li segnala al Server Tarian e facoltativamente intraprende un'azione: elimina il pod violato. Utilizza eBPF per rilevare nuovi processi. Per il rilevamento delle modifiche ai file, l'Agente del Cluster Tarian inietta un container sidecar nel pod dell'applicazione principale che verificherà i checksum dei file nel percorso configurato e li confronterà con i checksum registrati nel Server Tarian. Tarian farà parte del pod della tua applicazione dall'ambiente di sviluppo a quello di produzione, quindi puoi registrare nel tuo DB Tarian cosa dovrebbe accadere ed essere eseguito nel tuo container + le firme dei file da monitorare + cosa può essere notificato + l'azione da intraprendere (autodistruzione del pod) in base alle modifiche rilevate. Sposta a sinistra il tuo meccanismo di rilevamento!
Cosa succede se si verifica una modifica sconosciuta all'interno del container che non è presente nel DB di registrazione di Tarian? Come reagisce Tarian?
Se si verifica una modifica sconosciuta, Tarian può semplicemente notificare le analisi osservate al tuo Team di Sicurezza. Poi i tuoi Ingegneri della Sicurezza possono registrare quella modifica nel DB di Tarian, se è considerata una minaccia o meno. Inoltre, in base alla loro analisi, possono configurare quale azione intraprendere quando quella modifica si ripresenta.
In che modo il contributo della comunità aiuta a combattere le minacce tramite Tarian?
Qualsiasi nuovo rilevamento analizzato e contrassegnato come minaccia dai tuoi Esperti di Sicurezza, se lo desiderano, può essere condiviso con il DB della comunità open-source di Tarian con tutti i log, le stringhe da cercare, le osservazioni, la trasparenza, le azioni da configurare... Praticamente tutto ciò che gli Esperti vogliono segnalare e condividere con la comunità. Puoi utilizzare queste informazioni come utente di Tarian e configurare le azioni nell'app Tarian utilizzata nel tuo ambiente. Questo è fondamentalmente un meccanismo per condividere informazioni sulle minacce e su cosa fare con esse. Questo aiuta tutti coloro che utilizzano Tarian a intraprendere azioni insieme nei rispettivi ambienti K8s condividendo le loro conoscenze ed esperienze.
Quale tipo di azione/i intraprenderebbe Tarian in base a minacce note?
Tarian semplicemente autodistruggerebbe il pod su cui è in esecuzione. Se il malware/virus si diffonde al resto dell'ambiente, beh, sai cosa succede. Quindi, Tarian è fondamentalmente progettato per aiutare a ridurre il rischio il più possibile distruggendo i pod. Il provisioning di un nuovo pod sarà gestito dal deployment K8s. Tarian distruggerà i pod solo se glielo dici. Se non vuoi che accada alcuna azione, non devi configurarne o attivarne alcuna; puoi semplicemente dire a Tarian di notificarti. Tarian fa essenzialmente ciò che vuoi che sia fatto per ridurre il rischio.
Perché un altro nuovo strumento di sicurezza quando ci sono già molti strumenti disponibili, come Falco, Kube-Hunter, Kube-Bench, Calico Enterprise Security e molti altri strumenti di sicurezza (open-source e commerciali) in grado di rilevare e prevenire minacce a livello di rete, infrastruttura e applicazione? Perché Tarian?
Il motivo principale per cui Tarian è nato è per combattere le minacce in Kubernetes insieme come comunità. Un altro motivo è: cosa succede se esiste ancora qualche attacco sofisticato in grado di penetrare ogni livello della tua sicurezza, raggiungere la tua app in runtime (Remote Code Execution) e i tuoi volumi di archiviazione, e capace di diffondersi per danneggiare o bloccare la tua infrastruttura e i tuoi dati?! Cosa vuoi fare di fronte a tali attacchi, specialmente quelli che si trasformano in ransomware? Tarian è progettato per ridurre tali rischi, intraprendendo azioni. Sappiamo che Tarian non è la soluzione definitiva, ma siamo fiduciosi che possa aiutare a ridurre i rischi, specialmente quando la conoscenza viene condivisa continuamente dalla comunità. Da un punto di vista tecnico, Tarian può aiutare a ridurre il rischio distruggendo le risorse infette.
kubectl create namespace tarian-system
Puoi utilizzare qualsiasi opzione di installazione di Dgraph purché sia accessibile dal server tarian.
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
Scarica il binario tarianctl dalla pagina delle release di Github.
Esegui:
tarianctl install
Puoi utilizzare i seguenti flag per personalizzare la tua installazione.
Installa Tarian su Kubernetes.
Utilizzo:
tarianctl install [flags]
Flags:
--agents-values strings Percorso del file dei valori Helm per Tarian Cluster Agent e Node agent .
--charts string Percorso della directory dei chart Helm di tarian.
--dgraph-values strings Percorso del file dei valori Helm per DGraph.
-h, --help Aiuto per install
-n, --namespace string Namespace in cui installare Tarian. (default "tarian-system")
--nats-values strings Percorso del file dei valori Helm per Nats.
--server-values strings Percorso del file dei valori Helm per Tarian Server.
Global Flags:
-k, --kubeconfig string percorso del file kubeconfig da utilizzare
-e, --log-formatter string formati di log validi: json, text(default) (default "text")
-l, --log-level string livelli di log validi: debug, info(default), warn/warning, error, fatal (default "info")
-s, --server-address string indirizzo del server tarian con cui comunicare (default "localhost:50051")
-c, --server-tls-ca-file string file CA che il server utilizza per la connessione TLS
-t, --server-tls-enabled se abilitato, comunicherà con il server utilizzando TLS
-i, --server-tls-insecure-skip-verify se impostato su true, salterà la verifica della catena di certificati e del nome host del server (default true)
Vedi i valori dei chart Helm per
Un cluster GKE privato crea di default regole firewall per limitare la comunicazione tra master e nodi solo sulle porte 443 e 10250.
Per iniettare il container tarian-pod-agent, tarian utilizza un webhook di ammissione mutante. Il server webhook è in esecuzione sulla porta 9443. Pertanto, è necessario
creare una nuova regola firewall per consentire il traffico in ingresso dall'intervallo di indirizzi IP del master ai nodi sulla porta TCP 9443.
Per maggiori dettagli, consulta la documentazione GKE su questo argomento: 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
Dopo aver creato i vincoli, iniettiamo tarian-pod-agent nel pod aggiungendo un'annotazione:
metadata:
annotations:
pod-agent.k8s.tarian.dev/threat-scan: "true"
Un pod con questa annotazione avrà un container aggiuntivo iniettato (tarian-pod-agent). Il container tarian-pod-agent
verificherà continuamente l'ambiente di runtime in base ai vincoli registrati. Qualsiasi violazione verrà segnalata e sarà
accessibile con tarianctl get events.
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
# attendi che diventi pronto
kubectl wait --for=condition=ready pod nginx
# simula l'esecuzione di un processo sconosciuto
kubectl exec -ti nginx -c nginx -- sleep 15
# dovresti vederlo segnalato in tarian
tarianctl get events
Tarian viene fornito di default con Prometheus Alert Manager. Se desideri utilizzare un'altra istanza di alert manager:
helm install tarian-server tarian/tarian-server --devel \
--set server.alert.alertManagerAddress=http://alertmanager.monitoring.svc:9093 \
--set alertManager.install=false \
-n tarian-system
Per disabilitarlo, puoi impostare il valore alertManagerAddress a vuoto.
Quando tarian-pod-agent viene eseguito in modalità di registrazione, invece di segnalare processi e file sconosciuti come violazioni, li registra automaticamente come nuovo vincolo. Ciò è comodo per risparmiare tempo dalla registrazione manuale.
Per abilitare la registrazione dei vincoli, è necessario configurare il cluster-agent.
helm install tarian-cluster-agent tarian/tarian-cluster-agent --devel -n tarian-system \
--set clusterAgent.enableAddConstraint=true
metadata:
annotations:
# registra sia i processi che i checksum dei file
pod-agent.k8s.tarian.dev/register: "processes,files"
# ignora percorsi specifici dalla registrazione automatica
pod-agent.k8s.tarian.dev/register-file-ignore-paths: "/usr/share/nginx/**/*.txt"
La registrazione automatica dei vincoli può essere effettuata anche in un cluster di sviluppo/staging, in modo che ci siano meno modifiche in produzione.
metadata:
annotations:
# specifica la frequenza con cui tarian-pod-agent deve verificare il checksum dei file
pod-agent.k8s.tarian.dev/file-validation-interval: "1m"
Per proteggere tarian-server con TLS, crea un secret contenente il certificato TLS. Puoi creare il secret manualmente o utilizzando Cert Manager. Una volta ottenuto il secret, puoi passare il nome al valore del chart Helm:
helm upgrade -i tarian-server tarian/tarian-server --devel -n tarian-system \
--set server.tlsSecretName=tarian-server-tls
Vedi docs/contributing.md
Vedi CODE_OF_CONDUCT.md
Vedi MAINTAINERS.md
| Ambiente | Funzionante | Note |
|---|
| 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 |