🧱 Docker Buildx 0.36.0 มีจุดเล็กที่น่าสนใจกว่าชื่อ release: …

🧱 Docker Buildx 0.36.0 มีจุดเล็กที่น่าสนใจกว่าชื่อ release: build เริ่มมีด่านตรวจ input ก่อนปล่อยให้ image เกิดขึ้น

ปัญหาคือ container build ไม่ได้เริ่มจากโค้ดเราอย่างเดียว มันดึง base image, Git repo, remote file, artifact และบางครั้งยังต้องใช้ secret ระหว่าง build

ถ้า input เหล่านี้เปลี่ยนมือ โดนแก้ หรือไม่ได้มาจากแหล่งที่ทีมอนุมัติ CI ก็อาจสร้าง image ที่ “ผ่าน build” แต่ไม่ผ่านความไว้ใจ

ใน Buildx v0.36.0 มีหลายจุดที่ชี้ไปทางเดียวกัน:

• default source policy ตรวจ authenticity ของ BuildKit release images ตอนสร้าง docker-container builder
• Bake override secret sources ได้ ช่วยแยก pipeline config ออกจาก secret จริงตอนรัน
• BUILDX_BAKE_FILE_RELATIVE_PATHS=true ทำให้ path อิงจาก bake file ไม่ใช่ current working directory
• imagetools เพิ่ม validation ของ descriptor input จากไฟล์
• Windows release binaries ถูก code-signed แล้ว

ความหมายไม่ใช่ “Docker กัน supply-chain attack ให้หมดแล้ว”

แต่คือ build pipeline ควรมี policy layer ที่ fail ก่อนเริ่ม build ถ้า source, image, หรือ artifact ไม่ผ่านกติกาของทีม

Workflow ที่ทีม dev ลองได้:

1. วาง Dockerfile.rego ข้าง Dockerfile
2. เริ่มจาก deny-all แล้ว allow เฉพาะ base image, registry, Git source หรือ artifact ที่อนุมัติ
3. ใช้ docker buildx policy eval ทดสอบ source แยกก่อน
4. เปิด —policy strict=true ใน CI เพื่อไม่ให้ policy หายเงียบ
5. แยก secret เป็น secret mount อย่าใส่ใน ARG หรือ ENV

เหมาะกับทีมที่มี container image หลายตัว, monorepo, CI หลาย environment หรือใช้ agent ช่วยแก้ Dockerfile/Compose/Bake

ข้อจำกัดคือ build policies ยังเป็น experimental ใน Docker Docs และต้องใช้ Buildx/BuildKit version ที่รองรับ

ลิงก์ต้นทางอยู่ในคอมเมนต์แรกครับ

ทีมคุณตอนนี้เช็กแค่ “build passed” หรือเช็กด้วยว่า input ที่ใช้ build น่าเชื่อถือจริง?

อยากให้ SynapTech AI ช่วยวาง policy gate ให้ CI/CD, Dockerfile หรือ agent workflow ของทีม ทักมาคุยกันได้ครับ

#Docker #Buildx #DevSecOps #SupplyChain #SynapTechAI

---

📖 อ่านบทความเต็มบน Facebook | 🔔 ติดตาม SynapTech