Applied Kubernetes Hardening: A Practical Playbook

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

ล็อกระนาบควบคุมอันดับแรก

เซิร์ฟเวอร์ API เป็นเป้าหมายที่มีค่าสูงสุดในคลัสเตอร์ใดๆ เริ่มต้นด้วยการปิดใช้งานการรับรองตัวตนแบบนิรนาม และบังคับใช้วิธีการรับรองตัวตนที่แข็งแกร่ง—การบูรณาการ OIDC กับผู้ให้บริการตัวตนของคุณเป็นที่ต้องการมากกว่าโทเค็นแบบคงที่หรือใบรับรองไคลเอนต์ที่ไม่มีวันหมดอายุ จำกัดการเข้าถึงคลังเก็บข้อมูล etcd เนื่องจากมีทุกความลับและวัตถุการกำหนดค่าในรูปแบบข้อความธรรมชาติ เว้นแต่จะเปิดใช้งานการเข้ารหัสที่เหลือ เปิดใช้งานการเข้ารหัสสำหรับความลับโดยใช้ผู้ให้บริการ KMS แทนที่จะพึ่งพาการเข้ารหัส base64 ซึ่งไม่มีการป้องกันจริง การบันทึกการตรวจสอบควรเปิดใช้งานตั้งแต่วันแรก หากไม่มี คุณจะไม่มีเส้นทาง forensic เมื่อเกิดข้อผิดพลาด

RBAC: สิทธิน้อยที่สุด ไม่ใช่ความสะดวก

การกำหนดค่าผิดพลาดที่พบบ่อยที่สุดในคลัสเตอร์การผลิตคือการผูกมัด RBAC ที่กว้างเกินไป—cluster-admin ให้กับบัญชีบริการที่ต้องการเพียงอ่าน pod ในเนมสเปซเดียว สร้างบทบาทรอบฟังก์ชันงานจริงและจำกัดขอบเขตไปยังเนมสเปซโดยที่เป็นไปได้ หลีกเลี่ยงคำกริยาและทรัพยากรแบบไวลด์การ์ดในคำจำกัดความ Role และ ClusterRole ตรวจสอบการผูกมัดอย่างสม่ำเสมออย่างเป็นประจำด้วยเครื่องมือเช่น kubectl auth can-i --list หรือ rbac-lookup เพื่อจับการไต่ระดับสิทธิ บัญชีบริการสมควรได้รับการตรวจสอบแบบเดียวกับผู้ใช้จริง—ปิดใช้งานการติดตั้งโทเค็นบัญชีบริการโดยอัตโนมัติสำหรับ pod ที่ไม่จำเป็นต้องมีการเข้าถึง API

ความปลอดภัยของ Pod: สมมติว่าเสียหาย

Pod Security Admission (ซึ่งแทนที่ PodSecurityPolicy ที่เลิกใช้แล้ว) ช่วยให้คุณบังคับใช้โปรไฟล์พื้นฐานหรือจำกัดที่ระดับเนมสเปซ ในระดับต่ำสุด ไม่อนุญาต container ที่ได้รับสิทธิ์ การแบ่งปันเนมสเปซโฮสต์ และการไต่ระดับสิทธิ ตั้งค่า runAsNonRoot: true และปล่อยความสามารถ Linux ทั้งหมดตามค่าเริ่มต้น โดยเพิ่มกลับเฉพาะสิ่งที่จำเป็นอย่างชัดเจน ระบบไฟล์รูทที่อ่านอย่างเดียวจะป้องกันผู้โจมตีจากการเขียนไบนารี่ที่เป็นอันตรายลงในคอนเทนเนอร์ที่ทำงาน การควบคุมเหล่านี้มีความสำคัญเพราะการหลบหนีคอนเทนเนอร์หรือช่องโหว่ของแอปพลิเคชัน ไม่ควรแปลเป็นการประนีประนอมโหนดเต็มรูปแบบ

นโยบายเครือข่ายไม่ใช่ทางเลือก

ตามค่าเริ่มต้น ทุก pod ในคลัสเตอร์ Kubernetes สามารถพูดคุยกับ pod อื่นๆ ได้ โมเดลเครือข่าย flat นั้นเป็นฝันการเคลื่อนไหวด้านข้างสำหรับผู้โจมตี ใช้ทรัพยากร NetworkPolicy เพื่อบังคับใช้การปฏิเสธเริ่มต้นสำหรับการไหลเข้าและออก จากนั้นอนุญาตเฉพาะการไหลของการรับส่งข้อมูลที่แอปพลิเคชันของคุณต้องการ ซึ่งต้องใช้ปลั๊กอิน CNI ที่สนับสนุน NetworkPolicy enforcement—Calico, Cilium และอื่นๆ เติมเต็มบทบาทนี้เนื่องจากโมเดลเครือข่าย Kubernetes พื้นฐานไม่บังคับใช้อะไรด้วยตัวมันเอง การแบ่งเนมสเปซตามขอบเขตความเชื่อถือและการจัดชั้นนโยบายที่ด้านบนช่วยให้คุณมีการป้องกันที่แท้จริงแบบลึก

ความสมบูรณ์ของรูปภาพและห่วงโซ่อุปทาน

การปลดปล่อยไม่หยุดที่การกำหนดค่าเวลาทำงาน—มันเริ่มต้นด้วยสิ่งที่คุณปรับใช้ สแกนรูปภาพคอนเทนเนอร์เพื่อหาช่องโหว่ที่ทราบก่อนที่จะถึงรีจิสทรี และบังคับใช้ว่ามีเพียงรูปภาพที่ลงชื่อและตรวจสอบแล้วเท่านั้นที่สามารถทำงานในคลัสเตอร์ของคุณโดยใช้ตัวควบคุมการยอมรับเช่น Kyverno หรือ OPA Gatekeeper กำหนดแท็กรูปภาพให้กับไดเจสต์แทนแท็กที่เปลี่ยนได้เช่น latest ซึ่งสามารถเปลี่ยนได้อย่างเงียบๆ ใต้คุณ จำกัดรีจิสทรีที่ pod ได้รับอนุญาตให้ดึง ปิดเส้นทางทั่วไปสำหรับการโจมตีห่วงโซ่อุปทานที่รูปภาพที่ประนีประนอมหรือ typosquatted ลื่นไถลเข้าไปในการผลิต

การจัดการความลับเกินกว่าค่าเริ่มต้น Kubernetes

ความลับ Kubernetes ดั้งเดิมนั้นดีกว่าไม่มี แต่มันไม่ใช่วิธีแก้ปัญหาการจัดการความลับที่แท้จริง พิจารณาการบูรณาการตัวจัดการความลับภายนอก—Vault, AWS Secrets Manager หรือคล้ายกัน—และการฉีดความลับในเวลาทำงานแทนที่จะเก็บไว้เป็นวัตถุคลัสเตอร์ หากคุณต้องใช้ความลับดั้งเดิม ตรวจสอบให้แน่ใจว่าการเข้ารหัส etcd เปิดใช้งานและ RBAC จำกัดการเข้าถึงการอ่านอย่างแน่นหนา เนื่องจากปลั๊ก pod หรือผู้ใช้ใดๆ ที่มีสิทธิ์ get ของความลับในเนมสเปซสามารถส่งออกข้อมูลประจำตัว

การตรวจสอบอย่างต่อเนื่อง ไม่ใช่การตั้งค่าครั้งเดียว

การปลดปล่อยการกำหนดค่าเดินไปเมื่อเวลาผ่านไปเนื่องจากเวิร์กโลดใหม่ได้รับการปรับใช้และลำดับความสำคัญเปลี่ยนไปสู่ความเร็วมากกว่าความปลอดภัย เครื่องมือเช่น kube-bench ตรวจสอบการปฏิบัติตามมาตรฐาน CIS Kubernetes Benchmark ขณะที่ kube-hunter สามารถจำลองการเรียกหาข้อมูลของผู้โจมตีต่อคลัสเตอร์ของคุณ บวกการตรวจสอบเหล่านี้เข้าในไปป์ไลน์ CI/CD เพื่อให้การกำหนดค่าผิดพลาดถูกจับเมื่อพวกเขาไปถึงการผลิตแทนที่จะเป็นในระหว่างการเรียกระหว่างการตอบสนองต่อเหตุการณ์

การปลดปล่อย Kubernetes นั้นน้อยกว่าเรื่องของการควบคุมแบบกระสุนเงินเดียวและเพิ่มเติมเกี่ยวกับการจัดชั้นการป้องกันข้ามตัวตน เครือข่าย เวิร์กโลด และห่วงโซ่อุปทาน—เพื่อให้ความล้มเหลวในชั้นเดียวไม่ลดเหลือเพียงการประนีประนอมเต็มรูปแบบ สำหรับข้อมูลเพิ่มเติมเกี่ยวกับรูปแบบความปลอดภัยของโครงสร้างพื้นฐานระบบคลาวด์และเครื่องมือป้องกัน สำรวจส่วนที่เกี่ยวข้องบนแพลตฟอร์ม DEFENSE_GRID ของ Korra Studio