kube-tarian/tarianAgent de sécurité d'exécution basé sur eBPF pour Kubernetes qui détecte les processus inconnus et les modifications de fichiers, applique des contraintes pré-enregistrées et automatise la suppression de pods ou l'envoi d'alertes pour atténuer les ransomwares et autres attaques.
Protégez vos applications exécutées sur Kubernetes contre les attaques malveillantes en pré-enregistrant vos processus de confiance et les signatures de fichiers de confiance. Tarian détectera les processus inconnus et les modifications des fichiers enregistrés, puis enverra des alertes et prendra une action automatisée. Protégez votre environnement K8s des ransomwares !
Nous souhaitons maintenir ce projet en open-source pour lutter contre les attaques sur notre écosystème Kubernetes préféré. Grâce à une contribution continue, nous pouvons combattre les menaces ensemble en tant que communauté.
Comment fonctionne Tarian ?
L'Agent Cluster Tarian s'exécute dans le cluster Kubernetes, détectant les processus inconnus et les modifications inconnues des fichiers, les signale au Serveur Tarian et, éventuellement, prend une action : supprimer le pod violé. Il utilise eBPF pour détecter les nouveaux processus. Pour la détection des modifications de fichiers, l'Agent Cluster Tarian injecte un conteneur sidecar dans le pod de votre application principale, qui vérifiera les sommes de contrôle des fichiers dans le chemin configuré et les comparera avec les sommes de contrôle enregistrées dans le Serveur Tarian. Tarian fera partie du pod de votre application de l'environnement de développement à la production, vous permettant ainsi d'enregistrer dans votre base de données Tarian ce qui est censé se produire et s'exécuter dans votre conteneur, les signatures de fichiers à surveiller, ce qui peut être notifié et l'action à entreprendre (auto-destruction du pod) en fonction des changements détectés. Déplacez votre mécanisme de détection vers la gauche !
Que se passe-t-il si un changement inconnu se produit dans le conteneur, qui n'est pas dans la base de données d'enregistrement de Tarian ? Comment Tarian réagit-il ?
Si un changement inconnu se produit, Tarian peut simplement notifier les analyses observées à votre équipe de sécurité. Ensuite, vos ingénieurs sécurité peuvent enregistrer ce changement dans la base de données Tarian, qu'il soit considéré comme une menace ou non. De plus, en fonction de leur analyse, ils peuvent configurer l'action à entreprendre lorsque ce changement se reproduit.
Comment la contribution de la communauté aide-t-elle à lutter contre les menaces via Tarian ?
Toute nouvelle détection analysée et marquée comme menace par vos experts en sécurité, s'ils le souhaitent, peut être partagée dans la base de données communautaire open-source de Tarian avec tous les journaux, chaînes à rechercher, observations, transparence, actions à configurer, etc. Essentiellement, tout ce que les experts veulent signaler et partager avec la communauté. Vous pouvez utiliser ces informations en tant qu'utilisateur de Tarian et configurer des actions dans l'application Tarian que vous utilisez dans votre environnement. C'est fondamentalement un mécanisme pour partager des informations sur les menaces et quoi en faire. Cela aide tous ceux qui utilisent Tarian à agir ensemble dans leurs environnements K8s respectifs en partageant leurs connaissances et leur expérience.
Quel(s) type(s) d'action(s) Tarian entreprendrait-il en fonction des menaces connues ?
Tarian détruirait simplement le pod sur lequel il s'exécute. Si le malware/virus se propage au reste de l'environnement, vous savez ce qui se passe. Donc, Tarian est conçu pour aider à réduire le risque autant que possible en détruisant les pods. La mise à disposition d'un nouveau pod sera gérée par le déploiement K8s. Tarian ne détruira les pods que si vous lui demandez de le faire. Si vous ne voulez aucune action, vous n'avez pas besoin d'en configurer ou d'en déclencher ; vous pouvez simplement dire à Tarian de vous notifier. Tarian fait essentiellement ce que vous voulez pour réduire le risque.
Pourquoi un autre nouvel outil de sécurité alors qu'il existe déjà de nombreux outils, comme Falco, Kube-Hunter, Kube-Bench, Calico Enterprise Security, et bien d'autres outils de sécurité (open-source et commerciaux) capables de détecter et prévenir les menaces au niveau réseau, infrastructure et application ? Pourquoi Tarian ?
La principale raison de la naissance de Tarian est de lutter contre les menaces dans Kubernetes ensemble en tant que communauté. Une autre raison était : et s'il existe encore une attaque sophistiquée capable de pénétrer chaque couche de votre sécurité, d'atteindre votre application runtime (exécution de code à distance) et vos volumes de stockage, et capable de se propager pour endommager ou verrouiller votre infrastructure et vos données ? Que voulez-vous faire face à de telles attaques, surtout celles qui se transforment en ransomware ? Tarian est conçu pour réduire ces risques, en prenant des actions. Nous savons que Tarian n'est pas la solution ultime, mais nous sommes confiants qu'il peut aider à réduire les risques, surtout lorsque les connaissances sont partagées en continu par la communauté. D'un point de vue technique, Tarian peut aider à réduire le risque en détruisant les ressources infectées.
kubectl create namespace tarian-system
Vous pouvez utiliser n'importe quelle option d'installation Dgraph tant qu'elle est accessible depuis le serveur 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=ADRESSE_DGRAPH: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
Téléchargez le binaire tarianctl depuis la page de publication GitHub.
Exécutez :
tarianctl install
Vous pouvez utiliser les options suivantes pour personnaliser votre installation.
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)
Voir les valeurs du chart Helm pour
Un cluster GKE privé crée par défaut des règles de pare-feu pour restreindre la communication du maître vers les nœuds uniquement sur les ports 443 et 10250.
Pour injecter le conteneur tarian-pod-agent, Tarian utilise un webhook d'admission mutant. Le serveur webhook écoute sur le port 9443. Donc, nous devons
créer une nouvelle règle de pare-feu pour autoriser le trafic entrant depuis la plage d'adresses IP du maître vers les nœuds sur le port TCP 9443.
Pour plus de détails, voir la documentation GKE sur ce sujet : 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
Ensuite, une fois les contraintes créées, nous injectons tarian-pod-agent dans le pod en ajoutant une annotation :
metadata:
annotations:
pod-agent.k8s.tarian.dev/threat-scan: "true"
Le pod avec cette annotation aura un conteneur supplémentaire injecté (tarian-pod-agent). Le conteneur tarian-pod-agent
vérifiera en continu l'environnement d'exécution en fonction des contraintes enregistrées. Toute violation sera signalée, accessible avec 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
# attendre qu'il devienne prêt
kubectl wait --for=condition=ready pod nginx
# simuler l'exécution d'un processus inconnu
kubectl exec -ti nginx -c nginx -- sleep 15
# vous devriez le voir signalé dans tarian
tarianctl get events
Tarian est livré avec Prometheus Alert Manager par défaut. Si vous voulez utiliser une autre instance de gestionnaire d'alertes :
helm install tarian-server tarian/tarian-server --devel \
--set server.alert.alertManagerAddress=http://alertmanager.monitoring.svc:9093 \
--set alertManager.install=false \
-n tarian-system
Pour le désactiver, vous pouvez définir la valeur alertManagerAddress à vide.
Lorsque tarian-pod-agent s'exécute en mode d'enregistrement, au lieu de signaler les processus et fichiers inconnus comme violations, il les enregistre automatiquement comme une nouvelle contrainte. Cela permet de gagner du temps en évitant un enregistrement manuel.
Pour activer l'enregistrement des contraintes, l'agent cluster doit être configuré.
helm install tarian-cluster-agent tarian/tarian-cluster-agent --devel -n tarian-system \
--set clusterAgent.enableAddConstraint=true
metadata:
annotations:
# enregistrer à la fois les processus et les sommes de contrôle des fichiers
pod-agent.k8s.tarian.dev/register: "processes,files"
# ignorer des chemins spécifiques de l'enregistrement automatique
pod-agent.k8s.tarian.dev/register-file-ignore-paths: "/usr/share/nginx/**/*.txt"
L'enregistrement automatique des contraintes peut également être effectué dans un cluster de développement/staging, afin qu'il y ait moins de changements en production.
metadata:
annotations:
# spécifier à quelle fréquence tarian-pod-agent doit vérifier la somme de contrôle des fichiers
pod-agent.k8s.tarian.dev/file-validation-interval: "1m"
Pour sécuriser le serveur Tarian avec TLS, créez un secret contenant le certificat TLS. Vous pouvez créer le secret manuellement, ou en utilisant Cert Manager. Une fois que vous avez le secret, vous pouvez passer le nom à la valeur du chart Helm :
helm upgrade -i tarian-server tarian/tarian-server --devel -n tarian-system \
--set server.tlsSecretName=tarian-server-tls
Voir docs/contributing.md
Voir CODE_OF_CONDUCT.md
Voir MAINTAINERS.md
| Environnement | Fonctionne | Notes |
|---|
| 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 |