3 Tier Application on EKS: เลิกใช้ AWS Access Keys
เรียนรู้วิธีตั้งค่า Amazon EKS และ GitHub Actions ด้วย OIDC และ Kubernetes Access Entries เพื่อความปลอดภัยที่ดีขึ้น
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- เลิกเก็บ Static AWS Access Keys ใน GitHub Repo เพื่อความปลอดภัยที่สูงขึ้น
- ใช้ GitHub OIDC Token แทนคีย์ถาวรที่มีอายุการใช้งานจำกัดเฉพาะในแต่ละ Job
- จัดการสิทธิ์สองชั้นผ่าน AWS IAM และ Kubernetes RBAC Access Entries
การพัฒนาแอปพลิเคชัน 3-tier บน Amazon EKS และตั้งค่าระบบ Deployment อัตโนมัติด้วย GitHub Actions ซึ่งทำงานทุกครั้งที่มีการ Merge โค้ดเข้าสู่ Branch หลัก อาจเริ่มต้นด้วยการเก็บค่าความลับอย่าง AWS_ACCESS_KEY_ID และ AWS_SECRET_ACCESS_KEY ไว้ใน Settings ของ Repository ซึ่งแม้จะใช้งานได้จริง แต่วิธีนี้มีความเสี่ยงด้านความปลอดภัยสูงหากคีย์เกิดการรั่วไหล เนื่องจาก Access Keys ประเภทนี้ไม่มีวันหมดอายุจนกว่าจะมีคนสังเกตเห็นและทำการเพิกถอน
ทางเลือกที่ดีกว่าคือการใช้งาน OIDC (OpenID Connect) ซึ่งเข้ามาแทนที่คีย์ถาวรด้วยโทเค็นที่มีอายุการใช้งานเพียงชั่วคราวเท่ากับระยะเวลาของ Job นั้นๆ โดยไม่มีการเก็บรหัสผ่านใดๆ ไว้ในระบบ และความน่าเชื่อถือจะขึ้นอยู่กับ Claims ของ Token แทนที่จะเป็นสตริงที่แชร์ร่วมกัน
การเปลี่ยนผ่านจาก Static Keys สู่ OIDC เป็นแนวทางปฏิบัติด้านความปลอดภัยสมัยใหม่ (Zero Trust) ที่ช่วยจำกัดขอบเขตความเสียหายหากระบบ CI/CD ถูกโจมตี เนื่องจากโทเค็นจะใช้ได้ครั้งเดียวและหมดอายุทันที ลดภาระในการหมุนเวียนคีย์ (Key Rotation) และป้องกันปัญหาคีย์รั่วไหลบน GitHub Repository ได้อย่างเด็ดขาด
ขั้นตอนการตั้งค่าเริ่มต้นด้วยการสร้าง OIDC Provider ใน AWS IAM ผ่าน URL ของ GitHub Actions โดย AWS ในปัจจุบันไม่ต้องจัดการเรื่อง Certificate Thumbprint อีกต่อไป เนื่องจากระบบจะทำการตรวจสอบและหมุนเวียนใบรับรองให้โดยอัตโนมัติ จากนั้นจึงสร้าง IAM Role และกำหนด Trust Policy เพื่อจำกัดว่า Job ใดของ GitHub ที่ได้รับอนุญาตให้สวมบทบาทนี้ได้ โดยแนะนำให้ใช้รูปแบบ Environment สำหรับการผลิตเพื่อให้สามารถตั้งค่า Required Reviewer เพิ่มเติมได้
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
สิ่งที่ต้องระวังอย่างยิ่งคือการประกาศบล็อก Permissions โดยต้องระบุ permissions: id-token: write ให้ชัดเจน มิฉะนั้น GitHub จะไม่สร้างโทเค็นและขั้นตอนการยืนยันตัวตนจะล้มเหลวด้วยข้อผิดพลาดที่ระบุสาเหตุได้ยาก นอกจากนี้ การประกาศบล็อก Permissions จะรีเซ็ตสิทธิ์ทั้งหมดเป็นค่าว่าง ดังนั้นจึงต้องระบุ contents: read ควบคู่ไปด้วยหากมีการ Checkout โค้ด
แม้จะผ่านด่านยืนยันตัวตนของ AWS IAM มาได้แล้ว แต่มักจะพบปัญหาติดขัดที่ขั้นตอนการรันคำสั่ง kubectl ด้วยข้อความผิดพลาดว่า Unauthorized เนื่องจาก EKS มีระบบยืนยันตัวตนแยกเป็นสองเลเยอร์ โดย IAM ทำหน้าที่ตรวจสอบว่าสามารถติดต่อ API Endpoint ของคลัสเตอร์ได้หรือไม่ ในขณะที่ Kubernetes RBAC จะเป็นตัวกำหนดสิทธิ์ว่าสามารถทำอะไรได้บ้างหลังจากเข้าไปข้างในแล้ว
วิธีแก้ปัญหาคือต้องทำการแมป Role เข้ากับคลัสเตอร์โดยตรง โดยหากคลัสเตอร์เดิมใช้งาน ConfigMap อยู่ จะต้องอัปเดตโหมดการตรวจสอบสิทธิ์ให้รองรับ API หรือแก้ไข ConfigMap ในเนมสเปซ kube-system พร้อมทั้งผูกสิทธิ์เข้ากับ Role หรือ ClusterRole ของ Kubernetes โดยจำกัดขอบเขตสิทธิ์ของ Deployment Role ไว้ที่เนมสเปซเดียวผ่าน AmazonEKSEditPolicy เพื่อความปลอดภัยสูงสุด
"error: You must be logged in to the server (Unauthorized)"
Mayank Thakur
ผลลัพธ์จากการปรับปรุงนี้ทำให้ Repository ไม่มี AWS Secrets หลงเหลืออยู่เลย Credentials ที่ใช้มีอายุจำกัดเฉพาะ Job นั้น ถูกจำกัดสิทธิ์ในเนมสเปซเดียวและเฉพาะ Branch ที่กำหนด ช่วยลดความเสี่ยงด้านความปลอดภัยได้อย่างมีประสิทธิภาพ และใช้เวลาในการปรับแต่งเพียงช่วงบ่ายเท่านั้น
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น