
K8s के लिए एंटी-वायरस। कुबेरनेटीज़ पर चल रहे अपने एप्लिकेशन को पूर्व-पंजीकृत स्रोत कोड, रनटाइम प्रक्रियाओं की निगरानी, विश्लेषण, अलर्टिंग और समुदाय के साथ पहचान साझा करने के साथ दुर्भावनापूर्ण हमलों से बचाएं। शायद रैनसमवेयर से बचाएं।
हम इसे ओपन-सोर्स बनाए रखना चाहते हैं ताकि हम अपने पसंदीदा Kubernetes पारिस्थितिकी तंत्र पर होने वाले हमलों से लड़ सकें। हम एक समुदाय के रूप में निरंतर योगदान से मिलकर खतरों से लड़ सकते हैं।
Tarian कैसे काम करता है?
Tarian आपके मुख्य एप्लिकेशन के पॉड में एक साइडकार कंटेनर के रूप में चलता है, जो प्रक्रिया आईडी, चल रही प्रक्रियाओं की संख्या, पैरेंट और चाइल्ड प्रक्रियाओं के बीच संबंधों में परिवर्तन, फ़ाइल सिस्टम में फ़ाइलों और निर्देशिकाओं में परिवर्तन, आपकी फ़ाइलों के हस्ताक्षरों में परिवर्तन आदि पर नज़र रखता है। Tarian आपके एप्लिकेशन के पॉड का हिस्सा होगा डेव से लेकर प्रोड वातावरण तक, इसलिए आप अपने Tarian DB में पंजीकृत कर सकते हैं कि आपके कंटेनर में क्या होना चाहिए और क्या चल रहा है + क्या निगरानी की जा सकती है + क्या सूचित किया जा सकता है + पता लगाए गए परिवर्तनों के आधार पर कार्रवाई (पॉड को स्वयं नष्ट करना) की जा सकती है। अपने डिटेक्शन मैकेनिज्म को शिफ्ट-लेफ्ट करें!
यदि कंटेनर के अंदर कोई अज्ञात परिवर्तन होता है जो Tarian के पंजीकरण DB में नहीं है, तो Tarian उस पर कैसे प्रतिक्रिया करता है?
यदि कोई अज्ञात परिवर्तन होता है, तो Tarian आपकी सुरक्षा टीम को देखे गए एनालिटिक्स की सूचना दे सकता है + लॉग सुरक्षा टीम को भेज सकता है। फिर आपके सुरक्षा इंजीनियर Tarian DB में उस परिवर्तन को खतरा है या नहीं, इस आधार पर पंजीकृत कर सकते हैं और अपने विश्लेषण के आधार पर वे कॉन्फ़िगर कर सकते हैं कि क्या कार्रवाई करनी है। वह कार्रवाई साइडकार Tarian ऐप को कमांड के रूप में भेजी जाएगी ताकि वह कार्रवाई कर सके।
समुदाय का योगदान Tarian के माध्यम से खतरों से लड़ने में कैसे मदद करता है?
आपके सुरक्षा विशेषज्ञों द्वारा विश्लेषण किए गए और खतरे के रूप में चिह्नित किए गए कोई भी नए डिटेक्शन, यदि वे चुनें, तो ओपन-सोर्स Tarian समुदाय DB में सभी लॉग, खोजने के लिए स्ट्रिंग्स, अवलोकन, पारदर्शिता, कॉन्फ़िगर करने के लिए कार्रवाइयाँ, मूल रूप से विशेषज्ञ जो कुछ भी चेतावनी देना और समुदाय के साथ साझा करना चाहता है, साझा किया जा सकता है। आप Tarian उपयोगकर्ता के रूप में उस जानकारी का उपयोग कर सकते हैं और अपने वातावरण में उपयोग किए जाने वाले Tarian ऐप में कार्रवाइयाँ कॉन्फ़िगर कर सकते हैं। यह मूल रूप से खतरों और उनके बारे में क्या करना है, इसकी जानकारी साझा करना है। इससे Tarian का उपयोग करने वाले सभी लोगों को अपने विश्लेषण साझा करने और ज्ञान और अनुभव साझा करके अपने संबंधित K8s वातावरण में मिलकर कार्रवाई करने में मदद मिलती है।
Tarian ज्ञात खतरे (खतरों) के आधार पर किस प्रकार की कार्रवाई करेगा?
Tarian जोखिम को कम करने के लिए जिस पॉड पर चल रहा है, उसे स्वयं नष्ट कर देगा और वॉल्यूम पर किसी भी फ़ाइल को हटा देगा। यदि मैलवेयर/वायरस बाकी वातावरण में फैलता है, तो आप जानते हैं कि क्या होता है। इसलिए, Tarian मूल रूप से पॉड को नष्ट करके जोखिम को जितना संभव हो उतना कम करने में मदद करने के लिए डिज़ाइन किया गया है। नए पॉड की प्रावधानिंग K8s द्वारा की जाएगी क्योंकि K8s ऐसे ही काम करता है। Tarian केवल पॉड का विनाश करेगा, और केवल तभी जब आप Tarian को Tarian कंट्रोलर में कार्रवाई पूर्व-कॉन्फ़िगर करके या Tarian को ऑन-द-फ्लाई ऐसा करने के लिए कहकर ऐसा करने के लिए कहेंगे। यदि आप कोई कार्रवाई नहीं चाहते हैं, तो आपको कोई कॉन्फ़िगर या ट्रिगर करने की आवश्यकता नहीं है; आप बस Tarian को केवल आपको सूचित करने के लिए कह सकते हैं। Tarian मूल रूप से वही करता है जो आप जोखिम कम करने के लिए करना चाहते हैं।
जब पहले से ही कई उपकरण उपलब्ध हैं, जैसे Falco, Kube-Hunter, Kube-Bench, Calico Enterprise Security, और कई अन्य सुरक्षा उपकरण (ओपन-सोर्स और वाणिज्यिक) जो नेटवर्क स्तर, इंफ्रा स्तर और एप्लिकेशन स्तर पर खतरों का पता लगा सकते हैं और रोक सकते हैं, तो एक और नया सुरक्षा उपकरण क्यों? Tarian क्यों?
जैसा कि मैंने ऊपर उल्लेख किया, Tarian के जन्म का मुख्य कारण Kubernetes में खतरों के खिलाफ एक समुदाय के रूप में मिलकर लड़ना है। और दूसरा कारण यह था, क्या होगा यदि अभी भी कुछ परिष्कृत हमला है जो आपकी सुरक्षा की हर परत को भेदने और आपके रनटाइम ऐप, आपके स्टोरेज वॉल्यूम तक पहुंचने में सक्षम है और आपके इंफ्रा और डेटा को नुकसान पहुंचाने या लॉक करने के लिए फैलने में सक्षम है?! आप ऐसे हमलों के बारे में क्या करना चाहते हैं, खासकर जो रैनसमवेयर में बदल जाते हैं। Tarian ऐसे जोखिमों को कम करने के लिए डिज़ाइन किया गया है, कार्रवाई करके। हम जानते हैं कि Tarian अंतिम समाधान नहीं है, लेकिन हमें विश्वास है कि यह जोखिम को कम करने में मदद कर सकता है, खासकर जब समुदाय द्वारा लगातार ज्ञान साझा किया जाता है और तकनीकी दृष्टिकोण से भी Tarian संक्रमित संसाधनों को नष्ट करके जोखिम को कम करने में मदद कर सकता है।
मैं डिज़ाइन आरेख को जल्द ही अंतिम रूप दूंगा, जब मैं कुछ सुरक्षा विशेषज्ञों से बात करना समाप्त करूंगा (मैंने पहले ही कुछ से बात की है, और कुछ और चर्चाएं बाकी हैं)।
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
हेल्म चार्ट मान देखें:
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
फिर बाधाएँ बनने के बाद, हम पॉड में एक एनोटेशन जोड़कर tarian-pod-agent इंजेक्ट करते हैं:
metadata:
annotations:
pod-agent.k8s.tarian.dev/threat-scan: "true"
इस एनोटेशन वाले पॉड में एक अतिरिक्त कंटेनर (tarian-pod-agent) इंजेक्ट किया जाएगा। tarian-pod-agent कंटेनर पंजीकृत बाधाओं के आधार पर रनटाइम वातावरण को लगातार सत्यापित करेगा। कोई भी उल्लंघन रिपोर्ट किया जाएगा, जिसे 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
# wait for it to become ready
kubectl wait --for=condition=ready pod nginx
# simulate unknown process runs
kubectl exec -ti nginx -c nginx -- sleep 15
# you should see it reported in tarian
tarianctl get events
Tarian डिफ़ॉल्ट रूप से Prometheus 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
इसे अक्षम करने के लिए, आप alertManagerAddress मान को खाली सेट कर सकते हैं।
docs/falco-integration.md देखें
docs/troubleshooting.md देखें
जब tarian-pod-agent पंजीकरण मोड में चलता है, तो अज्ञात प्रक्रियाओं और फ़ाइलों को उल्लंघन के रूप में रिपोर्ट करने के बजाय, यह स्वचालित रूप से उन्हें एक नई बाधा के रूप में पंजीकृत करता है। यह मैन्युअल रूप से पंजीकरण करने से समय बचाने के लिए सुविधाजनक है।
बाधा पंजीकरण को सक्षम करने के लिए, क्लस्टर-एजेंट को कॉन्फ़िगर करने की आवश्यकता है।
helm install tarian-cluster-agent tarian/tarian-cluster-agent --devel -n tarian-system \
--set clusterAgent.enableAddConstraint=true
metadata:
annotations:
# both processes and file checksums register
pod-agent.k8s.tarian.dev/register: "processes,files"
# ignore specific paths from automatic registration
pod-agent.k8s.tarian.dev/register-file-ignore-paths: "/usr/share/nginx/**/*.txt"
स्वचालित बाधा पंजीकरण dev/staging क्लस्टर में भी किया जा सकता है, ताकि प्रोडक्शन में कम बदलाव हों।
metadata:
annotations:
# specify how often tarian-pod-agent should verify file checksum
pod-agent.k8s.tarian.dev/file-validation-interval: "1m"