SaaS workload के लिए Kubernetes security checklist
सीमित API access, least-privilege RBAC, pod security, network policies, protected secrets और जाँचे हुए audit controls से Kubernetes cluster मजबूत करें।
इस मार्गदर्शिका में
SaaS Kubernetes security checklist में क्या होना चाहिए?
Kubernetes security checklist में control plane, identities, workload permissions, network paths, secrets, images, runtime settings और audit records शामिल होने चाहिए। Kubernetes की अपनी checklist शुरुआती baseline है, पूरा security assessment नहीं; managed service और cluster version के अनुसार भी फर्क होता है। पहले cluster तथा workload owners पहचानें और फिर हर control को जाँचें कि वह आपकी SaaS service में वास्तव में कैसे काम करता है।
Kubernetes API तक पहुँच सीमित और monitored रखें
API server को केवल स्वीकृत operator और automation रास्तों से reachable रखें। मजबूत identity controls लागू करें और review करें कि कौन-से human तथा service identities cluster resources बदल सकते हैं। सामान्य काम में व्यापक cluster-admin access से बचें। Kubelet तथा etcd endpoints सुरक्षित रखें और managed provider के network defaults खुद जाँचें।
सीमित RBAC दें और admission पर pod security लागू करें
हर team और service account को काम के लिए जरूरी resource verbs तथा namespaces ही दें। Pods, deployments, role bindings और admission policies बनाने या बदलने के अधिकार खास तौर पर जाँचें, क्योंकि workload बनाना node संसाधनों तक पहुँच दे सकता है। उपयुक्त Pod Security Standard लागू करें और live namespace में सख्ती से पहले परीक्षण करें।
हर workload के लिए अलग identity इस्तेमाल करें
जो workload Kubernetes API नहीं बुलाता उसमें automatic service-account token mounting बंद करें। API की जरूरत हो तो dedicated service account और न्यूनतम permissions दें। जहाँ उपलब्ध हो, short-lived bound tokens और provider workload identity अपनाएँ; manifests में cloud keys न रखें।
| Cluster या namespace | Identity और permissions | Network paths | Pod और secret controls | Owner, evidence और exception |
|---|---|---|---|---|
| Production API | ||||
| Customer-data worker | ||||
| Build या deployment runner |
Kubernetes workload के attack paths कैसे घटाएँ?
Default network paths बंद रखकर जरूरी flow स्पष्ट जोड़ें
Kubernetes NetworkPolicy लागू करने वाला network plugin इस्तेमाल करें और workloads तथा namespaces के ingress व egress rules बनाएँ। DNS, identity और monitoring जैसी जरूरतें शामिल करें और दोनों दिशाओं में enforcement verify करें। Cloud metadata endpoint तक पहुँच रोकें, जब तक किसी workload को लिखित रूप में इसकी जरूरत न हो।
Containers को host और kernel पर कम privileges दें
Privileged container, host networking, host PID/IPC access, गैरजरूरी Linux capabilities और writable host paths से बचें। जहाँ समर्थित हो वहाँ non-root user, seccomp तथा AppArmor/SELinux controls रखें। Service के असल व्यवहार के आधार पर resource requests और limits तय करें और availability पर throttling या memory pressure का असर देखें।
Secrets सुरक्षित रखें और deployment पर images verify करें
Credentials को ConfigMaps या source-controlled manifests में न रखें। Kubernetes Secret data को cluster के समर्थित key controls से at-rest encrypt करें, पढ़ने की अनुमति सीमित रखें और गैरजरूरी containers में token या secret mount न करें। Production images को digest से pin या भरोसेमंद provenance से verify करें और release प्रक्रिया में scan तथा update करें।
Team cluster security कैसे चलाए और review करे?
अलग trust और sensitivity वाले workloads अलग रखें
जहाँ platform अनुमति दे, control-plane components और संवेदनशील workloads को उपयुक्त रूप से अलग nodes या runtimes पर रखें। Namespace access और policy व्यवस्थित करता है, पर अपने आप मजबूत tenant boundary नहीं है। Shared nodes, cross-namespace flow और provider की जिम्मेदारियाँ दर्ज करें।
जाँच के काम आने वाले audit records सुरक्षित रखें
जहाँ उपलब्ध हो provider का Kubernetes audit सुविधा चालू करें। ऐसे events रखें जिनसे पता चले किसने क्या और कब बदला, और log destination को लिखने या मिटाने का अधिकार सीमित रखें। Cluster events को deployment, identity और cloud records से जोड़ें; समय synchronized रखें और on-call team को relevant event खोजने का अभ्यास कराएँ।
Version, policy और architecture बदलाव के बाद controls फिर जाँचें
Upgrade से पहले deprecated APIs, admission behavior, network plugin की क्षमता और managed-service defaults review करें। Non-production cluster में policy change जाँचें और workload failure के लिए rollback रखें। Product service, team या data sensitivity बदलने पर service accounts तथा exceptions का फिर आकलन करें।
Kubernetes workload security FAQs
क्या official Kubernetes checklist compliance के लिए काफी है?
नहीं। Kubernetes project कहता है कि उसकी checklist exhaustive नहीं है और कुछ controls किसी environment के लिए बहुत सख्त या बहुत ढीले हो सकते हैं। इसे शुरुआती बिंदु मानें और service boundary, threat model, provider जिम्मेदारियों तथा लागू requirements से मिलाएँ।
क्या namespace एक SaaS customer को दूसरे से अलग करता है?
अकेले नहीं। Namespace Kubernetes resources और policy scope व्यवस्थित करता है, लेकिन workload identity, network rules, storage, cluster permissions और application authorization भी जरूरी हैं। असली tenant isolation design validate करें; namespace के नाम से सुरक्षा न मान लें।
क्या हर pod में Kubernetes service-account token होना चाहिए?
नहीं। जिस workload को Kubernetes API की जरूरत नहीं, उसका automatic token mounting बंद करें। जिसे जरूरत हो, उसके लिए dedicated service account और न्यूनतम permissions रखें तथा cluster version के अनुसार token lifetime और cloud identity integration review करें।
अगर CNI network policy लागू न करे तो क्या policy सुरक्षा दे सकती है?
नहीं। NetworkPolicy का enforcement ऐसे network plugin पर निर्भर है जो इसे support करता हो। Deployed CNI की क्षमताएँ confirm करें और सुरक्षित environment में allowed तथा blocked traffic दोनों test करें।
संबंधित व्यावहारिक मार्गदर्शिकाएँ
संबंधित मुद्दों की मार्गदर्शिकाएँ
स्रोत और प्रकाशन रिकॉर्ड
Draft prepared 27 September 2026; engineering, security and editorial review pending · स्रोत जाँचे गए .