コンテナとKubernetes作成・運用に関するセキュリティ

コンテナセキュリティの課題

前回は、アプリケーションコンテナDockerおよびそのオーケストレーションツールKubernetesについて説明しました。今回は、コンテナおよびKubernetesの作成／運用におけるセキュリティ上の課題について説明します。

コンテナはセキュアなのか？

前回の終わりに、コンテナおよびKubernetesのセキュリティについてまとめました。コンテナ使用によるセキュリティ的なメリットをもう一度挙げていきます。以下のメリットは、コンテナおよびKubernetesの運用方法によって変わります。

• コンテナ内のプロセスを非特権ユーザ（root以外のユーザ）権限で動作させることにより、コンテナホスト上で特権プロセスが動作しない
• コンテナ内では1アプリケーションとすることで、アプリケーションを動作させるのに必要なファイルしか含まない
• 複数のコンテナ間はプロセス空間が分離されており、同一ネットワークを通じてしか接続しない
• 複数Node間のネットワーク接続は、CNI（Container Network Interface）に対応したプラグインにより暗号化可能
• コンテナ外からの接続はポートフォワードのみで行うため、不要なサービスポートへのアクセスがない

上記を見ると、とてもセキュアな環境に見えます。しかしコンテナを使用するにあたっては、いくつかのセキュリティ問題があります。

コンテナホストと同じカーネルを使用するリスク

前回の図を用いて説明します。

Dockerを利用したシステムの構成図

カーネルパニックの危険性

コンテナが軽量な仮想化であることの理由として、コンテナホストと共通のカーネルを使用することが挙げられます。この仕組みは軽量に動作するというメリットと同時に、コンテナ内で動作するアプリケーションが原因でコンテナホスト全体がダウンすることがあり得るというデメリットをもたらします。実際、コンテナ内で動作するアプリケーションが、カーネルの脆弱性／バグを誘発する場合があり、これによりコンテナのアプリケーションがカーネルパニックのような障害を引き起こすと、コンテナホストとそこで動作している他コンテナもダウンすることになります。

リソースの共有

カーネルを複数コンテナ間で共有する仕組みが抱えるリスクとして、リソース使用量があります。コンテナが使用できるリソース量を制限しないと、負荷の高いコンテナがコンテナホストのリソースを専有し続けることがあります。

考えられるリソースは以下の通りです。

• CPU使用量
• 最大プロセス数
• 最大メモリ使用量
• ディスクのアクセス上限（IOPS／サイズ）
• ネットワーク帯域

上記のすべてはcgroupで制限でき、Linux User Namespaceで分離されます。またネットワーク帯域以外のリソースは、dockerコマンドでも指定可能です。ネットワーク帯域は個別にコンテナで使用する仮想NICまたは接続するブリッジに対して、cgroup／tcで制限をかける必要があります。

KubernetesでもCPU／メモリ使用量に対し、同様の制限が可能です。一方プロセス数およびディスクアクセスは、Kubernetesでは制限できません。またネットワーク帯域を制限するには、帯域制御可能なCNIプラグインを使用する必要があります。

カーネル共有の回避策

root権限でアプリケーションを動作させていなければ、カーネルの脆弱性／バグを誘発することはそれほど多くありません。ただまったくないとは断言できませんし、root権限で動作させる必要があるコンテナもあります。その場合の回避策として、軽量VM上でカーネルを動作させる実装があります。kata containerやgVisorなどが有名です。カーネル通過させるシステムコールを選択することで、カーネルパニック時の他コンテナへの影響をなくします。

軽量VMでカーネルを動作させるシステムの構成図

コンテナに含まれる脆弱性

コンテナ内のアプリケーション／ライブラリに含まれる脆弱性についても考慮が必要です。また、コンテナのベースOS・標準ライブラリに脆弱性が見つかることもあります。コンテナホスト側も同様に、カーネル／ライブラリー／コンテナエンジン（containerdなど）の脆弱性が考えられます。

コンテナおよびコンテナ上で動作するアプリケーションは、オープンソースソフトウェアで構成されることが一般的です。そのため、日々な脆弱性が発見され更新され続けます。「ゼロデイ攻撃」と呼ばれる、脆弱性が発見されて修正プログラムが提供される日より前に、その脆弱性を狙った攻撃が起きることもあります。

コンテナホストの脆弱性

コンテナホストに対する脆弱性スキャンには、現在は商用製品だけでなく、OpenVASやVulsなどのオープンソースソフトウェアが存在します。これらのソフトウェアを定期的に実行することで、コンテナホストの安全を確認できます。また、コンテナホスト上のカーネルやコンテナデーモンなど、主要なソフトウェアの定期的なアップデートも必要です。

コンテナの脆弱性スキャン

コンテナの脆弱性スキャンはコンテナイメージのレイヤーごとに行われます。コンテナイメージのレイヤーにはSHA256チェックサムがイメージ名とともに登録されています。レイヤーのチェックサムが同一であれば、一度脆弱性スキャンが済んだ同じチェックサムのレイヤーはスキャンする必要がありません。

コンテナイメージのレイヤー構造

スクリプト言語で作成された自作アプリケーションも、同様に脆弱性を考慮しなければなりません。自作アプリケーションの場合は通常のテストの他に、ペネトレーションテストなどのセキュリティ要件を満たすテストを実施する必要が出ます。

ただしコンテナの作成時に発見されていない脆弱性は、脆弱性スキャンでは検出できません。コンテナに対する定期期な脆弱性スキャンの実施など、継続的な対策が必要になります。

マルウェアの被害

マルウェアとは、不正かつ有害な動作を行う意図で作成された悪意のあるソフトウェア／コードの総称です。他人のリソースで仮想通貨のマイニングを行うマルウェアなどが、よく知られています。

マルウェアの感染ルート

マルウェアは以下のような場合にインジェクション（注入）される可能性が高いです。

• 既存の脆弱性への対応がされていない
• 不要なディレクトリへのアクセスが許可されている
• 不要なサービスポートを公開している

コンテナでは、ネットワークで不要なサービスポートを公開しないようにできます。一方、既存の脆弱性への対応不足や、不要なディレクトリへのアクセスが許可されている場合はありえます。たとえコンテナ環境であっても、脆弱性などを利用したマルウェアの感染への対策は必要です。

コンテナならではのマルウェア感染ルート

さらにコンテナならではの感染ルートとして、コンテナのベースとしたイメージ自体にマルウェアが含まれる場合があります。イメージにマルウェアを含めないための対策として、以下のようなものがあります。

• Docker Hub上で、OS／言語プロバイダーなどが提供する公式のイメージのみを使用する
• Dockerfileを見ることが可能なイメージを使用する
  • Dockerfile内に怪しいファイルがないか確認する
  • Dockerfileから自動生成されたイメージのみを使用する

誰が作成したかわからないコンテナイメージには、マルウェアが含まれている可能性があります。また、起動後すぐには問題がないように見えても、遅延実行するようなマルウェアも考えられます。

コンテナのイメージ作成時に、ベースイメージを選択する際には注意しましょう。