วิธีจัดการกับการอัพเดทความปลอดภัยภายในคอนเทนเนอร์ Docker

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

การอัปเดตความปลอดภัยแบบดั้งเดิมนั้นถูกนำไปใช้โดยเพียงแค่ดำเนินการคำสั่ง package manager เพื่อติดตั้งแพ็กเกจเวอร์ชันที่อัพเดตบนระบบปฏิบัติการ (เช่น "yum update" บน RHEL) แต่ด้วยการถือกำเนิดของเทคโนโลยี container เช่น Docker ที่รูปของ container รวมทั้งแอพพลิเคชั่นและแพลตฟอร์มเป็นวิธีที่ยอมรับได้ในการรักษาระบบด้วย container เป็นอะไร? ทั้งโฮสต์และคอนเทนเนอร์มีชุดแพ็กเกจของตนเองที่เป็นอิสระที่จำเป็นต้องอัพเดตและอัพเดตบนโฮสต์จะไม่อัพเดตแพ็กเกจใด ๆ ภายในคอนเทนเนอร์ ด้วยการเปิดตัว RHEL 7 ที่มีคุณสมบัติพิเศษของ Docker container มันน่าสนใจที่จะได้ยินว่า Redhat แนะนำวิธีใดในการจัดการกับการอัปเดตความปลอดภัยของคอนเทนเนอร์

ความคิดเกี่ยวกับตัวเลือกบางอย่าง:

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

ดังนั้นวิธีการเหล่านี้จึงไม่น่าพอใจ

แอปพลิเคชันชุดภาพอิมเมจและ "แพลตฟอร์ม" ที่ถูกต้อง แต่โดยปกติแล้วภาพนั้นจะประกอบไปด้วยภาพฐานและแอพพลิเคชั่นจริง

ดังนั้นวิธีมาตรฐานเพื่อจัดการกับการปรับปรุงความปลอดภัยคือการอัพเดทอิมเมจพื้นฐานจากนั้นสร้างอิมเมจแอปพลิเคชันของคุณ

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

ในขณะที่คุณสามารถปะติดอยู่ภายในตู้คอนเทนเนอร์

สิ่งนี้ถูกจัดการโดยอัตโนมัติใน SUSE Enterprise Linux โดยใช้ zypper-docker (1)

SUSE / zypper-นักเทียบท่า

นักเทียบท่าเริ่มต้นอย่างรวดเร็ว

ก่อนอื่นการอัปเดตจำนวนมากที่คุณเคยใช้ในอดีตจะไม่อยู่ในคอนเทนเนอร์ คอนเทนเนอร์ควรเป็นชุดย่อยที่มีน้ำหนักเบาและเล็กของระบบไฟล์แบบเต็มที่คุณคุ้นเคยในอดีต แพ็กเกจที่คุณควรอัปเดตจะเป็นแพ็กเกจที่เป็นส่วนหนึ่งของ DockerFile ของคุณและเนื่องจากคุณมี DockerFile คุณควรติดตามแพ็กเกจเหล่านั้นและ ID คอนเทนเนอร์ที่ต้องการการอัปเดต UI ของ Cloudstein ที่จะเปิดตัวเร็ว ๆ นี้จะติดตามส่วนผสม DockerFile เหล่านี้สำหรับคุณเพื่อให้สามารถสร้างชุดรูปแบบการอัปเดตที่เหมาะสมที่สุดสำหรับคอนเทนเนอร์ของพวกเขา หวังว่านี่จะช่วยได้

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

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

ฉันกำลังพิจารณาปรับใช้ sonarr และ radarr ในคอนเทนเนอร์ docker แต่รู้ว่าพวกเขาจะไม่ได้รับการปรับปรุงความปลอดภัยปกติคอนเทนเนอร์ของฉันได้รับเป็นตัวแบ่งการจัดการ การจัดการการอัปเดตความปลอดภัยสำหรับคอนเทนเนอร์ของฉันนั้นยุ่งยากพอสมควรโดยไม่ต้องจัดการกับปัญหาด้วยตนเองเลยต้องใช้การอัปเดตความปลอดภัยกับอิมเมจแต่ละตัวของ Docker ด้วยตนเอง