SaaS teams के लिए container image security checklist
Trusted और updated base images, कम layers, सुरक्षित build secrets, non-root execution, scanning और deployment controls से SaaS containers बनाएँ और चलाएँ।
इस मार्गदर्शिका में
Container image security में क्या शामिल है?
Container image application और dependencies को container runtime के लिए package करती है। इसकी सुरक्षा base image, build process, stored layers, registry, runtime configuration और host isolation पर निर्भर है। छोटी image गैर-जरूरी components घटा सकती है, लेकिन केवल image scan से privileged container, उजागर secret या कमजोर host सुरक्षित नहीं होते। Image और service को चलाने का तरीका साथ में जाँचें।
Supported base image चुनें और digest updates सँभालें
Maintained और भरोसेमंद publisher की image लें और केवल जरूरी packages रखें। Reproducible identity के लिए production inputs को digest पर pin करें, लेकिन नई security fixes जाँचने वाली reviewed update प्रक्रिया भी रखें; पुराने digest को लगातार pin करने से ज्ञात vulnerability रह सकती है। चुनी image और update owner दर्ज करें।
Multi-stage builds इस्तेमाल करें और बेकार files बाहर रखें
Compilers, package managers, test fixtures और debugging tools को build stage में रखें यदि runtime में इनकी जरूरत नहीं। Build context और `.dockerignore` सोचकर तय करें ताकि local credentials, source-control data और असंबंधित files image layers में न जाएँ। छोटी runtime image की समीक्षा आसान होती है, लेकिन फिर भी उसे patch और test करना चाहिए।
Build credentials को image layers में जाने से रोकें
Password या token को Docker `ARG` या persistent `ENV` से न दें; value final image या उसके history में रह सकती है। जिस build step को access चाहिए उसी के लिए supported BuildKit secret या SSH mounts इस्तेमाल करें और बनी image तथा logs में credential की अनुपस्थिति verify करें।
| Image / digest | Base image और update owner | Build secrets / context | Runtime identity और limits | Scan / deployment प्रमाण |
|---|---|---|---|---|
SaaS team containers को सुरक्षित रूप से चलाने के लिए कैसे configure करे?
केवल जरूरी capabilities वाले non-root user से चलाएँ
Dedicated unprivileged runtime identity चुनें और service को जिन Linux capabilities की जरूरत नहीं, उन्हें हटाएँ। Application की सही write paths test करने के बाद read-only root filesystem, सीमित writable mounts, resource limits और उचित seccomp या platform isolation profiles पर विचार करें।
Platform layer पर tenants और संवेदनशील workloads अलग रखें
Container को आपस में untrusted workloads के बीच पूरा isolation boundary न मानें। Least-privilege service identities, network policies, namespace और runtime controls लागू करें; threat model के अनुसार high-risk jobs या customer-specific processing अलग रखें। Host container-engine socket को सामान्य application container में कभी mount न करें।
Images scan करें और release context के साथ findings पर काम करें
Build के समय और नया advisory आने पर base तथा application layers scan करें। Findings को exact image digest, deployed services और पहुँच योग्य components से जोड़ें; केवल scanner severity label की बजाय active exploitation और exposure देखें। Base या application patch करें, rebuild और retest करें तथा पुष्टि करें कि replacement image सचमुच deploy हुई।
Registry और container deployment कैसे सुरक्षित रखें?
Production images publish और pull करने की पहुँच सीमित करें
Registry accounts के लिए मजबूत authentication रखें, write access को release pipeline तक सीमित करें और production tags को आसानी से बदलने से बचाएँ। जहाँ उपलब्ध हो deployment में immutable digests लें और हर environment में चल रहे digest का record रखें। Development images को approved release images से अलग रखें।
Provenance verify करें और पहले से tested image promote करें
Artifact एक बार build करें, digest दर्ज करें और वही object test से production तक ले जाएँ। जहाँ उपलब्ध हो deployment से पहले signed provenance या attestations validate करें। Signature signing identity से संबंध दिखाती है, code हानिरहित होने का प्रमाण नहीं; builder और signing permissions भी review करें।
असुरक्षित image वापस लाए बिना rollback और rebuild की योजना रखें
पहले की known-good image और tested rollback रास्ता रखें, लेकिन दोबारा उपयोग से पहले उसकी vulnerability स्थिति जाँचें। Compromise या जरूरी package fix के बाद trusted inputs से build करें, पुराने container को मिले credentials rotate करें, digest से redeploy करें और पुष्टि करें कि पुराने tasks रुक गए।
Container image security के सवाल
क्या minimal image सुरक्षा की गारंटी देती है?
नहीं। इससे unused packages कम हो सकते हैं और review आसान हो सकती है, लेकिन application, base image, build chain, runtime privileges और host भी मायने रखते हैं। Image छोटी करने के बाद भी उसे maintain और test करें।
Production images में tag लगाएँ या digest?
Tag सुविधाजनक है और दूसरी image पर जा सकता है। Digest exact content पहचानता है और reproducibility बढ़ाता है। Teams digest pin कर सकती हैं और stale image से बचने के लिए reviewed updates automate कर सकती हैं।
क्या Docker build argument में API key सुरक्षित है?
Build secret के लिए argument या persistent environment variable न लें। Build system का supported secret mount इस्तेमाल करें और जाँचें कि value layers, metadata, logs या exported cache में न हो।
क्या image scan runtime security की जगह लेती है?
नहीं। Scan application का हर behavior, host configuration, network path या runtime permission जाँचती नहीं। Least-privilege deployment, isolation, monitoring, patch management और incident response भी जरूरी हैं।
संबंधित व्यावहारिक मार्गदर्शिकाएँ
संबंधित मुद्दों की मार्गदर्शिकाएँ
स्रोत और प्रकाशन रिकॉर्ड
Draft prepared 27 September 2026; engineering, security and editorial review pending · स्रोत जाँचे गए .