Bottlerocket - Linux OS แบบ immutable ขั้นต่ำพร้อม verified boot

• Bottlerocket เป็น OS บน Linux ที่ปรับแต่งมาสำหรับการโฮสต์คอนเทนเนอร์ ใช้เป็นระบบปฏิบัติการพื้นฐานของ worker node ในคลัสเตอร์ที่จัดการโดย orchestrator อย่าง Kubernetes
• ใช้ การกำหนดค่าขั้นต่ำ โดยตัดแพ็กเกจ เครื่องมือ และ interpreter ของดิสโทรแบบใช้งานทั่วไปออก เพื่อลดภาระการปฏิบัติการและพื้นผิวการโจมตี พร้อม提供เฉพาะชุดที่จำเป็นผ่าน variant ตามแต่ละสภาพแวดล้อม
• ไม่มี shell และ package manager จัดการระบบผ่าน privileged host container และ API ส่วนการอัปเดตถูกนำไปใช้แบบ atomic ด้วยการสลับ image และ partition
• การตั้งค่าจัดการผ่าน API จึงรองรับการ migrate และ rollback ระหว่างเวอร์ชันได้ และการจัดการอัปเดตทำได้ทั้งแบบ manual หรือผ่านเครื่องมือเฉพาะของ orchestrator
• ลดเส้นทางการแก้ไขระบบและการรันโค้ดที่ไม่ผ่านการตรวจสอบ ด้วย root filesystem แบบ immutable, dm-verity, SELinux แบบจำกัดสิทธิ์, รวมถึงการ implement ด้วย Rust และบางส่วนด้วย Golang

---

OS พื้นฐานสำหรับคลัสเตอร์คอนเทนเนอร์

• Bottlerocket เป็นระบบปฏิบัติการบน Linux ที่ปรับแต่งมาเพื่อการโฮสต์คอนเทนเนอร์
  • เป็นซอฟต์แวร์โอเพนซอร์สฟรี และพัฒนาแบบเปิดบน GitHub
  • ติดตั้งเป็น ระบบปฏิบัติการพื้นฐาน ของเครื่องหรืออินสแตนซ์ที่คอนเทนเนอร์ทำงานอยู่
  • ออกแบบมาให้ทำงานร่วมกับ container orchestrator อย่าง Kubernetes เพื่อรองรับการทำงานอัตโนมัติของวงจรชีวิตคอนเทนเนอร์ภายในคลัสเตอร์
  • ทำงานได้ทั้งบนคลาวด์และในดาต้าเซ็นเตอร์
• เป้าหมายการออกแบบสรุปได้เป็นสามข้อคือ Minimal, Safe Updates, และ Security Focused

การกำหนดค่าขั้นต่ำและ variant ตามสภาพแวดล้อม

• เนื่องจากมุ่งเป้าเฉพาะการโฮสต์คอนเทนเนอร์ จึงตัดแพ็กเกจ เครื่องมือ interpreter และ dependency จำนวนมากที่มักรวมมากับดิสโทร Linux แบบใช้งานทั่วไปออก
  • เมื่อซอฟต์แวร์ที่ไม่จำเป็นลดลง overhead ด้านการปฏิบัติการ และ overhead ด้านความปลอดภัย ก็ลดลงตามไปด้วย
• ความต้องการของ orchestrator, แพลตฟอร์ม และสถาปัตยกรรมที่หลากหลาย ถูกจัดการด้วย variant ซึ่งเป็นบิลด์ตามชุดความเข้ากันได้แต่ละแบบ
  • variant คือรูปแบบที่ประกอบองค์ประกอบที่จำเป็นสำหรับการรันในสภาพแวดล้อมเฉพาะ
  • หากเลือก variant ที่เหมาะสม ก็ไม่ต้องมีองค์ประกอบเพิ่มเติมเพื่อ join เข้าคลัสเตอร์
• ตัว Bottlerocket เอง ไม่มี shell
  • การเข้าถึงระบบทำได้ผ่าน host container แบบมีสิทธิ์ ซึ่งมี shell
  • ใน host container สามารถสำรวจ OS พื้นฐาน และเปลี่ยนการตั้งค่าของระบบที่กำลังรันอยู่ผ่าน API ได้

การอัปเดตที่ปลอดภัยแบบอิง image

• Bottlerocket ออกแบบมาให้อัปเดตได้ แต่ไม่มี package manager
• การอัปเดตถูกส่งมาเป็น image ที่ดาวน์โหลดไปยัง partition ที่กำหนด
  • ระหว่างอัปเดต orchestrator จะ drain node แล้วสั่งให้ Bottlerocket ใช้อัปเดตและรีบูต
  • Bottlerocket จะสลับ partition และบูตเป็นเวอร์ชันใหม่แบบ atomic
• การตั้งค่าระบบจัดการผ่าน API ทำให้ Bottlerocket สามารถจัดการการ migrate การตั้งค่าระหว่างเวอร์ชันได้
  • หากเกิดปัญหาระหว่างอัปเดต สามารถย้อนกลับไปยังเวอร์ชันก่อนหน้าที่ทำงานได้ โดยยังคงการตั้งค่าเดิมไว้
• การจัดการอัปเดตทำได้แบบ manual หรือใช้เครื่องมือเฉพาะของแต่ละ orchestrator
  • Bottlerocket Update Operator (brupop)
  • ECS updater

การออกแบบที่เน้นความปลอดภัย

• การกำหนดค่าขั้นต่ำและวิธีอัปเดตเป็นสิ่งที่รองรับ การออกแบบที่เน้นความปลอดภัย ของ Bottlerocket
• เนื่องจาก variant ถูกส่งมาเป็น image จึงไม่จำเป็นต้องมี package registry หรือ manager ที่อาจเปลี่ยนระบบจนก่อให้เกิดปัญหาความปลอดภัย
• ฟีเจอร์เฉพาะของ Bottlerocket เขียนด้วย Rust และบางส่วนด้วย Golang
  • ทั้งสองภาษาเป็นภาษาแบบคอมไพล์ และมีการป้องกันในตัวต่อปัญหาด้าน memory safety
  • โค้ดทั้งหมดถูกส่งมาเป็น image ที่คอมไพล์ไว้ล่วงหน้า จึงไม่จำเป็นต้องมี shell และ interpreter และลดเส้นทางการรันโค้ดที่ไม่ผ่านการตรวจสอบ
• root filesystem เป็นแบบ immutable
  • dm-verity ให้การตรวจสอบความถูกต้องของ root filesystem แบบโปร่งใส
  • หากตรวจพบการเปลี่ยนแปลงของ block device พื้นฐาน kernel จะรีสตาร์ท
• filesystem ที่เปลี่ยนแปลงได้จะถูกใช้นโยบาย SELinux แบบจำกัดสิทธิ์ ซึ่งเปิดใช้งานและบังคับใช้เสมอ
  • เป็นนโยบายที่ช่วยไม่ให้คอนเทนเนอร์ทำงานที่อันตรายได้ แม้คอนเทนเนอร์จะรันเป็น root ก็ตาม

[GN⁺]

ความคิดเห็นบน Hacker News

• ยังให้ความรู้สึกว่าเป็น โปรเจกต์ของ AWS/Amazon อย่างมาก และเส้นทางที่จะกลายเป็นโปรเจกต์อิสระก็ดูไม่ชัดเจน
  เช่น ถ้าต้องสแกนช่องโหว่ของ OS ก็ใช้ผลิตภัณฑ์ของ Amazon ได้ ไม่อย่างนั้นวิธีก็คลุมเครือ https://bottlerocket.dev/en/faq/#4_2
  ถ้าคิดจะรัน Bottlerocket แค่บน AWS ก็คงโอเค แต่ถ้าจะเป็นผลิตภัณฑ์ที่ “รันในคลาวด์หรือดาต้าเซ็นเตอร์” อย่างที่เว็บไซต์บอก ก็ต้องแก้เรื่องพวกนี้ให้ได้

  • ถ้าพูดอย่างเป็นธรรม ผมไม่คิดว่า การจัดการช่องโหว่ ใน OS อย่าง Flatcar / BottleRocket / CoreOS จำเป็นต้องทำแบบเดียวกับ OS แบบดั้งเดิมอย่าง RHEL
    ถ้าอยากรู้ว่าแพตช์แล้วหรือยัง แค่ดูว่ากำลังรันเวอร์ชันล่าสุดอยู่หรือไม่ก็พอ และถ้าเป็นเวอร์ชันล่าสุดก็หมายความว่าแพตช์ที่มีทั้งหมดถูกใช้แล้ว
    แต่ในอุตสาหกรรมที่มีข้อกำกับดูแล เรื่องนี้อาจเป็นปัญหาได้ เพราะต้องกรอกรายการ “การจัดการช่องโหว่” ในเช็กลิสต์ compliance
    เหตุผลสำคัญที่ OS แบบดั้งเดิมต้องมีการจัดการช่องโหว่ คือพื้นที่การคอนฟิกกว้างมาก องค์ประกอบซอฟต์แวร์ถูกผสมกันอย่างอิสระจากหลายแหล่งและหลายผู้ให้บริการ และแต่ละเวอร์ชันก็เคลื่อนไหวอย่างเป็นอิสระ
    แต่ container OS ไม่ใช่ของที่ใช้กันแบบนั้น
    การค้นหาช่องโหว่เพิ่มเติมใน “latest” เป็นงานของ นักวิจัยด้านความปลอดภัย มากกว่างานของเจ้าของระบบที่ต้องคอยนำแพตช์ upstream มาใช้ให้ทันเวลา
  • ถ้ากำลังมองหาสิ่งที่ไม่ใช่ AWS Talos ก็น่าดูเช่นกัน https://www.talos.dev/
    เป็นโปรเจกต์ที่เก่ากว่า Bottlerocket ด้วย
  • ผมคิดว่ามันไม่ได้ปิดกั้นการสแกนช่องโหว่เองไม่ใช่หรือ
    ถ้ามีวิธีเข้าไปผ่าน SSM หรือใช้ admin container เพื่อรันการสแกน ก็น่าจะทำแบบเดียวกันได้ไหม นี่เป็นคำถามแบบบริสุทธิ์ใจ
  • ไม่เข้าใจว่าทำไม อิมเมจ OS แบบ immutable ถึงต้องสแกนช่องโหว่บนโฮสต์
    แค่ทำก่อน deploy อิมเมจไปยังเครื่องโฮสต์ก็พอแล้ว

• Bottlerocket ไม่ได้มี FIPS mode ต่างจากดิสโทร *nix สำหรับองค์กรส่วนใหญ่
  ใครที่ใช้โปรแกรม compliance ที่กำหนดให้ host OS สำหรับงานต้องมีการเข้ารหัสที่ผ่านการอนุมัติ FIPS ก็ขอให้ประหยัดเวลาไว้
  เพราะเรื่องนี้ Bottlerocket จึงไม่ใช่ตัวเลือกสำหรับเรา และ issue ที่เกี่ยวข้องก็เปิดและมีความเคลื่อนไหวมานานกว่า 2 ปีแล้ว แต่ทีมพัฒนาดูไม่ค่อยมั่นใจว่ามันสำคัญ
  เราได้คุยกับทีมพัฒนาผ่านผู้ดูแลบัญชี AWS โดยตรงแล้ว แต่ดูเหมือนไม่มีความตั้งใจจะเพิ่ม
  เธรดที่เปิดมานานกว่า 2 ปีอยู่ที่นี่: https://github.com/bottlerocket-os/bottlerocket/issues/1667

  • เปิดเผยข้อมูล: ผมทำงานที่ Amazon และเป็น principal engineer ของ Bottlerocket
    การรองรับ FIPS ยังคงเป็นคำขอจากลูกค้าที่อยู่อันดับ 1 แบบทิ้งห่าง
    แต่สำหรับดิสโทรใหม่ที่ไม่เคยมีประวัติการให้ FIPS มาก่อน จังหวะเวลาตอนนี้ไม่ดีนัก
    การรับรอง FIPS 140-2 ใหม่ไม่สามารถทำได้อีกแล้ว และการรับรอง FIPS 140-3 ใหม่ก็ต้องผ่านคิวยาว เพราะทั้งอุตสาหกรรมกำลังอยู่ในช่วงเปลี่ยนผ่าน
    ถ้าเป็นเรื่องที่ทีมพัฒนาผลักดันแล้วแก้ได้ ก็คงเสร็จไปแล้ว
    ถ้าเราทำให้รู้สึกว่าเรื่องนี้ไม่สำคัญก็ขอโทษด้วย ความจริงมันสำคัญ แต่ในกรณีนี้ไม่ได้ช่วยเรื่องกำหนดการ
  • การรับรอง FIPS มักจะต้องการการเปลี่ยนแปลงที่ทำให้ความปลอดภัยอ่อนลงอยู่บ่อยครั้ง
    ถ้าจำเป็นก็ช่วยไม่ได้ แต่โดยส่วนตัวแล้ว การมีการรับรองนี้ถือเป็นสัญญาณลบเล็กน้อย
    ความคิดแบบนี้ไม่ได้มีแค่ผมคนเดียว ทีม Microsoft Windows ก็ดูเหมือนจะมองคล้ายกัน: https://techcommunity.microsoft.com/t5/microsoft-security-ba...
  • “FIPS คือคำตอบของคำถามที่ว่า ‘ถ้าต้องการบังคับให้ซอฟต์แวร์เข้ารหัสทั้งหมดต้องได้รับการอนุมัติจากคณะกรรมการของรัฐบาล จะต้องทำอย่างไร?’” https://twitter.com/matthew_d_green/status/41279364233232384...
    แม้ FIPS เองจะไม่ได้เลวร้าย แต่ก็ควรจำไว้ว่ามันเคลื่อนไหวอยู่ท่ามกลางคนไม่ดีและสภาพแวดล้อมที่ไม่ดี https://threadreaderapp.com/thread/1433451378391883782.html

• ดูน่าสนใจมาก แต่เหมือนคอมเมนต์อื่น ๆ บอกไว้ เส้นทางสำหรับรันเองโดยตรง ยังดูไม่ชัด
  หน้า GitHub ก็ถูกลิงก์ไว้แค่ในหน้าหลัก
  ผมหาคู่มือ VMware เจอที่นี่: https://github.com/bottlerocket-os/bottlerocket/blob/develop...

• คล้ายกับทิศทางของ CoreOS มาก https://fedoraproject.org/coreos/

  • และยังมี Flatcar Linux ที่แยกสายมาจาก CoreOS ด้วย https://www.flatcar.org/
  • อาจเป็นคำถามโง่ ๆ แต่ผมสงสัยว่า ข้อดีของ CoreOS เมื่อเทียบกับทางเลือกอย่าง Alpine คืออะไร
  • สงสัยว่า วิธีพาร์ทิชัน A/B ที่ Bottlerocket ใช้สำหรับอัปเดต เทียบกับ ostree แล้วเป็นอย่างไร

• ไม่ว่าจะใน “Get Started” หรือ FAQ ก็ไม่มีบอก วิธีรัน เลย

  • https://bottlerocket.dev/en/os/1.15.x/install/quickstart/aws...
  • 1. สมัคร AWS ด้วยบัตรเครดิต
    2. เปิด instance ได้ง่าย ๆ เท่าที่ต้องการ

• เป็นโปรเจกต์ที่ดี แต่มีมาตั้งแต่ปี 2020 แล้ว: https://aws.amazon.com/about-aws/whats-new/2020/08/announcin...

• สงสัยว่ามีใครใช้สิ่งนี้นอก AWS ได้สำเร็จบ้างหรือไม่

  • เป็นแค่กรณีเดียว แต่บน Hetzner Cloud ผมทำให้มันทำงานไม่ได้

• ดูค่อนข้างมีประโยชน์สำหรับกรณีใช้งานอย่าง AMD SEV-SNP
  เพราะถ้าต้องการรับประกันพฤติกรรมบางอย่างของเครื่อง ก็จำเป็นต้องมีค่าการวัดของ kernel + initrd + อาร์กิวเมนต์
  ตามอุดมคติแล้ว อยากใช้สิ่งนี้เป็น container hypervisor และสามารถสร้างหลักฐานยืนยันที่ผูกกับแฮชของคอนเทนเนอร์ที่กำลังรันอยู่ได้
  แต่ต้องไม่มีการหลุดออกจากคอนเทนเนอร์ ซึ่งตอนนี้ไม่ค่อยแน่ใจว่าสถานะล่าสุดของด้านนี้เป็นอย่างไร

• ผมคงอยากใช้ CoreOS มากกว่า
  มีโอเพนซอร์สอะไรที่พวกเขาปล่อยออกมาแล้วถูกใช้กันแพร่หลายนอก AWS บ้างไหม?

• ในเว็บไซต์บอกว่า OS ไม่มี shell
  อย่างน้อยก็ยากจะจินตนาการถึง Docker container ที่มีประโยชน์แต่ไม่มี shell script สักตัว
  ถ้าอย่างนั้นการไม่มี shell ก็หมายความว่า Bottlerocket แทบจะใช้ไม่ได้ ยกเว้นบางสถานการณ์เฉพาะกลุ่มไม่ใช่หรือ?

  • ภายใน Docker container สามารถมี shell script ได้
    สิ่งที่ไม่มี shell คือเครื่อง host และถ้าดึง Docker container ที่มี shell มารันแบบมีสิทธิ์ ก็สามารถใช้ shell บน host ได้
  • คอนเทนเนอร์ที่มี shell script จะรวมตัว shell เองมาด้วย
    การนำ shell binary ของเครื่อง host ไปให้คอนเทนเนอร์ที่กำลังรันบน host ใช้นั้นไม่ใช่วิธีที่พบได้ทั่วไป
  • แนวคิดของ Bottlerocket คือบน host เองไม่มี shell ให้ใช้โดยตรง และไม่มีช่องทางเข้าถึงผ่าน SSH หรือวิธีอื่น
    แต่จะมอบความรับผิดชอบนี้ให้ admin container แทน และการเชื่อมต่อจริงจะทำผ่าน SSM/SSH ไปยังคอนเทนเนอร์นั้น
    หากต้องการ root shell ที่นั่น ก็ใช้ยูทิลิตี sheltie ได้
  • การใช้ Docker container ที่ไม่มี shell ด้วยเหตุผลด้านความปลอดภัยไม่ใช่เรื่องแปลก
    ตัวอย่างเช่น distroless
  • ถ้าวาดโครงสร้างระบบย่อยจะได้ประมาณนี้ และใน Bottlerocket มี API ที่เรียกจาก shell ภายในคอนเทนเนอร์ได้
    shells | containers | Bottlerocket | OS kernel