अंतिम समीक्षा: मई 2026
KCSA परीक्षा द्वारा परखे जाने वाले architectural patterns का स्कैन-योग्य संदर्भ। ऊपर से नीचे पढ़ें या किसी section पर जाएं।
एक समग्र क्लाउड नेटिव सुरक्षा रणनीति का आर्किटेक्टिंग करना।
4Cs: क्लाउड (नींव), क्लस्टर, कंटेनर और कोड में सुरक्षा नियंत्रण लागू करें।
क्यों: बाहरी परत (जैसे, क्लाउड) पर एक समझौता सभी आंतरिक परतों की सुरक्षा को कमजोर करता है। सुरक्षा उतनी ही मजबूत होती है जितनी उसकी सबसे कमजोर कड़ी।
सिंगल-पॉइंट सुरक्षा विफलताओं से बचाव करना।
विभिन्न परतों पर कई, अतिव्यापी सुरक्षा नियंत्रण लागू करें (जैसे, NetworkPolicies, RBAC, Security Contexts)।
क्यों: यदि एक नियंत्रण विफल हो जाता है या उसे बायपास कर दिया जाता है, तो अन्य परतें सुरक्षा प्रदान करना जारी रखती हैं, जिससे हमलावर के लिए कठिनाई बढ़ जाती है।
ऐसे वातावरण में नेटवर्क ट्रैफिक को सुरक्षित करना जहां नेटवर्क स्थान एक विश्वसनीय सीमा नहीं है।
"कभी विश्वास न करें, हमेशा सत्यापित करें" मॉडल लागू करें। प्रत्येक अनुरोध को प्रमाणित और अधिकृत करें, आमतौर पर mTLS के लिए एक service mesh का उपयोग करके।
क्यों: यह मानता है कि खतरे नेटवर्क के अंदर और बाहर दोनों जगह मौजूद हो सकते हैं, नेटवर्क स्थिति के आधार पर निहित विश्वास को समाप्त करते हुए।
एक समझौता किए गए पहचान या घटक के ब्लास्ट रेडियस को सीमित करना।
सभी विषयों (उपयोगकर्ताओं, service accounts, nodes) को उनके कार्य करने के लिए आवश्यक न्यूनतम अनुमतियाँ ही दें।
क्यों: हमलावर द्वारा चुराए गए क्रेडेंशियल्स से होने वाले संभावित नुकसान को कम करता है।
सुरक्षा कमजोरियों की लागत और प्रभाव को कम करना।
स्वचालित सुरक्षा स्कैनिंग (SAST, SCA, image scanning) और नीति जांच को CI/CD पाइपलाइन के शुरुआती चरणों में एकीकृत करें।
क्यों: विकास जीवनचक्र में कमजोरियों को पहले ढूंढता और ठीक करता है, जब उन्हें ठीक करना सबसे सस्ता होता है।
संवेदनशील क्लस्टर डेटा (विशेषकर Secrets) को सुरक्षित करना यदि etcd स्टोरेज से समझौता किया जाता है।
kube-apiserver पर, संसाधनों को etcd में संग्रहीत करने से पहले उनके लिए encryption at rest सक्षम करने के लिए `--encryption-provider-config` का उपयोग करें।
क्यों: डिफ़ॉल्ट रूप से, Kubernetes Secrets etcd में केवल base64 एन्कोडेड होते हैं। यह डिस्क पर वास्तविक एन्क्रिप्शन प्रदान करता है।
etcd संचार पर अनधिकृत पहुंच और छिपकर बातें सुनने से रोकना।
क्लाइंट (`--client-cert-auth`) और पीयर (`--peer-client-cert-auth`) दोनों संचार के लिए mTLS के साथ etcd को कॉन्फ़िगर करें।
क्यों: सुनिश्चित करता है कि केवल प्रमाणित घटक (apiserver, अन्य etcd सदस्य) etcd के साथ संचार कर सकें और ट्रैफिक एन्क्रिप्टेड हो।
Kubernetes API server पर अनाधिकृत पहुंच को रोकना।
`--anonymous-auth=false` फ़्लैग सेट करें। OIDC या x509 certificates जैसी मजबूत प्रमाणीकरण विधियों का उपयोग करें।
क्यों: `system:anonymous` उपयोगकर्ता को अक्षम करता है, जिससे सभी अनुरोधों को प्रमाणित किया जाता है और एक विशिष्ट पहचान के विरुद्ध लॉग किया जाता है।
सुरक्षा और अनुपालन के लिए सभी परिवर्तनों और पहुंच प्रयासों को ट्रैक करने की आवश्यकता।
`--audit-policy-file` के साथ API server audit logging सक्षम करें और लॉग को एक बाहरी, अपरिवर्तनीय लॉगिंग सिस्टम पर भेजें।
क्यों: घटना की जांच, खतरे का पता लगाने और अनुपालन ऑडिट के लिए एक आवश्यक, छेड़छाड़-प्रूफ ट्रेल प्रदान करता है।
वर्कर नोड्स के अटैक सरफेस को कम करना।
kubelet फ़्लैग सेट करें: `--anonymous-auth=false`, `--authorization-mode=Webhook`, और `--read-only-port=0`।
क्यों: यह सुनिश्चित करता है कि kubelet API के सभी अनुरोध API server द्वारा प्रमाणित और अधिकृत हों और असुरक्षित, अनाधिकृत रीड-ओनली पोर्ट को अक्षम करता है।
कंट्रोल प्लेन घटकों से सूचना रिसाव को रोकना।
प्रोडक्शन में kube-apiserver, kube-controller-manager और kube-scheduler पर `--profiling=false` फ़्लैग सेट करें।
क्यों: प्रोफाइलिंग एंडपॉइंट्स आंतरिक प्रदर्शन डेटा और सिस्टम विवरण को उजागर कर सकते हैं जो हमलावर को टोही में मदद कर सकते हैं।
कंट्रोल प्लेन घटकों को अनाधिकृत नेटवर्क पहुंच से बचाना।
API server (6443) और etcd (2379) पोर्ट तक पहुंच को केवल विश्वसनीय स्रोतों तक सीमित करने के लिए फ़ायरवॉल नियमों (cloud security groups, iptables) का उपयोग करें।
क्यों: नेटवर्क-स्तरीय अभिगम नियंत्रण रक्षा की एक मूलभूत परत है, जो हमलावरों को संवेदनशील घटक API तक पहुंचने से भी रोकती है।
उपयोगकर्ताओं या अनुप्रयोगों को अनुमतियाँ प्रदान करना।
`ClusterRoles` के ऊपर namespaced `Roles` का उपयोग करें। वाइल्डकार्ड (`*`) के बजाय विशिष्ट verbs (`get`, `list`) प्रदान करें।
क्यों: least privilege के सिद्धांत का पालन करता है, अनुमतियों के दायरे को एक विशिष्ट namespace के भीतर केवल आवश्यक तक सीमित करता है।
एक pod को Kubernetes API के साथ संचार करने की आवश्यकता नहीं है।
pod spec या ServiceAccount पर `automountServiceAccountToken: false` सेट करें।
क्यों: pod के अंदर अनावश्यक क्रेडेंशियल्स को उजागर होने से रोकता है, यदि pod से समझौता किया जाता है तो अटैक सरफेस को कम करता है।
एक namespace में सभी pods के लिए एक baseline सुरक्षा स्थिति लागू करना।
`pod-security.kubernetes.io/enforce: baseline` जैसे namespace लेबल लागू करके बिल्ट-इन `PodSecurity` admission controller का उपयोग करें।
क्यों: थर्ड-पार्टी टूल के बिना जोखिम भरी pod कॉन्फ़िगरेशन (जैसे privileged containers) को रोकने का एक मानकीकृत, बिल्ट-इन तरीका प्रदान करता है।
विशेषाधिकार वृद्धि को रोकने के लिए व्यक्तिगत कंटेनर सुरक्षा को मजबूत करना।
pod spec में, `securityContext` फ़ील्ड सेट करें: `runAsNonRoot: true`, `allowPrivilegeEscalation: false`, `readOnlyRootFilesystem: true`।
क्यों: ये नियंत्रण रूट के रूप में चलने से रोकते हैं, नए विशेषाधिकार प्राप्त करने के तंत्र को ब्लॉक करते हैं, और कंटेनर फाइलसिस्टम को अपरिवर्तनीय बनाते हैं, जिससे समझौता होने की स्थिति में प्रभाव में भारी कमी आती है।
क्लस्टर के भीतर एक zero-trust नेटवर्क मॉडल लागू करना।
प्रत्येक namespace पर एक default-deny NetworkPolicy लागू करें जो सभी pods (`podSelector: {}`) का चयन करती है और जिसमें एक खाली ingress/egress नियम सूची होती है।
क्यों: Kubernetes नेटवर्किंग default-allow है। यह नीति मॉडल को default-deny में उलट देती है, जिससे डेवलपर्स को आवश्यक ट्रैफिक को स्पष्ट रूप से अनुमति देने के लिए मजबूर होना पड़ता है।
केवल विशिष्ट एप्लिकेशन टियर (जैसे, web-to-api) के बीच ट्रैफिक की अनुमति देना।
`podSelector` और `namespaceSelector` का उपयोग करके NetworkPolicies बनाएं जो लेबल के आधार पर दानेदार ingress और egress नियमों को परिभाषित करती हैं।
क्यों: हमलावरों द्वारा lateral movement को रोकता है, यह सुनिश्चित करके कि एक समझौता किया गया pod केवल स्पष्ट रूप से अधिकृत साथियों के साथ संचार कर सकता है।
एक उपयोगकर्ता को डिबगिंग के लिए कंटेनरों में `kubectl exec` करने की अनुमति चाहिए।
प्रासंगिक Role या ClusterRole में `pods/exec` subresource पर `create` verb प्रदान करें।
क्यों: `exec` क्रिया को `create` verb द्वारा अप्रत्याशित रूप से नियंत्रित किया जाता है क्योंकि यह एक नया exec सत्र बनाता है। यह भ्रम का एक सामान्य बिंदु है।
एक हमलावर एक कंटेनर तक पहुंच प्राप्त करता है और host node से समझौता करने का प्रयास करता है।
privileged containers (`securityContext.privileged: false`), host namespaces (`hostNetwork`, `hostPID`), और Docker socket को माउंट करने पर प्रतिबंध लगाएं।
क्यों: ये कॉन्फ़िगरेशन प्रभावी रूप से कंटेनर अलगाव को तोड़ते हैं, जिससे समझौता किए गए कंटेनर को host तक रूट-स्तरीय पहुंच मिलती है।
ज्ञात कमजोरियों या दुर्भावनापूर्ण कोड वाले कंटेनर इमेज की तैनाती को रोकना।
CI/CD पाइपलाइन में और admission control के माध्यम से image scanning (जैसे, Trivy) और image signature verification (जैसे, Cosign) को लागू करें।
क्यों: एक defense-in-depth दृष्टिकोण प्रदान करता है: स्कैनिंग ज्ञात कमजोरियों को पकड़ता है, जबकि हस्ताक्षर इमेज की अखंडता और provenance को सत्यापित करता है।
एक हमलावर ने एक pod से समझौता कर लिया है और क्लस्टर में अन्य pods तक पहुंचने का प्रयास कर रहा है।
default-deny NetworkPolicies लागू करें और आवश्यक pod-to-pod संचार के लिए ही विशिष्ट allow rules बनाएं।
क्यों: एक समझौता किए गए pod से हमलावर की "दृष्टि की रेखा" को प्रतिबंधित करता है, उल्लंघन को नियंत्रित करता है और इसे फैलने से रोकता है।
एक समझौता किए गए pod को instance metadata service से cloud IAM क्रेडेंशियल्स चुराने से रोकना।
एक default-deny egress NetworkPolicy लागू करें जो metadata IP (जैसे, `169.254.169.254/32`) पर ट्रैफिक को स्पष्ट रूप से ब्लॉक करती है।
क्यों: यह क्लाउड वातावरण में एक सामान्य अटैक पाथ है। इस egress पाथ को ब्लॉक करना pods से IAM क्रेडेंशियल चोरी के जोखिम को कम करता है।
denial-of-service या cryptojacking हमलों से बचाव करना जो नोड संसाधनों को समाप्त कर देते हैं।
namespaces पर `ResourceQuota` ऑब्जेक्ट लागू करें ताकि कुल संसाधन उपयोग को सीमित किया जा सके और व्यक्तिगत pods पर सीमाओं को लागू करने के लिए `LimitRange` ऑब्जेक्ट का उपयोग करें।
क्यों: यह सुनिश्चित करता है कि कोई भी एकल tenant या workload दूसरों को संसाधनों से वंचित न कर सके, स्थिरता प्रदान करता है और दुरुपयोग को रोकता है।
एक हमलावर समझौता किए गए क्लस्टर तक दीर्घकालिक पहुंच बनाए रखने का प्रयास करता है।
अप्रत्याशित `DaemonSets`, `CronJobs`, या privileged pods के निर्माण की निगरानी करें। इन संसाधनों को बनाने की अनुमतियों को प्रतिबंधित करें।
क्यों: हमलावर इन workload प्रकारों का उपयोग यह सुनिश्चित करने के लिए करते हैं कि उनका दुर्भावनापूर्ण कोड लगातार चलता रहे, भले ही एक node या pod को पुनरारंभ किया जाए।
यह सुनिश्चित करना कि कंटेनर इमेज परिनियोजन से पहले ज्ञात कमजोरियों से मुक्त हों।
Trivy, Clair, या Grype जैसे image scanner को CI/CD पाइपलाइन में एकीकृत करें ताकि इमेज को स्कैन किया जा सके और यदि गंभीर कमजोरियां पाई जाती हैं तो बिल्ड को विफल किया जा सके।
क्यों: कमजोरियों का जल्दी पता लगाना ("shift left") स्वचालित करता है, कमजोर कोड को प्रोडक्शन तक पहुंचने से रोकता है।
यह सुनिश्चित करना कि क्लस्टर में केवल विश्वसनीय, अपरिवर्तित कंटेनर इमेज तैनात की जाएं।
CI पाइपलाइन में Cosign जैसे टूल से इमेज पर हस्ताक्षर करें। परिनियोजन के समय हस्ताक्षर को सत्यापित करने के लिए एक validating admission controller (जैसे, Kyverno, Gatekeeper) का उपयोग करें।
क्यों: इमेज की अखंडता (इसके साथ छेड़छाड़ नहीं की गई है) और provenance (यह एक विश्वसनीय स्रोत से आया है) का क्रिप्टोग्राफिक प्रमाण प्रदान करता है।
चल रहे कंटेनर के अंदर दुर्भावनापूर्ण गतिविधि का पता लगाना (जैसे, shell spawned, संवेदनशील फ़ाइल पहुंच)।
Falco जैसे runtime सुरक्षा टूल को तैनात करें, जो syscalls की निगरानी के लिए eBPF का उपयोग करता है और एक परिभाषित नियमसेट के आधार पर संदिग्ध व्यवहार पर अलर्ट करता है।
क्यों: runtime गतिविधि में दृश्यता प्रदान करता है, जिसे static scanning और admission control नहीं देख सकते हैं। यह सक्रिय उल्लंघनों का पता लगाने के लिए महत्वपूर्ण है।
कस्टम, संगठन-विशिष्ट सुरक्षा नीतियों को लागू करना (उदाहरण के लिए, "सभी इमेज हमारी कॉर्पोरेट रजिस्ट्री से आनी चाहिए")।
Rego या YAML में लिखी गई नीतियों को लागू करने के लिए OPA Gatekeeper या Kyverno जैसे policy engine का उपयोग validating admission controller के रूप में करें।
क्यों: सुरक्षा नीतियों के लचीले, घोषणात्मक और स्वचालित प्रवर्तन की अनुमति देता है जो Kubernetes के बिल्ट-इन नियंत्रणों से परे जाते हैं।
क्लस्टर के भीतर सभी service-to-service ट्रैफिक को एन्क्रिप्ट करना और प्रमाणित करना।
सभी meshed services के लिए स्वचालित रूप से mutual TLS (mTLS) प्रदान करने के लिए एक service mesh (जैसे, Istio, Linkerd) लागू करें।
क्यों: यह सुनिश्चित करके zero-trust नेटवर्किंग प्राप्त करता है कि सभी इन-क्लस्टर ट्रैफिक एन्क्रिप्टेड है और सेवाएं एक-दूसरे की पहचान को पारस्परिक रूप से सत्यापित करती हैं।
अविश्वसनीय या मल्टी-टेनेट वर्कलोड चलाना जिन्हें मानक कंटेनरों की तुलना में अधिक मजबूत अलगाव की आवश्यकता होती है।
gVisor या Kata Containers जैसे sandboxed container runtime का उपयोग करें, जो कंटेनर और host kernel के बीच एक अतिरिक्त अलगाव परत प्रदान करते हैं।
क्यों: host kernel के अटैक सरफेस को कम करता है, जिससे कंटेनर एस्केप काफी अधिक कठिन हो जाता है।
kernel स्तर पर एक कंटेनर की अनुमतियों पर बारीक नियंत्रण।
अनुमत syscalls को फ़िल्टर करने के लिए Seccomp profiles का उपयोग करें और फ़ाइल और नेटवर्क पहुंच पर mandatory access controls (MAC) को लागू करने के लिए AppArmor/SELinux profiles का उपयोग करें।
क्यों: ये Linux-native सुरक्षा सुविधाएँ रक्षा की एक गहरी परत प्रदान करती हैं, यह प्रतिबंधित करती हैं कि एक समझौता किया गया कंटेनर प्रक्रिया मौलिक रूप से क्या कर सकती है।
एक कंटेनर इमेज के भीतर अटैक सरफेस को कम करना।
केवल एप्लिकेशन और उसकी प्रत्यक्ष निर्भरता वाले न्यूनतम या "distroless" base images का उपयोग करके एप्लिकेशन इमेज बनाएं।
क्यों: शेल्स, पैकेज मैनेजर और अन्य उपयोगिताओं को हटाता है जो उत्पादन के लिए अनावश्यक हैं और समझौता होने के बाद एक हमलावर द्वारा उपयोग किए जा सकते हैं।
यह सत्यापित करना कि एक Kubernetes क्लस्टर सुरक्षा सर्वोत्तम प्रथाओं के अनुसार कॉन्फ़िगर किया गया है।
नियमित रूप से `kube-bench` चलाएं, एक स्वचालित टूल जो CIS Kubernetes Benchmark के खिलाफ क्लस्टर की जांच करता है।
क्यों: क्लस्टर सुरक्षा स्थिति का ऑडिट करने और गलत कॉन्फ़िगरेशन की पहचान करने का एक मानकीकृत, व्यापक और स्वचालित तरीका प्रदान करता है।
एक क्लस्टर को PCI DSS के अनुपालन में क्रेडिट कार्ड डेटा को संसाधित और संग्रहीत करना होगा।
Cardholder Data Environment (CDE) को अलग करने के लिए नेटवर्क सेगमेंटेशन के लिए NetworkPolicies का उपयोग करें, और etcd के लिए encryption at rest सक्षम करें।
क्यों: ये नियंत्रण सीधे नेटवर्क सेगमेंटेशन (आवश्यकता 1) और संग्रहीत कार्डधारक डेटा (आवश्यकता 3) की सुरक्षा के लिए PCI DSS आवश्यकताओं से मैप करते हैं।
एक क्लस्टर Protected Health Information (PHI) को संभालता है और उसे HIPAA का अनुपालन करना होगा।
कठोर RBAC लागू करें, व्यापक audit logging सक्षम करें, और सुनिश्चित करें कि डेटा at rest और in transit दोनों जगह एन्क्रिप्टेड है।
क्यों: ये नियंत्रण एक्सेस कंट्रोल, ऑडिट कंट्रोल और ट्रांसमिशन सिक्योरिटी के लिए HIPAA के टेक्निकल सेफगार्ड्स को संबोधित करते हैं।
यह सुनिश्चित करना कि अनुपालन और फ़ॉरेंसिक के लिए ऑडिट लॉग संरक्षित रहें, भले ही क्लस्टर से समझौता किया गया हो।
API server को ऑडिट लॉग को एक बाहरी, write-once/immutable logging backend (जैसे, एक SIEM या एक लॉक-डाउन cloud storage bucket) पर स्ट्रीम करने के लिए कॉन्फ़िगर करें।
क्यों: cluster-admin विशेषाधिकारों वाले हमलावर को स्थानीय ऑडिट लॉग को संशोधित या हटाकर अपने निशान छिपाने से रोकता है।