तपाइँ Docker कन्टेनरहरूलाई कसरी सुरक्षित गर्नुहुन्छ?

Question

Accepted Answer

Docker सुरक्षित गर्न एकाधिक तहहरू समावेश हुन्छन् — **न्यूनतम र विश्वासयोग्य इमेजहरू**, **non-root को रूपमा चलाउनु**, **कमजोरी स्क्यानिङ**, **रहस्य व्यवस्थापन**, **संसाधन र क्षमता सीमा**, र **होस्ट/डेमन कठोरीकरण**। कन्टेनर सुरक्षा महत्त्वपूर्ण छ किनभने कमजोरीहरूले कन्टेनर र होस्ट दुवैलाई असर गर्न सक्छन्।

## इमेज सुरक्षा

```text
✓ Use MINIMAL base images (alpine, distroless) → fewer packages = smaller attack surface
✓ Use TRUSTED/official images; pin specific versions/DIGESTS (not "latest")
✓ SCAN images for vulnerabilities (Trivy, docker scout, Snyk) — in CI and regularly
✓ Keep base images UPDATED (patch known CVEs)
✓ Don't include secrets or unnecessary tools in images
```

## रनटाइम सुरक्षा

```text
✓ Run as NON-ROOT (USER instruction) — a root container that's compromised is far more
  dangerous (especially with host access). This is one of the most important practices.
✓ Drop capabilities (--cap-drop ALL, add only needed ones) — limit what the container can do
✓ Read-only filesystem (--read-only) where possible
✓ no-new-privileges (prevent privilege escalation)
✓ Set RESOURCE LIMITS (prevent DoS from resource exhaustion)
✓ NEVER run --privileged unless absolutely necessary (it gives near-host access)
```

## रहस्य र होस्ट सुरक्षा

```text
✓ Don't bake secrets into images; use secrets management at runtime
✓ Protect the DOCKER DAEMON — the daemon runs as root; access to it = root on the host
  (don't expose the Docker socket; mounting /var/run/docker.sock into a container is risky)
✓ Keep the host and Docker engine PATCHED; use minimal/hardened host OS
✓ Isolate networks; limit container-to-container and container-to-host access
✓ Consider rootless Docker / user namespaces for stronger isolation
```

## यो किन महत्त्वपूर्ण छ

Docker कन्टेनरहरूलाई सुरक्षित गर्नु वरिष्ठ-स्तरीय ज्ञान महत्त्वपूर्ण छ किनभने कन्टेनर कमजोरीहरूले कन्टेनर र **होस्ट** दुवैलाई असर गर्न सक्छन्, जसले सुरक्षालाई वास्तविक परिणामहरू सहितको बहु-तहीय चिन्ता बनाउँछ। **इमेज सुरक्षा** अभ्यासहरू (आक्रमण सतह कम गर्न न्यूनतम/विश्वासयोग्य आधार इमेजहरू, संस्करण पिनिङ, **कमजोरीहरूको लागि स्क्यानिङ** ज्ञात CVEहरू पकड्न, इमेजहरू अद्यावधिक राख्न) शोषणयोग्य इमेजहरू पठाउनबाट रोकछन् — कमजोरीहरूको सामान्य स्रोत। **रनटाइम सुरक्षा** विशेष गरी महत्त्वपूर्ण छ: **non-root को रूपमा चलाउनु** सबैभन्दा महत्त्वपूर्ण अभ्यासहरू मध्ये एक हो किनभने एक समझौत गरिएको root कन्टेनर अत्यधिक खतरनाक छ (सम्भावित होस्ट समझौताको दिकतर्फ), र **क्षमताहरू छोड्नु**, read-only फाइलसिस्टमहरू प्रयोग गर्नु, विशेषाधिकार वृद्धि रोक्नु, र **कहिलेपनि `--privileged` प्रयोग नगर्नु** जब सम्भव हुन्न (यसले होस्ट-निकट पहुँच प्रदान गरिन्छ) सबैले एक कन्टेनर भंग भएमा एक आक्रमणकारीले के गर्न सक्छ भनेर सीमित गरिन्छ — गहिराइमा रक्षा। **रहस्य व्यवस्थापन** (कहिलेपनि इमेजहरूमा रहस्यहरू बेक नगर्नु, रनटाइम रहस्यहरू प्रयोग गर्नु) प्रमाणपत्र लीकहरू रोकिन्छ। **होस्ट र डेमन सुरक्षा** महत्त्वपूर्ण छ र प्राय: अलक्षित हुन्छ: **Docker डेमन root को रूपमा चलिन्छ**, त्यसैले यसमा पहुँच (वा Docker socket) प्रभावकारी रूपमा **होस्टमा root** छ — डेमनलाई सुरक्षित गर्नु, Docker socket उजागर नगर्नु, र होस्टलाई प्यास गरिएको राख्नु आवश्यक छ, rootless Docker र user namespaces अझ बलिष्ठ अलगीकरण प्रदान गर्दछन्।

कन्टेनरहरूले होस्ट kernel साझा गर्दछन् (त्यसैले एक कन्टेनर escape वा होस्ट समझौताको गम्भीर परिणाम छ) र containerized अनुप्रयोगहरू उत्पादनमा व्यापक छन्, र सही सुरक्षा (न्यूनतम/स्क्यान गरिएको इमेजहरू, limited क्षमताहरू सहित non-root रनटाइम, रहस्य व्यवस्थापन, र डेमन/होस्ट कठोरीकरण) वास्तविक कन्टेनर र होस्ट समझौताहरू रोकिन्छ, Docker कन्टेनरहरूलाई कसरी सुरक्षित गर्ने भनेर बुझ्नु वरिष्ठ-स्तरीय ज्ञान महत्त्वपूर्ण छ — उत्पादन कन्टेनर परिनियोजनहरूको लागि महत्त्वपूर्ण जिम्मेवारी, जहाँ बहु-तहीय अभ्यासहरू (विशेष गरी non-root execution र root-विशेषाधिकारप्राप्त डेमन रक्षा गर्नु) containerization को अन्तर्निहित, गम्भीर, वास्तविक सुरक्षा जोखिमहरू सम्बोधन गर्छन्।