devopstoday11/tarianAnti-Virus per K8s. Proteggi le tue applicazioni in esecuzione su Kubernetes da attacchi dannosi con codice sorgente preregistrato, monitoraggio dei processi in esecuzione, analisi, avvisi e anche condivisione delle rilevazioni con la comunità. Forse salva dal Ransomware.
Vogliamo mantenere questo progetto open-source per combattere gli attacchi al nostro ecosistema Kubernetes preferito. Possiamo combattere le minacce insieme come comunità, attraverso un contributo continuo.
Come funziona Tarian?
Tarian viene eseguito come contenitore sidecar nel pod della tua applicazione principale, monitorando le modifiche agli ID dei processi, al numero di processi in esecuzione, alle relazioni tra processi padre e figlio, ai file e alle directory nel filesystem che appartengono alla tua applicazione, alle modifiche alle firme dei file, ecc. Tarian farà parte del pod della tua applicazione dall'ambiente di sviluppo a quello di produzione, quindi puoi registrare nel tuo database Tarian ciò che dovrebbe accadere ed essere eseguito nel tuo contenitore + ciò che può essere monitorato + ciò che può essere notificato + le azioni (autodistruzione del pod) da intraprendere in base ai cambiamenti rilevati. Sposta a sinistra il tuo meccanismo di rilevamento!
Cosa succede se si verifica un cambiamento sconosciuto all'interno del contenitore che non è presente nel database di registrazione di Tarian? Come reagisce Tarian in tal caso?
Se si verifica un cambiamento sconosciuto, Tarian può semplicemente notificare le analisi osservate al tuo team di sicurezza + inviare il log al team di sicurezza. I tuoi ingegneri della sicurezza possono quindi registrare quel cambiamento nel database di Tarian come minaccia o meno e, in base alla loro analisi, possono configurare l'azione da intraprendere. Tale azione verrà inviata come comando all'app Tarian sidecar per eseguire l'azione.
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 nel database della comunità open-source di Tarian con tutti i log, le stringhe da cercare, le osservazioni, la trasparenza, le azioni da configurare, essenzialmente tutto ciò che l'esperto vuole segnalare e condividere con la comunità. Puoi utilizzare queste informazioni come utente di Tarian e configurare le azioni nella tua app Tarian che usi nel tuo ambiente. Questo significa essenzialmente condividere informazioni sulle minacce e su cosa fare al riguardo. Questo aiuta tutti coloro che usano Tarian a condividere le proprie analisi e ad agire insieme nei rispettivi ambienti K8s, condividendo conoscenza ed esperienza.
Quale/i azione/i intraprenderebbe Tarian in base a minacce note?
Tarian distruggerebbe semplicemente il pod su cui è in esecuzione, insieme all'eliminazione di eventuali file sui volumi, per ridurre il rischio. 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 da K8s, poiché è così che funziona K8s. Tarian eseguirà solo la distruzione dei pod, e solo se gli dici di farlo preconfigurando l'azione nel controller Tarian o dicendo a Tarian di farlo al volo. Se non vuoi che vengano eseguite azioni, non devi configurarle o attivarle; puoi semplicemente dire a Tarian di notificarti soltanto. Tarian fa essenzialmente ciò che vuoi che venga fatto per ridurre il rischio.
Perché un altro nuovo strumento di sicurezza quando esistono già molti strumenti, come Falco, Kube-Hunter, Kube-Bench, Calico Enterprise Security e molti altri strumenti di sicurezza (open-source e commerciali) che possono rilevare e prevenire minacce a livello di rete, infrastruttura e applicazione? Perché Tarian?
Come ho detto sopra, la ragione principale per cui Tarian è nato è per combattere insieme come comunità contro le minacce in Kubernetes. E un'altra ragione era: e se esistesse ancora un attacco sofisticato in grado di penetrare ogni livello delle tue difese e raggiungere la tua applicazione runtime, i tuoi volumi di archiviazione e in grado di diffondersi per danneggiare o bloccare la tua infrastruttura e i tuoi dati? Cosa vuoi fare contro 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à e anche dal punto di vista tecnico Tarian può aiutare a ridurre il rischio distruggendo le risorse infette.
Finalizzerò presto il diagramma di progettazione dopo aver parlato con alcuni esperti di sicurezza (ho già parlato con alcuni e ho ancora alcune discussioni in sospeso).
kubectl create namespace tarian-system
helm install tarian-postgresql bitnami/postgresql -n tarian-system \
--set postgresqlUsername=postgres \
--set postgresqlPassword=tarian \
--set postgresqlDatabase=tarian
helm repo add tarian https://devopstoday11.github.io/tarian
helm repo update
helm install tarian-server tarian/tarian-server --devel -n tarian-system
helm install 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 db migrate
Vedi i valori del chart Helm per:
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 contenitore aggiuntivo iniettato (tarian-pod-agent). Il contenitore tarian-pod-agent verificherà continuamente l'ambiente runtime in base ai vincoli registrati. Qualsiasi violazione verrà segnalata e sarà accessibile con tarianctl get events.
kubectl apply -f https://raw.githubusercontent.com/devopstoday11/tarian/main/dev/config/monitored-pod/configmap.yaml
kubectl apply -f https://raw.githubusercontent.com/devopstoday11/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 include Prometheus Alert Manager per impostazione predefinita. 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.
Vedi docs/falco-integration.md
Quando tarian-pod-agent viene eseguito in modalità di registrazione, invece di segnalare processi e file sconosciuti come violazioni, li registra automaticamente come nuovi vincoli. Ciò è utile per risparmiare tempo rispetto alla 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 processi che 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 eseguita anche in un cluster di sviluppo/staging, in modo che ci siano meno modifiche in produzione.
metadata:
annotations:
# specifica quanto spesso tarian-pod-agent deve verificare il checksum del file
pod-agent.k8s.tarian.dev/file-validation-interval: "1m"