コンテナのセキュリティ（第 2 回）: ノード イメージとコンテナ イメージ

編集部注 : コンテナのセキュリティをテーマにした連載の第 2 回目です。

デプロイするコンテナのイメージは、既知の脆弱性を持たず、最小限の機能を備えたものでなければなりません。そうであれば、攻撃面が小さくなり、インフラストラクチャに残された不要な穴が攻撃者によって悪用されることを防げます。

コンテナの場合、他のデプロイ メカニズムとは異なり、セキュアにしなければならない OS が 2 つあります。コンテナのノード OS とホスト OS、つまりコンテナを実行する OS と、コンテナ自体の内部で実行されるコンテナ イメージです。Google のマネージド コンテナ サービスである Google Kubernetes Engine では、Google Cloud Platform（GCP）上の他のホステッド サービスと同様に、Google がノード OS を管理しています。一方、コンテナ イメージについては複数の選択肢があります。

Kubernetes Engineでは、ノード イメージとコンテナ イメージのそれぞれについて、当初から次のような選択肢が用意されています。

• ノード イメージ : Container-Optimized OS か Ubuntu
  
• コンテナ イメージ : すぐに利用できる Debian と Ubuntu のイメージが Google Container Registry にあります。もちろん、独自イメージも導入可能です。
  

ノード イメージ : Container-Optimized OS（COS）

Chromium OS をベースとする COS は、本番サービス実行用の管理可能なプラットフォームを提供するため、以下をはじめとするさまざまなセキュリティ設計原則を実装しています。

• 最小限の OS フットプリント : COS は GCP 上でのコンテナ実行に最適化されており、実行をサポートするうえで絶対に必要な機能とパッケージだけに絞り込まれています。コンテナが自らの依存コードをパッケージングしているため、攻撃面が大幅に縮小するとともにパフォーマンスが向上しています。
  

• 読み出し専用の rootfs : COS のルート ファイルシステム（rootfs）は読み出し専用でマウントされています。しかも、そのチェックサムはカーネル ブートのたびにチェックされます。rootfs が改竄されていればカーネルはブートしません。また、他のいくつかのマウントがデフォルトで実行不能に設定されています。
  

• ステートレスなシステム構成 : rootfs が読み出し専用なのはセキュリティ的には都合がよいことですが、そのままではシステムは実用上使い物になりません（たとえば、システム ログインのためにユーザーを作成、追加できなければ困ります）。そこで私たちは、rootfs をカスタマイズして、/etc をステートレスにしました。そうすれば、起動時に設定を書き込めるようにしつつ、リブート時に設定が残らないようにすることができます。つまり、COS ノードはリブートのたびにクリーンな状態で起動します。ユーザーのホーム ディレクトリ、ログ、Docker イメージなどは rootfs の一部ではないので、リブート後も永続化されます。
  

• セキュリティが強化されたカーネル : COS には、Chromium OS Linux Security Module（LSM）の一部機能など、セキュリティ強化を目的としたカーネル機能が複数組み込まれています。たとえば、LoadPin（Chromium OS の LSM の 1 つ）と読み出し専用 rootfs、rootfs チェックの組み合わせにより、カスタム カーネル モジュールのロードによるカーネルの改竄を防ぐことができます。また、IMA、AUDIT、APPARMOR などの Linux 機能は、セキュリティ ポリシーの裏をかいて何かを隠すことを難しくします。
  

• セキュリティを第一に考えたデフォルト : COS は、いくつかの機能に適切なデフォルト値を提供することでセキュリティを強化しています。ptrace や非特権ユーザーの bpf を無効にする sysctl 設定、ロックダウンされたファイアウォールなどがそれです。このような適切なデフォルトを自動的にインスタンスに適用することは、クラスタ / プロジェクト / 組織全体のセキュリティ強化にとって大きな意味があります。
  

• 自動アップグレード : COS の自動更新機能により、実行中の VM に対してタイムリーにセキュリティ パッチを送信できます。Kubernetes Engine が管理する COS でノードの自動アップグレード機能を有効にすると、セキュリティと安定性をバランスよく確保できます。
  

• Google 社内でのソースからのビルド : COS の各パッケージは、Linux カーネル自体を含め、Chromium OS コード リポジトリのソースからビルドされます。そのため、OS に何が組み込まれ、誰がそれをチェックインし、どのバージョンからそれが導入されているかを正確に把握できます。脆弱性が見つかったときには、どのレベルであっても、すぐにパッチを適用し、パッケージを更新することができます。
  

• 脆弱性の継続的なスキャンと対策 : OS のコンポーネントに脆弱性が見つかったときは CVE スキャニング システムがアラートを発します。脆弱性が見つかると、COS チームは、パッチを適用したリリースをお客様に提供することを最優先にして対策を講じます。また、Google のインシデント対策チームと協力して、セキュリティ パッチが COS に迅速に組み込まれるように手配します。たとえば Spectre / Meltdown 脆弱性の場合、Google Cloud では脆弱性の公表前にパッチ適用済みの COS が使用可能でした。
  

• テストと品質保証のプロセス : 新しい COS イメージは、syzkaller によるカーネルのファズテスト、クラスタ レベルの Kubernetes テスト、複数のパフォーマンス ベンチマークなど、さまざまなレベルで徹底的にテストされてから Google Cloud に送られます。このようにして、リリースの安定性と品質が確保されています。
  

Kubernetes Engineは、すべてのマスターノードのOSイメージとしてCOSを使っています。ワークロードのノードイメージにもデフォルトではCOSが使用されています。特別な要件がある場合を除き、セキュリティに優れるCOSを使うことをお勧めします。

コンテナ イメージ : Debian と Ubuntu

セキュリティ上の観点から言えば、どちらのコンテナ イメージを使用するかは重要ではありません。大切なのは、定期的にスキャンして既知の脆弱性を見つけ出すことです。私たちは、定期的なパッチ適用とテストを通じて Debian と Ubuntu のベース イメージをメンテナンスしており、それらを再現可能な形でゼロからリビルドできます。皆さんが独自コンテナをビルドするときにも、Google が提供するベース イメージをお使いになれます。

• Debian は Google Container Registry から入手可能
  
• Ubuntu は Google Container Registry から入手可能
  

* この投稿は米国時間 4 月 5 日、Container-Optimized OS の Software Engineer である Aditya Kali と、Cloud Container Tools の Software Engineer である Dan Lorenc によって投稿されたもの（投稿はこちら）の抄訳です。

- By Aditya Kali, Software Engineer, Container-Optimized OS and Dan Lorenc, Software Engineer, Cloud Container Tools