Dockerとセキュアなマイクロサービス - Aaron Grattafiori氏のDockerCon 2016での講演より

米国シアトルで開催されたDockerCon 2016でAaron Grattafiori氏が，“The Golden Ticket: Docker and High Security Microservices”と題したプレゼンテーションを行なった。コンテナベースのマイクロサービスのセキュアな運用のために氏が強く推奨したのは，ユーザネームスペースの有効化，アプリケーション固有のAppArmorあるいはSELinuxの設定，アプリケーションの特性に合わせたseccompホワイトリストの使用，ホストシステムの強化(ミニマルOSの実行を含む)，ホストアクセスの制限，ネットワークセキュリティの考慮などだ。

NCC Groupでテクニカルディレクタを務め，“Understanding and Hardening Linux Containers” (PDF)の著者でもあるGrattafiori氏の講演は，多重防御(defense in depth)の原理の紹介から始まった。多重防御は防御層の多重化と攻撃面の縮小，他部分の強化といった施策で構成される。マイクロサービスはシステムアーキテクチャを全体的に複雑化(大規模な運用では特に)するが，セキュリティ上の単一障害点が存在しない実装が可能であるという事実により，一般的なモノリシックアプリケーションに対するアドバンテージを提供する。

アプリケーションをrootで実行しない，などの最小権限の原則は，システムをセキュアに保つ上で極めて重要だ。モノリシックアプリケーションは機能の大部分を単一のプロセスが提供するため，この原則を適用するのは難しい。驚き最小の原則(principle of least surprise) — “妥当な既定値，信頼による分離” — 最小アクセスの原則(principle of least access)，これらもまた，多重防御の提供には不可欠だ。Grattafiori氏は，“これらすべての原則に共通するのが最小限である”ことを指摘する。これは過剰性と複雑性を回避すると同時に，次のようなシステムの開発を可能にする。

1. 信頼境界線の確立
2. 攻撃面の特定，最小化，強化
3. スコープとアクセスの削減
4. 保護と防御の多層化

モノリシックなアプリケーションセキュリティ(AppSec)には，構造や動作が十分に理解されていて，すべてが既知である(‘known known’)というメリットがある — アーキテクチャは比較的単純な場合が多い上に，通常は開発やビジネス，コンプライアンスにおいて，十分に確立した文化(と関連する責任)がすでに存在している。モノリシックなAppSecのデメリットとしては，一点の妥協がアプリケーションないしネットワーク全体の妥協を意味する場合が多いこと，認証要件がスコープ内でグローバルであること，セキュリティの調整が困難な場合が多いこと，などがあげられる。

マイクロサービスAppSecの利点としては，単一責任の原則はUnixでその有効性が広く知られていること，攻撃の対象となる公開面が一般的に小さくできること，個々のサービスに独立してパッチを適用できること，アプリケーション(と関連するランタイムコンテナ)に対する最小権限の原則とサービス固有のセキュリティの実施が比較的容易であること，一般的にTCB(Trusted Computing Base)を確立しやすいこと，などがある。逆に欠点としては，セキュリティ面で不確実性(‘known unknown’)があること，成功するために(DevOpsやDevOpsSpecのような)文化的変革が必要な場合のあること，システム機能全体に対する十分な理解が求められること，レガシシステムへの適用が容易ではないこと，(規模の拡大による)複雑性がセキュリティを損なうこと，などがあげられる。

Grattafiori氏のプレゼンテーションでは次に，マイクロサービスシステムの個々の領域に対するセキュリティ的な影響が検討された。最初に取り上げられたのはネットワークセキュリティだ。ほとんどのソフトウェアシステムでは認証をOSIモデルのレイヤ７(アプリケーション層)で提供しているが，氏はこの方法について，メリットが限定的であり，レイヤ4および5での実装であるTLS(Transport Layer Security)が本当に望ましい方法だ，と主張した。さらなるネットワークセキュリティが必要ならば，レイヤ3 IPSECを実装することも可能だ。

多くの組織ではマイクロサービスをDocker，rkt，LXCといったLinuxコンテナ内にパッケージ化している。この２つにはセキュリティ上の明確なアナロジがある。

アプリケーションとコンテナの脅威モデル攻撃木を取り除くことが重要だ。これには防御的コーディングを使用してアプリケーションの脆弱性を通じて受けるダメージを限定的にすることや，ケーパビリティ，ユーザネームスペース，読み込み専用のルートファイルシステム，不変ファイル，マウントフラグ，MAC(Mandatory Access Control)などが含まれている。

コンテナが外部にリークすることのダメージは，ユーザネームスペースを利用して，コンテナ内のrootユーザを外部の非root(uid=0)ユーザにマップすることによって，限定的なものにすることができる。Docker 1.10のユーザネームスペースはDockerデーモンによって直接サポートされているが，この機能はデフォルトでは有効になっていない。カーネルやシステムコールのエクスプロイトはseccompやカーネル強化，MACなどで限定化することができる。カーネルやホストオペレーティングシステムの棄損によるダメージは，ネットワークの強化，信頼の分離，最小権限，ログや警告処理で軽減することが可能だ。

コンテナのセキュリティはホストシステム上のベースオペレーティングシステムから始まる，とGrattafiori氏は言う。CoreOSやalpine Linux，Project Atomic，RancherOSといったミニマルLinuxの採用が強く勧められる。ディストリビューションのアップデートやバイナリパッケージのコンパイル方法，セキュリティのデフォルト設定(MACなど)，デフォルトのカーネルオプションやsysctl設定について，オペレータが熟知することも大切だ。

コンテナイメージも同じように最小限であるべきだ。‘FROM debian:jessie’や‘FROM debian:wheezy’で生成されたイメージはその典型的な例だが，これだけではまだ十分に小さいとは言えない。apt-getでアプリケーション用のソフトウェアをインストールする前でさえ，アプリケーションプロセスが必要としないライブラリや実行ファイル，言語ファイルが多数インストールされている — これはつまり，必要以上に多くのパッチやディスクスペース，攻撃面，エクスプロイト対象のユーティリティが存在するということだ。

プレゼンテーションでは，DockerとrunCを使って最小のコンテナを構築する様子がデモンストレーションされた他，静的コンパイルされたバイナリ(Golangで開発されたアプリケーションなど)の実行にスクラッチのコンテナを使用する様子も示された。

最小アクセスの原則をOSの側から適用する方法としてGrattafiori氏は，MAC(Mandatory Access Control/強制アクセス制御)を強く勧める。MACは，対象物(一般的にはプロセスやスレッド)があるオブジェクト(ファイル，TCP/UDPポート，共有メモリセグメントなど)に対してアクセスなど何らかの操作を行なうことを，オペレーティングシステムのレベルで制限するタイプのアクセス管理だ。LSM(Linux Security Module)としてのMACでは，AppArmorとSELinux(Linuxカーネルのセキュリティを強化するパッチセットであるgrsecurityを推奨し，MACソリューションも含まれる)を介して実装されている。MACはMac OSXにもTrustedBSD経由で実装されている。またMicrosoftには，MIC(Mandatory Integrity Control)がある。

デフォルトのDocker AppArmorポリシは非常に優れているが，本質的に汎用性のあるものであるため，非常に多くのファイルと権限付与を含んだ複雑なものになっている。マイクロサービスではさらに独自のプロファイルを使用することで，より的を絞ったセキュリティ設定が可能だ。独自のAppArmorプロファイルはaa-genprofで生成可能である他，DockerベースのアプリケーションではJessie Frazelle氏のBaneを利用することもできる。しかしそのためには，対象アプリケーションに対するプロファイリングが(アプリケーションを理解し利用するために)必要となる。一般的な間違いとしては，必要以上のアクセス権の付与やワイルドカードの扱い，パスベースのACL(Access Control List)の使用といったものが見られる。

Grattafiori氏は，AppArmorの拒否リスト(ブラックリスト)の利用を避けるように警告する。サービスが提供する価値を制限することになるからだ。その他の経験的ノウハウ(“gotchas”)として，プロファイルがAppArmorによって最初にロードされなくてはならないという事実，プロファイルで使用する抽象化は過度に冗長である可能性のあること，実運用時にアプリケーションをすべて実行して全機能が有効であることを確認するのは難しい場合がある(ユニットテストや回帰テストスイートの実行が有効な場合もある)，などが紹介された。

MACは非常に効果的ではあるが，カーネル攻撃に対しては依然として脆弱だ。その上，カーネル攻撃の対象範囲は極めて広い。'セキュアコンピューティングモード’(seccomp)は，Linuxカーネル内にアプリケーションサンドボックス機構を提供するコンピュータのセキュリティ機能である(seccomp自体がサンドボックスなのではない)。seccompは，exit(), sigreturn(), オープン済みのファイルディスクリプタへのread()とwrite()以外のシステムコールをできなくすることで，プロセスの”セキュア”な状態への一方向の移行を実現する。これら以外のシステムコールを実行しようとしたプロセスは，カーネルによってSIGKILLで停止される。seccomp-bpfは，Berkeley Packet Filterルールによって設定可能なポリシを使用して，システムコールのフィルタリングが可能なseccompの拡張機能である。

seccompのデフォルトフィルタは，Docker Engineバージョン1.10以降では初期状態で有効になっているが，一般的な要件に合わせてあるため，304のシステムコール(利用可能なシステムコールのおよそ75%)が使用可能にされている。最小権限の原則に従うためには，マイクロサービスアプリケーションが利用可能なシステムコールは最小限に留めるべきであり，そのために独自のプロファイルを設定する必要がある。seccompプロファイルを生成する方法としては，strace/ltrace，カーネルのヘルプ(sysdigあるいはsystemtap)，auditd/auditctl，seccomp自体のSECCOMP_RET_TRACEとPTRACE_O_TRACESECCOMPなどがある。生成したseccompプロファイルは，Dockerの‘--security-opt seccomp=<profile>’フラグを使って指定可能だ。ただし，seccompのプロファイルはアーキテクチャ依存であり，コンテナの移植性を制限する，とGrattafiori氏は指摘している。

Grattafiori氏は講演のまとめとして，Dockerベースのセキュアなマイクロサービスの運用を強く勧めた。

• ユーザーネームスペースを有効にする
• 可能ならば，アプリケーションに合わせたAppArmorもしくはSELinuxを使用する
• 可能ならば，アプリケーションに合わせたホワイトリストを使用する
• ホストシステムを強化する
• ホストへのアクセスを制限する
• ネットワークセキュリティを考慮する
• 不変コンテナを使用する

ビルド時と実行時のsecretを管理する上での問題については，一時的なバインドをマウントするプロセスを通じて一時的なsecretを投入し，メモリ内にのみロードした上でアンマウントするか，理想的には，HashiCorp VaultやSquare Keywhizといったオープンソースのsecret管理ツールを使用することで解決できる。secretを環境変数や暗号化されていないファイルでsecretを投入することは，コンテナ層やログ，あるいはエラーレポートなどに簡単にリークするので避けるべきだ。

セキュリティに関する最後の推奨事項は，セキュリティ仕様を作成すること，アプリケーション特有ないし全体的な脅威モデルを生成すること，すべてのアプリケーションとサービスをセキュアにすること，オーケストレーションフレームワークや関連サービスディスカバリのセキュリティを確保すること，といったものだった。

アプリケーション自体が脆弱であれば，コンテナやマイクロサービスでそれをカバーすることはできません。

マイクロサービスのログとアカウンタビリティも重要だ。ログは一元的に収集して保持し，定期的にレビューする必要がある。ソフトウェアアプリケーション開発ライフサイクルの一部となっていれば，セキュリティの実装ははるかに簡単なものになる。また，標準的なビルドパイプラインには，OWASP’s ZAPやbdd-security，Brakeman，gauntltといったツーリングを使用した検証ステップを含めておくことが必要だ。

DockerConでのGrattafiori氏の講演“The Golden Ticket- Docker and High Security Microservices”を記録したビデオはYouTubeのカンファレンスのチャネルで，使用されたスライドはDocker SlideShareのアカウントで，それぞれ見ることができる。さらにGrattafiori氏は，NCC Groupの白書“Understanding and Hardening Linux Containers” (PDF)の著者でもある。コンテナセキュリティの詳細に理解したいのであれば，この白書は必読だ。