Bottlerocket - Doğrulanmış önyüklemeye sahip minimal, değiştirilemez Linux işletim sistemi

 (bottlerocket.dev)
1 puan yazan GN⁺ 2023-09-24 | 1 yorum | WhatsApp'ta paylaş
  • Bottlerocket, konteyner barındırmaya odaklanan Linux tabanlı bir işletim sistemidir ve Kubernetes gibi orkestratörlerin yönettiği küme worker node'ları için temel işletim sistemi olarak kullanılır
  • Genel amaçlı dağıtımların paketlerini, araçlarını ve yorumlayıcılarını çıkaran minimal yapı sayesinde operasyon yükünü ve saldırı yüzeyini azaltır; ortama göre variant yapılarıyla yalnızca gerekli bileşenleri sunar
  • Kabuk ve paket yöneticisi içermez; sistem, yetkili host container ve API üzerinden yönetilir, güncellemeler ise imaj ve bölüm geçişiyle atomik olarak uygulanır
  • Yapılandırma API tabanlı olarak yönetildiği için sürümler arası geçiş ve geri alma mümkündür; güncelleme yönetimi manuel olarak veya orkestratöre özel araçlarla yapılabilir
  • Değiştirilemez kök dosya sistemi, dm-verity, kısıtlı SELinux, Rust ve kısmen Golang kullanımı sayesinde sistem kurcalama riskini ve doğrulanmamış kod çalıştırma yollarını azaltır

Konteyner kümeleri için temel işletim sistemi

  • Bottlerocket, konteyner barındırma için optimize edilmiş Linux tabanlı bir işletim sistemidir
    • Ücretsiz ve açık kaynaklı bir yazılımdır, geliştirme süreci GitHub üzerinde açık olarak yürütülür
    • Konteynerlerin çalıştığı makine ya da instance'ın temel işletim sistemi olarak kurulur
    • Kubernetes gibi konteyner orkestratörleriyle birlikte çalışacak şekilde tasarlanmıştır ve küme içindeki konteyner yaşam döngüsünün otomasyonunu destekler
    • Bulutta ve veri merkezlerinde çalıştırılabilir
  • Tasarım hedefleri üç başlıkta toplanır: Minimal, Safe Updates, Security Focused

Minimal yapı ve ortama özel variant'lar

  • Yalnızca konteyner barındırmayı hedeflediği için genel amaçlı Linux dağıtımlarında varsayılan olarak gelen birçok paket, araç, yorumlayıcı ve bağımlılığı kaldırır
    • Gereksiz yazılım azaldıkça operasyonel ek yük ve güvenlik ek yükü de birlikte düşer
  • Farklı orkestratör, platform ve mimari gereksinimleri; uyumlu kombinasyonlara göre derlenen variant yapılarıyla yönetilir
    • Variant, belirli bir ortamda çalışmak için gerekli öğelerin bir araya getirilmiş halidir
    • Uygun variant seçildiğinde kümeye katılmak için ek bileşen gerekmez
  • Bottlerocket'ın kendisinde kabuk yoktur
    • Sisteme erişim, kabuk bulunan yetkili bir host container üzerinden sağlanır
    • Host container içinde temel işletim sistemi incelenebilir ve API üzerinden çalışan sistem yapılandırması değiştirilebilir

İmaj tabanlı güvenli güncellemeler

  • Bottlerocket güncellenebilir olacak şekilde tasarlanmıştır ancak paket yöneticisi içermez
  • Güncellemeler, belirli bir bölüme indirilen bir imaj olarak sunulur
    • Güncelleme sırasında orkestratör node'u drain ettikten sonra Bottlerocket'a güncellemeyi uygulamasını ve yeniden başlatmasını söyler
    • Bottlerocket bölümü değiştirir ve yeni sürüme atomik biçimde önyükleme yapar
  • Sistem yapılandırması API ile yönetildiği için Bottlerocket sürümler arası yapılandırma geçişlerini işleyebilir
    • Güncelleme sırasında bir sorun çıkarsa yapılandırmayı koruyarak daha önce çalışan sürüme geri dönülebilir
  • Güncelleme yönetimi manuel yapılabileceği gibi orkestratöre özel araçlar da kullanılabilir

Güvenlik odaklı tasarım

  • Minimal yapı ve güncelleme yöntemi, Bottlerocket'ın güvenlik odaklı tasarımını destekler
  • Variant'lar imaj olarak dağıtıldığı için sistemi değiştirerek güvenlik sorunları yaratabilecek bir paket kayıt deposu veya yöneticiye ihtiyaç duyulmaz
  • Bottlerocket'ın özgün işlevleri Rust ve kısmen Golang ile yazılmıştır
    • Bu iki dil derlenen dillerdir ve bellek güvenliği sorunlarına karşı yerleşik korumalar sunar
    • Tüm kod önceden derlenmiş imajlar halinde sunulduğu için kabuk ve yorumlayıcılara ihtiyaç kalmaz; böylece doğrulanmamış kodun çalıştırılabileceği yollar azalır
  • Kök dosya sistemi değiştirilemez yapıdadır
    • dm-verity, kök dosya sistemi için şeffaf bütünlük denetimi sağlar
    • Alttaki blok aygıtında bir değişiklik algılanırsa kernel yeniden başlatılır
  • Değiştirilebilir dosya sistemlerine, her zaman etkin ve zorunlu olan kısıtlı bir SELinux politikası uygulanır
    • Bu politika, konteyner root olarak çalışsa bile tehlikeli işlemleri gerçekleştirmesini engellemeye yardımcı olur

İlgili okumalar

1 yorum

 
GN⁺ 2023-09-24
Hacker News yorumları

  • Hâlâ güçlü biçimde bir AWS/Amazon projesi niteliğinde ve bağımsız bir projeye dönüşme yolu pek belirgin görünmüyor
    Örneğin OS zafiyet taraması gerekiyorsa Amazon ürününü kullanabilirsiniz; aksi halde yöntem belirsiz https://bottlerocket.dev/en/faq/#4_2
    Bottlerocket’ı yalnızca AWS üzerinde çalıştırmayı düşünüyorsanız sorun olmayabilir, ama web sitesinin söylediği gibi “bulutta veya veri merkezinde çalışan” bir ürün olacaksa bu tür noktaların çözülmesi gerekiyor

    • Adil olmak gerekirse Flatcar / BottleRocket / CoreOS gibi OS’lerde zafiyet yönetiminin RHEL gibi geleneksel OS’lerle aynı şekilde gerekli olduğunu düşünmüyorum
      Yama durumunu bilmek istiyorsanız sadece en güncel sürümü çalıştırıp çalıştırmadığınıza bakmanız yeterli; güncelse mevcut tüm yamalar uygulanmış demektir
      Ancak regüle sektörlerde uyumluluk kontrol listesinde “zafiyet yönetimi” maddesini doldurmak gerektiğinden bu sorun olabilir
      Geleneksel OS’lerde zafiyet yönetiminin gerekli olmasının büyük nedeni yapılandırma alanının çok geniş olması, yazılım bileşiminin birden fazla kaynak ve tedarikçiden rastgele karışması ve her sürümün bağımsız hareket etmesidir
      Ama container OS’leri böyle kullanılan şeyler değildir
      “latest” içinde ek zafiyetler bulmak, sistem sahibinin upstream yamaları zamanında uygulamasından çok güvenlik araştırmacısının işine yakındır
    • AWS dışı bir şey arıyorsanız Talos da bakmaya değer https://www.talos.dev/
      Bottlerocket’tan daha eski bir proje
    • Zafiyet taramasının kendisini engellediğini sanmıyorum
      SSM ile içeri girerek ya da admin container kullanarak tarama çalıştırmanın bir yolu varsa, aynı şekilde yapılabilir mi diye soruyorum; tamamen meraktan
    • Değişmez OS imajında host üzerinde zafiyet taramasına neden ihtiyaç olduğunu anlamıyorum
      Bu, imajı host makineye dağıtmadan önce yapılacak bir iş

  • Bottlerocket, çoğu kurumsal *nix dağıtımının aksine FIPS modu sunmuyor
    İş amaçlı host OS için FIPS onaylı kriptografi gerektiren bir uyumluluk programı kullananlar zamanını boşa harcamasın
    Bu yüzden bizim için Bottlerocket bir seçenek değil; ilgili issue 2 yılı aşkın süredir aktif olarak açık olsa da geliştirme ekibi bunun önemli olduğuna pek ikna olmuş görünmüyor
    AWS’deki özel temsilcimiz üzerinden geliştirme ekibiyle de konuştuk, ama ekleme niyetleri yok gibi görünüyordu
    2 yılı aşkın süredir açık olan thread burada: https://github.com/bottlerocket-os/bottlerocket/issues/1667

    • Açıklama: Amazon’da çalışıyorum ve Bottlerocket’ın baş mühendisi/yöneticisiyim
      FIPS desteği hâlâ müşteri talepleri arasında açık ara 1 numara
      Ancak daha önce FIPS sunma geçmişi olmayan yeni bir dağıtım için zamanlama iyi değil
      Yeni FIPS 140-2 sertifikaları artık alınamıyor; yeni FIPS 140-3 sertifikalarında ise tüm sektör geçiş sürecinde olduğundan uzun bir kuyruğa girmek gerekiyor
      Geliştirme ekibinin bastırarak çözebileceği bir iş olsaydı şimdiye kadar çözülürdü
      Önemli olmadığı izlenimini verdiysek özür dilerim; aslında önemli, fakat bu durumda takvime yardımcı olmuyor
    • FIPS sertifikasyonu çoğu zaman güvenliği zayıflatan değişiklikler gerektirmiştir
      Gerekliyse yapacak bir şey yok, ama sertifikalı olması kişisel olarak bana biraz kötü bir işaret gibi geliyor
      Bu düşüncede yalnız değilim; Microsoft Windows ekibi de benzer bakıyor gibi görünüyor: https://techcommunity.microsoft.com/t5/microsoft-security-ba...
    • “FIPS, ‘tüm kriptografi yazılımlarını bir devlet komitesinin onayına tabi olmaya nasıl zorlarız?’ sorusunun cevabıdır” https://twitter.com/matthew_d_green/status/41279364233232384...
      FIPS’in kendisi kötü olmasa bile, kötü insanlar ve kötü ortamlar içinde hareket ettiğini hatırlamak gerekir https://threadreaderapp.com/thread/1433451378391883782.html

  • Çok ilginç görünüyor, ama diğer yorumlarda da denildiği gibi doğrudan çalıştırma yolu belirsiz görünüyor
    GitHub sayfası da yalnızca ana sayfaya konmuş
    VMware yönergesini burada buldum: https://github.com/bottlerocket-os/bottlerocket/blob/develop...

  • CoreOS’un yönüyle çok benzer https://fedoraproject.org/coreos/

    • Ayrıca CoreOS’tan türetilen Flatcar Linux da var https://www.flatcar.org/
    • Aptalca bir soru olabilir ama Alpine gibi alternatiflere kıyasla CoreOS’un avantajının ne olduğunu merak ediyorum
    • Bottlerocket’ın güncellemeler için kullandığı A/B partition yöntemi ile ostree’nin nasıl karşılaştırıldığını merak ediyorum

  • “Get Started”da ya da FAQ’da hiçbir yerde nasıl çalıştırılacağı anlatılmıyor

  • İyi bir proje ama 2020’den beri var: https://aws.amazon.com/about-aws/whats-new/2020/08/announcin...

  • Bunu AWS dışında başarıyla kullanan biri var mı merak ediyorum

    • Tekil bir örnek ama Hetzner Cloud üzerinde çalıştıramadım

  • AMD SEV-SNP gibi kullanım amaçları için oldukça faydalı görünüyor
    Çünkü bir makinenin belirli davranışlarını garanti etmek için kernel + initrd + argümanlara ait ölçüm değerleri gerekiyor
    İdeal olarak bunu bir container hypervisor olarak kullanıp, çalışan container’ın hash’ine bağlı bir kanıt üretebilmek güzel olurdu
    Ancak container escape olmaması gerekiyor; bu alandaki güncel durumun şu an ne olduğunu pek bilmiyorum

  • Onun yerine CoreOS kullanmayı tercih ederim
    AWS dışında yaygın kullanılan açık kaynak olarak bunların çıkardığı bir şey var mı?

  • Web sitesinde OS’te shell olmadığı yazıyor
    En azından tek bir shell script’i bile olmayan faydalı bir Docker container’ı hayal etmek zor
    O halde shell olmaması, Bottlerocket’ın bazı niş senaryolar dışında genel olarak kullanılamaz olduğu anlamına gelmiyor mu?

    • Docker container’ının içinde shell script’leri olabilir
      Shell olmayan yer host makinedir; içinde shell bulunan bir Docker container’ı alıp ayrıcalıklı şekilde çalıştırırsanız host üzerinde shell kullanabilirsiniz
    • Shell script’i içeren bir container, shell’in kendisini de birlikte içerir
      Host makinedeki shell binary’sini host üzerinde çalışan bir container’a sağlamak yaygın bir yöntem değildir
    • Bottlerocket’ın fikri, host’un kendisinde doğrudan shell olmaması ve SSH ya da başka bir yöntemle erişim yolunun da olmamasıdır
      Bunun yerine bu sorumluluğu admin container’a devreder ve asıl bağlantı SSM/SSH ile oraya yapılır
      Burada root shell gerekiyorsa sheltie yardımcı aracını kullanabilirsiniz
    • Güvenlik gerekçesiyle shell’siz Docker container’ları kullanmak nadir değildir
      Örneğin distroless var
    • Alt sistem yapısını çizerseniz şöyle olur; Bottlerocket’ta container içindeki shell’den çağrılabilen bir API vardır
      shells | containers | Bottlerocket | OS kernel