コンテナーのセキュリティは長年無視されてきましたが、今こそコンテナーのロックダウンに着手すべきときです。この記事では、その方法について説明します。

DevOps環境で何かを行う場合、コンテナーは大きな力を発揮します。コンテナーを使用すれば各サーバーで実行できるジョブが増え、サーバー間のプロジェクトの移動が容易になります。
ただし、非常の多くの人が魔法のように安全と言わんばかりにコンテナーを扱っていますが、それは間違いです。
実際、オープンソースセキュリティ企業のSnyk社が、自社のコンテナースキャン機能で最も広く普及している10個のDockerイメージを分析したところ、すべてのイメージに脆弱なシステムライブラリがあることが明らかになりました。その中でも群を抜いて最悪だったのはDocker社の公式のNode.jsイメージで、580もの脆弱なシステムライブラリが含まれていました。
これは大きな問題です。
コンテナーの基本的なセキュリティの問題は、その安全性がコンテナー内のプログラムによって決まるという点にあり、それがコンテナーに適切に組み込まれていたとしても、「ガベージインガベージアウト」という言葉が当てはまります。それではここから、コンテナーを保護する5つの方法を見ていきましょう。

 

1. コンテナーのソフトウェアを信用しない

コンテナーの保護は、それが必要であると認識することから始まります。これについて、VMware社のバイスプレジデント兼最高オープンソース責任者であるDirk Hohndel氏は、2019 Open Source Leadership Summitで次のように指摘しています。「コンテナーのパッケージング形式はWindowsの.exeやmacOSの.dmgに似ており、基本的にファイルシステムにすべての依存関係が含められます。(コンテナーには)このような依存関係が含められているため、それらのバイナリの提供元、作成方法、およびそれらに対応するソースのことを心配しなければなりません」。
もちろん、信頼できるレジストリの署名付きのイメージだけを使用することでこのような心配は減りますが、Snyk社が明らかにしたように、Docker社のイメージにさえセキュリティホールが存在するのが実情です。
ここでの教訓としては、コンテナーを展開する前にその内容をダブルチェックすること、不明なソフトウェアや古いソフトウェアでコンテナーを実行しないこと、そしてコンテナーイメージに最新かつ最高のプログラムとライブラリが含まれていると謳われているからといって、実際にそうであると思ってはならないことが挙げられます。

 

2. コンテナーの状況を確実に把握する

コンテナーを展開するにあたっては、その前にコンテナー内の状況を確実に把握することが重要です。
これについてHohndel氏は、Docker社が提供する非常に人気のあるデータベースの公式イメージが、ある独立系企業のレポジトリを追加したことを例に挙げています。「このデータベースベンダーはその後、すべてのパッケージをそのレポジトリと組み合わせてapt update apt upgradeを実行した」のですが、そうすることでレポジトリ内のすべてのパッケージを置き換えられるようにしたのです。
セキュリティとコンプライアンスの観点から見れば、このような対応にはユーザーが何を実行しているのかがわからないという問題があります。
同氏によると、コンテナーイメージを最初の状態に保つには、ビルドのときに作業に加わってすべてのコンポーネントを確認し、何が含まれているのかを明確にしなければなりません。つまり、コンテナーに含まれるプログラムが適切なものであると認めるのではなく、詳細にチェックする必要があります。
そして同氏はこれについて、次のように付け加えています。「そうしなければ、インターネットからでたらめなものをダウンロードしてしまうことになる可能性がありますが、そうした行為は一般的にベストプラクティスとは言えません」。
今日では、コンテナーをクリーンアップするのに役立つアプリケーションがいくつか提供されており、以下のようなオープンソースのコンテナーファイルセキュリティスキャンツールからニーズに合ったものを選択できます。

• Anchoreエンジンは、Dockerイメージの検査、分析、および認証を行います。このツールは、Kubernetesのコンテナーオーケストレーションプログラムでスタンドアロンのプログラムとして、またはJenkinsの継続的インテグレーション/継続的デプロイプラグインとして実行できます。
  
  
• Clairは、コンテナー脆弱性スキャナーであり、静的分析ツールの役割も果たします。このツールは、klarクライアントでコンテナーをスキャンするときにバックエンドのプログラムとして使用できます。
  
  
• Dagdaは、ClamAVのウイルス対策エンジンを使用してDockerイメージの既知の脆弱性をスキャンします。このツールは、共通脆弱性識別子(CVE)、Bugtraq ID、Red Hat Security Advisoryなどのセキュリティホールデータベースを利用します。
  
  
• すでにご存知かもしれませんが、OpenSCAPは評価の高いセキュリティ監査プログラムです。このプログラムのoscap-dockerツールを使用すれば、コンテナーイメージもスキャンできます。
  
  
• Linux FoundationのAutomated Compliance Toolingプロジェクトの一部であるTernは、コンテナーイメージのファイルシステムを調べて個々のソフトウェアパッケージとそのメタデータを特定します。これにより、コンテナーイメージのソースコードと「部品表」が手に入ります。

コンテナー内の不要なものを減らす別の方法としては、他の誰かのコンテナーイメージを使用するという習慣をなくします。より困難な道を選んで独自のコンテナーイメージを作成すれば、その内部構造をより詳細に把握し、セキュリティを超えるメリットを得ることができます。

 

3. ルートアクセスを制御する

大部分のコンテナーは、デフォルトでルートアクセスが可能になっていますが、セキュリティに詳しい人なら、これを疑問に思うはずです。Dockerを実行するときにはルート権限が必要ですが、コンテナーには必要ありません。確かに開発者にとってはルートとしてコンテナーを実行する方が簡単ですが、ルートアクセスには常に非常に大きなリスクがあります。
この問題は、いくつかのアプローチのいずれかを取ることで解決できます。まず、ルートとして一切コンテナーを実行できないようにする企業ポリシーを定めます。これが不可能と思うのは ナンセンスです。Red Hat社のOpenShiftコンテナーは、ルートとしてコンテナーを実行することをデフォルトで禁止しています。
コンテナーイメージを作成するときにDockerfileでルート以外のユーザーを指定することにより、独自にルールを定めてもかまいません。たとえば、Dockerfileに以下を追加すれば、最低限必要なシステムにアクセスできる特定ユーザーとしてコンテナーが実行されます。
FROM
RUN groupadd -g 100 appuser && \
useradd -r -u 100 -g appuser appuser
USER appuser
#Rest of Dockerfile
また、コンテナーを保護するための特権コンテナーのプロセスを実行するときに、ユーザー名前空間を使用することも可能です。この方法の場合、これらのプロセスを実行するためのUIDは、コンテナー内では0 (つまりルート)になりますが、コンテナー外では非特権の1000になります。

 

4. コンテナーのランタイムをチェックする

アメリカ国立標準技術研究所(NIST)の『Application Container Security Guide』には、コンテナーのランタイムも攻撃に対して脆弱になると記載されています。ランタイムには、containerd、CRI-O、rktなどのコンテナーの起動と管理が行われるため、ランタイムのセキュリティパッチを注意深くチェックしなければなりません。古いランタイムプログラムには、それ自体にセキュリティホールが含まれている可能性があります。
このようなセキュリティホールが一般的なのかというと、そうではありません。ただし、NISTが指摘しているように、ランタイムのセキュリティホールによって他のコンテナーやホストオペレーティングシステムのリソースが攻撃を受ける可能性があるため、コンテナーのランタイムのセキュリティ脆弱性は「特に危険」なものになり得ます。
ランタイムの構成に関してはセキュリティの問題がさらに多く、構成が不適切な環境では、コンテナーからすべてのホストのデバイスやディレクトリにアクセスできてしまうことがあります。その場合、悪意のあるコンテナーが特権を昇格させてサーバーを攻撃し、業務、会社、さらには雇用にまで悪影響を及ぼす可能性があります。

 

5. オペレーティングシステムをロックダウンする

またNISTは、必要最小限のコンテナーに特化したオペレーティングシステムを実行することを推奨していますが、その理由は、オペレーティングシステムが小さくなると、攻撃対象領域も小さくなるからです。このようにOSにインストールするコンポーネントをコンテナーで必要なものだけに減らせば、攻撃が成功する確率が大幅に下がります。
その方法の1つとして、コンテナーに特化したオペレーティングシステムを使用するわけですが、最小限の(つまりより安全な)オペレーティングシステムでコンテナーを実行できる設計の重要なLinuxディストリビューションには、以下の3つがあります。

• Container Linuxは、特にコンテナーを実行することを念頭に置いた設計となっています。Red Hat社はこのディストリビューションをRed Hat OpenShift Container Platformに統合しましたが、引き続き独立したオペレーティングシステムとしても使用されています。Container Linuxは今後、Red Hat社が提供する同じようにコンテナーフレンドリなLinux Fedora Atomic Hostと統合される予定ですが、その目的はこちらもコンテナーフレンドリなオペレーティングシステムである Fedora CoreOSに代わるものを作ることにあります。
  
  
• RancherOSでは、Dockerコンテナーとして実行できるすべてのものがDockerコンテナーとして実行されます。実際、initシステムさえもSystem Dockerと呼ばれるDockerコンテナーに置き換えられます。
  
  
• Photon OSは、VMware社のコンテナーに特化したLinuxディストリビューションです。このディストリビューションは、Fedora CoreOSのようにスリム化してDockerコンテナーを実行するのに必要なものだけを含めた従来型のLinuxであり、vSphereでもスムーズに動作する特別な設計となっています。

コンテナーで従来型のオペレーティングシステムを使用している場合は、同じサーバー上にコンテナー化されたワークロードとその他のワークロードを混在させてはなりません。これについて、コンテナーセキュリティ企業のAqua Security社は次のように説明しています。「そのロジックはシンプルです。2種類のアプリケーションはアップデートサイクルが大きく異なるうえ、イミュータブルなものもあればミュータブルなものもあり、スタックアーキテクチャーにも違いがあります。同じマシンで両方を使用すると、コンテナーを使用することで得られるセキュリティのメリットが打ち消され、両方のワークロードを適切に保護するのが非常に難しくなる可能性があります」。

 

コンテナーのロックダウンが最優先

コンテナーに関しては、今まで重大なセキュリティ侵害が起きたことはありませんが、それも 時間の問題でしょう。
Datadog社の最新のデータによると、ほぼ4分の1の企業がコンテナーを導入していますが、これだけコンテナーを導入している企業が多いにもかかわらず、コンテナーの保護にあまり注意が払われていないことを考えると、多くの企業が感染したコンテナーを実行しているのは間違いなく、まだそれに気づいていないだけなのです。
自分の会社とお客様を守りたいのであれば、今こそコンテナーのセキュリティについて真剣に考え始めるべきときです。今行動を起こさなければ、明日には手遅れになっている