1 poin oleh GN⁺ 2023-09-24 | 1 komentar | Bagikan ke WhatsApp
  • Bottlerocket adalah OS berbasis Linux yang disesuaikan untuk hosting container, dan digunakan sebagai sistem operasi dasar untuk node worker klaster yang dikelola oleh orkestrator seperti Kubernetes
  • Dengan konfigurasi minimal yang menyingkirkan paket, alat, dan interpreter dari distribusi umum, Bottlerocket mengurangi beban operasional dan permukaan serangan, serta hanya menyediakan kombinasi yang diperlukan melalui variant per lingkungan
  • Tanpa shell dan package manager, sistem dikelola melalui host container berhak istimewa dan API, sementara pembaruan diterapkan secara atomik lewat image dan pergantian partisi
  • Konfigurasi dikelola berbasis API sehingga migrasi antarversi dan rollback dimungkinkan, dan pengelolaan pembaruan bisa dilakukan secara manual atau lewat alat khusus tiap orkestrator
  • Melalui root filesystem yang immutable, dm-verity, SELinux yang dibatasi, serta implementasi dalam Rust dan sebagian Golang, Bottlerocket mengurangi risiko modifikasi sistem dan jalur eksekusi kode yang tidak terverifikasi

OS dasar untuk klaster container

  • Bottlerocket adalah sistem operasi berbasis Linux yang dioptimalkan untuk hosting container
    • Merupakan perangkat lunak open source gratis dan dikembangkan secara terbuka di GitHub
    • Dipasang sebagai sistem operasi dasar pada mesin atau instance tempat container berjalan
    • Dirancang untuk bekerja bersama orkestrator container seperti Kubernetes, sehingga mendukung otomatisasi siklus hidup container di dalam klaster
    • Dapat dijalankan di cloud maupun data center
  • Tujuan desainnya diringkas dalam tiga hal: Minimal, Safe Updates, dan Security Focused

Konfigurasi minimal dan variant per lingkungan

  • Karena hanya menargetkan hosting container, Bottlerocket menghapus banyak paket, alat, interpreter, dan dependensi yang biasanya disertakan secara default dalam distribusi Linux umum
    • Berkurangnya perangkat lunak yang tidak perlu juga menurunkan overhead operasional dan overhead keamanan
  • Beragam kebutuhan orkestrator, platform, dan arsitektur dikelola sebagai variant bawaan untuk tiap kombinasi yang kompatibel
    • Variant adalah bentuk rakitan elemen yang diperlukan untuk berjalan di lingkungan tertentu
    • Dengan memilih variant yang sesuai, tidak diperlukan elemen tambahan untuk bergabung ke klaster
  • Bottlerocket sendiri tidak memiliki shell
    • Akses ke sistem dimungkinkan melalui host container berhak istimewa yang memiliki shell
    • Dari host container, OS dasar dapat dijelajahi dan konfigurasi sistem yang sedang berjalan dapat diubah melalui API

Pembaruan aman berbasis image

  • Bottlerocket dirancang agar dapat diperbarui, tetapi tidak menyertakan package manager
  • Pembaruan dikirim sebagai image yang diunduh ke partisi tertentu
    • Saat pembaruan dilakukan, orkestrator akan melakukan drain pada node lalu menginstruksikan Bottlerocket untuk menerapkan pembaruan dan reboot
    • Bottlerocket menukar partisi dan melakukan boot ke versi baru secara atomik
  • Konfigurasi sistem dikelola melalui API sehingga Bottlerocket dapat menangani migrasi konfigurasi antarversi
    • Jika terjadi masalah saat pembaruan, sistem dapat dikembalikan ke versi sebelumnya yang berfungsi sambil tetap mempertahankan konfigurasi
  • Pengelolaan pembaruan dapat dilakukan secara manual atau menggunakan alat khusus tiap orkestrator

Desain yang berfokus pada keamanan

  • Konfigurasi minimal dan cara pembaruan mendukung desain Bottlerocket yang berfokus pada keamanan
  • Karena variant dikirim sebagai image, tidak diperlukan registry paket atau pengelola paket yang bisa memodifikasi sistem dan menimbulkan masalah keamanan
  • Fitur khas Bottlerocket ditulis dalam Rust dan sebagian Golang
    • Keduanya adalah bahasa terkompilasi dan menyediakan perlindungan bawaan terhadap masalah keamanan memori
    • Semua kode dikirim sebagai image yang sudah dikompilasi sebelumnya, sehingga shell dan interpreter tidak diperlukan dan jalur eksekusi kode yang tidak terverifikasi berkurang
  • Root filesystem bersifat immutable
    • dm-verity menyediakan pemeriksaan integritas transparan untuk root filesystem
    • Jika perubahan pada block device dasar terdeteksi, kernel akan melakukan restart
  • Pada filesystem yang dapat diubah diterapkan kebijakan SELinux terbatas yang selalu aktif dan dipaksakan
    • Kebijakan ini membantu mencegah container menjalankan operasi berbahaya meskipun berjalan sebagai root

1 komentar

 
GN⁺ 2023-09-24
Komentar Hacker News
  • Masih sangat terasa sebagai proyek AWS/Amazon, dan jalurnya untuk menjadi proyek independen tampak belum jelas
    Misalnya, jika perlu pemindaian kerentanan OS, Anda bisa memakai produk Amazon; kalau tidak, caranya agak tidak jelas https://bottlerocket.dev/en/faq/#4_2
    Kalau Anda hanya berniat menjalankan Bottlerocket di AWS, ini tidak masalah, tetapi jika ingin menjadi produk yang “berjalan di cloud atau pusat data” seperti yang disebut di situs webnya, bagian seperti ini perlu diselesaikan

    • Agar adil, menurut saya manajemen kerentanan pada OS seperti Flatcar / BottleRocket / CoreOS tidak diperlukan dengan cara yang sama seperti OS tradisional semacam RHEL
      Jika ingin tahu apakah sudah dipatch, cukup lihat apakah Anda menjalankan versi terbaru; jika sudah terbaru, semua patch yang tersedia sudah diterapkan
      Namun di industri teregulasi, ini bisa menjadi masalah karena checklist kepatuhan harus mengisi item “manajemen kerentanan”
      Alasan besar manajemen kerentanan diperlukan pada OS tradisional adalah ruang konfigurasinya sangat luas, komposisi perangkat lunaknya bercampur bebas dari berbagai sumber dan vendor, dan tiap versi bergerak secara independen
      Tetapi OS kontainer bukanlah barang yang digunakan dengan cara seperti itu
      Menemukan kerentanan tambahan di “latest” lebih dekat ke pekerjaan peneliti keamanan, bukan pekerjaan pemilik sistem untuk menerapkan patch upstream tepat waktu
    • Jika mencari sesuatu yang bukan AWS, Talos juga layak dilihat https://www.talos.dev/
      Proyek ini lebih tua daripada Bottlerocket
    • Sepertinya pemindaian kerentanan itu sendiri tidak diblokir, bukan?
      Ini pertanyaan murni: jika ada cara masuk lewat SSM atau memakai kontainer admin untuk menjalankan pemindaian, bukankah bisa dilakukan dengan cara yang sama?
    • Saya tidak mengerti mengapa image OS immutable memerlukan pemindaian kerentanan di host
      Itu bisa dilakukan sebelum image dideploy ke mesin host
  • Berbeda dari kebanyakan distro *nix enterprise, Bottlerocket tidak menyediakan mode FIPS
    Jika Anda memakai program kepatuhan yang mewajibkan kriptografi yang disetujui FIPS pada OS host untuk pekerjaan, sebaiknya hemat waktu Anda
    Karena itu, bagi kami Bottlerocket bukan pilihan, dan meski isu terkait sudah aktif terbuka lebih dari 2 tahun, tim pengembang tampaknya tidak yakin bahwa ini penting
    Kami juga sudah berbicara dengan tim pengembang melalui penanggung jawab khusus AWS kami, tetapi mereka tampaknya tidak punya niat menambahkannya
    Thread yang sudah terbuka lebih dari 2 tahun ada di sini: https://github.com/bottlerocket-os/bottlerocket/issues/1667

    • Pengungkapan: saya bekerja di Amazon dan merupakan principal engineer Bottlerocket
      Dukungan FIPS masih menjadi permintaan pelanggan nomor satu dengan selisih besar
      Namun waktunya kurang menguntungkan untuk distro baru yang belum punya riwayat penyediaan FIPS sebelumnya
      Sertifikasi FIPS 140-2 baru sudah tidak bisa lagi diperoleh, dan sertifikasi FIPS 140-3 baru harus melewati antrean panjang karena seluruh industri sedang bertransisi
      Jika ini sesuatu yang bisa diselesaikan dengan dorongan keras dari tim pengembang, hal itu pasti sudah dilakukan
      Jika kami memberi kesan bahwa ini tidak penting, saya minta maaf; kenyataannya ini penting, tetapi dalam kasus ini hal tersebut tidak membantu jadwal
    • Sertifikasi FIPS sering kali menuntut perubahan yang justru melemahkan keamanan
      Jika memang diperlukan, mau bagaimana lagi, tetapi secara pribadi saya melihat adanya sertifikasi itu sebagai sinyal yang agak buruk
      Pandangan ini bukan hanya milik saya; tim Microsoft Windows tampaknya juga melihatnya serupa: https://techcommunity.microsoft.com/t5/microsoft-security-ba...
    • “FIPS adalah jawaban atas pertanyaan ‘bagaimana caranya memaksa semua perangkat lunak kriptografi menjadi objek persetujuan komite pemerintah?’” https://twitter.com/matthew_d_green/status/41279364233232384...
      Sekalipun FIPS itu sendiri tidak jahat, perlu diingat bahwa ia bergerak bersama orang-orang jahat dan dalam lingkungan yang jahat https://threadreaderapp.com/thread/1433451378391883782.html
  • Terlihat sangat menarik, tetapi seperti komentar lain, jalur untuk menjalankannya sendiri tampak samar
    Halaman GitHub juga hanya muncul di halaman utama
    Saya menemukan panduan VMware di sini: https://github.com/bottlerocket-os/bottlerocket/blob/develop...

  • Arahnya sangat mirip dengan CoreOS https://fedoraproject.org/coreos/

    • Dan ada juga Flatcar Linux yang diturunkan dari CoreOS https://www.flatcar.org/
    • Mungkin ini pertanyaan bodoh, tetapi saya penasaran apa keunggulan CoreOS dibanding alternatif seperti Alpine
    • Saya penasaran bagaimana metode partisi A/B yang dipakai Bottlerocket untuk update dibandingkan dengan ostree
  • Di “Get Started” maupun FAQ tidak ada cara menjalankannya

  • Proyek yang bagus, tetapi sudah ada sejak 2020: https://aws.amazon.com/about-aws/whats-new/2020/08/announcin...

  • Saya penasaran apakah ada orang yang berhasil memakainya di luar AWS

    • Hanya satu kasus, tetapi di Hetzner Cloud saya tidak berhasil menjalankannya
  • Tampaknya cukup berguna untuk penggunaan seperti AMD SEV-SNP
    Karena untuk menjamin perilaku tertentu dari mesin, diperlukan pengukuran atas kernel + initrd + argumen
    Idealnya, ini dipakai sebagai hypervisor kontainer, lalu bisa menghasilkan attestasi yang terikat pada hash kontainer yang sedang berjalan
    Namun tidak boleh ada container escape, dan saya tidak begitu tahu seperti apa kondisi terkini di bidang ini

  • Saya lebih ingin memakai CoreOS saja
    Apakah mereka pernah merilis open source yang banyak dipakai di luar AWS?

  • Di situs webnya tertulis bahwa OS ini tidak memiliki shell
    Sulit membayangkan kontainer Docker yang berguna tanpa setidaknya satu skrip shell
    Kalau begitu, bukankah tidak adanya shell berarti Bottlerocket pada dasarnya tidak bisa dipakai kecuali untuk beberapa skenario niche?

    • Di dalam kontainer Docker bisa saja ada skrip shell
      Yang tidak memiliki shell adalah mesin host, dan jika Anda mengambil kontainer Docker yang berisi shell lalu menjalankannya dengan privilege, Anda bisa memakai shell di host
    • Kontainer yang menyertakan skrip shell juga menyertakan shell itu sendiri
      Memberikan biner shell dari mesin host ke kontainer yang berjalan di host bukanlah cara yang umum
    • Ide Bottlerocket adalah host itu sendiri tidak memiliki shell langsung, dan juga tidak ada jalur akses lewat SSH atau metode lain
      Sebagai gantinya, tanggung jawab ini didelegasikan ke kontainer admin, dan koneksi sebenarnya dilakukan ke sana melalui SSM/SSH
      Jika membutuhkan shell root di sini, Anda bisa memakai utilitas sheltie
    • Memakai kontainer Docker tanpa shell demi alasan keamanan bukan hal yang langka
      Contohnya distroless
    • Jika struktur subsistemnya digambarkan, kira-kira seperti ini, dan Bottlerocket memiliki API yang bisa dipanggil dari shell di dalam kontainer
      shells | containers | Bottlerocket | kernel OS