การเสริมความปลอดภัยให้ Pod ด้วย securityContext

ชาร์ตที่มาพร้อมค่าเริ่มต้นแบบใช้สิทธิ์เท่าที่จำเป็นจะปกป้องทุกคลัสเตอร์ที่ติดตั้งชาร์ตนั้น การใส่ความปลอดภัยไว้ในแม่แบบตั้งแต่ต้นย่อมดีกว่าหวังว่าผู้ใช้จะจำได้ว่าต้องเพิ่มเอง

คุณสามารถกำหนด securityContext ในระดับพ็อดเพื่อใช้กับคอนเทนเนอร์ทั้งหมด และกำหนดค่าที่จำกัดกว่าเป็นรายคอนเทนเนอร์ได้ การตั้งค่าระดับคอนเทนเนอร์จะมีผลแทนระดับพ็อดสำหรับคอนเทนเนอร์นั้น

กำหนด runAsNonRoot เป็น true เพื่อให้ Kubernetes ปฏิเสธการเริ่มคอนเทนเนอร์ที่จะทำงานด้วยสิทธิ์ root นี่คือค่าเริ่มต้นที่ส่งผลต่อความปลอดภัยมากที่สุดเพียงค่าเดียวที่คุณกำหนดได้

เปิดใช้ readOnlyRootFilesystem เพื่อไม่ให้คอนเทนเนอร์เขียนลงในเลเยอร์อิมเมจของตนเอง ให้เมานต์ emptyDir สำหรับเส้นทางใด ๆ ที่แอปจำเป็นต้องเขียนจริง

แอปส่วนใหญ่ไม่จำเป็นต้องมีสิทธิ์พิเศษระดับเคอร์เนล ดังนั้นให้ลบความสามารถ ALL แล้วเพิ่มกลับเฉพาะความสามารถที่เวิร์กโหลดจำเป็นต้องใช้จริงในกรณีที่พบไม่บ่อย

กำหนด allowPrivilegeEscalation เป็น false เพื่อไม่ให้กระบวนการได้รับสิทธิ์มากกว่าที่มีตั้งแต่เริ่มต้น แม้จะทำผ่านไบนารี setuid ก็ตาม 🔒

ใช้ fsGroup ใน securityContext ระดับพ็อด เพื่อให้วอลุ่มที่เมานต์มีเจ้าของเป็นกลุ่มที่ผู้ใช้ซึ่งไม่ใช่ root เป็นสมาชิก และหลีกเลี่ยงข้อผิดพลาดด้านสิทธิ์

คอนเทนเนอร์แบบ privileged มีสิทธิ์เข้าถึงโฮสต์เกือบทั้งหมด จึงแทบไม่ควรปรากฏเป็นค่าเริ่มต้นของชาร์ต ปล่อยค่าไว้โดยไม่กำหนด ซึ่งหมายถึง false

เชื่อม securityContext เข้ากับ values ด้วย toYaml เพื่อให้ผู้ใช้ปรับค่าได้ แต่ยังคงการตั้งค่าที่เสริมความปลอดภัยไว้เป็นค่าเริ่มต้นที่ปลอดภัย

ค่าเริ่มต้นเหล่านี้สอดคล้องกับมาตรฐานความปลอดภัยของพ็อดแบบ restricted ของ Kubernetes ดังนั้นชาร์ตของคุณจึงติดตั้งได้อย่างราบรื่นแม้ในเนมสเปซที่ล็อกการเข้าถึงอย่างเข้มงวด

ยืนยันว่าการเสริมความปลอดภัยมีผลแล้ว โดยตรวจสอบข้อกำหนดของพ็อดที่กำลังทำงานด้วย kubectl get pod -o yaml และตรวจดูฟิลด์ securityContext

การตั้งค่าใดจะหยุดไม่ให้คอนเทนเนอร์เริ่มทำงาน หากคอนเทนเนอร์นั้นจะทำงานด้วยผู้ใช้ root

คุณได้เสริมความปลอดภัยให้พ็อดด้วย runAsNonRoot ลบความสามารถต่าง ๆ ใช้ระบบไฟล์แบบอ่านอย่างเดียว และปิดการยกระดับสิทธิ์ ค่าเริ่มต้นที่ปลอดภัยจะปกป้องทุกการติดตั้ง ✅