このページでは、Google Cloud 上で実行される Container-Optimized OS のセキュリティ機能の概要を説明します。
OS のセキュリティ
Container-Optimized OS from Google は Chromium OS に基づいており、本番環境サービスの実行向けに適切に構成されたプラットフォームを提供するために、いくつかのセキュリティ設計の原則が実装されています。
最小限の OS フットプリント
これは、Container-Optimized OS のセキュリティの中核をなすものです。Container-Optimized OS はコンテナの実行向けに最適化されており、またコンテナは自身の依存関係をパッケージ化しているため、不要なパッケージをカットすることで OS の攻撃範囲を最小限に抑えることができます。
不変のルート ファイルシステムと確認済みブート
Container-Optimized OS のルート ファイルシステムは、常に読み取り専用としてマウントされます。 また、そのチェックサムはビルド時に計算済みであり、ブートのたびにカーネルによって確認されます。 このメカニズムによって、ローカルを永続的に変更してマシンを所有する攻撃を防ぐことができます。さらに、他のいくつかのマウントはデフォルトで実行不可能になっています。詳細については、ファイルシステムをご覧ください。
ステートレス構成
読み取り専用のルート ファイルシステムは、セキュリティ面では優れていますが、システムが使いにくくなります。たとえば、システムにログインするには、ユーザーを作成して追加する機能が必要です。この問題に対処するため、Google は、/etc/
が書き込み可能であってもステートレスになるようにルート ファイルシステムをカスタマイズしています。これにより実行時に構成設定を書き込むことができますが、これらの設定は再起動時に維持されません。したがって、Container-Optimized OS ノードは再起動するたびにクリーンな状態から起動します。ユーザーのホーム ディレクトリ、ログ、Docker イメージなどの特定のデータはルート ファイルシステムの一部ではないため、再起動を行っても維持されます。
セキュリティが強化されたカーネル
Container-Optimized OS では、Chromium OS に含まれている Integrity Measurement Architecture(IMA)、監査、Kernel Page Table Isolation(KPTI)、Linux セキュリティ モジュール(LSM)など、複数のセキュリティ強化カーネル機能が有効になっています。さらに、Container-Optimized OS は、よりきめ細かいセキュリティ ポリシーを適用できるようにする、seccomp や AppArmor などのセキュリティ機能をサポートしています。
セキュリティが中心のデフォルト
Container-Optimized OS は、複数の機能にセキュリティを考慮したデフォルト値を提供することで、さらなるレベルの強化を実現しています。これには、ptrace と非特権 BPF の無効化、ファイアウォールのロックダウンなどを行う sysctl 設定などが含まれます。 これらのデフォルトが一連のインスタンスに自動的に適用されることにより、クラスタ、プロジェクト、組織の全体的なセキュリティ保護に役立ちます。
自動更新
Container-Optimized OS の自動更新機能により、実行中の VM にセキュリティ パッチをタイムリーに配信できます。Container-Optimized OS が Kubernetes Engine によって管理されている場合は、ノードの自動アップグレードを利用することにより、セキュリティと安定性のバランスが実現されます。
ファイルシステム
以下に Container-Optimized OS ノードイメージのファイルシステムのパスの一覧を示し、その特性や推奨される使用方法を説明します。
パス | プロパティ | 目的 |
---|---|---|
/ |
|
整合性を維持するため、ルート ファイルシステムは読み取り専用としてマウントされます。カーネルによって、整合性のあるルート ファイルシステムが起動時に確認され、エラー時にはブートが拒否されます。 |
/home /var |
|
これらのパスは、ブートディスクの存続期間にわたって保存されるようにデータを格納するためのものです。これらは /mnt/stateful_partition からマウントされます。 |
/var/lib/google /var/lib/docker /var/lib/toolbox |
|
これらのパスはそれぞれ、Compute Engine パッケージ(アカウント マネージャー サービスなど)、Docker、Toolbox の作業ディレクトリです。 |
/var/lib/cloud |
|
このパスは、cloud-init パッケージの作業ディレクトリです。 |
/etc |
|
通常、構成(cloud-init によって定義される systemd サービスなど)が保存されます。インスタンスを新規作成するときやインスタンスを再起動するときに cloud-init が適用されるため、インスタンスの望ましい状態を cloud-init にキャプチャすることをおすすめします。 |
/tmp |
|
通常、一時的な領域として使用され、永続的なデータの格納には使用できません。 |
/mnt/disks |
|
/mnt/disks 内のディレクトリには永続ディスクをマウントできます。 |
ファイアウォール
デフォルトでは、Container-Optimized OS は、ポート 22 の SSH を除くすべての受信 TCP/UDP 接続を拒否するように構成されています。デフォルトを変更してその他のポートを開く方法については、ホスト ファイアウォールの構成をご覧ください。
インスタンス アクセス
デフォルトでは、Container-Optimized OS には、アクセス可能なユーザー アカウントはありません。 ユーザー アカウントと SSH 認証鍵は、インスタンスまたはプロジェクトのメタデータあるいは OS Login によって管理されます。 OS Login では、IAM を使用してインスタンスへのアクセスを管理できます。よりきめ細かいアクセス制御(sudo と sudo 以外の区別)、識別可能な SSH 認証鍵、組織ログイン ポリシーが可能です。
SSH デーモンは、パスワードベースの認証および root ログインを拒否するように構成されています。 ただし、ユーザー アカウントが OS Login で管理されていない限り、ユーザーはログイン後に sudo を使用して root 権限を獲得できます。
インフラストラクチャのセキュリティ
イメージを開発、構築、デプロイする際、Container-Optimized OS チームでは、全体的に Chromium OS と Google 両方の長年の経験に基づき、OS 自体のさまざまな強化機能に加え、ソフトウェアのサプライ チェーンも重要視するとともにインフラストラクチャのセキュリティを優先しています。
Google でのソースからの構築
Linux カーネル自体を含む Container-Optimized OS の各パッケージは、ChromiumOS コード リポジトリのソースから構築されています。これは、OS に何が組み込まれるか、どの人物がチェックインしたか、どのバージョンに導入されたかなどを、Container-Optimized OS チームが正確に把握していることを意味します。このため、脆弱性が発見された場合は、どのレベルでも、すばやくパッケージにパッチを適用して更新できます。
継続的な脆弱性(CVE)のスキャンと対応
CVE スキャン システムにより、OS のカーネルやパッケージに脆弱性が発見された場合は、必ず Container-Optimized OS チームにアラートが通知されます。これは、Android と Chromium OS の脆弱性検出に使用されているのと同じシステムです。Container-Optimized OS チームは、パッチ適用リリースの作成を優先して対応します。また、Container-Optimized OS チームは、Google のインシデント対応チームと連携して、Container-Optimized OS の幅広いセキュリティ パッチを迅速に提供します。
テストと認定プロセス
新しい Container-Optimized OS イメージを Google Cloud に公開する前に、syzkaller によるカーネルのファズテスト、クラスタレベルの Kubernetes テスト、Compute Engine の機能との統合テスト、複数のパフォーマンス ベンチマークなど、複数のレベルでイメージをテストしています。これにより、リリースの安定性と品質を確保しています。