LEVEL 4 · ระดับเทพ
ความปลอดภัยของ Pipeline
pipeline ของคุณมีกุญแจสู่ production มันจึงเป็น เป้าหมายการโจมตีชั้นดี — เจาะ pipeline ได้ เท่ากับเจาะทุกอย่างที่มันเข้าถึง บทนี้คือหลักการทำให้ pipeline แข็งแกร่ง ซึ่งเป็นทักษะที่แยกมือสมัครเล่นออกจากมืออาชีพ
12.1 Supply chain — โค้ดที่คุณไม่ได้เขียนแต่ให้สิทธิ์เต็ม
ทุก uses: someone/action@v4 คือการรันโค้ดของคนอื่นในสภาพแวดล้อมที่เข้าถึง secret ของคุณ ถ้าเจ้าของ action นั้นถูกแฮ็กหรือกลายเป็นคนร้าย เขารันอะไรใน pipeline คุณก็ได้ ป้องกันด้วย:
- ปักหมุดเป็น commit SHA ไม่ใช่ tag —
uses: actions/checkout@a1b2c3d...เพราะ tag อย่าง@v4ถูกย้ายไปชี้โค้ดร้ายได้ แต่ SHA ผูกกับเนื้อหาตายตัว (หลักการ SHA จากบทที่ 2 ของเล่ม Git ตรง ๆ) - ใช้เฉพาะ action ที่เชื่อถือได้ และตรวจก่อนอัปเกรด
- ล็อกเวอร์ชัน dependencies ด้วย lock file เสมอ
12.2 สิทธิ์น้อยที่สุด (least privilege)
โดยปริยาย token ของ pipeline มักได้สิทธิ์กว้างเกินจำเป็น จงหดให้เหลือเท่าที่ใช้จริง งานที่แค่รันเทสต์ไม่ควรมีสิทธิ์เขียน repo:
permissions:
contents: read # อ่านโค้ดได้พอ ไม่ให้สิทธิ์เขียนโดยไม่จำเป็นหลักคิด: ถ้า pipeline ถูกเจาะ ความเสียหายถูกจำกัดด้วยสิทธิ์ที่มันมี — ให้น้อย เสียหายน้อย
12.3 OIDC — เลิกเก็บกุญแจถาวร
วิธีเก่าคือเก็บ credential ระยะยาวของ cloud ไว้เป็น secret ซึ่งถ้ารั่วก็ใช้ได้ตลอดจนกว่าจะเพิกถอน วิธีใหม่คือ OIDC (OpenID Connect): pipeline แลก "ตัวตนที่ cloud เชื่อถือ" เป็น credential ชั่วคราวที่หมดอายุในไม่กี่นาที สำหรับการรันครั้งนั้นโดยเฉพาะ ไม่มีกุญแจถาวรให้รั่วอีกต่อไป — นี่คือมาตรฐานที่ทีมจริงจังขยับไปใช้
✅ สรุปบทที่ 12 — pipeline คือเป้าโจมตีเพราะถือกุญแจสู่ prod · ปักหมุด action ด้วย commit SHA ไม่ใช่ tag (ผูกเนื้อหาตายตัวเหมือน SHA ใน Git) · ให้ สิทธิ์น้อยที่สุด เพื่อจำกัดความเสียหายเมื่อถูกเจาะ · ใช้ OIDC แทน credential ถาวรเพื่อเลิกเก็บกุญแจที่รั่วได้ · กันโค้ดจาก fork ไม่ให้แตะ secret/สิทธิ์