DevSecConでコンテナセキュリティに関して発表するHerokuのエティエンヌ・スタルマンズ氏

　NCRは、Red Hatのコンテナ管理ツール「Red Hat OpenShift」を利用している。OpenShiftはKubernetesのAPIの設定に標準で制約を設けている。「だが認証情報を定義するためのセキュリティコンテキストについては、ユーザー自身が制約を設定しなければならない」とパターソン氏は言う。

　一般に、ユーザーのアクセス許可と各コンテナの機能には可能な限り厳しい制約を設け、実行を承認された呼び出しと操作のみをホワイトリストに入れるようにコンテナイメージを構成するのが最適だ。しかし「それでもまだ最高の方法とはいえない」と同氏は付け加える。

　「コンテナ外部、あるいはコンテナを実行しているホストOSで、コンテナの管理権限を持つユーザー（ルートユーザー）が実行可能なことを制限する、という選択肢もある」――DevSecConの別のプレゼンテーションでこう話したのは、PaaS（Platform as a Service）製品を展開し、2011年にSalesforceに買収されたHerokuでシニアセキュリティエンジニアを務めるエティエンヌ・スタルマンズ氏だ。そのためには、コンテナの管理者がLinuxカーネル内でアプリケーションをサンドボックス化するメカニズム「seccomp」の設定を調整して、アプリケーションのアクセス許可や権限を設定する必要がある。

　「依然としてルートユーザーには権限があるが、コンテナ外での権限はなくなる。つまり、コンテナを利用するユーザーの全権限を削除してから、必要な権限だけを付け直すのが最適だ」（スタルマンズ氏）

　特に重要なアプリケーションに対しては、ハイパーバイザーによる分離が必要だ。分離すれば、攻撃者がホストOSにアクセスする危険性はなくなる。Intel、Google、Microsoftなどのベンダーは、コンテナ分離用に調整を施したハイパーバイザーを提供している。

　従業員管理とベンダー管理ソフトウェアを販売するBeelineは、「Smith」というOracle製のコンテナ構築ツールを使用して不必要なOS機能を取り除いている。Beelineでエンタープライズアーキテクトを務めるジェイソン・ルーニー氏は「このツールによって当社のDockerイメージのサイズは65MBから800KB～2MB程度にまで減らすことができた」と話す。

ホストOSよりもコンテナのセキュリティに注意

　コンテナセキュリティに関する著名な手法の大半は、攻撃者が侵害したコンテナインスタンスから、ホストOSやその他のバックエンドシステムにアクセスしないよう抑制するというものだ。一方でAPIへの不正アクセスを防ぐことも重要だ。クラウドサービス「Amazon Web Services」（AWS）ベースのシステムへの攻撃で、ホストOSではなく、脆弱性のあるAPIを標的としていたものが注目を集めていたためだ。DevSecConのプレゼンテーションでこう語ったのは、ITセキュリティソフトウェアベンダーThreat Stackで、最高セキュリティ責任者（CSO）を務めるサム・ビスビー氏だ。

　ビスビー氏によると、攻撃者は必ずしも大量のデータを探しているわけではないという。「セキュリティポリシーは、重要なデータだけではなく、インフラ全体をカバーしなければならない」と同氏は言う。

　Kubernetesのバージョン1.8では、従来の属性ベースのアクセス制御から、ロールベースのアクセス制御（RBAC）に切り替えることで、APIのセキュリティを強化している。Kubernetesの導入企業、あるいはベンダーの大半が、RBACのKubernetesのAPIへのアクセスをデフォルトで実装するようになってきている。一方でユーザーは、信頼できないポッドがKubernetesのAPIと通信するのを防ぐために、構成設定を細かく調整する必要がある。

　「（Kubernetesコミュニティーでは）RBACをデフォルト設定にしようという議論がある。『Calico』『Istio』『Weave』などのコンテナネットワーキングユーティリティーを通じて設定することも可能だ。しかしこれは新しい標準設定が決まるまで、ファイアウォールによる防御という原始的な手法が必要なことを意味する」（ビスビー氏）