अंतिम समीक्षा: मई 2026
CKS परीक्षा द्वारा परखे जाने वाले architectural patterns का स्कैन-योग्य संदर्भ। ऊपर से नीचे पढ़ें या किसी section पर जाएं।
उद्योग-मानक सुरक्षा सर्वोत्तम प्रथाओं के विरुद्ध क्लस्टर कॉन्फ़िगरेशन का आकलन करें।
कंट्रोल प्लेन और वर्कर नोड्स के विरुद्ध CIS Kubernetes Benchmark चेक चलाने के लिए `kube-bench` का उपयोग करें।
क्यों: `kube-bench` इस विशिष्ट कार्य के लिए मानक उपकरण है, जो व्यापक CIS दिशानिर्देशों के विरुद्ध जांच को स्वचालित करता है।
सभी API सर्वर अनुरोधों के लिए मजबूत प्रमाणीकरण लागू करें।
`kube-apiserver` फ़्लैग सेट करें: अप्रामाणिक अनुरोधों को अस्वीकार करने के लिए `--anonymous-auth=false`, और क्लाइंट प्रमाणपत्र सत्यापन (mTLS) लागू करने के लिए `--client-ca-file`।
क्यों: ये फ़्लैग अनाम पहुंच को खत्म करने और API सर्वर के साथ प्रमाणित, एन्क्रिप्टेड संचार लागू करने के लिए मौलिक नियंत्रण हैं।
क्लस्टर के etcd स्टेट स्टोर को अनधिकृत पहुंच और डेटा चोरी से सुरक्षित करें।
सभी क्लाइंट और पीयर संचार के लिए etcd को mTLS के साथ कॉन्फ़िगर करें (`--cert-file`, `--key-file`, `--peer-cert-file`)। API सर्वर के `--encryption-provider-config` फ़्लैग के माध्यम से secrets-at-rest एन्क्रिप्शन सक्षम करें।
क्यों: etcd में क्लस्टर के सभी सीक्रेट होते हैं। डेटा को इन-ट्रांजिट (mTLS) और एट-रेस्ट एन्क्रिप्ट करना संवेदनशील जानकारी की सुरक्षा के लिए महत्वपूर्ण है, भले ही etcd नोड्स से समझौता किया गया हो।
शून्य डाउनटाइम के साथ etcd एन्क्रिप्शन-एट-रेस्ट कुंजियों को घुमाएं।
1. नई कुंजी को `EncryptionConfiguration` फ़ाइल में पहली प्रविष्टि के रूप में जोड़ें। 2. सभी API सर्वर को पुनरारंभ करें। 3. सभी सीक्रेट्स को फिर से एन्क्रिप्ट करने के लिए मजबूर करें (`kubectl get secrets -A -o json | kubectl replace -f -`)। 4. सत्यापन के बाद, कॉन्फ़िगरेशन से पुरानी कुंजी को हटा दें और API सर्वर को फिर से पुनरारंभ करें।
क्यों: कॉन्फ़िगरेशन बदलने से केवल नए राइट्स प्रभावित होते हैं। मौजूदा डेटा को नई कुंजी के साथ एन्क्रिप्ट करने के लिए फिर से लिखना होगा। पुरानी कुंजी को समय से पहले हटाने से आप अपने डेटा तक पहुंच खो देंगे।
एक नेमस्पेस के भीतर एक ज़ीरो-ट्रस्ट नेटवर्क मॉडल लागू करें।
एक `NetworkPolicy` को खाली `podSelector: {}` और `policyTypes: [Ingress, Egress]` के साथ लागू करें, लेकिन कोई `ingress` या `egress` नियम नहीं। यह सभी पॉड्स का चयन करता है और सभी ट्रैफ़िक को अस्वीकार करता है।
क्यों: यह पॉलिसी एक "सभी को अस्वीकार करें" आधार रेखा स्थापित करती है, जो सभी आवश्यक संचार के लिए स्पष्ट "अनुमति दें" नियमों को मजबूर करती है, जो ज़ीरो-ट्रस्ट नेटवर्किंग की नींव है।
एग्रेस `NetworkPolicies` पॉड्स के लिए DNS रिज़ॉल्यूशन को ब्लॉक कर रहे हैं।
क्लस्टर DNS सेवा में ट्रैफ़िक की अनुमति देने के लिए एक विशिष्ट एग्रेस नियम जोड़ें। UDP और TCP दोनों प्रोटोकॉल पर पोर्ट 53 पर एग्रेस की अनुमति दें। यदि संभव हो तो `namespaceSelector` और `podSelector` के माध्यम से kube-dns पॉड्स का चयन करें।
क्यों: `NetworkPolicies` दानेदार होते हैं। एक IP ब्लॉक के लिए एक सामान्य एग्रेस नियम DNS के लिए आवश्यक विशिष्ट प्रोटोकॉल (UDP) को कवर नहीं कर सकता है, जिससे रिज़ॉल्यूशन विफलताएं हो सकती हैं।
एक Ingress के माध्यम से उजागर सेवाओं तक बाहरी पहुंच को सुरक्षित करें।
एक `tls` अनुभाग जोड़कर Ingress रिसोर्स को कॉन्फ़िगर करें जो `kubernetes.io/tls` प्रकार के Kubernetes सीक्रेट को संदर्भित करता है। सीक्रेट में TLS प्रमाणपत्र और निजी कुंजी होनी चाहिए।
क्यों: यह Ingress कंट्रोलर पर TLS टर्मिनेशन को केंद्रीकृत करता है, क्लाइंट से क्लस्टर सीमा तक ट्रैफ़िक को एन्क्रिप्ट करता है और बैकएंड सेवाओं के लिए प्रमाणपत्र प्रबंधन को सरल बनाता है।
उपयोगकर्ताओं या अनुप्रयोगों को केवल न्यूनतम आवश्यक अनुमतियाँ प्रदान करें।
जहां संभव हो, नेमस्पेस-स्कोप वाले `Roles` और `RoleBindings` का उपयोग करें। `cluster-admin` और `verbs` या `resources` में वाइल्डकार्ड (`"*"`) से बचें। `["pods"]` पर `["get", "list"]` जैसी विशिष्ट अनुमतियाँ प्रदान करें।
क्यों: यह हमले के दायरे को कम करता है यदि कोई खाता या टोकन समझौता किया जाता है, तो पार्श्व गति और विशेषाधिकार वृद्धि को रोकता है।
उन पॉड्स के लिए हमले के सतह को कम करें जिन्हें Kubernetes API के साथ इंटरैक्ट करने की आवश्यकता नहीं है।
ServiceAccount पर या Pod स्पेसिफिकेशन में `automountServiceAccountToken: false` सेट करके सर्विस अकाउंट टोकन के स्वचालित माउंटिंग को अक्षम करें।
क्यों: यदि कोई पॉड समझौता किया जाता है, तो हमलावर API सर्वर तक पहुंचने के लिए माउंटेड टोकन का लाभ नहीं उठा सकता है, जिससे समझौता किए गए पॉड से उत्पन्न होने वाले क्लस्टर-स्तरीय हमलों को रोका जा सकता है।
जांचें कि क्या किसी विशिष्ट उपयोगकर्ता या सेवा खाते के पास कोई कार्रवाई करने की अनुमति है।
`kubectl auth can-i <verb> <resource> --as=<user>` या `kubectl auth can-i <verb> <resource> --as=system:serviceaccount:<ns>:<sa-name>` का उपयोग करें।
क्यों: यह कमांड सभी `Roles` और `Bindings` को मैन्युअल रूप से पार्स करने की आवश्यकता के बिना प्रभावी अनुमतियों की सटीक जांच करने के लिए प्रतिरूपण की अनुमति देता है।
कंट्रोल प्लेन और kubelet प्रमाणपत्रों को नियमित रूप से घुमाकर क्लस्टर सुरक्षा बनाए रखें।
kubeadm क्लस्टर के लिए, `kubeadm certs renew all` का उपयोग करें। दूसरों के लिए, दस्तावेज़ में उल्लिखित मैनुअल या स्वचालित रोटेशन प्रक्रिया का पालन करें। kubelet क्लाइंट/सर्वर प्रमाणपत्र रोटेशन को इसके कॉन्फ़िगरेशन के माध्यम से सक्षम करें।
क्यों: नियमित रोटेशन उस समय सीमा को सीमित करता है जिसका हमलावर समझौता किए गए प्रमाणपत्र का उपयोग कर सकता है। यह एक महत्वपूर्ण सुरक्षा स्वच्छता अभ्यास है।
एक वर्कर नोड पर समझौता होने का संदेह है और उसे तुरंत अलग किया जाना चाहिए।
सबसे पहले, नए पॉड्स को शेड्यूल होने से रोकने के लिए `kubectl cordon <node-name>` का उपयोग करें। फिर, चल रहे वर्कलोड को सुरक्षित रूप से निकालने के लिए `kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data` का उपयोग करें।
क्यों: कॉर्डनिंग और ड्रेनिंग एक नोड को सेवा से हटाने की मानक, गैर-विनाशकारी प्रक्रिया है, जिससे वर्कलोड को कहीं और फिर से शेड्यूल किया जा सकता है जबकि समझौता किए गए नोड को फॉरेंसिक विश्लेषण के लिए संरक्षित रखा जा सकता है।
एक कंटेनर द्वारा होस्ट कर्नेल पर किए जा सकने वाले सिस्टम कॉल को प्रतिबंधित करें।
पॉड या कंटेनर `securityContext` में, एक सुरक्षित आधार रेखा के लिए `seccompProfile.type` को `RuntimeDefault` पर सेट करें, या सख्त नियंत्रण के लिए एक कस्टम-परिभाषित JSON प्रोफ़ाइल के पथ के साथ `Localhost` पर सेट करें।
क्यों: Seccomp एक कंटेनर के भीतर से कर्नेल हमले के सतह को कम करता है, अप्रयुक्त या खतरनाक syscalls को ब्लॉक करके कर्नेल कमजोरियों के खिलाफ शोषण को रोकता है।
फ़ाइलों, नेटवर्क क्षमताओं और अन्य संसाधनों तक पहुंच को प्रतिबंधित करके कंटेनर प्रक्रियाओं को सीमित करें।
एनोटेशन के माध्यम से एक कंटेनर में एक AppArmor प्रोफ़ाइल लागू करें: `container.apparmor.security.beta.kubernetes.io/<container_name>: localhost/<profile_name>`। प्रोफ़ाइल को नोड पर पहले से लोड किया जाना चाहिए।
क्यों: AppArmor अनिवार्य एक्सेस कंट्रोल (MAC) प्रदान करता है, जो समझौता किए गए एप्लिकेशन को समाहित करने और उसे अनधिकृत संसाधनों तक पहुंचने से रोकने के लिए रक्षा-में-गहराई की एक महत्वपूर्ण परत जोड़ता है।
एक कंटेनर को रूट के रूप में चले बिना एक विशिष्ट विशेषाधिकार प्राप्त ऑपरेशन (जैसे, पोर्ट 80 से बाइंडिंग) की आवश्यकता है।
`securityContext.capabilities` में, `drop: ["ALL"]` करें और फिर `add: ["NET_BIND_SERVICE"]` करें।
क्यों: यह केवल आवश्यक विशिष्ट Linux क्षमता प्रदान करके न्यूनतम विशेषाधिकार के सिद्धांत का पालन करता है, रूट के रूप में चलने की व्यापक अनुमतियों से बचता है।
एक कंटेनर को होस्ट सिस्टम तक पूर्ण पहुंच प्राप्त करने से रोकें।
`securityContext.privileged: false` सेट करें (जो डिफ़ॉल्ट है)। इसे क्लस्टर-व्यापी लागू करने के लिए Pod Security Standards या OPA/Kyverno का उपयोग करें।
क्यों: एक विशेषाधिकार प्राप्त कंटेनर में लगभग सभी होस्ट क्षमताएं और डिवाइस एक्सेस होते हैं, जो प्रभावी रूप से कंटेनर अलगाव को अक्षम करते हैं। यह कंटेनर पलायन के लिए एक प्राथमिक वेक्टर है।
नेमस्पेस स्तर पर पॉड्स के लिए आधारभूत या सख्त सुरक्षा कॉन्फ़िगरेशन लागू करें।
नेमस्पेस में लेबल लागू करें, उदा., `pod-security.kubernetes.io/enforce: restricted`। मोड `enforce`, `audit`, और `warn` हैं।
क्यों: Pod Security Standards (PSS) एक अंतर्निहित, बहु-स्तरीय सुरक्षा नीति प्रदान करते हैं जो अप्रचलित PodSecurityPolicy को प्रतिस्थापित करती है, जिससे सुरक्षा सर्वोत्तम प्रथाओं को लागू करना आसान हो जाता है।
एक पॉड को एक साथ कई सुरक्षा नियंत्रण लागू करके मजबूत करें।
एक `securityContext` कॉन्फ़िगर करें जो `runAsNonRoot: true`, `allowPrivilegeEscalation: false`, और `readOnlyRootFilesystem: true` को जोड़ता है।
क्यों: यह रक्षा-में-गहराई दृष्टिकोण कई सुरक्षा परतों को जोड़ता है: रूट निष्पादन को रोकना, विशेषाधिकार वृद्धि वैक्टर (जैसे setuid) को ब्लॉक करना, और कंटेनर फ़ाइलसिस्टम को अपरिवर्तनीय बनाना।
मानक कंटेनरों की तुलना में मजबूत अलगाव के साथ अविश्वसनीय या बहु-किरायेदार वर्कलोड चलाएं।
एक सैंडबॉक्स्ड रनटाइम हैंडलर (जैसे, gVisor, Kata Containers) की ओर इशारा करते हुए एक `RuntimeClass` रिसोर्स को परिभाषित करें। `spec.runtimeClassName` का उपयोग करके पॉड्स को इसे असाइन करें।
क्यों: सैंडबॉक्स्ड रनटाइम syscalls को इंटरसेप्ट करने के लिए एक उपयोगकर्ता-स्थान कर्नेल या हल्के VMs का उपयोग करते हैं, जो कंटेनर और होस्ट कर्नेल के बीच अलगाव की एक अतिरिक्त परत प्रदान करते हैं।
जटिल, कस्टम सुरक्षा नीतियों को लागू करें जो मानक Kubernetes नियंत्रणों द्वारा कवर नहीं की जाती हैं।
OPA Gatekeeper को डिप्लॉय करें। `ConstraintTemplate` (Rego लॉजिक) का उपयोग करके नीतियों को परिभाषित करें और उन्हें `Constraint` रिसोर्स के साथ लागू करें।
क्यों: Gatekeeper एक वैलिडेटिंग एडमिशन वेबहुक के रूप में कार्य करता है, जिससे आप मनमानी नीतियों को लागू कर सकते हैं, जैसे विशिष्ट लेबल की आवश्यकता, होस्ट पथों को अस्वीकार करना, या संसाधन सीमाओं को लागू करना।
पॉड्स को सबसे सुरक्षित तरीके से सीक्रेट प्रदान करें।
सीक्रेट्स को एक वॉल्यूम में फ़ाइलों के रूप में माउंट करें। और भी अधिक सुरक्षा के लिए, बाहरी वॉल्ट (जैसे, HashiCorp Vault, AWS Secrets Manager) से सीधे पॉड में सीक्रेट्स को माउंट करने के लिए एक secrets-store CSI ड्राइवर का उपयोग करें।
क्यों: फ़ाइलों के रूप में माउंट करना पर्यावरण चर (जो लॉग किया जा सकता है या उजागर हो सकता है) की तुलना में अधिक सुरक्षित है। एक CSI ड्राइवर etcd में सीक्रेट को स्टोर करने से पूरी तरह बचाता है।
सभी पॉड-टू-पॉड नेटवर्क ट्रैफ़िक को स्वचालित रूप से एन्क्रिप्ट और प्रमाणित करें।
Istio या Linkerd जैसे सर्विस मेश को डिप्लॉय करें। मेश प्रत्येक पॉड में एक साइडकार प्रॉक्सी इंजेक्ट करता है ताकि mTLS एन्क्रिप्शन, प्रमाणीकरण और नीति प्रवर्तन को संभाला जा सके।
क्यों: एक सर्विस मेश बिना किसी एप्लिकेशन कोड परिवर्तन की आवश्यकता के पारदर्शी, ज़ीरो-ट्रस्ट नेटवर्किंग प्रदान करता है, जिससे सभी आंतरिक सेवा संचार सुरक्षित होते हैं।
ज्ञात कमजोरियों (CVEs) वाले कंटेनर छवियों के डिप्लॉयमेंट को रोकें।
CI/CD पाइपलाइन में Trivy या Grype जैसे स्कैनर को एकीकृत करें। यदि कमजोरियां एक परिभाषित गंभीरता थ्रेशोल्ड (जैसे, HIGH या CRITICAL) से अधिक हो जाती हैं तो बिल्ड को विफल करें।
क्यों: यह "शिफ्ट-लेफ्ट" दृष्टिकोण उत्पादन तक पहुंचने से पहले कमजोरियों को जल्दी पकड़ता है, जिससे चल रहे अनुप्रयोगों के हमले के सतह को नाटकीय रूप से कम किया जा सकता है।
यह सुनिश्चित करें कि केवल विश्वसनीय, अपरिवर्तित कंटेनर छवियों को क्लस्टर में डिप्लॉय किया जाए।
CI बिल्ड प्रक्रिया के दौरान `cosign` के साथ छवियों पर हस्ताक्षर करें। पॉड बनाने की अनुमति देने से पहले एक सार्वजनिक कुंजी के विरुद्ध हस्ताक्षर को सत्यापित करने के लिए एक एडमिशन कंट्रोलर के रूप में एक पॉलिसी इंजन (Kyverno, OPA Gatekeeper) का उपयोग करें।
क्यों: क्रिप्टोग्राफिक हस्ताक्षर छवि की अखंडता (इसमें छेड़छाड़ नहीं की गई है) और प्रामाणिकता (यह एक विश्वसनीय स्रोत से आया है) की मजबूत गारंटी प्रदान करता है।
एक कंटेनर छवि के भीतर हमले के सतह को कम करें।
न्यूनतम बेस छवियों (जैसे, distroless, Alpine) का उपयोग करें। बिल्ड टूल को हटाने के लिए एक मल्टी-स्टेज Dockerfile का उपयोग करें। `USER` निर्देश के साथ एक गैर-रूट उपयोगकर्ता सेट करें। संवेदनशील फ़ाइलों को बाहर करने के लिए `.dockerignore` का उपयोग करें।
क्यों: एक न्यूनतम छवि में कम पैकेज और उपकरण होते हैं, जो कम संभावित कमजोरियां प्रदान करते हैं और हमलावर के लिए कंटेनर के समझौता होने पर धुरी बनाना कठिन बनाते हैं।
एक नीति लागू करें कि सभी डिप्लॉय की गई छवियां संगठन के निजी रजिस्ट्री से उत्पन्न होनी चाहिए।
एक एडमिशन कंट्रोलर (जैसे OPA Gatekeeper या Kyverno) का उपयोग करके एक नीति बनाएं जो रजिस्ट्री होस्टनेम की अनुमति-सूची के विरुद्ध सभी कंटेनर स्पेसिफिकेशन के `image` फ़ील्ड को मान्य करती है।
क्यों: यह डेवलपर्स को Docker Hub जैसे सार्वजनिक रिपॉजिटरी से अविश्वसनीय या अन-स्कैन की गई छवियों को खींचने से रोकता है, यह सुनिश्चित करता है कि सभी कोड आंतरिक सुरक्षा जांच से गुजरे हैं।
एक कंटेनर छवि के भीतर सभी सॉफ्टवेयर घटकों और निर्भरताओं की एक सूची बनाए रखें।
SPDX या CycloneDX जैसे मानक प्रारूप में एक सॉफ्टवेयर बिल ऑफ मटेरियल्स (SBOM) उत्पन्न करने के लिए CI/CD पाइपलाइन में `Syft` जैसे उपकरण को एकीकृत करें।
क्यों: SBOM आपूर्ति श्रृंखला सुरक्षा के लिए आवश्यक है, जब किसी निर्भरता में एक नई भेद्यता का पता चलता है तो सभी प्रभावित संपत्तियों की त्वरित पहचान को सक्षम करता है।
Kubernetes YAML मैनिफेस्ट में सुरक्षा गलत कॉन्फ़िगरेशन की पहचान करें, इससे पहले कि उन्हें लागू किया जाए।
CI पाइपलाइन में, `trivy config` या `kubesec` जैसे उपकरण का उपयोग करें ताकि Kubernetes मैनिफेस्ट फ़ाइलों को जोखिम भरी कॉन्फ़िगरेशन के लिए स्कैन किया जा सके, जैसे रूट के रूप में चलना, विशेषाधिकार वृद्धि की अनुमति देना, या संवेदनशील होस्ट पथों को माउंट करना।
क्यों: यह सक्रिय जांच इंफ्रास्ट्रक्चर-एज़-कोड में सुरक्षा मुद्दों को पकड़ती है, इससे पहले कि वे चल रहे क्लस्टर में कमजोरियां पैदा करें।
चल रहे कंटेनरों या क्लस्टर नोड्स पर संदिग्ध गतिविधि का पता लगाएं और अलर्ट करें।
Falco को DaemonSet के रूप में डिप्लॉय करें। Falco eBPF या एक कर्नेल मॉड्यूल का उपयोग करके सिस्टम कॉल की निगरानी करता है और अपने नियम सेट (जैसे, कंटेनर में शेल, अप्रत्याशित नेटवर्क कनेक्शन) के आधार पर विषम व्यवहार पर अलर्ट करता है।
क्यों: Falco रनटाइम व्यवहार में वास्तविक समय की दृश्यता प्रदान करता है, जिससे कंटेनर पलायन, क्रिप्टोमिंग, या डेटा एक्सफ़िल्ट्रेशन जैसे खतरों का पता लगाने में मदद मिलती है जिन्हें स्थिर स्कैनिंग नहीं देख सकती है।
एक डिफ़ॉल्ट Falco नियम बहुत अधिक गलत पॉजिटिव उत्पन्न कर रहा है।
डिफ़ॉल्ट नियम को ओवरराइड करने के लिए एक कस्टम Falco नियम फ़ाइल बनाएं। नियम की `condition` में अपवाद जोड़ें ताकि ज्ञात-अच्छे व्यवहार को बाहर किया जा सके, जैसे विशिष्ट प्रक्रियाएं या कंटेनर छवियां (उदा., `and not container.image.repository contains "debug"`)।
क्यों: नियमों को ट्यून करना परिचालन रनटाइम सुरक्षा के लिए महत्वपूर्ण है। शोर को कम करने से यह सुनिश्चित होता है कि सुरक्षा टीमें कार्रवाई योग्य, उच्च-प्राथमिकता वाले अलर्ट पर ध्यान केंद्रित कर सकें।
Kubernetes API के विरुद्ध की गई सभी कार्रवाइयों का एक कालानुक्रमिक, अपरिवर्तनीय लॉग रिकॉर्ड करें।
`--audit-policy-file` और `--audit-log-path` फ़्लैग प्रदान करके `kube-apiserver` पर ऑडिट लॉगिंग सक्षम करें। नीति को कॉन्फ़िगर करें ताकि परिभाषित किया जा सके कि क्या लॉग किया जाए और किस स्तर पर।
क्यों: ऑडिट लॉग सुरक्षा विश्लेषण, घटना जांच और अनुपालन के लिए आवश्यक हैं। वे किसने क्या किया, और कब किया, इसका एक निश्चित रिकॉर्ड प्रदान करते हैं।
सीक्रेट सामग्री को लॉग किए बिना सीक्रेट्स जैसे संवेदनशील संसाधनों तक पहुंच का ऑडिट करें।
सीक्रेट्स के लिए ऑडिट नीति नियम को `level: Metadata` का उपयोग करने के लिए कॉन्फ़िगर करें। यह उपयोगकर्ता, टाइमस्टैम्प, संसाधन और क्रिया को लॉग करता है, लेकिन अनुरोध और प्रतिक्रिया निकायों को छोड़ देता है।
क्यों: यह ऑडिट लॉग में संवेदनशील डेटा लिखकर एक नया सुरक्षा जोखिम पैदा किए बिना सीक्रेट्स तक कौन पहुंच रहा है, इसके लिए जवाबदेही प्रदान करता है।
केंद्रीकृत विश्लेषण के लिए सभी क्लस्टर घटकों और अनुप्रयोगों से लॉग एकत्र करें।
नोड्स से लॉग एकत्र करने और उन्हें एक केंद्रीकृत SIEM या लॉग प्रबंधन प्रणाली (जैसे, Elasticsearch, Splunk) पर फॉरवर्ड करने के लिए एक लॉग संग्रह एजेंट (जैसे, Fluentd, Vector) को DaemonSet के रूप में डिप्लॉय करें।
क्यों: घटना जांच के दौरान क्लस्टर में घटनाओं को सहसंबंधित करने और अनुपालन के लिए दीर्घकालिक रिकॉर्ड बनाए रखने के लिए केंद्रीकृत लॉगिंग महत्वपूर्ण है।
Falco सुरक्षा अलर्ट को अधिसूचना और प्रतिक्रिया के लिए एक बाहरी सिस्टम पर फॉरवर्ड करें।
Falco के साथ `Falcosidekick` को डिप्लॉय करें। इसे Falco से अलर्ट प्राप्त करने और उन्हें Slack, PagerDuty, या एक SIEM जैसे आउटपुट पर फॉरवर्ड करने के लिए कॉन्फ़िगर करें।
क्यों: Falcosidekick Falco के वास्तविक समय के अलर्ट को मौजूदा परिचालन और सुरक्षा वर्कफ़्लो में एकीकृत करने के लिए एक लचीला और मजबूत तंत्र प्रदान करता है।
जांच करें कि क्या एक चल रहे कंटेनर को संशोधित किया गया है, जो एक समझौते का संकेत दे सकता है।
`readOnlyRootFilesystem: true` के साथ अपरिवर्तनीय कंटेनरों को लागू करें। Falco जैसे रनटाइम सुरक्षा उपकरण का उपयोग करें ताकि अप्रत्याशित स्थानों पर किसी भी फ़ाइल लेखन की निगरानी और अलर्ट किया जा सके।
क्यों: एक अपरिवर्तनीय मॉडल में, कंटेनरों को रनटाइम पर कभी नहीं बदला जाता है; उन्हें बदल दिया जाता है। इस पैटर्न से कोई भी विचलन संभावित सुरक्षा उल्लंघन का एक मजबूत संकेतक है।