Pavel Selivanov สถาปนิกโซลูชัน Southbridge และอาจารย์สอน Slurm ได้นำเสนอที่ DevOpsConf 2019 การพูดคุยนี้เป็นส่วนหนึ่งของหนึ่งในหัวข้อของหลักสูตรเชิงลึกเกี่ยวกับ Kubernetes “Slurm Mega”
จะจัดขึ้นที่กรุงมอสโกในวันที่ 18-20 พฤศจิกายน
— มอสโก 22-24 พฤศจิกายน
ว่างเสมอ.
ด้านล่างของการตัดคือสำเนาของรายงาน
สวัสดีตอนบ่ายเพื่อนร่วมงานและผู้ที่เห็นอกเห็นใจพวกเขา วันนี้ฉันจะพูดเกี่ยวกับความปลอดภัย
ฉันเห็นว่าวันนี้มีรปภ. มากมายในห้องโถง ฉันขอโทษคุณล่วงหน้าหากฉันใช้คำศัพท์จากโลกแห่งความปลอดภัยไม่ตรงตามที่เป็นธรรมเนียมสำหรับคุณ
มันเกิดขึ้นเมื่อประมาณหกเดือนที่แล้ว ฉันได้พบกับคลัสเตอร์ Kubernetes สาธารณะแห่งหนึ่ง สาธารณะหมายความว่ามีเนมสเปซจำนวนที่ n ในเนมสเปซเหล่านี้มีผู้ใช้ที่แยกออกจากเนมสเปซ ผู้ใช้ทั้งหมดนี้เป็นของบริษัทที่แตกต่างกัน สันนิษฐานว่าควรใช้คลัสเตอร์นี้เป็น CDN นั่นคือ พวกเขาให้คลัสเตอร์แก่คุณ พวกเขาให้คุณมีผู้ใช้ที่นั่น คุณไปที่เนมสเปซของคุณที่นั่น และปรับใช้แนวรบของคุณ
บริษัทเดิมของฉันพยายามขายบริการดังกล่าว และฉันถูกขอให้กระตุ้นคลัสเตอร์เพื่อดูว่าวิธีแก้ปัญหานี้เหมาะสมหรือไม่
ฉันมาที่กลุ่มนี้ ฉันได้รับสิทธิ์อันจำกัด เนมสเปซที่จำกัด พวกที่นั่นเข้าใจว่าความปลอดภัยคืออะไร พวกเขาอ่านเกี่ยวกับการควบคุมการเข้าถึงตามบทบาท (RBAC) ใน Kubernetes และพวกเขาก็บิดเบือนมันจนฉันไม่สามารถเปิดพ็อดแยกจากการปรับใช้ได้ ฉันจำปัญหาที่ฉันพยายามแก้ไขด้วยการเปิดตัวพ็อดโดยไม่ต้องปรับใช้ไม่ได้ แต่ฉันต้องการเปิดตัวเพียงพ็อดจริงๆ เพื่อความโชคดี ฉันตัดสินใจดูว่าฉันมีสิทธิ์ใดบ้างในกลุ่ม สิ่งที่ฉันทำได้ สิ่งที่ฉันทำไม่ได้ และสิ่งที่พวกเขาทำพังที่นั่น ในเวลาเดียวกัน ฉันจะบอกคุณว่าพวกเขากำหนดค่าอะไรไม่ถูกต้องใน RBAC
มันเกิดขึ้นภายในสองนาทีที่ฉันได้รับผู้ดูแลระบบสำหรับคลัสเตอร์ของพวกเขา ดูเนมสเปซใกล้เคียงทั้งหมด และเห็นฝ่ายการผลิตที่กำลังดำเนินการอยู่ของบริษัทที่ได้ซื้อบริการและปรับใช้แล้ว ฉันแทบจะหยุดตัวเองไม่ให้ไปต่อหน้าใครซักคนแล้วใส่คำสาบานลงบนหน้าหลักได้เลย
ฉันจะบอกคุณพร้อมตัวอย่างว่าฉันทำเช่นนี้ได้อย่างไรและจะป้องกันตัวเองจากสิ่งนี้ได้อย่างไร
แต่ก่อนอื่น ให้ฉันแนะนำตัวเองก่อน ฉันชื่อพาเวล เซลิวานอฟ ฉันเป็นสถาปนิกที่ Southbridge ฉันเข้าใจ Kubernetes, DevOps และสิ่งแฟนซีทุกประเภท วิศวกรของ Southbridge และฉันกำลังสร้างทั้งหมดนี้ และฉันกำลังให้คำปรึกษา
นอกเหนือจากกิจกรรมหลักของเราแล้ว เรายังได้เปิดตัวโครงการที่เรียกว่า Slurms เมื่อเร็วๆ นี้ เรากำลังพยายามนำความสามารถของเราในการทำงานกับ Kubernetes ไปสู่คนจำนวนมาก เพื่อสอนให้ผู้อื่นทำงานกับ K8 ด้วยเช่นกัน
วันนี้ฉันจะพูดถึงเรื่องอะไร? หัวข้อของรายงานชัดเจน - เกี่ยวกับความปลอดภัยของคลัสเตอร์ Kubernetes แต่ฉันอยากจะบอกทันทีว่าหัวข้อนี้ใหญ่มาก - ดังนั้นฉันจึงอยากชี้แจงทันทีว่าฉันจะไม่พูดถึงอะไรอย่างแน่นอน ฉันจะไม่พูดถึงคำศัพท์ที่ถูกแฮ็กซึ่งมีการใช้แล้วบนอินเทอร์เน็ตเป็นร้อยครั้ง RBAC และใบรับรองทุกประเภท
ฉันจะพูดถึงสิ่งที่ทำให้ฉันและเพื่อนร่วมงานเจ็บปวดเกี่ยวกับการรักษาความปลอดภัยในคลัสเตอร์ Kubernetes เราเห็นปัญหาเหล่านี้ทั้งในหมู่ผู้ให้บริการที่ให้บริการคลัสเตอร์ Kubernetes และในกลุ่มลูกค้าที่มาหาเรา และแม้กระทั่งจากลูกค้าที่มาหาเราจากบริษัทที่ปรึกษาที่ปรึกษาอื่นๆ นั่นคือขนาดของโศกนาฏกรรมนั้นใหญ่มากจริงๆ
มีสามประเด็นที่ฉันจะพูดถึงในวันนี้:
- สิทธิ์ผู้ใช้เทียบกับสิทธิ์พ็อด สิทธิ์ของผู้ใช้และสิทธิ์ของพ็อดนั้นไม่เหมือนกัน
- รวบรวมข้อมูลเกี่ยวกับคลัสเตอร์ ฉันจะแสดงให้เห็นว่าคุณสามารถรวบรวมข้อมูลทั้งหมดที่คุณต้องการจากคลัสเตอร์โดยไม่ต้องมีสิทธิ์พิเศษในคลัสเตอร์นี้
- การโจมตี DoS บนคลัสเตอร์ หากเราไม่สามารถรวบรวมข้อมูลได้เราจะสามารถใส่คลัสเตอร์ได้ทุกกรณี ฉันจะพูดเกี่ยวกับการโจมตี DoS ในองค์ประกอบการควบคุมคลัสเตอร์
อีกเรื่องทั่วไปที่ฉันจะพูดถึงคือสิ่งที่ฉันทดสอบทั้งหมดนี้ ซึ่งฉันสามารถพูดได้อย่างแน่นอนว่ามันใช้งานได้ทั้งหมด
เราใช้การติดตั้งคลัสเตอร์ Kubernetes โดยใช้ Kubespray เป็นพื้นฐาน หากใครไม่ทราบ จริงๆ แล้วนี่คือชุดบทบาทของ Ansible เราใช้มันในการทำงานของเราอย่างต่อเนื่อง สิ่งที่ดีคือคุณสามารถม้วนมันได้ทุกที่ - คุณสามารถม้วนมันลงบนเศษเหล็กหรือก้อนเมฆที่ไหนสักแห่งก็ได้ วิธีการติดตั้งวิธีเดียวใช้ได้กับทุกสิ่งโดยหลักการแล้ว
ในคลัสเตอร์นี้ ฉันจะมี Kubernetes v1.14.5 คลัสเตอร์ Cube ทั้งหมดซึ่งเราจะพิจารณานั้นแบ่งออกเป็นเนมสเปซ แต่ละเนมสเปซเป็นของทีมที่แยกจากกัน และสมาชิกในทีมนี้สามารถเข้าถึงแต่ละเนมสเปซได้ พวกเขาไม่สามารถไปที่เนมสเปซอื่นได้ แต่จะไปยังเนมสเปซของพวกเขาเองเท่านั้น แต่มีบัญชีผู้ดูแลระบบบางบัญชีที่มีสิทธิ์ในคลัสเตอร์ทั้งหมด
ฉันสัญญาว่าสิ่งแรกที่เราจะทำคือรับสิทธิ์ของผู้ดูแลระบบในคลัสเตอร์ เราต้องการพ็อดที่เตรียมไว้เป็นพิเศษที่จะทำลายคลัสเตอร์ Kubernetes สิ่งที่เราต้องทำคือนำไปใช้กับคลัสเตอร์ Kubernetes
kubectl apply -f pod.yamlพ็อดนี้จะมาถึงหนึ่งในต้นแบบของคลัสเตอร์ Kubernetes และหลังจากนี้คลัสเตอร์จะส่งคืนไฟล์ชื่อ admin.conf ให้เราอย่างมีความสุข ใน Cube ไฟล์นี้จะจัดเก็บใบรับรองผู้ดูแลระบบทั้งหมด และในเวลาเดียวกันก็กำหนดค่า API ของคลัสเตอร์ ฉันคิดว่า 98% ของคลัสเตอร์ Kubernetes จะทำให้ผู้ดูแลระบบเข้าถึงคลัสเตอร์ Kubernetes ได้อย่างง่ายดายขนาดนี้
ขอย้ำอีกครั้งว่าพ็อดนี้สร้างโดยนักพัฒนารายหนึ่งในคลัสเตอร์ของคุณที่มีสิทธิ์เข้าถึงเพื่อปรับใช้ข้อเสนอของเขาในเนมสเปซขนาดเล็กแห่งเดียว ซึ่งทั้งหมดถูกยึดโดย RBAC เขาไม่มีสิทธิ แต่อย่างไรก็ตามใบรับรองก็ถูกส่งคืน
และตอนนี้เกี่ยวกับพ็อดที่เตรียมไว้เป็นพิเศษ เรารันมันบนรูปภาพใดก็ได้ ลองใช้ debian:jessie เป็นตัวอย่าง
เรามีสิ่งนี้:
tolerations:
- effect: NoSchedule
operator: Exists
nodeSelector:
node-role.kubernetes.io/master: "" ความอดทนคืออะไร? ผู้เชี่ยวชาญในคลัสเตอร์ Kubernetes มักจะถูกทำเครื่องหมายด้วยสิ่งที่เรียกว่ามลทิน และสาระสำคัญของ "การติดเชื้อ" นี้คือมันบอกว่าไม่สามารถกำหนดพ็อดให้กับโหนดหลักได้ แต่ไม่มีใครสนใจที่จะระบุในฝักว่าสามารถทนต่อ "การติดเชื้อ" ได้ ส่วน Toleration บอกว่าหากบางโหนดมี NoSchedule แสดงว่าโหนดของเราจะทนต่อการติดไวรัสดังกล่าวได้ และไม่มีปัญหาใดๆ
นอกจากนี้ เรายังกล่าวอีกว่าอันเดอร์ของเราไม่เพียงแต่มีความอดทน แต่ยังต้องการกำหนดเป้าหมายไปที่ปรมาจารย์โดยเฉพาะอีกด้วย เพราะปรมาจารย์มีของอร่อยที่สุดที่เราต้องการ - ใบรับรองทั้งหมด ดังนั้นเราจึงพูดว่า nodeSelector - และเรามีป้ายกำกับมาตรฐานบนต้นแบบ ซึ่งช่วยให้คุณสามารถเลือกโหนดเหล่านั้นที่เป็นต้นแบบจากโหนดทั้งหมดในคลัสเตอร์ได้อย่างแน่นอน
ด้วยสองส่วนนี้เขาจะมาหาอาจารย์อย่างแน่นอน และเขาจะได้รับอนุญาตให้อยู่ที่นั่น
แต่แค่มาหาอาจารย์ยังไม่เพียงพอสำหรับเรา สิ่งนี้จะไม่ให้อะไรเราเลย ต่อไปเราจะมีสองสิ่งนี้:
hostNetwork: true
hostPID: true เราระบุว่าพ็อดของเราซึ่งเราเปิดตัวจะอยู่ในเนมสเปซเคอร์เนล ในเนมสเปซเครือข่าย และในเนมสเปซ PID เมื่อพ็อดถูกเปิดใช้งานบนต้นแบบ มันจะสามารถดูอินเทอร์เฟซที่ใช้งานจริงทั้งหมดของโหนดนี้ ฟังการรับส่งข้อมูลทั้งหมด และดู PID ของกระบวนการทั้งหมด
แล้วมันเป็นเรื่องเล็กๆ น้อยๆ ใช้ etcd และอ่านสิ่งที่คุณต้องการ
สิ่งที่น่าสนใจที่สุดคือฟีเจอร์ Kubernetes ซึ่งมีอยู่ในค่าเริ่มต้น
volumeMounts:
- mountPath: /host
name: host
volumes:
- hostPath:
path: /
type: Directory
name: host และสาระสำคัญของมันคือเราสามารถพูดได้ในพ็อดที่เราเปิดตัว แม้ว่าจะไม่มีสิทธิ์ในคลัสเตอร์นี้ก็ตาม ว่าเราต้องการสร้างวอลุ่มประเภท hostPath นี่หมายถึงการรับเส้นทางจากโฮสต์ที่เราจะเปิดตัว - และถือเป็นปริมาณ จากนั้นเราเรียกมันว่าชื่อ: โฮสต์ เราเมานต์ hostPath ทั้งหมดนี้ภายในพ็อด ในตัวอย่างนี้ ไปยังไดเร็กทอรี /host
ฉันจะทำซ้ำอีกครั้ง เราบอกให้พ็อดมาหามาสเตอร์ รับโฮสต์เครือข่ายและโฮสต์PID ที่นั่น และติดตั้งรูททั้งหมดของมาสเตอร์ภายในพ็อดนี้
คุณเข้าใจว่าใน Debian เรามี bash ทำงานอยู่ และ bash นี้ทำงานภายใต้รูท นั่นคือเราเพิ่งได้รับการรูทบนต้นแบบ โดยไม่มีสิทธิ์ใดๆ ในคลัสเตอร์ Kubernetes
จากนั้น งานทั้งหมดคือไปที่ไดเร็กทอรีย่อย /host /etc/kubernetes/pki หากจำไม่ผิด ให้รับใบรับรองหลักทั้งหมดของคลัสเตอร์ที่นั่น จากนั้นจึงกลายเป็นผู้ดูแลระบบคลัสเตอร์
หากคุณมองด้วยวิธีนี้ นี่คือสิทธิ์ที่อันตรายที่สุดในพ็อด ไม่ว่าผู้ใช้จะมีสิทธิ์ใดก็ตาม:
หากฉันมีสิทธิ์เรียกใช้พ็อดในเนมสเปซบางส่วนของคลัสเตอร์ พ็อดนี้จะมีสิทธิ์เหล่านี้ตามค่าเริ่มต้น ฉันสามารถเรียกใช้พ็อดที่ได้รับสิทธิพิเศษได้ และโดยทั่วไปแล้วสิ่งเหล่านี้ล้วนเป็นสิทธิ์ทั้งหมด โดยในทางปฏิบัติแล้วสามารถรูทบนโหนดได้
สิ่งที่ฉันชอบคือผู้ใช้รูท และ Kubernetes มีตัวเลือก Run As Non-Root นี้ นี่คือการป้องกันประเภทหนึ่งจากแฮกเกอร์ คุณรู้หรือไม่ว่า “ไวรัสมอลโดวา” คืออะไร? หากคุณเป็นแฮ็กเกอร์และมาที่คลัสเตอร์ Kubernetes ของฉันอย่างกระทันหัน พวกเราที่เป็นผู้ดูแลระบบที่ไม่ดีถามว่า: “โปรดระบุในพ็อดของคุณว่าคุณจะแฮ็กคลัสเตอร์ของฉัน ทำงานแบบไม่ใช่รูท มิฉะนั้น มันจะเกิดขึ้นหากคุณรันกระบวนการในพ็อดของคุณภายใต้รูท และมันจะง่ายมากสำหรับคุณที่จะแฮ็กฉัน โปรดป้องกันตัวเองจากตัวคุณเอง”
ในความคิดของฉัน ปริมาณเส้นทางโฮสต์คือวิธีที่เร็วที่สุดในการรับผลลัพธ์ที่ต้องการจากคลัสเตอร์ Kubernetes
แต่จะทำอย่างไรกับทั้งหมดนี้?
ความคิดที่ผู้ดูแลระบบทั่วไปที่พบกับ Kubernetes ควรคิดคือ: “ใช่ ฉันบอกคุณแล้วว่า Kubernetes ใช้งานไม่ได้ มีรูอยู่ในนั้น และ Cube ทั้งหมดก็เป็นเรื่องไร้สาระ” ในความเป็นจริงมีสิ่งเช่นเอกสารและถ้าคุณดูที่นั่นก็มีส่วน .
นี่คือวัตถุ yaml ซึ่งเราสามารถสร้างได้ในคลัสเตอร์ Kubernetes ซึ่งควบคุมด้านความปลอดภัยโดยเฉพาะในคำอธิบายของพ็อด นั่นคือในความเป็นจริง จะควบคุมสิทธิ์ในการใช้โฮสต์เครือข่าย, hostPID, วอลุ่มบางประเภทที่อยู่ในพ็อดเมื่อเริ่มต้นระบบ ด้วยความช่วยเหลือของ Pod Security Policy คุณสามารถอธิบายทั้งหมดนี้ได้
สิ่งที่น่าสนใจที่สุดเกี่ยวกับนโยบายความปลอดภัยของ Pod ก็คือในคลัสเตอร์ Kubernetes ตัวติดตั้ง PSP ทั้งหมดไม่ได้อธิบายไว้แต่อย่างใด แต่จะถูกปิดใช้งานโดยค่าเริ่มต้น นโยบายความปลอดภัยของพ็อดเปิดใช้งานโดยใช้ปลั๊กอินการรับเข้า
เอาล่ะ มาปรับใช้นโยบายความปลอดภัยของ Pod ในคลัสเตอร์กันดีกว่า สมมติว่าเรามีพ็อดบริการบางส่วนในเนมสเปซ ซึ่งมีเพียงผู้ดูแลระบบเท่านั้นที่สามารถเข้าถึงได้ สมมติว่าในกรณีอื่นๆ พ็อดมีสิทธิ์ที่จำกัด เนื่องจากนักพัฒนาซอฟต์แวร์ส่วนใหญ่ไม่จำเป็นต้องเรียกใช้พ็อดที่ได้รับสิทธิพิเศษในคลัสเตอร์ของคุณ
และทุกอย่างดูเหมือนจะดีกับเรา และคลัสเตอร์ Kubernetes ของเราไม่สามารถถูกแฮ็กได้ภายในสองนาที
มีปัญหาเกิดขึ้น เป็นไปได้มากว่าถ้าคุณมีคลัสเตอร์ Kubernetes ระบบจะติดตั้งการตรวจสอบบนคลัสเตอร์ของคุณ ฉันอยากจะทำนายด้วยซ้ำว่าถ้าคลัสเตอร์ของคุณมีการตรวจสอบ มันจะเรียกว่าโพร
สิ่งที่ฉันกำลังจะบอกคุณจะใช้ได้กับทั้งผู้ดำเนินการ Prometheus และ Prometheus ที่ส่งมอบในรูปแบบที่บริสุทธิ์ คำถามก็คือ หากฉันไม่สามารถนำผู้ดูแลระบบเข้าสู่คลัสเตอร์ได้เร็วขนาดนี้ นั่นหมายความว่าฉันต้องตรวจสอบเพิ่มเติม และฉันสามารถค้นหาด้วยความช่วยเหลือจากการติดตามของคุณ
ทุกคนอาจอ่านบทความเดียวกันเกี่ยวกับHabré และการมอนิเตอร์อยู่ในเนมสเปซการมอนิเตอร์ แผนภูมิ Helm เรียกว่าเหมือนกันสำหรับทุกคน ฉันเดาว่าถ้าคุณ helm install stable/prometheus คุณจะจบลงด้วยชื่อที่เหมือนกัน และเป็นไปได้มากว่าฉันจะไม่ต้องเดาชื่อ DNS ในคลัสเตอร์ของคุณด้วยซ้ำ เพราะมันเป็นมาตรฐาน
ต่อไปเรามี dev ns บางตัวซึ่งคุณสามารถเรียกใช้พ็อดบางตัวได้ และจากพ็อดนี้ มันง่ายมากที่จะทำสิ่งนี้:
$ curl http://prometheus-kube-state-metrics.monitoring prometheus-kube-state-metrics เป็นหนึ่งในผู้ส่งออก Prometheus ที่รวบรวมตัววัดจาก Kubernetes API เอง มีข้อมูลจำนวนมาก สิ่งใดที่ทำงานอยู่ในคลัสเตอร์ของคุณ ข้อมูลคืออะไร คุณมีปัญหาอะไรบ้าง
เป็นตัวอย่างง่ายๆ:
kube_pod_container_info{namespace=“kube-system”,pod=”kube-apiserver-k8s- 1″,container=”kube-apiserver”,รูปภาพ=
"gcr.io/google-containers/kube-apiserver:v1.14.5"
,image_id=»docker-pullable://gcr.io/google-containers/kube- apiserver@sha256:e29561119a52adad9edc72bfe0e7fcab308501313b09bf99df4a96 38ee634989″,container_id=»docker://7cbe7b1fea33f811fdd8f7e0e079191110268f2 853397d7daf08e72c22d3cf8b»} 1
ด้วยการขอขดอย่างง่ายจากพ็อดที่ไม่มีสิทธิพิเศษ คุณจะได้รับข้อมูลต่อไปนี้ หากคุณไม่ทราบว่าคุณใช้ Kubernetes เวอร์ชันใด ระบบจะแจ้งให้คุณทราบได้อย่างง่ายดาย
และสิ่งที่น่าสนใจที่สุดก็คือ นอกเหนือจากการเข้าถึง kube-state-metrics แล้ว คุณยังสามารถเข้าถึง Prometheus ได้โดยตรงได้อย่างง่ายดายเช่นเดียวกัน คุณสามารถรวบรวมเมตริกได้จากที่นั่น คุณสามารถสร้างตัวชี้วัดได้จากที่นั่น ในทางทฤษฎีแล้ว คุณสามารถสร้างแบบสอบถามดังกล่าวจากคลัสเตอร์ใน Prometheus ซึ่งจะปิดใช้งานได้ และการตรวจสอบของคุณจะหยุดทำงานจากคลัสเตอร์โดยสิ้นเชิง
และนี่คือคำถามที่เกิดขึ้นว่ามีการตรวจสอบภายนอกติดตามการตรวจสอบของคุณหรือไม่ ฉันเพิ่งได้รับโอกาสในการทำงานในคลัสเตอร์ Kubernetes โดยไม่มีผลกระทบใดๆ ต่อตัวฉันเอง คุณจะไม่รู้ด้วยซ้ำว่าฉันทำงานอยู่ที่นั่น เนื่องจากไม่มีการตรวจสอบอีกต่อไป
เช่นเดียวกับ PSP รู้สึกว่าปัญหาคือเทคโนโลยีสุดล้ำเหล่านี้ เช่น Kubernetes, Prometheus พวกมันใช้งานไม่ได้และเต็มไปด้วยช่องโหว่ ไม่เชิง.
มีสิ่งนั้น - .
หากคุณเป็นผู้ดูแลระบบทั่วไป เป็นไปได้มากว่าคุณจะรู้เกี่ยวกับนโยบายเครือข่ายว่านี่เป็นเพียง yaml อื่นซึ่งมีจำนวนมากในคลัสเตอร์อยู่แล้ว และนโยบายเครือข่ายบางอย่างก็ไม่จำเป็นอย่างแน่นอน และแม้ว่าคุณจะอ่านว่านโยบายเครือข่ายคืออะไร แต่เป็นไฟร์วอลล์ yaml ของ Kubernetes แต่ก็ช่วยให้คุณสามารถจำกัดสิทธิ์การเข้าถึงระหว่างเนมสเปซระหว่างพ็อดได้ จากนั้นคุณก็ตัดสินใจอย่างแน่นอนว่าไฟร์วอลล์ในรูปแบบ yaml ใน Kubernetes นั้นมีพื้นฐานมาจากนามธรรมถัดไป ... ไม่ ไม่ นี่ไม่จำเป็นอย่างแน่นอน
แม้ว่าคุณจะไม่ได้บอกผู้เชี่ยวชาญด้านความปลอดภัยว่าการใช้ Kubernetes คุณสามารถสร้างไฟร์วอลล์ที่ง่ายและไม่ซับซ้อนได้ และไฟร์วอลล์ที่ละเอียดมากในนั้น หากพวกเขายังไม่รู้เรื่องนี้และไม่รบกวนคุณ: “เอาล่ะ ให้ฉันหน่อย…” จากนั้น ไม่ว่าในกรณีใด คุณจะต้องมีนโยบายเครือข่ายเพื่อบล็อกการเข้าถึงสถานที่ให้บริการบางแห่งที่สามารถดึงออกจากคลัสเตอร์ของคุณได้ โดยไม่ได้รับอนุญาตใดๆ
ดังตัวอย่างที่ฉันให้ไป คุณสามารถดึงเมตริกสถานะ kube จากเนมสเปซใดๆ ในคลัสเตอร์ Kubernetes ได้โดยไม่ต้องมีสิทธิ์ใดๆ ในการดำเนินการดังกล่าว นโยบายเครือข่ายมีการเข้าถึงแบบปิดจากเนมสเปซอื่นๆ ทั้งหมดไปยังเนมสเปซการตรวจสอบ เพียงเท่านี้: ไม่มีสิทธิ์เข้าถึง ไม่มีปัญหา ในแผนภูมิทั้งหมดที่มีอยู่ ทั้ง Prometheus มาตรฐานและ Prometheus ที่อยู่ในตัวดำเนินการ มีเพียงตัวเลือกในค่า helm เพื่อเปิดใช้งานนโยบายเครือข่ายสำหรับพวกเขา คุณเพียงแค่ต้องเปิดใช้งานและมันก็จะทำงานได้
มีปัญหาหนึ่งจริงๆที่นี่ เนื่องจากเป็นผู้ดูแลระบบที่มีหนวดเคราธรรมดา คุณจึงมักตัดสินใจว่าไม่จำเป็นต้องใช้นโยบายเครือข่าย และหลังจากอ่านบทความทุกประเภทเกี่ยวกับแหล่งข้อมูล เช่น Habr คุณตัดสินใจว่าผ้าสักหลาด โดยเฉพาะอย่างยิ่งในโหมดโฮสต์เกตเวย์ เป็นสิ่งที่ดีที่สุดที่คุณสามารถเลือกได้
จะทำอย่างไร?
คุณสามารถลองปรับใช้โซลูชันเครือข่ายที่คุณมีในคลัสเตอร์ Kubernetes ของคุณอีกครั้ง และลองแทนที่ด้วยสิ่งที่ใช้งานได้ดีกว่า ตัวอย่างเช่นสำหรับผ้าดิบเดียวกัน แต่ฉันอยากจะบอกทันทีว่างานในการเปลี่ยนโซลูชันเครือข่ายในคลัสเตอร์การทำงานของ Kubernetes นั้นค่อนข้างไม่สำคัญ ฉันแก้ไขมันสองครั้ง (ตามทฤษฎีทั้งสองครั้ง) แต่เรายังแสดงวิธีการทำที่ Slurms ด้วย สำหรับนักเรียนของเรา เราได้แสดงวิธีเปลี่ยนโซลูชันเครือข่ายในคลัสเตอร์ Kubernetes โดยหลักการแล้ว คุณสามารถลองตรวจสอบให้แน่ใจว่าไม่มีการหยุดทำงานบนคลัสเตอร์การผลิต แต่คุณคงไม่ประสบความสำเร็จ
และปัญหาก็แก้ไขได้ง่ายมากจริงๆ มีใบรับรองอยู่ในคลัสเตอร์ และคุณทราบว่าใบรับรองของคุณจะหมดอายุในหนึ่งปี และโดยปกติแล้วจะเป็นโซลูชันปกติที่มีใบรับรองในคลัสเตอร์ - ทำไมเราถึงต้องกังวล เราจะสร้างคลัสเตอร์ใหม่ที่อยู่ใกล้เคียง ปล่อยให้คลัสเตอร์เก่าเน่าเสีย และปรับใช้ทุกอย่างอีกครั้ง จริงอยู่ที่เมื่อมันเน่าเราต้องนั่งสักวันหนึ่ง แต่นี่คือคลัสเตอร์ใหม่
เมื่อคุณยกคลัสเตอร์ใหม่ ในเวลาเดียวกันก็ใส่ผ้าดิบแทนผ้าสักหลาด
จะทำอย่างไรถ้าใบรับรองของคุณออกเป็นเวลาร้อยปี และคุณจะไม่ปรับใช้คลัสเตอร์อีกครั้ง มีสิ่งเช่น Kube-RBAC-Proxy นี่เป็นการพัฒนาที่ยอดเยี่ยมมาก โดยช่วยให้คุณสามารถฝังตัวเองเป็นคอนเทนเนอร์ไซด์คาร์ให้กับพ็อดใดๆ ในคลัสเตอร์ Kubernetes ได้ และจริงๆ แล้วจะเพิ่มการอนุญาตให้กับพ็อดนี้ผ่าน RBAC ของ Kubernetes เอง
มีปัญหาหนึ่งคือ ก่อนหน้านี้ โซลูชัน Kube-RBAC-Proxy นี้ถูกสร้างขึ้นใน Prometheus ของผู้ปฏิบัติงาน แต่แล้วเขาก็จากไป ขณะนี้เวอร์ชันที่ทันสมัยขึ้นอยู่กับว่าคุณมีนโยบายเครือข่ายและปิดโดยใช้นโยบายเหล่านี้ ดังนั้นเราจะต้องเขียนแผนภูมิใหม่เล็กน้อย จริงๆแล้วถ้าไป. มีตัวอย่างวิธีใช้สิ่งนี้เป็นรถเทียมข้างรถจักรยานยนต์ และแผนภูมิจะต้องเขียนใหม่เพียงเล็กน้อย
มีปัญหาเล็กๆ น้อยๆ อีกอย่างหนึ่ง Prometheus ไม่ใช่เพียงคนเดียวที่แจกหน่วยวัดให้กับใครก็ตาม ส่วนประกอบคลัสเตอร์ Kubernetes ทั้งหมดของเรายังสามารถส่งคืนตัววัดของตนเองได้เช่นกัน
แต่อย่างที่ฉันได้กล่าวไปแล้ว หากคุณไม่สามารถเข้าถึงคลัสเตอร์และรวบรวมข้อมูลได้ อย่างน้อยคุณก็สามารถสร้างความเสียหายได้
ดังนั้น ฉันจะแสดงสองวิธีอย่างรวดเร็วว่าคลัสเตอร์ Kubernetes สามารถถูกทำลายได้อย่างไร
คุณจะหัวเราะเมื่อฉันบอกคุณ นี่เป็นสองกรณีในชีวิตจริง
วิธีที่หนึ่ง การสิ้นเปลืองทรัพยากร
เปิดตัวพ็อดพิเศษอีกอัน มันก็จะมีภาคประมาณนี้
resources:
requests:
cpu: 4
memory: 4Gi ดังที่คุณทราบ คำขอคือจำนวน CPU และหน่วยความจำที่สงวนไว้บนโฮสต์สำหรับพ็อดเฉพาะที่มีคำขอ หากเรามีโฮสต์แบบสี่คอร์ในคลัสเตอร์ Kubernetes และพ็อด CPU สี่ตัวมาถึงที่นั่นพร้อมคำขอ นั่นหมายความว่าจะไม่มีพ็อดที่มีคำขอมาที่โฮสต์นี้อีกต่อไป
หากฉันรันพ็อดดังกล่าว ฉันจะรันคำสั่ง:
$ kubectl scale special-pod --replicas=...จากนั้นจะไม่มีใครสามารถปรับใช้กับคลัสเตอร์ Kubernetes ได้ เพราะโหนดทั้งหมดจะหมดคำขอ ดังนั้นฉันจะหยุดคลัสเตอร์ Kubernetes ของคุณ หากฉันทำสิ่งนี้ในตอนเย็น ฉันสามารถหยุดการปรับใช้เป็นเวลานานได้
หากเราดูเอกสาร Kubernetes อีกครั้ง เราจะเห็นสิ่งนี้เรียกว่า Limit Range มันตั้งค่าทรัพยากรสำหรับวัตถุคลัสเตอร์ คุณสามารถเขียนออบเจ็กต์ Limit Range ใน yaml แล้วนำไปใช้กับเนมสเปซบางตัว จากนั้นในเนมสเปซนี้ คุณสามารถพูดได้ว่าคุณมีทรัพยากรเริ่มต้น สูงสุด และต่ำสุดสำหรับพ็อด
ด้วยความช่วยเหลือดังกล่าว เราสามารถจำกัดผู้ใช้ในเนมสเปซผลิตภัณฑ์เฉพาะของทีมให้สามารถระบุสิ่งที่น่ารังเกียจทุกประเภทบนพ็อดของพวกเขาได้ แต่น่าเสียดาย แม้ว่าคุณจะบอกผู้ใช้ว่าพวกเขาไม่สามารถเปิดพ็อดพร้อมกับคำขอสำหรับ CPU มากกว่าหนึ่งตัวได้ แต่ก็มีคำสั่งขนาดที่ยอดเยี่ยม หรือพวกเขาสามารถปรับขนาดผ่านแดชบอร์ดได้
และนี่คือที่มาของวิธีที่ 11 เราเปิดตัว 111 พ็อด นั่นคือหนึ่งหมื่นเอ็ดพันล้าน ไม่ใช่เพราะฉันคิดเลขมาได้ขนาดนี้ แต่เป็นเพราะฉันเห็นเอง
เรื่องจริง. ตอนเย็นฉันกำลังจะออกจากออฟฟิศ ฉันเห็นนักพัฒนากลุ่มหนึ่งนั่งอยู่ตรงมุมห้อง กำลังทำอะไรบางอย่างกับแล็ปท็อปอย่างบ้าคลั่ง ฉันขึ้นไปหาพวกเขาแล้วถามว่า:“ เกิดอะไรขึ้นกับคุณ?”
ก่อนหน้านี้เล็กน้อย ประมาณเก้าโมงเย็น นักพัฒนาคนหนึ่งกำลังเตรียมตัวกลับบ้าน และฉันก็ตัดสินใจว่า: “ตอนนี้ฉันจะลดขนาดใบสมัครของฉันลงเหลือหนึ่งรายการ” ฉันกดไปอันหนึ่ง แต่อินเทอร์เน็ตช้าลงเล็กน้อย เขากดอันหนึ่งอีกครั้ง เขากดอันหนึ่งแล้วคลิก Enter ฉันแหย่ทุกสิ่งที่ฉันทำได้ จากนั้นอินเทอร์เน็ตก็มีชีวิตขึ้นมา - และทุกอย่างก็เริ่มลดขนาดลงเหลือเพียงเท่านี้
จริงอยู่ เรื่องราวนี้ไม่ได้เกิดขึ้นใน Kubernetes ตอนนั้นคือ Nomad มันจบลงด้วยความจริงที่ว่าหลังจากหนึ่งชั่วโมงของความพยายามของเราที่จะหยุด Nomad จากความพยายามอย่างต่อเนื่องในการปรับขนาด Nomad ก็ตอบว่าเขาจะไม่หยุดการปรับขนาดและจะไม่ทำอะไรอย่างอื่น “ผมเหนื่อยแล้ว ผมจะไปแล้ว” และเขาก็ขดตัว
โดยปกติแล้วฉันพยายามทำเช่นเดียวกันกับ Kubernetes Kubernetes ไม่พอใจกับจำนวนพ็อดจำนวน 1 พันล้านตัว เขากล่าวว่า "ฉันทำไม่ได้ เกินอุปกรณ์ป้องกันปากภายใน” แต่ 000 พ็อดสามารถทำได้
เพื่อตอบสนองต่อหนึ่งพันล้าน Cube จึงไม่ถอยกลับเข้าไปในตัวมันเอง เขาเริ่มปรับขนาดจริงๆ ยิ่งกระบวนการดำเนินไปไกลเท่าไร เขาก็ยิ่งใช้เวลาในการสร้างพ็อดใหม่มากขึ้นเท่านั้น แต่กระบวนการยังคงดำเนินต่อไป ปัญหาเดียวคือหากฉันสามารถเปิดใช้พ็อดได้ไม่จำกัดในเนมสเปซของฉัน แม้ว่าจะไม่มีคำขอและขีดจำกัด ฉันก็สามารถเปิดพ็อดจำนวนมากได้ด้วยงานบางอย่างที่โหนดจะเริ่มเพิ่มจำนวนในหน่วยความจำใน CPU ด้วยความช่วยเหลือของงานเหล่านี้ เมื่อฉันเปิดตัวพ็อดจำนวนมาก ข้อมูลจากพ็อดเหล่านั้นควรถูกจัดเก็บ กล่าวคือ ฯลฯ และเมื่อมีข้อมูลมากเกินไป พื้นที่จัดเก็บข้อมูลก็เริ่มกลับมาช้าเกินไป และ Kubernetes ก็เริ่มหมองคล้ำ
และอีกปัญหาหนึ่ง... ดังที่คุณทราบ องค์ประกอบการควบคุม Kubernetes ไม่ใช่สิ่งสำคัญเพียงอย่างเดียว แต่มีหลายองค์ประกอบ โดยเฉพาะอย่างยิ่ง มีผู้จัดการคอนโทรลเลอร์ ตัวกำหนดเวลา และอื่นๆ คนเหล่านี้ทั้งหมดจะเริ่มทำงานที่ไม่จำเป็นและโง่เขลาไปพร้อมๆ กัน ซึ่งเมื่อเวลาผ่านไปจะเริ่มใช้เวลามากขึ้นเรื่อยๆ ผู้จัดการคอนโทรลเลอร์จะสร้างพ็อดใหม่ ผู้วางกำหนดการจะพยายามค้นหาโหนดใหม่ให้พวกเขา โหนดใหม่ในคลัสเตอร์ของคุณมีแนวโน้มว่าจะหมดเร็วๆ นี้ คลัสเตอร์ Kubernetes จะเริ่มทำงานช้าลงเรื่อยๆ
แต่ฉันตัดสินใจที่จะไปไกลกว่านี้ อย่างที่คุณทราบ ใน Kubernetes มีสิ่งที่เรียกว่าบริการ ตามค่าเริ่มต้นในคลัสเตอร์ของคุณ มีแนวโน้มว่าบริการจะทำงานโดยใช้ตาราง IP
ตัวอย่างเช่น หากคุณใช้งานหนึ่งพันล้านพ็อด แล้วใช้สคริปต์เพื่อบังคับให้ Kubernetis สร้างบริการใหม่:
for i in {1..1111111}; do
kubectl expose deployment test --port 80
--overrides="{"apiVersion": "v1",
"metadata": {"name": "nginx$i"}}";
done บนโหนดทั้งหมดของคลัสเตอร์ กฎ iptables ใหม่จะถูกสร้างขึ้นพร้อมกันมากขึ้นเรื่อยๆ ยิ่งไปกว่านั้น จะมีการสร้างกฎ iptable หนึ่งพันล้านกฎสำหรับแต่ละบริการ
ฉันตรวจสอบทั้งหมดนี้หลายพันถึงสิบ และปัญหาก็คือเมื่อถึงเกณฑ์นี้แล้ว การทำ ssh กับโหนดค่อนข้างมีปัญหา เพราะแพ็กเก็ตผ่านหลายลูกโซ่เริ่มรู้สึกไม่ค่อยดี
และทั้งหมดนี้ก็แก้ไขได้ด้วยความช่วยเหลือของ Kubernetes มีวัตถุโควต้าทรัพยากรดังกล่าว ตั้งค่าจำนวนทรัพยากรและอ็อบเจ็กต์ที่มีอยู่สำหรับเนมสเปซในคลัสเตอร์ เราสามารถสร้างวัตถุ yaml ในแต่ละเนมสเปซของคลัสเตอร์ Kubernetes เมื่อใช้ออบเจ็กต์นี้ เราสามารถพูดได้ว่าเรามีคำขอและขีดจำกัดจำนวนหนึ่งที่จัดสรรไว้สำหรับเนมสเปซนี้ จากนั้นเราสามารถพูดได้ว่าในเนมสเปซนี้ คุณสามารถสร้างบริการได้ 10 บริการและ 10 พ็อด และนักพัฒนาเพียงคนเดียวก็สามารถสำลักตัวเองในตอนเย็นได้ Kubernetes จะบอกเขาว่า: "คุณไม่สามารถปรับขนาดพ็อดของคุณเป็นจำนวนนั้นได้ เนื่องจากทรัพยากรเกินโควต้า" แค่นั้นแหละ ปัญหาได้รับการแก้ไขแล้ว .
ประเด็นปัญหาประการหนึ่งเกิดขึ้นในเรื่องนี้ คุณรู้สึกว่าการสร้างเนมสเปซใน Kubernetes กลายเป็นเรื่องยากเพียงใด ในการสร้างมันขึ้นมา เราต้องคำนึงถึงหลายสิ่งหลายอย่าง
โควต้าทรัพยากร + ช่วงขีดจำกัด + RBAC
• สร้างเนมสเปซ
• สร้างขอบเขตจำกัดภายใน
• สร้างโควต้าทรัพยากรภายใน
• สร้างบัญชีบริการสำหรับ CI
• สร้างการผูกบทบาทสำหรับ CI และผู้ใช้
• สามารถเลือกเปิดพ็อดบริการที่จำเป็นได้
ผมจึงขอใช้โอกาสนี้แบ่งปันพัฒนาการของผม มีสิ่งที่เรียกว่าตัวดำเนินการ SDK นี่เป็นวิธีสำหรับคลัสเตอร์ Kubernetes ในการเขียนตัวดำเนินการให้ คุณสามารถเขียนคำสั่งโดยใช้ Ansible
ตอนแรกมันถูกเขียนด้วย Ansible จากนั้นฉันก็เห็นว่ามีตัวดำเนินการ SDK และเขียนบทบาท Ansible ใหม่เป็นตัวดำเนินการ คำสั่งนี้ช่วยให้คุณสร้างออบเจ็กต์ในคลัสเตอร์ Kubernetes ที่เรียกว่าคำสั่ง ภายในคำสั่ง จะช่วยให้คุณสามารถอธิบายสภาพแวดล้อมสำหรับคำสั่งนี้ใน yaml และภายในสภาพแวดล้อมของทีม ช่วยให้เราสามารถอธิบายได้ว่าเรากำลังจัดสรรทรัพยากรจำนวนมาก
จิ๋ว .
และโดยสรุปแล้ว จะทำอย่างไรกับทั้งหมดนี้?
อันดับแรก. นโยบายความปลอดภัยของพ็อดเป็นสิ่งที่ดี และถึงแม้ว่าในปัจจุบันนี้ไม่มีโปรแกรมติดตั้ง Kubernetes ใดที่ใช้โปรแกรมติดตั้งเหล่านี้ แต่คุณยังคงต้องใช้โปรแกรมติดตั้งเหล่านี้ในคลัสเตอร์ของคุณ
นโยบายเครือข่ายไม่ได้เป็นเพียงคุณสมบัติที่ไม่จำเป็นอีกประการหนึ่ง นี่คือสิ่งที่จำเป็นจริงๆ ในคลัสเตอร์
LimitRange/ResourceQuota - ถึงเวลาใช้แล้ว เราเริ่มใช้สิ่งนี้มาเป็นเวลานานแล้ว และฉันก็มั่นใจว่าทุกคนใช้มันมานานแล้ว ปรากฎว่าสิ่งนี้หายาก
นอกเหนือจากสิ่งที่ฉันพูดถึงในระหว่างรายงาน ยังมีฟีเจอร์ที่ไม่มีเอกสารที่อนุญาตให้คุณโจมตีคลัสเตอร์ได้ เปิดตัวเมื่อเร็ว ๆ นี้ .
บางสิ่งก็เศร้าและเจ็บปวดมาก ตัวอย่างเช่น ภายใต้เงื่อนไขบางประการ cubelets ในคลัสเตอร์ Kubernetes สามารถมอบเนื้อหาของไดเร็กทอรี warlocks ให้กับผู้ใช้ที่ไม่ได้รับอนุญาต
มีคำแนะนำเกี่ยวกับวิธีการทำซ้ำทุกสิ่งที่ฉันบอกคุณ มีไฟล์พร้อมตัวอย่างการใช้งานจริงว่า ResourceQuota และ Pod Security Policy มีลักษณะอย่างไร และคุณสามารถสัมผัสทั้งหมดนี้ได้
ขอบคุณทุกคน.
ที่มา: will.com