ความปลอดภัยของหมวกกันน็อค

สาระสำคัญของเรื่องราวเกี่ยวกับตัวจัดการแพ็คเกจยอดนิยมสำหรับ Kubernetes สามารถแสดงได้โดยใช้อิโมจิ:

• กล่องคือ Helm (ซึ่งเป็นสิ่งที่ใกล้เคียงที่สุดกับ Emoji ล่าสุด);
• ล็อค - ความปลอดภัย;
• ชายน้อยคือผู้แก้ปัญหา

ในความเป็นจริงทุกอย่างจะซับซ้อนขึ้นเล็กน้อยและเรื่องราวก็เต็มไปด้วยรายละเอียดทางเทคนิค ทำอย่างไรให้เฮล์มปลอดภัย.

• สรุปว่า Helm คืออะไร ในกรณีที่คุณไม่รู้หรือลืม มันแก้ปัญหาอะไรได้บ้างและมันอยู่ที่ไหนในระบบนิเวศ
• มาดูสถาปัตยกรรมของ Helm กัน ไม่มีการสนทนาเกี่ยวกับความปลอดภัยและวิธีทำให้เครื่องมือหรือโซลูชันมีความปลอดภัยมากขึ้นจะสมบูรณ์ไม่ได้หากไม่เข้าใจสถาปัตยกรรมของส่วนประกอบ
• เรามาพูดถึงส่วนประกอบของ Helm กันดีกว่า
• คำถามที่ร้อนแรงที่สุดคืออนาคต - Helm 3 เวอร์ชันใหม่ 

ทุกอย่างในบทความนี้ใช้กับ Helm 2 เวอร์ชันนี้อยู่ในเวอร์ชันที่ใช้งานจริงและน่าจะเป็นเวอร์ชันที่คุณใช้อยู่ และเป็นเวอร์ชันที่มีความเสี่ยงด้านความปลอดภัย

เกี่ยวกับวิทยากร: อเล็กซานเดอร์ คาโยรอฟ (อเล็กซ์) ได้รับการพัฒนามาเป็นเวลา 10 ปี เพื่อช่วยปรับปรุงเนื้อหา การประชุมมอสโกหลาม ++ และเข้าร่วมเป็นคณะกรรมการ การประชุมสุดยอดหางเสือ. ตอนนี้เขาทำงานที่ Chainstack ในตำแหน่งหัวหน้าฝ่ายพัฒนา ซึ่งเป็นการผสมผสานระหว่างผู้จัดการฝ่ายพัฒนาและบุคคลที่รับผิดชอบในการส่งมอบเวอร์ชันสุดท้าย นั่นคือมันตั้งอยู่ในสนามรบที่ทุกอย่างเกิดขึ้นตั้งแต่การสร้างผลิตภัณฑ์ไปจนถึงการดำเนินงาน

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

หางเสือ

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

แน่นอนว่าเรากำลังพูดถึงแนวทางเชิงโครงสร้างและเชิงอุตสาหกรรมมากกว่าการสร้างรายการ YAML ของคุณเองและการเขียนยูทิลิตี้ขนาดเล็ก

Helm เป็นสิ่งที่ดีที่สุดที่มีอยู่และเป็นที่นิยมในปัจจุบัน

ทำไมต้องหางเสือ? สาเหตุหลักมาจากได้รับการสนับสนุนจาก CNCF Cloud Native เป็นองค์กรขนาดใหญ่และเป็นบริษัทแม่ของโครงการ Kubernetes, ฯลฯ, Fluentd และอื่นๆ

ข้อเท็จจริงที่สำคัญอีกประการหนึ่งคือ Helm เป็นโครงการที่ได้รับความนิยมมาก เมื่อฉันเริ่มพูดถึงวิธีทำให้ Helm ปลอดภัยในเดือนมกราคม 2019 โปรเจ็กต์นี้มีดาวนับพันดวงบน GitHub ภายในเดือนพฤษภาคมมี 12 คน

มีคนจำนวนมากสนใจ Helm ดังนั้นแม้ว่าคุณจะไม่ได้ใช้มัน แต่คุณก็จะได้รับประโยชน์จากการรู้เกี่ยวกับความปลอดภัยของมัน ความปลอดภัยเป็นสิ่งสำคัญ

ทีม Helm หลักได้รับการสนับสนุนจาก Microsoft Azure ดังนั้นจึงเป็นโครงการที่ค่อนข้างมีเสถียรภาพ ไม่เหมือนทีมอื่นๆ การเปิดตัว Helm 3 Alpha 2 ในช่วงกลางเดือนกรกฎาคมบ่งชี้ว่ามีผู้คนจำนวนมากที่ทำงานในโครงการนี้ และพวกเขามีความปรารถนาและพลังที่จะพัฒนาและปรับปรุง Helm

Helm แก้ปัญหาต้นตอหลายประการของการจัดการแอปพลิเคชันใน Kubernetes

• บรรจุภัณฑ์ใบสมัคร แม้แต่แอปพลิเคชันอย่าง “Hello, World” บน WordPress ก็มีบริการหลายอย่างอยู่แล้ว และคุณต้องการรวมเข้าด้วยกัน
• การจัดการความซับซ้อนที่มาพร้อมกับการจัดการแอปพลิเคชันเหล่านี้
• วงจรชีวิตที่ไม่สิ้นสุดหลังจากติดตั้งหรือปรับใช้แอปพลิเคชัน มันยังคงมีอยู่ จำเป็นต้องได้รับการอัปเดต และ Helm ช่วยในเรื่องนี้และพยายามนำมาตรการและนโยบายที่เหมาะสมสำหรับสิ่งนี้

การบรรจุถุง มีการจัดระเบียบอย่างชัดเจน: มีข้อมูลเมตาที่สอดคล้องกับการทำงานของผู้จัดการแพ็คเกจปกติสำหรับ Linux, Windows หรือ MacOS นั่นคือ พื้นที่เก็บข้อมูล การพึ่งพาแพ็คเกจต่างๆ ข้อมูลเมตาสำหรับแอปพลิเคชัน การตั้งค่า คุณสมบัติการกำหนดค่า การทำดัชนีข้อมูล ฯลฯ Helm ช่วยให้คุณรับและใช้ทั้งหมดนี้สำหรับแอปพลิเคชัน

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

การจัดการวงจรชีวิตของแอปพลิเคชัน - ในความคิดของฉัน นี่เป็นคำถามที่น่าสนใจและยังไม่ได้รับการแก้ไขที่สุด นี่คือเหตุผลว่าทำไมฉันถึงมาที่เฮล์มในสมัยนั้น เราจำเป็นต้องจับตาดูวงจรการใช้งานของแอปพลิเคชัน และต้องการย้าย CI/CD และวงจรการใช้งานของเราไปที่กระบวนทัศน์นี้

หางเสือช่วยให้คุณ:

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

ยิ่งไปกว่านั้น หมวกมี "แบตเตอรี่" - ของอร่อยมากมายที่สามารถรวมไว้ในรูปแบบของปลั๊กอินทำให้ชีวิตของคุณง่ายขึ้น ปลั๊กอินสามารถเขียนได้อย่างอิสระ โดยค่อนข้างแยกออกจากกันและไม่ต้องใช้สถาปัตยกรรมที่กลมกลืนกัน หากคุณต้องการนำสิ่งใดไปใช้ ฉันขอแนะนำให้ใช้เป็นปลั๊กอิน จากนั้นอาจรวมไว้ในอัปสตรีมด้วย

หมวกกันน็อคมีพื้นฐานอยู่บนแนวคิดหลักสามประการ:

• แผนภูมิซื้อคืน — คำอธิบายและอาร์เรย์ของการกำหนดพารามิเตอร์ที่เป็นไปได้สำหรับรายการของคุณ 
• การกำหนดค่า —นั่นคือค่าที่จะนำไปใช้ (ข้อความ ค่าตัวเลข ฯลฯ)
• ปล่อย รวบรวมส่วนประกอบด้านบนทั้งสองเข้าด้วยกัน และกลายเป็น Release รีลีสสามารถกำหนดเวอร์ชันได้ ดังนั้นจึงบรรลุวงจรชีวิตที่มีการจัดระเบียบ: เล็กน้อยในขณะที่ติดตั้ง และขนาดใหญ่ในขณะที่อัปเกรด ดาวน์เกรด หรือย้อนกลับ

สถาปัตยกรรมหางเสือ

แผนภาพแสดงแนวคิดสถาปัตยกรรมระดับสูงของ Helm

ฉันขอเตือนคุณว่า Helm เป็นสิ่งที่เกี่ยวข้องกับ Kubernetes ดังนั้นเราจึงทำไม่ได้หากไม่มีคลัสเตอร์ Kubernetes (สี่เหลี่ยม) ส่วนประกอบ kube-apiserver อยู่บนต้นแบบ หากไม่มี Helm เราก็มี Kubeconfig Helm นำไบนารีขนาดเล็กมาหนึ่งตัวหากคุณสามารถเรียกได้ว่าเป็นยูทิลิตี้ Helm CLI ซึ่งติดตั้งบนคอมพิวเตอร์แล็ปท็อปเมนเฟรมบนอะไรก็ได้

แต่นี่ยังไม่เพียงพอ Helm มีส่วนประกอบเซิร์ฟเวอร์ที่เรียกว่า Tiller ซึ่งแสดงถึงความสนใจของ Helm ภายในคลัสเตอร์ ซึ่งเป็นแอปพลิเคชันภายในคลัสเตอร์ Kubernetes เช่นเดียวกับแอปพลิเคชันอื่นๆ

องค์ประกอบถัดไปของ Chart Repo คือพื้นที่เก็บข้อมูลที่มีแผนภูมิ มีพื้นที่เก็บข้อมูลอย่างเป็นทางการ และอาจมีพื้นที่เก็บข้อมูลส่วนตัวของบริษัทหรือโครงการ

ปฏิสัมพันธ์

มาดูกันว่าส่วนประกอบทางสถาปัตยกรรมโต้ตอบกันอย่างไรเมื่อเราต้องการติดตั้งแอปพลิเคชันโดยใช้ Helm

• เราคุย Helm installเข้าถึงพื้นที่เก็บข้อมูล (Chart Repo) และรับแผนภูมิ Helm

• ยูทิลิตี้ Helm (Helm CLI) โต้ตอบกับ Kubeconfig เพื่อดูว่าคลัสเตอร์ใดที่จะติดต่อ 
• เมื่อได้รับข้อมูลนี้แล้ว ยูทิลิตี้นี้จะอ้างถึง Tiller ซึ่งอยู่ในคลัสเตอร์ของเราเป็นแอปพลิเคชัน 
• Tiller เรียก Kube-apiserver เพื่อดำเนินการใน Kubernetes สร้างอ็อบเจ็กต์บางอย่าง (บริการ พ็อด แบบจำลอง ข้อมูลลับ ฯลฯ)

ต่อไป เราจะทำให้ไดอะแกรมซับซ้อนขึ้นเพื่อดูเวกเตอร์การโจมตีที่สถาปัตยกรรม Helm ทั้งหมดสามารถสัมผัสได้ แล้วเราจะพยายามปกป้องเธอ

เวกเตอร์โจมตี

จุดอ่อนที่เป็นไปได้ประการแรกคือ API สิทธิพิเศษ-ผู้ใช้งาน. ส่วนหนึ่งของโครงการนี้คือแฮ็กเกอร์ที่ได้รับสิทธิ์การเข้าถึง Helm CLI ของผู้ดูแลระบบ

ผู้ใช้ API ที่ไม่มีสิทธิพิเศษ อาจก่อให้เกิดอันตรายได้หากอยู่ใกล้ๆ ผู้ใช้ดังกล่าวจะมีบริบทที่แตกต่างกัน เช่น เขาสามารถแก้ไขได้ในเนมสเปซคลัสเตอร์เดียวในการตั้งค่า Kubeconfig

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

รูปแบบการโจมตีที่แปลกใหม่ แต่ได้รับความนิยมมากขึ้นเรื่อยๆ นั้นเกี่ยวข้องกับ Chart Repo แผนภูมิที่สร้างขึ้นโดยผู้เขียนที่ไร้หลักจริยธรรมอาจมีแหล่งข้อมูลที่ไม่ปลอดภัย และคุณจะต้องทำให้สมบูรณ์โดยยึดถือตามศรัทธา หรืออาจแทนที่แผนภูมิที่คุณดาวน์โหลดจากพื้นที่เก็บข้อมูลอย่างเป็นทางการ และสร้างทรัพยากรในรูปแบบของนโยบายและเพิ่มการเข้าถึง

เรามาลองป้องกันการโจมตีจากทั้งสี่ด้านและหาคำตอบว่าสถาปัตยกรรม Helm มีปัญหาตรงไหน และบางทีอาจไม่มีเลยที่ไหนบ้าง

มาขยายไดอะแกรม เพิ่มองค์ประกอบเพิ่มเติม แต่เก็บส่วนประกอบพื้นฐานทั้งหมดไว้

Helm CLI สื่อสารกับ Chart Repo โต้ตอบกับ Kubeconfig และงานจะถูกถ่ายโอนไปยังคลัสเตอร์ไปยังส่วนประกอบ Tiller

ทิลเลอร์แสดงด้วยวัตถุสองชิ้น:

• Tiller-deploy svc ซึ่งเปิดเผยบริการบางอย่าง
• พ็อดปรับใช้ Tiller (ในไดอะแกรมในสำเนาเดียวในเรพลิกาเดียว) ซึ่งโหลดทั้งหมดทำงานซึ่งเข้าถึงคลัสเตอร์

มีการใช้โปรโตคอลและโครงร่างที่แตกต่างกันสำหรับการโต้ตอบ จากมุมมองด้านความปลอดภัย เราสนใจมากที่สุดใน:

• กลไกที่ Helm CLI เข้าถึงแผนภูมิ repo: โปรโตคอลใด มีการตรวจสอบสิทธิ์ และสิ่งที่สามารถทำได้
• โปรโตคอลที่ Helm CLI สื่อสารกับ Tiller โดยใช้ kubectl นี่คือเซิร์ฟเวอร์ RPC ที่ติดตั้งภายในคลัสเตอร์
• ตัว Tiller นั้นสามารถเข้าถึงไมโครเซอร์วิสที่อยู่ในคลัสเตอร์และโต้ตอบกับ Kube-apiserver

เรามาหารือเกี่ยวกับประเด็นเหล่านี้ทั้งหมดตามลำดับ

อาร์แบค

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

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

https://rbac.dev/ — ทนายความเว็บไซต์ของ RBAC ประกอบด้วยเนื้อหาที่น่าสนใจจำนวนมากที่จะช่วยคุณในการตั้งค่า RBAC แสดงให้เห็นว่าเหตุใดจึงดี และจะใช้ชีวิตร่วมกับมันในการผลิตได้อย่างไร

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

เมื่อคุณเริ่มต้น Helm และติดตั้งบนเซิร์ฟเวอร์เป็นครั้งแรก คุณสามารถตั้งค่าบัญชีบริการได้ --service-account. ซึ่งจะทำให้คุณสามารถใช้ผู้ใช้ที่มีชุดสิทธิ์ขั้นต่ำที่จำเป็นได้ จริงอยู่ที่คุณจะต้องสร้าง "พวงมาลัย" เช่นนี้: Role และ RoleBinding

น่าเสียดายที่ Helm จะไม่ทำสิ่งนี้เพื่อคุณ คุณหรือผู้ดูแลระบบคลัสเตอร์ Kubernetes ต้องเตรียมชุดบทบาทและ RoleBindings สำหรับบัญชีบริการล่วงหน้าเพื่อที่จะส่ง Helm

คำถามเกิดขึ้น - อะไรคือความแตกต่างระหว่าง Role และ ClusterRole? ข้อแตกต่างก็คือ ClusterRole ใช้ได้กับเนมสเปซทั้งหมด ซึ่งแตกต่างจาก Roles และ RoleBindings ปกติซึ่งใช้ได้กับเนมสเปซเฉพาะเท่านั้น คุณสามารถกำหนดค่านโยบายสำหรับทั้งคลัสเตอร์และเนมสเปซทั้งหมด หรือกำหนดค่าส่วนบุคคลสำหรับแต่ละเนมสเปซแยกกันได้

เป็นที่น่าสังเกตว่า RBAC แก้ปัญหาใหญ่อีกปัญหาหนึ่งได้ หลายๆ คนบ่นว่า Helm น่าเสียดาย ไม่ใช่การเช่าหลายกรณี (ไม่รองรับการเช่าหลายกรณี) หากหลายทีมใช้คลัสเตอร์และใช้ Helm โดยทั่วไปแล้วจะเป็นไปไม่ได้ที่จะตั้งค่านโยบายและจำกัดการเข้าถึงภายในคลัสเตอร์นี้ เนื่องจากมีบัญชีบริการบางอย่างที่ Helm ทำงานอยู่ และจะสร้างทรัพยากรทั้งหมดในคลัสเตอร์จากข้างใต้ ซึ่งบางครั้งก็ไม่สะดวกอย่างมาก นี่เป็นเรื่องจริง - เช่นเดียวกับไฟล์ไบนารี่เอง เช่นเดียวกับกระบวนการ Helm Tiller ไม่มีแนวคิดเรื่องการครอบครองหลายส่วน.

อย่างไรก็ตาม มีวิธีที่ดีเยี่ยมที่ช่วยให้คุณสามารถเรียกใช้ Tiller ได้หลายครั้งในคลัสเตอร์ ไม่มีปัญหาในเรื่องนี้ Tiller สามารถเปิดใช้งานได้ในทุกเนมสเปซ ดังนั้น คุณสามารถใช้ RBAC, Kubeconfig เป็นบริบท และจำกัดการเข้าถึง Helm พิเศษได้

มันจะมีลักษณะเช่นนี้

ตัวอย่างเช่น มี Kubeconfig สองรายการพร้อมบริบทสำหรับทีมที่แตกต่างกัน (สองเนมสเปซ): X Team สำหรับทีมพัฒนาและคลัสเตอร์ผู้ดูแลระบบ คลัสเตอร์ผู้ดูแลระบบมี Wide Tiller ของตัวเอง ซึ่งอยู่ในเนมสเปซของระบบ Kube ซึ่งเป็นบัญชีบริการขั้นสูงที่สอดคล้องกัน และเนมสเปซแยกต่างหากสำหรับทีมพัฒนา พวกเขาจะสามารถปรับใช้บริการของตนกับเนมสเปซพิเศษได้

นี่เป็นแนวทางที่ใช้การได้ Tiller ไม่ได้ใช้พลังงานมากจนส่งผลต่องบประมาณของคุณอย่างมาก นี่เป็นหนึ่งในวิธีแก้ปัญหาที่รวดเร็ว

คุณสามารถกำหนดค่า Tiller แยกกันได้ และจัดเตรียมบริบทให้กับทีม สำหรับนักพัฒนาเฉพาะราย หรือสำหรับสภาพแวดล้อมให้กับ Kubeconfig: Dev, Staging, Production (ไม่แน่ใจว่าทุกอย่างจะอยู่ในคลัสเตอร์เดียวกัน อย่างไรก็ตาม สามารถทำได้)

สานต่อเรื่องราวของเรา เรามาเปลี่ยนจาก RBAC และพูดคุยเกี่ยวกับ ConfigMaps กันดีกว่า

ConfigMap

Helm ใช้ ConfigMaps เป็นที่เก็บข้อมูล เมื่อเราพูดถึงสถาปัตยกรรม ไม่มีฐานข้อมูลใดที่จะจัดเก็บข้อมูลเกี่ยวกับการเผยแพร่ การกำหนดค่า การย้อนกลับ ฯลฯ ConfigMaps ใช้สำหรับสิ่งนี้

ทราบปัญหาหลักของ ConfigMaps แล้ว โดยหลักการแล้วไม่ปลอดภัย เป็นไปไม่ได้ที่จะจัดเก็บข้อมูลที่ละเอียดอ่อน. เรากำลังพูดถึงทุกสิ่งที่ไม่ควรไปไกลกว่าบริการ เช่น รหัสผ่าน วิธีดั้งเดิมที่สุดสำหรับ Helm ในขณะนี้คือการเปลี่ยนจากการใช้ ConfigMaps ไปเป็นความลับ

ทำได้ง่ายมาก แทนที่การตั้งค่า Tiller และระบุว่าที่เก็บข้อมูลจะเป็นความลับ จากนั้น สำหรับการปรับใช้แต่ละครั้ง คุณจะไม่ได้รับ ConfigMap แต่เป็นความลับ

คุณสามารถโต้แย้งได้ว่าความลับนั้นเป็นแนวคิดที่แปลกและไม่ปลอดภัยมากนัก อย่างไรก็ตาม ควรทำความเข้าใจว่านักพัฒนา Kubernetes กำลังทำเช่นนี้ เริ่มต้นจากเวอร์ชัน 1.10 เช่น เป็นเวลานานพอสมควรแล้ว อย่างน้อยก็ในระบบคลาวด์สาธารณะ สามารถเชื่อมต่อที่เก็บข้อมูลที่ถูกต้องเพื่อจัดเก็บความลับได้ ขณะนี้ทีมงานกำลังดำเนินการหาวิธีกระจายการเข้าถึงข้อมูลลับ พ็อดเดี่ยว หรือเอนทิตีอื่น ๆ ได้ดียิ่งขึ้น

เป็นการดีกว่าที่จะถ่ายโอน Storage Helm ไปเป็นความลับ และในทางกลับกัน พวกมันก็จะได้รับการรักษาความปลอดภัยจากส่วนกลาง

แน่นอนมันจะยังคงอยู่ ขีดจำกัดการจัดเก็บข้อมูล 1 MB. Helm ที่นี่ใช้ etcd เป็นที่เก็บข้อมูลแบบกระจายสำหรับ ConfigMaps และที่นั่นพวกเขาพิจารณาว่านี่เป็นก้อนข้อมูลที่เหมาะสมสำหรับการจำลองแบบ ฯลฯ มีการพูดคุยที่น่าสนใจเกี่ยวกับเรื่องนี้ใน Reddit ฉันแนะนำให้หาเรื่องอ่านตลกๆ ในช่วงสุดสัปดาห์หรืออ่านสารสกัด ที่นี่.

Repos แผนภูมิ

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

คุณต้องเปิดเผย Helm Repo ผ่าน HTTPS แน่นอน - นี่คือตัวเลือกที่ดีที่สุดและราคาไม่แพง

ให้ความสนใจกับ กลไกลายเซ็นแผนภูมิ. เทคโนโลยีนั้นง่ายเหมือนนรก นี่เป็นสิ่งเดียวกับที่คุณใช้บน GitHub ซึ่งเป็นเครื่อง PGP ทั่วไปที่มีคีย์สาธารณะและส่วนตัว ตั้งค่าและตรวจสอบให้แน่ใจว่ามีคีย์ที่จำเป็นและลงนามทุกอย่างว่านี่คือแผนภูมิของคุณจริงๆ

นอกจากนี้ ไคลเอนต์ Helm รองรับ TLS (ไม่ใช่ในแง่ HTTP ฝั่งเซิร์ฟเวอร์ แต่เป็น TLS ร่วมกัน) คุณสามารถใช้คีย์เซิร์ฟเวอร์และไคลเอนต์เพื่อสื่อสาร พูดตามตรง ฉันไม่ได้ใช้กลไกดังกล่าวเพราะฉันไม่ชอบใบรับรองร่วมกัน โดยพื้นฐานแล้ว แผนภูมิพิพิธภัณฑ์ - เครื่องมือหลักสำหรับการตั้งค่า Helm Repo สำหรับ Helm 2 - รองรับการรับรองความถูกต้องขั้นพื้นฐานด้วย คุณสามารถใช้การรับรองความถูกต้องขั้นพื้นฐานได้หากสะดวกและเงียบกว่า

นอกจากนี้ยังมีปลั๊กอิน หางเสือ-gcsซึ่งช่วยให้คุณสามารถโฮสต์ Chart Repos บน Google Cloud Storage ได้ วิธีนี้ค่อนข้างสะดวก ใช้งานได้ดี และค่อนข้างปลอดภัย เนื่องจากกลไกที่อธิบายไว้ทั้งหมดได้รับการรีไซเคิล

หากคุณเปิดใช้งาน HTTPS หรือ TLS ใช้ mTLS และเปิดใช้งานการตรวจสอบสิทธิ์ขั้นพื้นฐานเพื่อลดความเสี่ยงเพิ่มเติม คุณจะได้รับช่องทางการสื่อสารที่ปลอดภัยด้วย Helm CLI และ Chart Repo

gRPC API

ขั้นตอนต่อไปมีความสำคัญมาก - ในการรักษาความปลอดภัย Tiller ซึ่งอยู่ในคลัสเตอร์และในอีกด้านหนึ่งเป็นเซิร์ฟเวอร์ ตัวมันเองจะเข้าถึงส่วนประกอบอื่น ๆ และพยายามแกล้งทำเป็นใครบางคน

ดังที่ฉันได้กล่าวไปแล้ว Tiller เป็นบริการที่เปิดเผย gRPC โดยที่ไคลเอ็นต์ Helm เข้ามาผ่านทาง gRPC แน่นอนว่า TLS จะถูกปิดใช้งานตามค่าเริ่มต้น เหตุใดจึงทำเช่นนี้เป็นคำถามที่ถกเถียงกัน สำหรับฉันแล้วดูเหมือนว่าการตั้งค่าจะง่ายขึ้นตั้งแต่เริ่มต้น

สำหรับการผลิตและการจัดเตรียม ฉันขอแนะนำให้เปิดใช้งาน TLS บน gRPC

ในความคิดของฉัน ซึ่งไม่เหมือนกับ mTLS สำหรับแผนภูมิ นี่เป็นสิ่งที่เหมาะสมที่นี่และทำได้ง่ายมาก - สร้างโครงสร้างพื้นฐาน PQI สร้างใบรับรอง เรียกใช้ Tiller ถ่ายโอนใบรับรองระหว่างการเริ่มต้น หลังจากนี้ คุณสามารถดำเนินการคำสั่ง Helm ทั้งหมด โดยนำเสนอใบรับรองที่สร้างขึ้นและคีย์ส่วนตัว

ด้วยวิธีนี้ คุณจะป้องกันตัวเองจากคำขอทั้งหมดที่ส่งถึง Tiller จากภายนอกคลัสเตอร์

ดังนั้นเราจึงรักษาช่องทางการเชื่อมต่อกับ Tiller เราได้หารือเกี่ยวกับ RBAC แล้ว และปรับสิทธิ์ของ Kubernetes apiserver เพื่อลดโดเมนที่สามารถโต้ตอบได้

หมวกกันน็อคที่ได้รับการคุ้มครอง

ลองดูแผนภาพสุดท้าย เป็นสถาปัตยกรรมเดียวกันกับลูกศรเดียวกัน

ขณะนี้การเชื่อมต่อทั้งหมดสามารถวาดเป็นสีเขียวได้อย่างปลอดภัย:

• สำหรับ Chart Repo เราใช้ TLS หรือ mTLS และการตรวจสอบสิทธิ์ขั้นพื้นฐาน
• mTLS สำหรับ Tiller และแสดงเป็นบริการ gRPC พร้อม TLS เราใช้ใบรับรอง
• คลัสเตอร์ใช้บัญชีบริการพิเศษที่มีบทบาทและ RoleBinding 

เราได้รักษาความปลอดภัยให้กับคลัสเตอร์อย่างมีนัยสำคัญ แต่มีคนฉลาดกล่าวว่า:

“มีวิธีแก้ปัญหาที่ปลอดภัยที่สุดได้ทางเดียวเท่านั้น นั่นคือคอมพิวเตอร์ที่ปิดอยู่ซึ่งอยู่ในกล่องคอนกรีตและมีทหารคอยคุ้มกัน”

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

โบนัส

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

ในที่เก็บข้อมูล github.com/helm/charts ขณะนี้มีแผนภูมิประมาณ 300 รายการและสองสตรีม: เสถียรและแบบบ่มเพาะ ใครก็ตามที่มีส่วนร่วมรู้ดีว่าการเดินทางจากตู้ฟักไปยังคอกม้านั้นยากเพียงใด และการบินออกจากคอกม้านั้นง่ายเพียงใด อย่างไรก็ตาม นี่ไม่ใช่เครื่องมือที่ดีที่สุดในการค้นหาแผนภูมิสำหรับ Prometheus และอะไรก็ตามที่คุณต้องการ ด้วยเหตุผลง่ายๆ ข้อเดียว นั่นไม่ใช่พอร์ทัลที่คุณสามารถค้นหาแพ็คเกจได้อย่างสะดวก

แต่มีบริการ hub.helm.shซึ่งทำให้การค้นหาแผนภูมิสะดวกยิ่งขึ้น สิ่งสำคัญที่สุดคือมีที่เก็บภายนอกอีกมากมายและมีเครื่องรางให้เลือกเกือบ 800 รายการ นอกจากนี้ คุณยังสามารถเชื่อมต่อพื้นที่เก็บข้อมูลของคุณได้ หากคุณไม่ต้องการส่งแผนภูมิของคุณไปยังที่เสถียรด้วยเหตุผลบางประการ

ลองใช้ hub.helm.sh แล้วมาพัฒนาไปด้วยกัน บริการนี้อยู่ภายใต้โครงการ Helm และคุณสามารถมีส่วนร่วมกับ UI ได้หากคุณเป็นนักพัฒนาส่วนหน้าและต้องการปรับปรุงรูปลักษณ์ภายนอก

ฉันอยากจะดึงความสนใจของคุณไปที่ การรวม API โบรกเกอร์บริการแบบเปิด. ฟังดูยุ่งยากและไม่ชัดเจน แต่ก็ช่วยแก้ปัญหาที่ทุกคนต้องเผชิญได้ ผมขออธิบายด้วยตัวอย่างง่ายๆ

มีคลัสเตอร์ Kubernetes ที่เราต้องการเรียกใช้แอปพลิเคชันคลาสสิก - WordPress โดยทั่วไป ฐานข้อมูลเป็นสิ่งจำเป็นสำหรับฟังก์ชันการทำงานเต็มรูปแบบ มีโซลูชันที่แตกต่างกันมากมาย เช่น คุณสามารถเปิดใช้บริการ statefull ของคุณเองได้ ไม่สะดวกนักแต่หลายๆคนก็ทำกัน

คนอื่นๆ เช่นเราที่ Chainstack ต่างก็ใช้ฐานข้อมูลที่ได้รับการจัดการ เช่น MySQL หรือ PostgreSQL สำหรับเซิร์ฟเวอร์ของตน นั่นเป็นเหตุผลว่าทำไมฐานข้อมูลของเราจึงอยู่ที่ไหนสักแห่งในระบบคลาวด์

แต่ปัญหาเกิดขึ้น: เราจำเป็นต้องเชื่อมต่อบริการของเรากับฐานข้อมูล สร้างรสชาติฐานข้อมูล ถ่ายโอนข้อมูลรับรอง และจัดการมันด้วยวิธีใดวิธีหนึ่ง โดยปกติแล้วทั้งหมดนี้จะทำด้วยตนเองโดยผู้ดูแลระบบหรือผู้พัฒนา และไม่มีปัญหาเมื่อมีแอปพลิเคชั่นน้อย เมื่อมีจำนวนมากคุณต้องรวมกัน มีเครื่องเก็บเกี่ยว - เป็นนายหน้าบริการ อนุญาตให้คุณใช้ปลั๊กอินพิเศษสำหรับคลัสเตอร์คลาวด์สาธารณะและสั่งซื้อทรัพยากรจากผู้ให้บริการผ่านนายหน้า ราวกับว่าเป็น API ในการดำเนินการนี้ คุณสามารถใช้เครื่องมือ Kubernetes ดั้งเดิมได้

มันง่ายมาก ตัวอย่างเช่น คุณสามารถสืบค้น Managed MySQL ใน Azure ด้วยระดับพื้นฐานได้ (ซึ่งสามารถกำหนดค่าได้) เมื่อใช้ Azure API ฐานข้อมูลจะถูกสร้างขึ้นและเตรียมพร้อมสำหรับการใช้งาน คุณไม่จำเป็นต้องเข้าไปยุ่งเกี่ยวกับเรื่องนี้ ปลั๊กอินจะเป็นผู้รับผิดชอบในเรื่องนี้ ตัวอย่างเช่น OSBA (ปลั๊กอิน Azure) จะส่งคืนข้อมูลประจำตัวให้กับบริการและส่งต่อไปยัง Helm คุณจะสามารถใช้ WordPress กับ Cloud MySQL โดยไม่ต้องจัดการกับฐานข้อมูลที่ได้รับการจัดการเลย และไม่ต้องกังวลกับบริการแบบ statefull ภายใน

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

คุณสามารถเขียนปลั๊กอินของคุณเองและใช้เรื่องราวทั้งหมดนี้ภายในองค์กรได้ จากนั้นคุณก็จะมีปลั๊กอินของคุณเองสำหรับผู้ให้บริการคลาวด์ขององค์กร ฉันขอแนะนำให้ลองใช้วิธีนี้ โดยเฉพาะอย่างยิ่งหากคุณมีขนาดใหญ่และต้องการปรับใช้การพัฒนา การจัดเตรียม หรือโครงสร้างพื้นฐานทั้งหมดอย่างรวดเร็วสำหรับคุณสมบัติหนึ่งๆ สิ่งนี้จะทำให้ชีวิตง่ายขึ้นสำหรับการดำเนินงานหรือ DevOps ของคุณ

อีกอย่างที่ผมได้กล่าวไปแล้วก็คือ ปลั๊กอิน helm-gcsซึ่งช่วยให้คุณใช้ Google-buckets (ที่เก็บข้อมูลวัตถุ) เพื่อจัดเก็บแผนภูมิ Helm

คุณต้องการเพียงสี่คำสั่งเพื่อเริ่มใช้งาน:

1. ติดตั้งปลั๊กอิน
2. เริ่มต้นมัน;
3. กำหนดเส้นทางไปยังที่เก็บข้อมูลซึ่งอยู่ใน gcp
4. เผยแพร่แผนภูมิด้วยวิธีมาตรฐาน

สิ่งที่สวยงามก็คือจะใช้วิธี gcp แบบเนทีฟเพื่อการอนุญาต คุณสามารถใช้บัญชีบริการ บัญชีนักพัฒนา อะไรก็ได้ที่คุณต้องการ สะดวกมากและไม่มีค่าใช้จ่ายใด ๆ ในการทำงาน หากคุณส่งเสริมปรัชญาที่ไร้ทางเลือกเหมือนฉัน สิ่งนี้จะสะดวกมาก โดยเฉพาะสำหรับทีมขนาดเล็ก

ทางเลือก

Helm ไม่ใช่โซลูชันการจัดการบริการเพียงอย่างเดียว มีคำถามมากมายเกี่ยวกับเรื่องนี้ซึ่งอาจเป็นสาเหตุว่าทำไมเวอร์ชันที่สามจึงปรากฏอย่างรวดเร็ว แน่นอนว่ายังมีทางเลือกอื่นอยู่

สิ่งเหล่านี้อาจเป็นโซลูชันเฉพาะทาง เช่น Ksonnet หรือ Metaparticle คุณสามารถใช้เครื่องมือการจัดการโครงสร้างพื้นฐานแบบคลาสสิก (Ansible, Terraform, Chef ฯลฯ) เพื่อจุดประสงค์เดียวกับที่ฉันพูดถึง

ในที่สุดก็มีวิธีแก้ปัญหา กรอบงานตัวดำเนินการซึ่งความนิยมมีเพิ่มมากขึ้น

Operator Framework เป็นทางเลือกอันดับต้นๆ ของ Helm ที่ต้องพิจารณา

มันมีความเป็นพื้นเมืองของ CNCF และ Kubernetes มากกว่า แต่อุปสรรคในการเข้านั้นสูงกว่ามากคุณต้องเขียนโปรแกรมมากขึ้นและอธิบายรายการให้น้อยลง

มีส่วนเสริมต่างๆ เช่น Draft, Scaffold พวกเขาทำให้ชีวิตง่ายขึ้นมาก เช่น ลดความซับซ้อนของวงจรการส่งและเปิดใช้ Helm เพื่อให้นักพัฒนาปรับใช้สภาพแวดล้อมการทดสอบ ฉันจะเรียกพวกเขาว่าผู้มีอำนาจ

นี่คือแผนภูมิภาพว่าทุกอย่างอยู่ที่ไหน

บนแกน x คือระดับการควบคุมส่วนบุคคลของคุณต่อสิ่งที่เกิดขึ้น บนแกน y คือระดับความเป็นต้นกำเนิดของ Kubernetes Helm เวอร์ชัน 2 อยู่ตรงกลาง ในเวอร์ชัน 3 ไม่ได้มีการปรับปรุงมากนัก แต่ทั้งการควบคุมและระดับความเป็นพื้นเมืองได้รับการปรับปรุงแล้ว โซลูชั่นในระดับ Ksonnet ยังคงด้อยกว่า Helm 2 อีกด้วย อย่างไรก็ตาม พวกเขาก็คุ้มค่าที่จะดูว่ามีอะไรอีกบ้างในโลกนี้ แน่นอนว่าตัวจัดการการกำหนดค่าของคุณจะอยู่ภายใต้การควบคุมของคุณ แต่ไม่ใช่ Kubernetes อย่างแน่นอน

Operator Framework นั้นมีต้นกำเนิดมาจาก Kubernetes และช่วยให้คุณจัดการได้อย่างสวยงามและรอบคอบมากขึ้น (แต่อย่าลืมเกี่ยวกับระดับเริ่มต้น) แต่เหมาะสำหรับการใช้งานเฉพาะทางและการสร้างการจัดการ แทนที่จะเป็นรถเก็บเกี่ยวจำนวนมากสำหรับการบรรจุการใช้งานจำนวนมากโดยใช้ Helm

Extender เพียงปรับปรุงการควบคุมเพียงเล็กน้อย เสริมเวิร์กโฟลว์ หรือตัดมุมบนไปป์ไลน์ CI/CD

อนาคตของเฮล์ม

ข่าวดีก็คือ Helm 3 กำลังจะมา Helm 3.0.0-alpha.2 เวอร์ชันอัลฟ่าออกวางจำหน่ายแล้ว คุณสามารถลองใช้งานได้ มันค่อนข้างเสถียร แต่ฟังก์ชันการทำงานยังมีจำกัด

ทำไมคุณถึงต้องการ Helm 3? ก่อนอื่นนี่คือเรื่องราวเกี่ยวกับ การหายตัวไปของทิลเลอร์มาเป็นองค์ประกอบ ตามที่คุณเข้าใจแล้ว สิ่งนี้ถือเป็นก้าวสำคัญไปข้างหน้า เพราะจากมุมมองของความปลอดภัยของสถาปัตยกรรม ทุกอย่างก็ง่ายขึ้น

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

จะปรากฏขึ้น รองรับที่เก็บ OCI ดั้งเดิม (ความคิดริเริ่มเปิดคอนเทนเนอร์) นี่เป็นความคิดริเริ่มที่ยิ่งใหญ่ และ Helm สนใจที่จะโพสต์แผนภูมิเป็นหลัก มาถึงจุดที่ Docker Hub รองรับมาตรฐาน OCI มากมาย ฉันไม่ได้คาดเดา แต่บางทีผู้ให้บริการพื้นที่เก็บข้อมูล Docker แบบคลาสสิกจะเริ่มให้โอกาสคุณในการโฮสต์แผนภูมิ Helm ของคุณ

เรื่องราวที่ถกเถียงกันสำหรับผมก็คือ หลัวสนับสนุนเป็นเครื่องมือสร้างเทมเพลตสำหรับการเขียนสคริปต์ ฉันไม่ใช่แฟนตัวยงของ Lua แต่นี่อาจเป็นฟีเจอร์เสริมโดยสิ้นเชิง ฉันตรวจสอบสิ่งนี้ 3 ครั้ง - การใช้ Lua นั้นไม่จำเป็น ดังนั้นใครที่อยากใช้ Lua ชอบ Go ก็มาเข้าร่วมค่ายใหญ่ของเราแล้วใช้ go-tmpl เพื่อสิ่งนี้

ในที่สุดสิ่งที่ฉันขาดหายไปอย่างแน่นอนคือ การเกิดขึ้นของสคีมาและการตรวจสอบประเภทข้อมูล. จะไม่มีปัญหากับ int หรือ string อีกต่อไป ไม่จำเป็นต้องใส่ศูนย์ด้วยเครื่องหมายคำพูดคู่ สคีมา JSONS จะปรากฏขึ้นเพื่อให้คุณอธิบายค่านี้ได้อย่างชัดเจน

จะได้รับการปรับปรุงใหม่อย่างหนัก โมเดลที่ขับเคลื่อนด้วยเหตุการณ์. ได้มีการอธิบายแนวคิดไว้แล้ว ดูที่สาขา Helm 3 แล้วคุณจะเห็นว่ามีเหตุการณ์และ hooks และสิ่งอื่นๆ เพิ่มเข้ามากี่เหตุการณ์ ซึ่งจะลดความซับซ้อนลงอย่างมาก และในทางกลับกัน เพิ่มการควบคุมกระบวนการปรับใช้และการตอบสนองต่อสิ่งเหล่านั้น

Helm 3 จะง่ายกว่า ปลอดภัยกว่า และสนุกกว่า ไม่ใช่เพราะเราไม่ชอบ Helm 2 แต่เป็นเพราะ Kubernetes มีความก้าวหน้ามากขึ้น ดังนั้น Helm จึงสามารถใช้การพัฒนาของ Kubernetes และสร้างผู้จัดการที่ยอดเยี่ยมสำหรับ Kubernetes ได้

ข่าวดีอีกอย่างก็คือ DevOpsConf Alexander Khayorov จะบอกคุณว่า ตู้คอนเทนเนอร์จะปลอดภัยได้ไหม? เราขอเตือนคุณว่าการประชุมเกี่ยวกับการบูรณาการกระบวนการพัฒนา การทดสอบ และการดำเนินงานจะจัดขึ้นที่กรุงมอสโก 30 กันยายน และ 1 ตุลาคม. คุณยังทำได้จนถึงวันที่ 20 สิงหาคม ส่งรายงาน และบอกเราเกี่ยวกับประสบการณ์ของคุณกับโซลูชันนี้ หนึ่งในนั้น งานของแนวทาง DevOps

ติดตามด่านประชุมและข่าวสารได้ที่ รายชื่อผู้รับจดหมาย и ช่องโทรเลข.

ที่มา: will.com