AWSがBottlerocketという、Linuxベースのオペレーティングシステムを発表した。
InfoQは今回、AWSでコンピュータサービスVPの職にあるDeepak Singh氏に、発表の詳細を聞くことができた。
インタビューの中でDeepak Singh氏は、Linuxベースの新オペレーティングシステムを開発した動機に加えて、Amazon Linuxの運用から得た教訓が開発に活かされていること、セキュリティやパフォーマンスの問題を重視していることなどに触れた上で、
これらの問題にBottlerocketがどのように取り組んでいるかを説明し、現時点での動作対象であるKubernetesサポートを越えるロードマップについても語ってくれた。
InfoQ: Bottlerocketのユニークな点は何でしょう？開発に至った経緯について、簡単に説明して頂けますか？
Deepak Singh: Bottlerocketの開発に着手するまで、私たちは長い時間をかけて、すでに利用可能な選択肢について調べると同時に、コンテナを主要な対象とするディストリビューションがどのようなものであるべきかをカスタマたちと話し合ってきました。その結果開発されたものは、それらカスタマからの要望の他、私たちがAmazon Linuxの運用から得た教訓にも基づいたものになっています。特に対処が必要だと考えたのは、次のような点です。
- 最優先課題としてのセキュリティ: これはブート時のdm-verityとSELinuxのポリシによって実現しています。この流れに乗って、Bottlerocketホスト上でFirecracher VMのローンチを可能にするなど、さらなる開発を行う計画も持っています。
- フレキシビリティ: 新たなカスタマニーズにも対応できるように、Bottlerocketを拡張可能なものにしたいと考えました。これを具体化したものがカスタムビルドシステムです。使いやすさと複雑さのバランスのバランスとして、適切なものだと思います。また将来的に、さまざまなカスタマニーズに適応するように修正された、Bottlerocketのバリアントが数多く存在できるような設計判断を行うように努力しています。
- API設定のモデル化: Aamzon Linuxでは、柔軟性を実現することによる複雑さを多くの面で経験しました。そこで今回は、カスタマに公開する設定オプションを深く理解しなければならない、という考え方からスタートしました。そうすることで、OSの変更がカスタマに及ぼす影響を推察し、破損から保護することが可能になるからです。
InfoQ: Bottlerocketによって、セキュリティや起動時間といったコンテナ関連の問題に対する保護がどのように改善されるのか、技術的な面からもう少し説明して頂けますか？
Singh: Bottlerocketはセキュリティを改善するためにさまざまなテクニックを導入しています。特に重視しているのは、全体的な攻撃対象面を削減することと、永続的な脅威の構築に対して障壁を強化することです。Bottlerocketでは、オペレーティングシステムに含まれるソフトウエアの全体量を削減することで攻撃対象面を制限すると同時に、シェル、Pythonなどのインタプリタ、さらにはSSHまで、攻撃の実行やエスカレーションに使用可能なコンポーネントを排除しています。また、SELinuxの設計ポリシを採用して、コンテナがオペレーティングシステムにとって望ましくない変更が、予期せずに引き起こされることを阻止しています。さらに、位置独立実行形式(Position-independent executables、PIE)の構築や、RELRO(Relocation read-only)リンクの使用、ファーストパーティソフトウェアをすべてRustやGoなどメモリ安全な言語で開発するなど、最新のソフトウェア強化技術を適用しています。
大部分のLinuxディストリビューションとは異なり、Bottlerocketはルートファイルシステムを読み取り専用でマウントします。さらにdm-verityを使って、ファイルシステムの内容が変更されていないことを暗号的に検証します。これらの技術を使うことで、アップデートやリブートを越えて永続化可能な攻撃を成功させるための難易度を高めているのです。
InfoQ: BottlerocketベースのアプリのSDLCは、他のOSで動作する場合とまったく同じなのでしょうか？開発者やDevOpsユーザが新たなツールを習得する必要はありますか？
Singh: Bottlerocketは、開発者が現在行っているのとまったく同じ方法で、アプリケーション開発ができるようにデザインされています。コンテナランタイムとしてKubernetes CRIに適合するcontainerdを使用しているので、既存のコンテナは修正することなくBottlerocketで実行可能なはずです。
ただし運用面では、少し違う部分があります。Bottlerocketはパッケージ毎のアップデートではなく、イメージベースのアップデートを採用することで、オペレーティングシステムの一貫性と予測性を向上しています。Bottlerocketの設定はAPIによって行います。一般的なパッケージコンフィギュレーションファイル(それぞれ独自のフォーマット)とは違って強く型付けされていて、対象ソフトウェアに適用される前に検証が行われます。Bottlerocketにはpsやtopといった一般的なシステムユーティリティは含まれません。SSH経由でアクセスすることもできません。これはBottlerocketのセキュリティ設計の一部です。Bottlerocketの操作は"control"や"admin"コンテナ内から行うことを前提としています。またデバッグ用に"break-glass"というツールが提供されています。
InfoQ: AWSでのみ使用可能なのでしょうか、あるいは、マルチクラウドで利用可能にする計画ないし活動がありますか？
Singh: AWSカスタマに提供されるAWS AMIと、GitHubで私たちがローンチしたプロジェクトを区別する必要があると思います。オープンソースプロジェクトに関しては、コミュニティとともに今後の方向性を定義したいと思っています。Bottlerocketは、ユーザによる拡張や修正が可能になるように構築されています。これにコミュニティが関与することで、別のオーケストレータや新しいAPI機能、あるいは私たちがまだ考えていないものを備えた、新たなバリアントが登場することを期待しています。
InfoQ: 大まかなロードマップを教えてください。具体的に、Kubernetesを越えてどこまで拡張できるのでしょうか？
Singh: ロードマップはGitHubで公開しています。現在はKubernetesをサポートしていますが、BottlerocketはKubernetes専用のオペレーティングシステムという訳ではありません。Amazon ECSをサポートする計画や、無停止アップデートなどの動作をAmazon ECSクラスタに統合する計画がロードマップに記載されています。
セキュリティも継続的なロードマップのテーマです。BottlerocketのSELinuxポリシは今後も継続的に改善を繰り返して行きますし、通常のオーケストレーションされたコンテナによるファイルアクセスのレベルを下げる方法についても検討中です。コンテナ化されたワークロードを運用する別の方法も考えています。高度な分離性を必要とするユースケースを想定した、Firecrackerを使ってマイクロVM内で動作させる方法もそのひとつです。
GPUをアタッチしたインスタンスタイプやARMプロセッサなどのEC2ハードウェアオプションを追加サポートする計画もあります。
Singh氏の話を要約すれば、Amazon Linuxあるいは他の一般的なLinuxディストリビューションによるコンテナ運用の背後にある運用上の問題と、それに対処するためのBottlerocketの進化、さらにはその進化をEC2や、GPUを含む他のコンピューティングサービスで活用する潜在的方法、といった内容になる。ロードマップや入門資料、その他プロジェクトに関する詳細はGitHubにある。