คุณทำให้ Docker container มีความปลอดภัยอย่างไร?

Question

Accepted Answer

การทำให้ Docker ปลอดภัยเกี่ยวข้องกับหลายชั้น — **image ที่เล็กและน่าเชื่อถือ** การ **รันแบบ non-root** การ **scan หาช่องโหว่** การ **จัดการ secrets** การ **จำกัดทรัพยากรและ capability** และการ **เสริมความแข็งแกร่งให้ host/daemon** ความปลอดภัยของ container เป็นเรื่องสำคัญเพราะช่องโหว่สามารถส่งผลกระทบทั้งต่อ container และ host

## ความปลอดภัยของ image

```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
```

## ความปลอดภัยตอน runtime

```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)
```

## ความปลอดภัยของ secrets และ host

```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 container ปลอดภัยเป็นความรู้ระดับ senior ที่สำคัญ เพราะช่องโหว่ของ container สามารถส่งผลกระทบทั้งต่อ container และ **host** ทำให้ความปลอดภัยเป็นเรื่องหลายชั้นที่มีผลกระทบจริง แนวปฏิบัติด้าน **ความปลอดภัยของ image** (base image ที่เล็กและน่าเชื่อถือเพื่อลด attack surface, การ pin เวอร์ชัน, การ **scan หาช่องโหว่** เพื่อจับ CVE ที่รู้จัก, การอัปเดต image อยู่เสมอ) ช่วยป้องกันการส่งมอบ image ที่มีช่องโหว่ — ซึ่งเป็นแหล่งของช่องโหว่ที่พบบ่อย **ความปลอดภัยตอน runtime** สำคัญเป็นพิเศษ: การ **รันแบบ non-root** เป็นหนึ่งในแนวปฏิบัติที่สำคัญที่สุดเพราะ container ที่รันแบบ root ที่ถูกเจาะนั้นอันตรายกว่ามาก (อาจนำไปสู่การเจาะ host) และการ **drop capabilities** การใช้ filesystem แบบ read-only การป้องกัน privilege escalation และการ **ไม่ใช้ `--privileged`** เว้นแต่จำเป็นจริง ๆ (เพราะให้สิทธิ์เกือบเทียบเท่า host) ล้วนจำกัดสิ่งที่ผู้โจมตีทำได้หาก container ถูกเจาะ — เป็นการป้องกันแบบหลายชั้น (defense in depth) **การจัดการ secrets** (ไม่ฝัง secrets ลงใน image, ใช้ secrets ตอน runtime) ป้องกันการรั่วไหลของ credential **ความปลอดภัยของ host และ daemon** สำคัญและมักถูกมองข้าม: **Docker daemon รันแบบ root** ดังนั้นการเข้าถึงมัน (หรือ Docker socket) จึงเท่ากับ **root บน host** ทำให้การปกป้อง daemon การไม่เปิดเผย Docker socket และการ patch host อยู่เสมอเป็นเรื่องจำเป็น โดย rootless Docker และ user namespaces ให้การแยกที่แข็งแกร่งกว่า

เนื่องจาก container ใช้ kernel ของ host ร่วมกัน (ดังนั้นการหลุดออกจาก container หรือการเจาะ host จึงมีผลกระทบร้ายแรง) และแอปพลิเคชันแบบ container มีอยู่ทั่วไปใน production และเนื่องจากความปลอดภัยที่เหมาะสม (image ที่เล็ก/ถูก scan, runtime แบบ non-root ที่จำกัด capability, การจัดการ secrets และการเสริมความแข็งแกร่งให้ daemon/host) คือสิ่งที่ป้องกันการเจาะ container และ host จริง การเข้าใจวิธีทำให้ Docker container ปลอดภัยจึงเป็นความรู้ระดับ senior ที่สำคัญ — เป็นความรับผิดชอบสำคัญสำหรับการ deploy container ใน production ที่แนวปฏิบัติแบบหลายชั้น (โดยเฉพาะการรันแบบ non-root และการปกป้อง daemon ที่มีสิทธิ์ root) ตอบโจทย์ความเสี่ยงด้านความปลอดภัยที่ร้ายแรงและมีอยู่จริงซึ่งติดมากับ containerization