ใน AKS ของเรา พบการแจ้งเตือนที่มีความรุนแรงสูงที่เกี่ยวข้องกับเรื่องนี้ใน Azure Security Center
CAPSYSADMIN มีไว้เพื่ออะไร? พ็อดเปิดใช้งานโดยค่าเริ่มต้นด้วยคุณสมบัตินี้หรือไม่ เพราะเราไม่ได้เปิดใช้งานโดยเฉพาะใน AKS ของเรา? แล้วอะไรคือสาเหตุของการแจ้งเตือนนี้ ? และเราจะแก้ไขการแจ้งเตือนนี้ได้อย่างไร
CAPSYSADMIN มีไว้เพื่ออะไร?
ความสามารถของลีนุกซ์เป็นหัวข้อกว้างๆ ในตัวมันเอง แต่โดยสรุปแล้ว คุณสามารถอ่านได้ ที่นี่:
เริ่มต้นด้วยเคอร์เนล 2.2 ลินุกซ์แบ่งสิทธิ์ ประเพณีที่เกี่ยวข้องกับ superuser เป็นหน่วยที่แตกต่างกัน เรียกว่าความสามารถซึ่งสามารถเปิดใช้งานได้อย่างอิสระและ พิการ. ความสามารถเป็นแอตทริบิวต์ต่อเธรด
กล่าวอีกนัยหนึ่งคือหน่วยเหล่านี้เป็นหน่วยที่แตกต่างกันซึ่งสามารถใช้ควบคุมการเพิ่มระดับสิทธิ์ในระบบปฏิบัติการ Linux ของคุณได้
และ CAP_SYS_ADMIN เป็นหนึ่งในนั้น และอันที่จริงมันค่อนข้างทรงพลังทีเดียว อนุญาตให้ดำเนินการช่วงของการดูแลระบบ ซึ่งเป็นสิทธิพิเศษที่ผู้ใช้ทั่วไปไม่สามารถทำได้ สำหรับรายการทั้งหมด โปรดดูที่ เอกสารนี้ และ Ctrl+ฉ สำหรับ CAP_SYS_ADMIN.
อย่างที่คุณสามารถจินตนาการได้ จากมุมมองด้านความปลอดภัย ไม่แนะนำให้ใช้ความสามารถนี้ เว้นแต่จะมีความจำเป็นอย่างยิ่ง ซึ่งสอดคล้องกับ หลักการสิทธิพิเศษน้อยที่สุด ซึ่งโดยทั่วไปหมายถึง "ให้บัญชีผู้ใช้หรือดำเนินการเฉพาะสิทธิพิเศษที่จำเป็นต่อการปฏิบัติหน้าที่ตามที่ตั้งใจไว้".
แต่ขอกลับไปที่บริบทของ คูเบอร์เนเตส, อคส และ อาซัวร์ เนื่องจากคุณยังคงสงสัยว่าสิ่งที่ฉันกล่าวถึงข้างต้นเหมาะสมอย่างไร
พ็อดเปิดใช้งานโดยค่าเริ่มต้นด้วยคุณสมบัตินี้หรือไม่
ไม่ มันไม่ใช่ เว้นแต่คุณจะเปิดใช้งานอย่างชัดเจนใน พ็อด คำนิยาม. ดังนั้นคำเตือนที่คุณได้รับจึงไม่เกี่ยวกับข้อเท็จจริงที่ว่าพ็อดใดๆ ของคุณใช้ความสามารถนี้ แต่เกี่ยวกับความเป็นไปได้ที่ผู้ใช้ของคุณที่ได้รับอนุญาตให้สร้างพ็อดใหม่ในคุณสมบัตินี้สามารถใช้ได้ อคส กลุ่ม. กล่าวอีกนัยหนึ่ง ในขณะนี้ พ็อดที่ใช้ประโยชน์ CAP_SYS_ADMIN ความสามารถในการสร้างบนของคุณ อคส กลุ่ม.
ด้านล่างนี้คุณสามารถดูตัวอย่างดังกล่าวได้ พ็อด:
api เวอร์ชัน: v1
ชนิด: ฝัก
ข้อมูลเมตา:
ชื่อ: security-context-demo-4
ข้อมูลจำเพาะ:
ตู้คอนเทนเนอร์:
- ชื่อ: วินาที-ctx-4
รูปภาพ: gcr.io/google-samples/node-hello:1.0
บริบทความปลอดภัย:
ความสามารถ:
เพิ่ม: ["SYS_ADMIN"]
สำหรับรายละเอียดเพิ่มเติมโปรดดูที่ ตั้งค่าความสามารถสำหรับคอนเทนเนอร์ ส่วนในเอกสาร kubernetes อย่างเป็นทางการ
คุณสามารถทดสอบได้ง่ายๆ ด้วยตัวคุณเอง แล้วคุณจะเห็นว่าเป็นไปตามข้างต้น พ็อด จะสร้างสำเร็จเพราะตอนนี้ไม่ได้ห้ามไว้แต่อย่างใด
คุณสามารถแล้ว ผู้บริหาร kubectl ไปดังกล่าว พ็อด และตรวจสอบว่า CAP_SYS_ADMIN ความสามารถนั้นถูกใช้โดยมัน เพียงแค่เรียกใช้:
kubectl exec -it security-context-demo-4 -- /bin/bash
เมื่อเชื่อมต่อกับ พ็อด คุณสามารถเรียกใช้:
capsh -- พิมพ์ | grep cap_sys_admin
แล้วคุณจะเห็นว่า cap_sys_admin เปิดใช้งานความสามารถแล้ว
คุณสามารถตรวจสอบสิ่งเดียวกันได้ใน พ็อด ซึ่งไม่ได้ใช้ความสามารถนี้:
api เวอร์ชัน: v1
ชนิด: ฝัก
ข้อมูลเมตา:
ชื่อ: security-context-demo-4-1
ข้อมูลจำเพาะ:
ตู้คอนเทนเนอร์:
- ชื่อ: วินาที-ctx-4
รูปภาพ: gcr.io/google-samples/node-hello:1.0
เมื่อคุณ ผู้บริหาร kubectl เข้าไปในนั้น:
kubectl exec -ti security-context-demo-4-1 -- /bin/bash
และเรียกใช้คำสั่งเดียวกัน:
capsh -- พิมพ์ | grep cap_sys_admin
คุณจะเห็นว่ามันไม่ได้เปิดใช้งานตามค่าเริ่มต้น
แม้ว่า อคส เป็นบริการ kubernetes ที่มีการจัดการ และอันที่จริงแล้ว Microsoft มีเลเยอร์ความปลอดภัยจำนวนมากที่จัดการให้คุณแล้ว คุณยังคงได้รับความรับผิดชอบค่อนข้างหลากหลายเมื่อพูดถึงการจัดการของคุณ อคส กลุ่ม. คุณสามารถเช่น ดำเนินการเพิ่มเติมด้วยตัวคุณเองเพื่อให้ปลอดภัยยิ่งขึ้น
ข่าวดีก็คือคุณจะไม่ถูกทิ้งให้อยู่ตามลำพังกับงานดังกล่าว และคุณได้รับโซลูชันที่พร้อมใช้งานมากมายซึ่งคุณสามารถนำไปใช้ในสภาพแวดล้อม Azure ของคุณได้
หนึ่งในนั้นคือ ศูนย์รักษาความปลอดภัย Azureซึ่งช่วยลดภาระในการตรวจจับภัยคุกคามใหม่ๆ ที่อาจเกิดขึ้นในการตั้งค่าปัจจุบันด้วยตัวคุณเอง ตามที่คุณอ่าน ที่นี่ คำแนะนำ คลัสเตอร์ Kubernetes ไม่ควรให้ความสามารถด้านความปลอดภัยของ CAPSYSADMIN เป็นส่วนหนึ่งของ คำแนะนำใหม่สำหรับการทำให้คลัสเตอร์ Kubernetes แข็งตัว ซึ่งยังอยู่ในการแสดงตัวอย่าง ดังนั้นคุณอาจยังไม่เคยเห็นมาก่อน:
คำแนะนำใหม่สำหรับการทำให้คลัสเตอร์ Kubernetes แข็งตัว (ในตัวอย่าง)
คำแนะนำต่อไปนี้ช่วยให้คุณแข็งแกร่งขึ้น คลัสเตอร์ Kubernetes
- คลัสเตอร์ Kubernetes ไม่ควรใช้เนมสเปซเริ่มต้น - เพื่อป้องกันการเข้าถึงโดยไม่ได้รับอนุญาตสำหรับ ConfigMap, Pod, Secret, ประเภททรัพยากรบริการและ ServiceAccount ป้องกันการใช้งานของ เนมสเปซเริ่มต้นในคลัสเตอร์ Kubernetes
- คลัสเตอร์ Kubernetes ควรปิดใช้ข้อมูลรับรอง API ที่ต่อเชื่อมอัตโนมัติ - เพื่อป้องกันทรัพยากร Pod ที่อาจถูกบุกรุก จากการเรียกใช้คำสั่ง API กับคลัสเตอร์ Kubernetes ให้ปิดใช้งาน การเมานต์ข้อมูลรับรอง API โดยอัตโนมัติ
- คลัสเตอร์ Kubernetes ไม่ควรให้ความสามารถด้านความปลอดภัยของ CAPSYSADMIN
แล้วอะไรคือสาเหตุของการแจ้งเตือนนี้ ?
จากคำถามข้างต้น สามารถตอบคำถามนี้ได้: เพื่อให้คุณมีโอกาสปรับปรุงความปลอดภัยของคลัสเตอร์ kubernetes โดยการลดพื้นผิวการโจมตีที่อาจเกิดขึ้นกับคอนเทนเนอร์ของคุณ แต่ทั้งนี้ทั้งนั้นขึ้นอยู่กับคุณว่าคุณตัดสินใจทำตามคำแนะนำนี้หรือไม่
มากสำหรับส่วนการตรวจจับภัยคุกคาม แล้วในส่วนของการแก้ไขล่ะ ?
และเราจะแก้ไขการแจ้งเตือนนี้ได้อย่างไร
นโยบาย Azure คือคำตอบสำหรับสิ่งนั้น คุณอาจเคยได้ยินเกี่ยวกับพวกเขาแล้ว โชคดีที่การแก้ไขภัยคุกคามเฉพาะนี้ คุณไม่จำเป็นต้องเขียนนโยบายแบบกำหนดเองตามที่ Azure จัดเตรียมไว้ให้ ข้อกำหนดนโยบายในตัวสำหรับบริการ Azure Kubernetes และคุณก็สามารถใช้ประโยชน์จากมันได้ อคส กลุ่ม.
ในคอลัมน์แรกคุณจะได้รับ เชื่อมโยงโดยตรงไปยัง Azure Portal ของคุณซึ่งจะนำคุณไปยังหน้าข้อกำหนดนโยบาย ซึ่งคุณสามารถตรวจสอบรายละเอียดและตำแหน่งที่สามารถกำหนดให้กับการสมัครรับข้อมูลและกลุ่มทรัพยากรซ้ำ:
สำหรับรายละเอียดเพิ่มเติม โปรดดูที่:
ลิงก์ที่มีประโยชน์อื่นๆ:
คนส่วนใหญ่ไม่เข้าใจว่าการถามคำถามมากมายจะปลดล็อกการเรียนรู้และปรับปรุงความสัมพันธ์ระหว่างบุคคล ตัวอย่างเช่น ในการศึกษาของ Alison แม้ว่าผู้คนจะจำได้อย่างแม่นยำว่ามีคำถามกี่ข้อที่ถูกถามในการสนทนา แต่พวกเขาไม่เข้าใจความเชื่อมโยงระหว่างคำถามและความชอบ จากการศึกษาทั้ง 4 เรื่องที่ผู้เข้าร่วมมีส่วนร่วมในการสนทนาด้วยตนเองหรืออ่านบันทึกการสนทนาของผู้อื่น ผู้คนมักไม่ตระหนักว่าการถามคำถามจะมีอิทธิพลหรือมีอิทธิพลต่อระดับมิตรภาพระหว่างผู้สนทนา
