Cloud & IT Cert Prep · บทเรียน

ความปลอดภัยคอนเทนเนอร์: การเสริมความแข็งแกร่งของอิมเมจและการป้องกันขณะทำงาน

เสริมความแข็งแกร่งให้ Docker image ด้วยการลบแพ็กเกจที่ไม่จำเป็น การทำงานโดยไม่ใช้สิทธิ์ root และการใช้เครื่องมือรักษาความปลอดภัยขณะทำงาน (Falco, Sysdig) เพื่อตรวจจับพฤติกรรมคอนเทนเนอร์ผิดปกติ

บทเรียน 1 จาก 413 ขั้นตอน

ความปลอดภัยคอนเทนเนอร์: การเสริมความแข็งแกร่งของอิมเมจและการป้องกันขณะทำงาน เป็นบทเรียน Cloud & IT Cert Prep ฟรีบน CoddyKit นี่คือบทเรียนที่ 1 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Cloud & IT Cert Prep และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Cloud & IT Cert Prep มีบทเรียนทั้งหมด 4 บทเรียน

พื้นฐานความปลอดภัยของคอนเทนเนอร์

คอนเทนเนอร์ บรรจุโค้ดของแอปพลิเคชันและส่วนที่ต้องพึ่งพาไว้ในหน่วยที่แยกออกจากกัน โดยใช้เคอร์เนลของระบบปฏิบัติการโฮสต์ร่วมกัน แตกต่างจากเครื่องเสมือน (VM) ที่มีระบบปฏิบัติการสำหรับแขกอยู่อย่างครบถ้วน การใช้ทรัพยากรร่วมกันนี้ทำให้คอนเทนเนอร์มีน้ำหนักเบาและทำงานได้รวดเร็ว แต่ก็นำไปสู่รูปแบบความปลอดภัยที่แตกต่างกัน กล่าวคือ ช่องโหว่ที่ทำให้หลบหนีออกจากคอนเทนเนอร์ได้อาจเปิดทางให้ผู้โจมตีออกจากคอนเทนเนอร์และเข้าถึง เคอร์เนลของโฮสต์ ได้โดยตรง ซึ่งส่งผลกระทบต่อคอนเทนเนอร์อื่นทั้งหมด ความปลอดภัยของคอนเทนเนอร์มุ่งเน้นที่สามชั้น ได้แก่ อิมเมจ (สิ่งที่ถูกบรรจุไว้), ขณะทำงาน (สิ่งที่คอนเทนเนอร์ทำได้ระหว่างทำงาน) และ แพลตฟอร์มจัดการคอนเทนเนอร์ (วิธีจัดการคอนเทนเนอร์)

อิมเมจพื้นฐานขั้นต่ำ: ลดพื้นที่การโจมตี

แพ็กเกจทุกชุดที่ติดตั้งไว้ในอิมเมจคอนเทนเนอร์อาจเป็นพื้นที่การโจมตีได้ หลักการของ อิมเมจพื้นฐานขั้นต่ำ คือการเริ่มต้นจากพื้นฐานที่เล็กที่สุดเท่าที่เป็นไปได้ เช่น Alpine Linux (5MB มีแพ็กเกจเท่าที่จำเป็น), อิมเมจแบบไม่มีส่วนประกอบของระบบปฏิบัติการ (อิมเมจของ Google ที่มีเฉพาะส่วนทำงานและแอปพลิเคชัน ไม่มีเชลล์หรือตัวจัดการแพ็กเกจ) หรือ scratch (ว่างเปล่าโดยสมบูรณ์ เหมาะสำหรับไบนารีที่คอมไพล์แบบสแตติก) คอนเทนเนอร์ที่ไม่มีเชลล์จะทำให้ผู้โจมตีที่สั่งให้โค้ดทำงานได้ไม่สามารถเรียกใช้ wget, curl หรือเครื่องมืออื่น ๆ เพื่อขยายการโจมตีได้โดยง่าย — หลักการนี้เรียกว่า การป้องกันด้วยการเปิดเผยให้น้อยที่สุด

# Bad: starts from a full OS image
FROM ubuntu:22.04

# Better: minimal Alpine base
FROM alpine:3.18

# Best: distroless for Java apps
FROM gcr.io/distroless/java17-debian11

การทำงานโดยไม่ใช้สิทธิ์รูท: กฎข้อแรก

โดยค่าเริ่มต้น คอนเทนเนอร์ Docker จะทำงานด้วยสิทธิ์ รูท (UID 0) หากผู้โจมตีใช้ประโยชน์จากช่องโหว่ในแอปพลิเคชันที่อยู่ในคอนเทนเนอร์ ผู้โจมตีจะได้รับสิทธิ์รูทภายในคอนเทนเนอร์ หากคอนเทนเนอร์ใช้โวลุมร่วมกันหรือมีการเมานต์จากโฮสต์ สิทธิ์รูทภายในคอนเทนเนอร์ก็อาจเทียบเท่ากับสิทธิ์รูทบนโฮสต์ วิธีแก้ไขนั้นง่ายมาก: สร้างผู้ใช้เฉพาะในไฟล์ Dockerfile แล้วสลับไปใช้ผู้ใช้นั้นด้วยคำสั่ง USER ก่อนคำสั่ง CMD/ENTRYPOINT สุดท้าย เครื่องมือสแกนความปลอดภัยของคอนเทนเนอร์จำนวนมากจะแจ้งเป็นข้อค้นพบสำหรับอิมเมจใดก็ตามที่ไม่มีผู้ใช้ที่ไม่ใช่รูท

FROM alpine:3.18
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
COPY --chown=appuser:appgroup app /app/app
USER appuser
CMD ["/app/app"]

คอนเทนเนอร์ที่เปลี่ยนแปลงไม่ได้และระบบไฟล์แบบอ่านอย่างเดียว

คอนเทนเนอร์ที่เปลี่ยนแปลงไม่ได้ คือคอนเทนเนอร์ที่ไม่สามารถแก้ไขระบบไฟล์ขณะทำงานได้ การเปิดใช้ --read-only ใน Docker (หรือ readOnlyRootFilesystem: true ใน Kubernetes) จะป้องกันไม่ให้ผู้โจมตีเขียนมัลแวร์ลงดิสก์ แก้ไขไฟล์กำหนดค่า หรือติดตั้งเครื่องมือภายในคอนเทนเนอร์ที่กำลังทำงาน แอปพลิเคชันที่จำเป็นต้องเขียนข้อมูลจริง ๆ เช่น บันทึกการทำงานและไฟล์ชั่วคราว สามารถเมานต์ โวลุม tmpfs เฉพาะสำหรับการเขียนชั่วคราวได้ คอนเทนเนอร์ที่เปลี่ยนแปลงไม่ได้บังคับใช้หลักการที่ว่าสถานะขณะทำงานควรมาจากอิมเมจและการกำหนดค่าเท่านั้น ไม่ใช่จากการแก้ไขภายในคอนเทนเนอร์ที่หลีกเลี่ยงกระบวนการ CI/CD ด้านความปลอดภัยของคุณ

# Run container with read-only root filesystem
docker run --read-only \
  --tmpfs /tmp \
  --tmpfs /var/run \
  myapp:latest

การสแกนอิมเมจ: ค้นหา CVE ก่อนนำไปใช้งาน

เครื่องมือสแกนอิมเมจของ Containerจะวิเคราะห์แพ็กเกจที่ติดตั้งอยู่ในอิมเมจของ Docker โดยเปรียบเทียบกับฐานข้อมูลช่องโหว่ (NVD, CVE) และรายงาน CVE ที่ทราบแล้ว เครื่องมือสแกนชั้นนำได้แก่ Trivy (Aqua Security ซึ่งรวดเร็วและใช้งานได้ฟรี), Grype (Anchore), Snyk Container และ AWS ECR image scanning ควรผสานการสแกนเข้ากับไปป์ไลน์ CI/CD เพื่อให้อิมเมจใดก็ตามที่มี CVE ระดับร้ายแรงหรือสูงทำให้ไปป์ไลน์ล้มเหลวก่อนถูกส่งไปยังรีจิสทรี นอกจากนี้ เครื่องมือสแกนควรตรวจหาความลับ (คีย์ API รหัสผ่าน) ที่ถูกฝังไว้ในชั้นของอิมเมจโดยไม่ตั้งใจด้วย

# Scan a Docker image with Trivy
trivy image --severity HIGH,CRITICAL myapp:latest

# Fail CI pipeline if vulnerabilities found
trivy image --exit-code 1 --severity CRITICAL myapp:latest

การจัดการความลับ: ห้ามเก็บไว้ในชั้นของอิมเมจ

ข้อผิดพลาดที่พบบ่อยและอันตรายคือการฝังความลับ (คีย์ API รหัสผ่านฐานข้อมูล ใบรับรอง TLS) ไว้ภายในอิมเมจของ Docker ไม่ว่าจะเป็นตัวแปรสภาพแวดล้อมที่ถูกฝังลงในอิมเมจ หรือไฟล์ที่เพิ่มเข้ามาผ่าน COPY ความลับเหล่านี้จะปรากฏให้ทุกคนที่เข้าถึงอิมเมจเห็นได้ผ่าน docker history หรือโดยการแยกชั้นของอิมเมจออกมา แม้ชั้นถัดมาจะลบไฟล์ดังกล่าว ไฟล์นั้นก็ยังคงอยู่ในประวัติของอิมเมจ ควรส่งความลับเข้าไปในขณะทำงานผ่านตัวแปรสภาพแวดล้อมจากตัวจัดการความลับ ผ่านความลับของ Docker หรือผ่านความลับของ Kubernetes ที่เมานต์เป็นโวลุม

# Never bake secrets into images
# Bad: ENV DATABASE_PASSWORD='supersecret'

# Good: inject at runtime via environment
docker run -e DATABASE_PASSWORD=$(vault read -field=password secret/db) myapp:latest

# Or use Docker secrets in Swarm/K8s

การป้องกันขณะทำงาน: Falco และการตรวจติดตามการเรียกระบบ

เครื่องมือรักษาความปลอดภัยขณะทำงานจะตรวจติดตามพฤติกรรมของ Container ระหว่างที่กำลังทำงาน และแจ้งเตือนหรือบล็อกกิจกรรมที่ผิดปกติ Falco (โครงการของ CNCF) เชื่อมต่อเข้ากับเคอร์เนล Linux โดยใช้ eBPF หรือโมดูลเคอร์เนล เพื่อดักจับการเรียกระบบและเปรียบเทียบกับกฎ ตัวอย่างเช่น กฎอาจแจ้งเตือนเมื่อ Container สร้างเชลล์ (execve('/bin/sh')) เปิดการเชื่อมต่อเครือข่ายบนพอร์ตที่ไม่คาดคิด หรืออ่าน /etc/shadow ตัวบ่งชี้ด้านพฤติกรรมเหล่านี้มักส่งสัญญาณว่ากำลังเกิดการโจมตี แม้จะไม่มี CVE ที่ทราบแล้วถูกใช้ประโยชน์ก็ตาม Sysdig Secure และ Aqua Security ให้บริการแพลตฟอร์มเชิงพาณิชย์สำหรับการป้องกันขณะทำงาน

# Example Falco rule: alert on shell execution in container
# - rule: Shell Spawned in Container
#   desc: A shell was spawned in a container
#   condition: container and proc.name in (bash, sh, zsh)
#   output: Shell spawned (user=%user.name container=%container.name)
#   priority: WARNING

ความสามารถของ Linux และโพรไฟล์ Seccomp

โดยค่าเริ่มต้น Container ของ Docker จะตัดความสามารถของ Linux ออกไปหลายรายการ แต่ยังคงเหลือไว้มากกว่าที่แอปพลิเคชันส่วนใหญ่ต้องการ ความสามารถจะแบ่งสิทธิ์ระดับ root ออกเป็นหน่วยย่อยที่แยกจากกัน (เช่น CAP_NET_ADMIN, CAP_SYS_ADMIN) แนวทางปฏิบัติที่ดีคือให้ตัดความสามารถทั้งหมดออก แล้วเพิ่มกลับมาเฉพาะรายการที่จำเป็นด้วย --cap-drop=ALL --cap-add=NET_BIND_SERVICE โพรไฟล์ Seccomp (Secure Computing Mode) จะกำหนดรายการการเรียกระบบที่ Container อนุญาตให้ทำได้ โดย Docker มีโพรไฟล์ seccomp เริ่มต้นที่บล็อกการเรียกระบบอันตรายประมาณ 44 รายการ โพรไฟล์ seccomp แบบกำหนดเองสำหรับแอปพลิเคชันเฉพาะสามารถจำกัดให้เข้มงวดยิ่งขึ้น โดยบล็อกการเรียกระบบทั้งหมดที่แอปพลิเคชันนั้นไม่เคยใช้งานอย่างถูกต้องตามปกติ

# Drop all capabilities, add only what's needed
docker run \
  --cap-drop=ALL \
  --cap-add=NET_BIND_SERVICE \
  --security-opt seccomp=/etc/docker/seccomp-custom.json \
  myapp:latest

รีจิสทรีของ Container และการลงลายเซ็นอิมเมจ

รีจิสทรีของ Container (Docker Hub, AWS ECR, Google Artifact Registry) ใช้จัดเก็บและแจกจ่ายอิมเมจ การรักษาความปลอดภัยของรีจิสทรีประกอบด้วย: การเปิดใช้การสแกนช่องโหว่เมื่อส่งอิมเมจ การจำกัดสิทธิ์การส่งอิมเมจให้เฉพาะบัญชีบริการของ CI/CD การเปิดใช้การลงลายเซ็นอิมเมจโดยใช้ Sigstore/Cosign หรือ Docker Content Trust (Notary) เพื่อให้สภาพแวดล้อมขณะทำงานดึงเฉพาะอิมเมจที่ลงลายเซ็นเข้ารหัสจากแหล่งที่เชื่อถือได้ และการกำหนดค่าอิมเมจแบบแก้ไขไม่ได้เพื่อไม่ให้แท็กถูกเขียนทับ (กำจัดการโจมตีด้วยการเปลี่ยนแท็ก ซึ่งผู้โจมตีแทนที่แท็ก :latest ที่เชื่อถือได้ด้วยอิมเมจอันตราย)

# Sign a container image with Cosign
cosign sign --key cosign.key myregistry.io/myapp:v1.2.3

# Verify signature before deployment
cosign verify --key cosign.pub myregistry.io/myapp:v1.2.3

เทคนิคการหลบหนีออกจาก Container และการป้องกัน

ผู้โจมตีที่ได้ความสามารถในการประมวลผลโค้ดภายใน Container อาจพยายามหลบหนีออกจาก Containerเพื่อเข้าถึงโฮสต์ เทคนิคที่พบบ่อย ได้แก่ การใช้ประโยชน์จากContainer ที่มีสิทธิ์สูง (--privileged ให้สิทธิ์เข้าถึงโฮสต์เกือบทั้งหมด) การใช้ซ็อกเก็ต Docker ที่เปิดเผยในทางที่ผิด (/var/run/docker.sock ที่เมานต์เข้าไปใน Container ทำให้เข้าถึง Docker API ได้เต็มรูปแบบ รวมถึงการสร้าง Container ที่มีสิทธิ์สูง) และการใช้ประโยชน์จากช่องโหว่ของเคอร์เนลผ่านความสามารถที่ไม่ได้รักษาความปลอดภัย การป้องกันมีดังนี้: อย่าใช้โหมดที่มีสิทธิ์สูงเว้นแต่จำเป็นอย่างยิ่ง อย่าเมานต์ซ็อกเก็ต Docker เข้าไปใน Container ของแอปพลิเคชัน อัปเดตแพตช์เคอร์เนลของโฮสต์ให้เป็นปัจจุบัน และใช้ gVisor หรือ Kata Containers กับภาระงานที่ต้องการการแยกกักกันอย่างเข้มงวด

# DANGEROUS: never do this in production
# docker run --privileged -v /:/host myapp:latest

# Check if a container is running privileged
docker inspect mycontainer | grep -i privileged

การปฏิบัติตามเกณฑ์มาตรฐาน CIS Docker

Center for Internet Security (CIS) Docker Benchmark ให้แนวทางการกำหนดค่าด้านความปลอดภัยโดยละเอียดสำหรับโฮสต์และ Container ของ Docker ครอบคลุมการกำหนดค่าดีมอน สุขอนามัยของอิมเมจ การตั้งค่าขณะทำงานของ Container และการควบคุมเครือข่าย เครื่องมืออย่าง Docker Bench for Security ช่วยตรวจสอบการปฏิบัติตามเกณฑ์มาตรฐาน CIS โดยอัตโนมัติ และสร้างรายงานแบบให้คะแนนของรายการที่ผ่านหรือล้มเหลว การเรียกใช้เกณฑ์มาตรฐานนี้เป็นระยะและผสานเข้ากับ CI/CD ช่วยให้ตรวจพบการเปลี่ยนแปลงของการกำหนดค่าด้านความปลอดภัยจากมาตรฐานได้อย่างรวดเร็ว ผู้เข้าสอบ Security+ ควรทราบว่า CIS Benchmarks เป็นแหล่งอ้างอิงหลักสำหรับการเสริมความแข็งแกร่งให้ OS และแพลตฟอร์มในบริบทของการสอบ

# Run Docker Bench for Security
docker run -it --net host --pid host --userns host --cap-add audit_control \
  -v /var/lib:/var/lib -v /var/run/docker.sock:/var/run/docker.sock \
  -v /etc:/etc docker/docker-bench-security

ตรวจสอบอย่างรวดเร็ว

ทดสอบความเข้าใจแนวคิด CompTIA Security+ (SY0-701) จากบทเรียนนี้

สรุปบทเรียน

ในบทเรียนนี้ คุณได้เรียนรู้ว่า อิมเมจพื้นฐานแบบมินิมอลและผู้ใช้ที่ไม่ใช่ rootช่วยลดพื้นผิวการโจมตีและระดับสิทธิ์ของภาระงานที่ทำงานใน Container ได้อย่างไร เครื่องมือป้องกันขณะทำงานอย่าง Falcoตรวจจับรูปแบบการเรียกระบบที่ผิดปกติซึ่งบ่งชี้ถึงการโจมตีที่กำลังเกิดขึ้นภายใน Container ได้อย่างไร และอย่าใช้ Container ที่มีสิทธิ์สูงหรือเมานต์ซ็อกเก็ต Dockerเข้าไปใน Container ของแอปพลิเคชัน เนื่องจากการกำหนดค่าเหล่านี้เปิดทางให้เกิดการหลบหนีออกจาก Container บทถัดไปเราจะสำรวจความปลอดภัยของ Kubernetes ซึ่งรวมถึง RBAC นโยบายเครือข่าย และมาตรฐานความปลอดภัยของ Pod

เริ่มต้นได้ฟรี

เรียนรู้ Cloud & IT Cert Prep ด้วย AI tutor — ฟรี

เขียนและเรียกใช้โค้ดจริงในเบราว์เซอร์ของคุณ รับความช่วยเหลือทันทีจาก AI tutor 24/7 และเรียนรู้ต่อจากที่คุณหยุดบนเว็บหรือในแอป

คอร์ส
150
บทเรียน
600

คำถามที่พบบ่อย

บทเรียน “ความปลอดภัยคอนเทนเนอร์: การเสริมความแข็งแกร่งของอิมเมจและการป้องกันขณะทำงาน” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “ความปลอดภัยคอนเทนเนอร์: การเสริมความแข็งแกร่งของอิมเมจและการป้องกันขณะทำงาน” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Cloud & IT Cert Prep ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Cloud & IT Cert Prep มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “ความปลอดภัยคอนเทนเนอร์: การเสริมความแข็งแกร่งของอิมเมจและการป้องกันขณะทำงาน”

เสริมความแข็งแกร่งให้ Docker image ด้วยการลบแพ็กเกจที่ไม่จำเป็น การทำงานโดยไม่ใช้สิทธิ์ root และการใช้เครื่องมือรักษาความปลอดภัยขณะทำงาน (Falco, Sysdig) เพื่อตรวจจับพฤติกรรมคอนเทนเนอร์ผิดปกติ คุณปฏิบัติ Cloud & IT Cert Prep ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Cloud & IT Cert Prep หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน Cloud & IT Cert Prep บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 1 จากทั้งหมด 4 บทเรียน

บทเรียน “ความปลอดภัยคอนเทนเนอร์: การเสริมความแข็งแกร่งของอิมเมจและการป้องกันขณะทำงาน” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน Cloud & IT Cert Prep นี้ได้ไหม

ได้ บทเรียน Cloud & IT Cert Prep ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

  1. ความปลอดภัยคอนเทนเนอร์: การเสริมความแข็งแกร่งของอิมเมจและการป้องกันขณะทำงาน
  2. ความปลอดภัย Kubernetes: RBAC นโยบายเครือข่าย และความปลอดภัยของพ็อด
  3. ความปลอดภัยแบบไร้เซิร์ฟเวอร์และความปลอดภัยของฟังก์ชัน
  4. การสแกนความปลอดภัยโครงสร้างพื้นฐานในรูปโค้ด
← กลับไปที่ Cloud & IT Cert Prep