SaaS में Container Runtime Security
चलते containers को least privilege, kernel controls और runtime alerts से harden करें। Evidence सुरक्षित रखने वाली response प्रक्रिया भी बनाएँ।
इस मार्गदर्शिका में
Container Runtime Security क्या है?
Container runtime security चल रहे workload को host या Kubernetes cluster पर सुरक्षित रखती है। इसमें privileges, kernel isolation, mounted files, network व्यवहार, runtime identity और असामान्य गतिविधि का पता लगाना शामिल है। यह deployment से पहले image scan से अलग है: भरोसेमंद image भी बहुत permission के साथ चल सकती है, और runtime monitoring unsafe build या vulnerable dependency ठीक नहीं करती। Prevention और detection साथ रखें।
Process को न्यूनतम व्यावहारिक privilege दें
Non-root user रखें, privilege escalation बंद करें, Linux capabilities हटाएँ और privileged container, host PID या network namespace, host path तथा device access से बचें जब तक लिखित जरूरत न हो। Kubernetes Pod Security Standards में non-root, सीमित capabilities और seccomp profile जैसे restricted controls हैं; अपने Kubernetes और node version के साथ compatibility जाँचें।
Kernel और filesystem की सीमा लागू करें
जहाँ समर्थन हो RuntimeDefault या reviewed local seccomp profile, AppArmor अथवा SELinux लागू करें। Application सह सके तो root filesystem read-only रखें। केवल जरूरी data paths mount करें और sensitive host files container से दूर रखें। Profile व्यापक करने से पहले application startup, update और recovery test करें।
Workload identity और network पहुँच सीमित करें
हर workload को अपनी service identity और जरूरी Kubernetes या cloud permissions ही दें। Ingress तथा egress को अपेक्षित services तक सीमित करें, उपलब्ध और लागू network policies इस्तेमाल करें, और compromised process को metadata endpoint या दूसरे tenant तक पहुँचने से रोकें। जाँचें कि cluster networking implementation घोषित policies लागू करती है।
| Workload और owner | User और privilege settings | Kernel तथा filesystem profile | Network और service identity | Test और exception expiry |
|---|---|---|---|---|
| Public API service | ||||
| Queue worker | ||||
| Support या migration job |
Container runtime threats कैसे पहचानें?
Service के लिए मायने रखने वाले कुछ behaviors चुनें
Production container में अनपेक्षित shell, sensitive host path पर write, privilege change, अप्रत्याशित package manager, संदिग्ध outbound connection या cloud credential endpoint की पहुँच जैसे events प्राथमिकता से देखें। Alert को संचालन का संदर्भ देने के लिए सामान्य startup और maintenance behavior पहले लिखें।
Alert को deployment और workload context के साथ जोड़ें
Cluster, namespace, pod या task, image digest, workload identity, node, event समय और deployment revision जोड़ें। High-confidence event को on-call responder तक पहुँचाएँ, पर notification में secrets या पूरा customer payload न डालें। Falco एक open-source runtime detection विकल्प है; अपनाने से पहले उसके privileges, event sources, coverage और संचालन लागत जाँचें।
Safe simulation से rules और telemetry जाँचें
Non-production environment में सामान्य application behavior और मंजूर test events चलाएँ। मापें कि signal आया या नहीं, उसमें उपयोगी context है या नहीं और वह सही owner तक पहुँचा या नहीं। Dropped events, agent health, rule changes और noisy alerts देखें। Runtime tool केवल उन्हीं events और hosts को देखेगा जिनकी निगरानी के लिए वह set up और authorized है।
Container runtime alert पर responder क्या करे?
Event की पुष्टि करें और जल्दी मिटने वाला evidence बचाएँ
Deployment revision, workload owner, service identity, event क्रम और संबंधित cloud या cluster audit record देखें। Pod या node गायब होने से पहले जरूरी logs और alert data सुरक्षित करें। संदेह वाले container के भीतर मनमाने commands चलाने से पहले सोचें कि उनसे evidence बदलेगा या access बढ़ेगा।
संबंधित workload और credentials को contain करें
Test की हुई प्रक्रिया से network रास्ते सीमित करें, प्रभावित workload अलग करें, compromised service identity रोकें और असुरक्षित deployment थामें। संभव हो तो traffic known-good replica पर भेजकर customer service जारी रखें। एक pod हटाना पूरी सफाई नहीं है यदि image, deployment credentials या node भी प्रभावित हों।
Verified deployment से rebuild करें और मूल कारण बंद करें
Trusted image तथा configuration से सेवा लौटाने से पहले build source, dependency state, admission policy और node health जाँचें। Process जिन credentials तक पहुँच सकती थी उन्हें rotate करें, पास के workloads भी जाँचें और timeline लिखें। कारण मिलने पर regression test या policy जोड़ें और फिर पुष्टि करें कि वैसा event रोका या alert किया जाता है।
Container runtime security के सवाल
क्या image scanning runtime protection देती है?
नहीं। Image scan package और configuration की ज्ञात समस्याएँ दिखा सकती है, लेकिन चल रहे process के privileges लागू नहीं करती, workload को isolate नहीं करती और हर runtime behavior नहीं पकड़ती। Build, admission, runtime और incident controls साथ चलाएँ।
क्या Kubernetes namespace अपने-आप tenants को अलग करता है?
नहीं। Namespace resources और policy scope व्यवस्थित करता है; लेकिन application authorization, storage, network, workload identity और cluster administration भी सुरक्षित होने चाहिए। पूरी tenant सीमा का test करें।
क्या हर container non-root चलना चाहिए?
Linux workload के लिए यह अच्छा baseline है, यदि application इसका समर्थन करे। ज्यादा privilege जरूरी हो तो कारण लिखें, केवल आवश्यक capability दें, workload अलग रखें और exception की समीक्षा करें। Kubernetes guidance user namespaces जैसे दूसरे isolation तरीके भी बताती है; उपलब्धता platform पर निर्भर है।
अगर runtime alert नहीं आया तो क्या container सुरक्षित है?
नहीं। शांत monitor में host coverage, rules या event source गायब हो सकते हैं। Sensor health जाँचें, अपेक्षित alerts test करें और least privilege, patching, image review तथा audit logging भी रखें।
संबंधित व्यावहारिक मार्गदर्शिकाएँ
संबंधित मुद्दों की मार्गदर्शिकाएँ
स्रोत और प्रकाशन रिकॉर्ड
27 सितंबर 2026 को तैयार मसौदा; engineering, security और संपादकीय समीक्षा बाकी है · स्रोत जाँचे गए .
- Pod Security Standards
- Configure a Security Context for a Pod or Container
- The Falco Project: Cloud Native Runtime Security
- NIST SP 800-190: Application Container Security Guide
- Kubernetes Security Checklist
- AWS IAM: Security Best Practices
- Security Best Practices in AWS CloudTrail
- Google SRE Workbook: incident response