Bottlerocket - 検証済みブートを備えた最小限の不変 Linux OS

 (bottlerocket.dev)
1 ポイント 投稿者 GN⁺ 2023-09-24 | 1件のコメント | WhatsAppで共有
  • Bottlerocket は、コンテナホスティング向けに最適化された Linux ベースの OS で、Kubernetes のようなオーケストレーターが管理するクラスタワーカーノードの基本 OS として使われる
  • 汎用ディストリビューションに含まれるパッケージ、ツール、インタープリターを削ぎ落とした 最小構成 により、運用負荷と攻撃対象領域を縮小し、環境ごとの variant で必要な組み合わせだけを提供する
  • シェルやパッケージマネージャーを持たず、権限付き host コンテナと API を通じてシステムを扱い、更新はイメージとパーティション切り替えによってアトミックに適用される
  • 設定は API ベースで管理されるため、バージョン間のマイグレーションとロールバックが可能で、更新管理は手動またはオーケストレーター別ツールで行える
  • 不変のルートファイルシステム、dm-verity、制限付き SELinux、Rust と一部 Golang による実装を通じて、システム改ざんや未検証コードの実行経路を減らしている

コンテナクラスタ向けの基本 OS

  • Bottlerocket は、コンテナホスティングに最適化された Linux ベースのオペレーティングシステム
    • 無料のオープンソースソフトウェアであり、GitHub で公開開発されている
    • コンテナが実行されるマシンやインスタンスの 基本オペレーティングシステム としてインストールされる
    • Kubernetes のようなコンテナオーケストレーターとともに動作するよう設計されており、クラスタ内のコンテナライフサイクル自動化を支援する
    • クラウドとデータセンターで実行可能
  • 設計目標は Minimal、Safe Updates、Security Focused の3つに整理される

最小構成と環境別 variant

  • コンテナホスティングのみを目的としているため、汎用 Linux ディストリビューションに標準で含まれる多くのパッケージ、ツール、インタープリター、依存関係を取り除いている
    • 不要なソフトウェアが減ることで、運用オーバーヘッド と セキュリティオーバーヘッド もあわせて低減される
  • さまざまなオーケストレーター、プラットフォーム、アーキテクチャ要件は、互換組み合わせごとにビルドされた variant で管理される
    • variant は、特定環境で実行するために必要な要素を組み合わせた形態
    • 適切な variant を選べば、クラスタに参加するための追加要素は不要
  • Bottlerocket 自体には シェルがない
    • システムへのアクセスは、シェルを備えた権限付き host コンテナ を通じて可能
    • host コンテナでは、基盤 OS を調査し、API を通じて実行中システムの設定を変更できる

イメージベースの安全な更新

  • Bottlerocket は更新可能なように設計されているが、パッケージマネージャー は含まない
  • 更新は、特定パーティションにダウンロードされる イメージ として配信される
    • 更新時にはオーケストレーターがノードを drain した後、Bottlerocket に更新の適用と再起動を指示する
    • Bottlerocket はパーティションを切り替え、新バージョンへアトミックにブートする
  • システム設定は API で管理されるため、Bottlerocket がバージョン間の設定マイグレーションを処理できる
    • 更新中に問題が発生した場合でも、設定を維持したまま以前に動作していたバージョンへ戻せる
  • 更新管理は手動でも、オーケストレーター別ツールでも行える

セキュリティ重視の設計

  • 最小構成と更新方式は、Bottlerocket の セキュリティ重視設計 を支えている
  • variant がイメージとして配信されるため、システム変更によってセキュリティ問題を引き起こしうる パッケージレジストリやマネージャー は不要
  • Bottlerocket 独自の機能は Rust と一部 Golang で書かれている
    • これら2つの言語はコンパイル言語であり、メモリ安全性に関する組み込み保護を提供する
    • すべてのコードは事前コンパイル済みイメージとして配信されるため、シェルやインタープリターが不要で、未検証コードの実行経路が減る
  • ルートファイルシステムは 不変
    • dm-verity がルートファイルシステムの透過的な整合性検証を提供する
    • 基盤ブロックデバイスの変更が検出されると、カーネルが再起動する
  • 変更可能なファイルシステムには、常時有効で強制適用される制限付き SELinux ポリシーが適用される
    • コンテナが root で実行されても危険な操作を実行できないよう支援するポリシー

関連記事

1件のコメント

 
GN⁺ 2023-09-24
Hacker Newsのコメント

  • 依然として AWS/Amazonのプロジェクトという性格が強く、独立したプロジェクトになる道筋ははっきり見えない
    例えばOSの脆弱性スキャンが必要ならAmazon製品を使えばよく、そうでなければ方法が曖昧 https://bottlerocket.dev/en/faq/#4_2
    BottlerocketをAWS上でだけ動かすつもりなら問題ないだろうが、Webサイトで述べているように「クラウドやデータセンターで実行」される製品になるには、こうした点を解決する必要がある

    • 公平に見ると、Flatcar / BottleRocket / CoreOSのようなOSにおける脆弱性管理は、RHELのような従来型OSと同じ方式では必要ないと思う
      パッチ適用状況を知りたいなら、最新バージョンを動かしているかだけ見ればよく、最新なら利用可能なパッチはすべて適用済みの状態である
      ただし規制産業では、コンプライアンスのチェックリストに「脆弱性管理」の項目を埋める必要があり、問題になり得る
      従来型OSで脆弱性管理が必要な大きな理由は、構成の幅が非常に広く、ソフトウェア構成が複数の出所やベンダーから任意に混ざり、各バージョンが独立して動くためである
      しかしコンテナOSはそのように使うものではない
      「latest」から追加で脆弱性を見つけ出す作業は、システム所有者が上流のパッチを適時適用する仕事というより、セキュリティ研究者の仕事に近い
    • AWS以外を探しているなら Talos も見る価値がある https://www.talos.dev/
      Bottlerocketよりも古いプロジェクトである
    • 脆弱性スキャン自体を妨げているわけではないのでは、と思う
      SSMで入るかadminコンテナを使ってスキャンを実行する方法があるなら、同じようにできるのではないかという純粋な疑問である
    • イミュータブルOSイメージに対して、ホスト上で脆弱性スキャンがなぜ必要なのか分からない
      イメージをホストマシンにデプロイする前にやれば済むことだ

  • Bottlerocketは、ほとんどのエンタープライズ向け*nixディストリビューションと違って FIPSモードを提供していない
    業務用ホストOSにFIPS承認済み暗号化を必要とするコンプライアンスプログラムを使っている人は、時間を節約してほしい
    このため私たちにとってBottlerocketは選択肢ではなく、関連Issueは2年以上活発に開かれているが、開発チームは重要だと確信していないように見える
    AWSの専任担当者を通じて開発チームとも話したが、追加する意志はなさそうだった
    2年以上開いているスレッドはこれ: https://github.com/bottlerocket-os/bottlerocket/issues/1667

    • 開示: Amazonで働いており、Bottlerocketのプリンシパルエンジニアである
      FIPSサポートは今も顧客からの要望の中で圧倒的な最優先事項である
      ただし、過去に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/

    • そしてCoreOSから派生した Flatcar Linux もある https://www.flatcar.org/
    • ばかな質問かもしれないが、Alpineのような代替と比べて CoreOSの利点 が何なのか気になる
    • Bottlerocketがアップデートに使う A/Bパーティション方式 とostreeはどう比較されるのか気になる

  • “Get Started”にもFAQにも実行方法が載っていない

  • 良いプロジェクトだが、2020年から存在していたもの: https://aws.amazon.com/about-aws/whats-new/2020/08/announcin...

  • AWSの外でこれをうまく使っている人がいるのか気になる

    • 単一の事例だが、Hetzner Cloudでは動かせなかった

  • AMD SEV-SNPのような用途にはかなり有用に見える
    マシンの特定の動作を保証するには、カーネル + initrd + 引数に対する測定値が必要だからだ
    理想的には、これをコンテナハイパーバイザーとして使い、実行中のコンテナのハッシュに紐づいた証明を生成できるとよさそう
    ただしコンテナ脱出がないことが前提だが、この分野の最新状況が今どうなっているのかはよく分からない

  • むしろCoreOSを使いたい
    彼らがAWS外で広く使われているオープンソースを出したことはあるのだろうか？

  • WebサイトにはOSにシェルがないと書かれている
    少なくともシェルスクリプトが1つもない有用なDockerコンテナは想像しにくい
    だとすると、シェルがないというのは、Bottlerocketが一部のニッチなシナリオを除けばおおむね使えないという意味ではないのか？

    • Dockerコンテナ内にはシェルスクリプトがあり得る
      シェルがないのはホストマシンであり、シェル入りのDockerコンテナを持ってきて権限付きで実行すれば、ホスト上でシェルを使える
    • シェルスクリプトを含むコンテナは、シェル自体も一緒に含んでいる
      ホストマシンのシェルバイナリを、ホスト上で実行中のコンテナに提供する方式は一般的ではない
    • Bottlerocketの考え方は、ホスト自体に直接シェルもなく、SSHや他の方法でアクセスする経路もないというもの
      その代わり、この責任をadminコンテナに委譲し、実際の接続はSSM/SSHでそこに対して行う
      ここでルートシェルが必要なら、sheltieユーティリティを使えばよい
    • セキュリティ上の理由で、シェルのないDockerコンテナを使うのは珍しいことではない
      例えばdistrolessがある
    • サブシステム構造を図にするとこうで、Bottlerocketにはコンテナ内のシェルから呼び出せるAPIがある
      shells | containers | Bottlerocket | OS kernel