Dockerコンテナのセキュリティと仮想マシン対ベアメタルの議論：「The Next Platform」で読むグローバルITトレンド（2）

英国のIT専門媒体、「The Register」とも提携し、エンタープライズITのグローバルトレンドを先取りしている「The Next Platform」から、＠IT編集部が独自の視点で“読むべき記事”をピックアップ。プラットフォーム3へのシフトが急速に進む今、IT担当者は何を見据え、何を考えるべきか、バリエーション豊かな記事を通じて、目指すべきゴールを考えるための指標を提供していきます。

　新しい技術では、何度も同じことが繰り返されている。開発者がコードを書いて新しいものを生み出し、それが実験としてデプロイされる。オープンソースプロジェクトなら、それが世界で共有される。その有用性が理解されるとともに、特定の問題解決に熱心に取り組んでいる多くの人がDIYで使い始め急速に導入が進む。すると大企業や中堅企業が興味を持ち、それに伴ってセキュリティが問われるようになる。

　「野菜を食べて大きくなりなさい」と大人に言われるようなものだが、実際、この正しいアドバイスの通り、セキュリティを確保することは広く採用され、ITを支えることを目指す全ての技術にとって望ましい健全な取り組みだ。

　Dockerコンテナではこの数年間に、まさにこうしたことが起こっている。Docker技術は、ハイパースケールデータセンターを担う技術者たちによって開発が進められ、最先端にいる人々による熱心なトライアルを経て、先進的でありたい一方リスクは抑えたい大企業が、実環境にデプロイするようになっている。

「仮想マシンよりも強固なセキュリティを目指す」

　Dockerコンテナランタイムとその管理ツールを手掛けるソフトウェア会社のDockerは、「コンテナのセキュリティをベアメタルサーバやハイパーバイザーベースの仮想マシンよりも高める」という野心的な目標を掲げている。Dockerのセキュリティディレクターを務めるネーサン・マコーリー氏は、The Next Platformの取材に対し、「Dockerベースのコンテナプラットフォームを、アプリケーションソフトウェアの作成、デプロイにおいて、この上なく安全な方法にすることを目指す」と話している。

　「セキュリティが万全とはまだとても言えないが、『アイアンマン』のスーツになぞらえると、スーツはいつでも改良でき、いつでも機能を追加できる。Dockerでは、追加可能なセキュリティ機能がたくさんあり、われわれはそれらに順序を付けて、段階的に機能を拡充していける。過去2年間のセキュリティ強化の多くは、アプリケーションの安全性の向上を目的としていた」とマコーリー氏は語る。

　「私の見方では、内部的には、われわれは可能なことを始めたばかりのような気がする。もっとも、コンテナベースのデプロイは、現在利用できる他のどのアプリケーションデプロイ方法よりも基本的に安全だと思う。われわれは既に、他の選択肢の先を行っていることになる。だが、コンテナはアプリケーションのパラダイムを根本的に変えており、アプリケーション単位でデプロイが行われるようになっている。そのため、セキュリティを強化するチャンスがたくさんある」（マコーリー氏）

　10年前の仮想マシンやハイパーバイザーの場合と同様、金融サービス会社や政府機関、医療機関など、機密性の高い情報を扱い、規制の厳しい業種が、新しいアプリケーションをコンテナでのデプロイを前提に開発し、さらに一部のレガシーアプリケーションをコンテナ環境向けに改良することを求めるようになっている。

　「これらの組織はコンテナを、ハイブリッドクラウドやマルチクラウド環境で安全なソフトウェアサプライチェーンを実現する方法と考えている。セキュリティが、Docker導入の最大のメリットの1つになりそうだ。企業や政府機関でこのメリットが確認されつつある」と、Dockerのマーケティング担当シニアバイスプレジデントを務めるDavid Messina（デビッド・メッシーナ）氏は説明する。

シークレット情報の集中管理を実現

　Dockerは2017年2月、コンテナスタックをアップデートし、アプリケーションが実行時に持つ“シークレット”をまとめて管理できるようにした。コンテナスタックにはランタイム、コンテナ作成ツールの「Docker Compose」、管理ツールの「Docker Datacenter」が含まれる。

　われわれがデバイスやその上で実行するアプリケーション、あるいはデバイスから実行するアプリケーションにアクセスするためのパスワードを持っているように、アプリケーションは自らの機能を実行するため、シークレット情報を保持する必要がある。シークレットには、パスワード、暗号鍵、API鍵、認証証明書、サードパーティーサービスとの通信のためのトークンなどがある。「全てのアプリケーションがこうしたシークレットを持っており、企業からの要望が最も高いのはこれらの安全な集中管理だ」とマコーリー氏は語る。

　コンテナプラットフォームを適切に機能させるためにDockerが最初に理解しなければならなかったのは、このプラットフォームが非常に動的な環境であり、アプリケーションが必要とするシークレット情報は、クラスタ内でのアプリケーションの移動に合わせなければならず、アプリケーションの起動と終了に合わせて生成、消滅しなければならないということだった。

　これは、大半の仮想マシン環境とは全く対照的だ。仮想マシンは非常に静的で、設定したら忘れてしまえる。仮想マシンが移動しても、シークレットは仮想マシン自体にはなく、アプリケーションを実際に実行するOSに保存されている（このアプローチについては危険性も指摘できるが、単一OSのベアメタルでも考え方は何ら変わらない）。

　「コンテナ環境でシークレット管理を実現するのは少し厄介だ」と、マコーリー氏は語る。まず、Dockerはこのシークレット管理システムを、Windows Server環境とLinux環境で、またプライベートクラウドとパブリッククラウドで同じものにしようとした。Dockerコンテナ自体はこれらの環境を一貫してシームレスにカバーするが、セキュリティ管理ソフトウェアが同じようにカバーできなければソリューションにならないという。

　これまで、一部のユーザーはシークレットをアプリケーションのソースコードに追加していたが、それは賢明なことではなく一時しのぎにしかならないと、マコーリー氏はクギを刺す。また、構成自動化ツールのChef、Salt、Vaultなどを使って、コンテナ環境でシークレットを管理できるようにしたケースもあったが、これは機能の付け足しであり、Dockerスタックにネイティブではない。

　Googleとオープンソースコミュニティーが開発したコンテナコントローラーKubernetesは、一定のコンテナ管理が可能だが、「Kubernetes環境では、全てのアプリケーションが全てのアプリケーションの全てのシークレットを見ることができる」と、マコーリー氏は説明する。これでは「オープンなシークレット」だと、同氏は揶揄（やゆ）している。

　新しいDockerスタックでは、こうしたシークレットはDockerランタイムに保存され、システムのメインメモリでしか提供されない。ディスクやフラッシュストレージに保存されることはなく、メインメモリで動作するファイルシステムによってアクセスされ、おなじみのアクセス方法を提供することで、レガシーアプリケーションや新しいコードが同じ方法でこうしたシークレットにアクセスできるようにする。

　さらに、このDockerシークレット管理システムでは、特定のシークレットにアクセスすることを想定されているアプリケーションだけがそれらを認識でき、アプリケーションは他のシークレットを認識できない。以下のように、シークレットを構成するデータは鍵で暗号化され、中央リポジトリから各サーバノード上のアプリケーションに転送される。

Dockerのシークレット管理

　シークレットの管理には、コンテナ作成ツールであるDocker Composeが利用される。シークレットは単一の分散ストアに保存され、各サーバ上の各DockerランタイムデーモンのローカルSwarmモードに組み込まれる。プログラマーはDocker Composeでフェイクシークレットを作成し、アプリケーションの開発、テストを行うとともに、ネットワーク上の別の位置でシークレットを無効にできる。

　シークレット管理機能は、アプリケーションやコンテナ自体のロックダウンを行うDocker Datacenterの役割ベースのアクセス制御やコンテナデプロイポリシー管理機能を補完する。

　こうした機能は全て、Docker ComposeやDocker Datacenterのサポート契約を結んでいる顧客に無料で提供されている。コンテナシークレット管理の仕組みについての詳しい解説を読みたい場合は、まずこのブログ記事（英文）に目を通すとよい。

パブリッククラウドでベアメタル上のコンテナ環境が広がる？

　Dockerに対する取材でわれわれが知りたかったことの1つは、「Dockerがセキュリティの観点から、仮想マシン環境でDockerコンテナを実行することについてどう考えているか」ということだ。結局のところ、グーグルはGoogle Cloud Platformを構築したとき、Linuxコンテナに見切りをつけてKVMハイパーバイザーをロードし、その上で仮想マシンをスピンアップし、最終的にKubernetesを実行して仮想マシン上で動作するコンテナのオーケストレーションを可能にした。

　Amazon Web Services（AWS）、Microsoft Azure、あるいはGoogle Cloud PlatformでDockerを実行すると、デフォルトでは仮想マシン環境で実行することになる。VMwareのESXiやRedHatのKVM、MicrosoftのHyper-VとKubernetesのようなコンテナ管理システムを組み合わせても同様のことが可能だ。これについてマコーリー氏は、必要とも望ましいとも考えていない。だが、企業が当面は仮想マシン環境でDockerコンテナを実行するもっともな理由がある。

　「コンテナは幅広い環境で動作する。クラウド環境やベアメタルなど、どこにデプロイしてもこれまでよりセキュリティが必ず向上する。要するに、Dockerはセキュリティを強化するために追加すべき技術ということだ。真っさらな状況でDockerを仮想マシンにデプロイすることについては、私は賢明な選択とは思わない」とマコーリー氏は語る。

　「多くの組織は、コンテナによってかなり高いセキュリティが得られることを理解している。そしてセキュリティを確保したい事項の多くは、健全で安全なソフトウェアサプライチェーンを確保することでうまく扱えることを理解している。インフラに入り込むものを適切な管理下に置くことは、最も効果的な措置の1つであり、安全なソフトウェアサプライチェーンがあれば悪意あるコードをインフラに入れてしまう可能性は非常に小さくなる。サービスやシークレット、それに類するものの管理に注目すべきだ」（マコーリー氏）

　「興味深いことに、現在、Dockerの実際の実装の大多数は仮想マシン上で動作している」と、メッシーナ氏は語る。その主な理由は、この10年間にサーバの柔軟性や使用率を高めるために物理サーバから仮想サーバへの移行が進み、仮想マシンがデプロイ手段として広く選ばれるようになったからだ。

　主要なサーバ仮想化環境は、いずれもコンテナを動かすことができ、クラスタコントローラーのMesosやOpenStackも同様だ。だがわれわれは、長い目で見れば「企業はDockerコンテナをできるだけベアメタル環境にデプロイしたいと考えるようになり、仮想化インフラについては、必要な場合にのみ受け入れるようになる」と予想している。

　実際、われわれは、3大クラウドプロバイダー（AWS、Microsoft Azure、Google Cloud Platform）がベアメタルに特化し、Dockerコンテナのみが実行される新しいクラウドを別途立ち上げるのがいつになるのか注目している。その日は確実にやって来るだろう。おそらく2017年にいずれか1つが先陣を切り、他の2つもすぐに追随すると予想される。

出典：Locking Down Docker To Open Up Enterprise Adoption（The Next Platform）