コンテナセキュリティ入門【前編】

• 
• 

ビジネス開発本部 第３応用技術部
第２チーム
松尾 咲季

コンテナの需要と利便性

近年、コンテナの持つ様々な利便性に注目が集まり、国内でも商用利用を検討する企業が増えています。コンテナは従来の仮想マシンと比べて軽量に動作し、非常に短時間でデプロイや削除が可能です。また可搬性に優れており、オンプレミス、クラウドを問わず利用することができます。コンテナの特性については過去のネットワンブログで紹介しているため、詳しくは コンテナ技術入門などを併せてご覧ください。

コンテナ自体のメリットに加え、近年トレンドであるエンタープライズのDX推進や、アプリケーションのマイクロサービス化も、注目度を高める要因となっています。コンテナの特性がレガシーなシステムの近代化と、クラウドネイティブアプリ活用の両面にマッチするからです。コンテナを構成するエコシステム（Cloud Native Landcape）に様々なベンダが参入しつつあることも大きな促進要因です。RedHatや VMWare、Ciscoを含む大手ベンダが商用プラットフォームの提供を開始しており、AWS、Azure、GCPなどのパブリッククラウドも顧客の需要により様々なマネージドサービスをリリースしています。

Gartnerは「2022までに 75%以上のグローバル組織がコンテナ化されたアプリケーションを商用利用する」との予測を出しています。

セキュリティの課題

コンテナの商用利用が増える一方、コンテナをターゲットとするサイバー攻撃も年々増加しています。それに対して十分なセキュリティ対策を施行できていない環境も多く見られます。パロアルトネットワークス社 Unit42 の 2019年上半期の調査によると、「40,000 以上のコンテナがデフォルトのまま、もしくはセキュアでない設定で稼働」しています。問題の内訳には、コンテナ上で RDPポートが公開されている、TLS 1.1以前のセキュアでないプロトコルでSSL通信が行われている、設定ミスによるクラウドインシデントが発生したことがある、などが含まれます。このようなシステムは往々にしてパッチ当てやアップグレードがなされず、攻撃の成功率が高くなります。

不適切な設定に加え、脆弱性やマルウェアを足がかりにされる場合もあります。目立つところでは、コンテナに仮想通貨の採掘を行うマルウェアイメージをダウンロードさせるキャンペーンが頻繁に行われており、ピーク時は 2,000以上の Dockerホストがマルウェア感染したとの報告もあります。

コンテナ上で稼働するアプリケーションイメージやランタイムだけでなく、コンテナランタイムやオーケストレータも脆弱性の対象となり得ます。2019年度には Kubernetesで 11件、Dockerで 7件の脆弱性が報告されています。そのうち Dockerが該当する runc権限昇格の脆弱性 (CVE-2019-5736)は脆弱性の深刻度を示す CVSS Scoreが 10段階中、9.3であり、アップグレードもしくは脆弱コンポーネントの置き換えが急務となりました。

攻撃者はサービスとデータが存在するリソースから攻撃可能面を探します。コンテナの商用利用が増えるにつれ、攻撃件数も増加し、セキュリティ対策の必要性がより切実なものとなることは間違いありません。ではコンテナ環境の攻撃可能面はどこであり、どのような対策が必要なのでしょう。

本コラムではコンテナ環境の特性を踏まえ、従来と異なるセキュリティアプローチが必要となるであろう以下の 3点について、説明したいと思います。

• インフラの保護
• マイクロサービスの保護
• コンテナイメージの保護

インフラの保護

コンテナ環境のセキュリティ対策としてまず重要なのは、コンテナインフラの基盤の強化です。

コンテナ環境に特有なセキュリティ上の懸念の一つは、コンテナ型仮想化モデルの アーキテクチャに起因します。コンテナ型仮想化モデルでは、複数のコンテナがホストOSのカーネルを共有します。これによりCPUやメモリの利用効率が向上し、軽量な動作が可能となる一方、仮想マシンごとに独立したOSが起動するホストOS型仮想化モデルと比べて、コンテナ間の分離が弱くなります。特に同一のインフラ上に複数顧客のコンテナを収容するマルチテナント構成では、他社のコンテナから自社管理のコンテナへ不正アクセスされるコンテナエスケープのリスクや、ホストOS側に対する権限昇格のリスクに特別な注意を払うべきでしょう。

コンテナの分離を強化するための種々の テクノロジーは GoogleやAmazon、IBMなど様々なベンダで開発が進んでいます。オープンソースでは OpenStack Foundation が開発している Kata Containersが注目されています。Kata Containerはコンテナごとにカーネルを持つことで、従来の仮想マシンに近い実装で高レベルの分離を実現するコンテナランタイムです。また、コンテナかVMかの二者択一ではなく、両方を併用するハイブリッド構成を提唱するベンダもおり、今後何が主流になるかは議論の余地があります。いったんそれは脇に置いておいて、まずは現在主流のコンテナ環境を想定し、セキュアなインフラを構築するために考慮が必要な点について触れていきます。

一般的なコンテナは Linuxベースの OS上に Dockerなどのコンテナランタイムをインストールし、必要な数のコンテナ用ホストを Kubernetesなどのオーケストレーションツールで管理します。Linux、Docker、Kubernetes以外の選択肢やパブリッククラウドのマネージドサービスを組み合わせるパターンもありますが、ここではオンプレミスの典型的な構成を想定します。以下は Kubernetes管理化のコンテナ環境を抽象化した図です。

Kubernetesはコンテナを複数ホストに展開し、冗長化やスケーリング、負荷分散などを行うコンテナオーケストレーションツールです。Kubernetesクラスタというユニット内にマスターノードとワーカーノードが所属し、マスターノードがコントロールプレーンとなってコンテナが稼働するワーカーノードを管理します。ワーカーノードにはDockerなどのコンテナランタイムが動作し、コンテナのビルドや削除といったコンテナ操作をバックグラウンドで担当します。

この全体像の中で、コンテナ周りを包む要素を拡大します。

この中の Namespace、Pod、Containerは、コンテナの分離を強化するためのセキュリティ制御を施行できる境界線と考えられます。ここでNamespaceが登場しますが、Namespaceは２種類あり、一つはコンテナホスト内でコンテナを分離して機能するために利用されるLinuxの機能です。もう一つはKubernetesクラスタのリソースとして、Kubernetes上のリソースを論理的にグルーピングするためのNamespaceです。これらの分離境界はKubernetesやDockerの機能である程度最適化されますが、意識して設定することで、より強固な多層防御を施行できます。また設計時にあらかじめ考慮が必要なポイントも存在します。それぞれのセキュリティ上の役割を簡単に解説します。

• Namespace (コンテナの分離を実現するLinuxの機能)
  Dockerは cgroup と namespaceを使ってコンテナの分離を実現します。両方とも Linuxカーネルの機能であり、cgroupは CPU、メモリ、ディスクi/oといったプロセルグループの物理リソースを隔離します。namespaceはプロセスID、ネットワークスタック、ファイルシステムなどのLinux要素に名前を与えることで、プロセス空間を他のコンテナやホストOSから分離します。
• Namespace (Kubernetesクラスタにおけるリソースのグルーピング機能)
  Kubernetesクラスタ内で誰に何のオペレーションを許すかを役割ベースに制御するRole Based Access Control(RBAC)を紐づける基本単位となります。また、KubernetesのAPIリクエスト制御機能である Admission Controlのうち、サービス不能攻撃やデータ漏洩を防止する制御は namespaceレベルで適用されます。Kubernetesでのオブジェクト作成時に namespaceを指定しなかった場合、defaultという名前の namespaceが紐づけられますが、これはコンテナの分離を困難にするため推奨されません。
• Pod
  Namespaceとコンテナ間に存在する境界である Podは、Kubernetesが管理するデプロイメントの最小単位です。Podには一つまたは複数のコンテナ、ストレージリソース、ユニークなネットワークIPが割り当てられます。Kubernetesは Podレベルのセキュリティ強化と分離を実現するため、Pod定義内の Security Contextオプションや Pod Security Policyといった機能を用意しています。

Security Context は Podの仕様を定義する yamlファイル内に指定できるパラメータです。Podに権限を与える UserID/GroupIDに対する権限昇格の可否などをコントロールできます。また、強制アクセスコントロール（MAC）を提供する Linuxのセキュリティモジュールである SELinux または AppArmorをアサインすることも可能です。これにより、仮にコンテナ内のプロセスが root権限で稼働しても、不要な権限(capability)を奪うことで Linuxカーネルをセキュリティ上の脅威から保護する強力なシステムコール制御を適用できます。

Pod Security Policy は Podのセキュリティ仕様をコントロールする Kubernetesクラスタレベルのリソースです。システムが許可するpodの稼働条件やデフォルト制御を定義することで、例えばLinuxカーネルやデバイスに対して多大な権限を与える priviledgedモードでのコンテナ稼働を禁止したり、ホストのプロセスID namespace（hostPID）共有オプションを禁止することで、コンテナ外への権限昇格リスクを軽減できます。Pod Security Policyはオプショナルですが、コンテナに脆弱性があった場合に備えて追加の保護レイヤーを敷くことができるため、利用が推奨されます。

コンテナ間でネットワーク的な制御を加えたい場合、Kubernetesリソースには podレベルで施行できる Network Policyがあります。デフォルトで pod間のトラフィックは全て許可されますが、Network Policyを紐づけることにより、ingress/egressで許可するpodやnamespace、ポート番号などを制限できます。尚、Network Policyを利用するには、これをサポートする Container Network Interface(CNI)プラグインを選択する必要があります。例えば Weave、Calico、Ciliumなどは　Network Policyをサポートしますが、flannelはサポートされません。CNIプラグインの選択により、Layer 3でセグメンテーションできるか、ブリッジングやvxlanなのか、などセキュリティが関わるネットワーク実装が異なるため、設計時に考慮が必要です。

• Container
  コンテナは前述のnamespace (コンテナの分離を実現するLinuxの機能)とcgroupによって分離され、Pod内にデプロイされます。コンテナにはアプリケーションやライブラリ、アプリが依存するバイナリなどがロードされ、与えられた権限やリソースの範囲内で動作します。またKubernetes の Service機能を使い、外部からの接続を許可することが可能です。外部ユーザはコンテナ内のアプリケーションに接続したり、内部のシェルを起動しPod内のリソースにアクセスするなどの操作が許容される場合もあります。必要以上の権限付与はコンテナエスケープのリスクを高め、脆弱性への耐性を弱めてしまいます。

最低限の権限でコンテナを実行し、コンテナ内のプロセスから Linuxカーネルへのシステムコールを制御する機能として、Linuxの seccomp (secure computing mode)があります。Dockerはコンテナ運用に最適化した seccomp profileを用意しており、デフォルトでは数十個の syscallをホワイトリスト化することで、その他の潜在的に危険な syscallをブロックします。デフォルトのプロファイルはコンテナ上で動かすアプリケーション毎に最適化されているわけではないため、よりカスタマイズした制御を行いたい場合は seccomp profileをカスタムなものに置き換える必要があります。尚、自動で最適化された profileに置き換えるサードパーティ製品もあります。

以上、Namespace、Pod、Containerをセキュリティ境界として適用できる制御機能について触れました。これらの機能を活用し、ホストOS、コンテナランタイム、オーケストレータ、その他の要素にて多層にセキュリティレイヤーを敷くことで、コンテナのアーキテクチャに起因するセキュリティリスクを軽減することが可能です。また説明を割愛しましたが、Nodeへのアクセス制御を行うためには Linux OSの強化が必要であり、Kubernetes Clusterへのアクセスを制御するためには API制御や認証・認可の施行など、コントロールプレーンの強化が必要です。これらの設定はホストOS、コンテナランタイム、コンテナオーケストレータなど様々な要素が絡み、どの部分の設定がリスクを孕むのかを抽出・監査するのはなかなかに困難です。

手っ取り早くそれを行うには、kube-benchや docker-benchなどの CIS Benchmarkに基づく監査ツールを活用する方法があります。CISベンチマークは、米国政府や企業、各機関のエキスパートが所属する非営利団体が開発した、システムを安全に利用するための構成およびベストプラクティスが定型フォーマットでまとまったもので、読み物としても非常に参考になります。ベンチマークに対応するツールを用いてコンテナ環境の設定をスキャンすることで、それぞれの項目における pass/failを手っ取り早く可視化することができます。例えば Dockerの CIS Benchmarkであれば、稼働するホストOSの設定、Dockerデーモンの設定、設定ファイルのオーナーやパーミッション、コンテナイメージ自体の安全性、ランタイムの設定などが監査の対象となります。

コンテナが利用される環境は日々変化し、セキュリティ制御の適用も迅速化が求められています。従来型のサーバよりも短いスパンで継続的な監査が必要となります。

＜コンテナセキュリティ入門【後編】につづく＞

執筆者プロフィール

執筆者プロフィール
松尾 咲季
ネットワンシステムズ株式会社 ビジネス開発本部 第３応用技術部 第２チーム所属
オンプレミス、クラウドのセキュリティ商材を評価、検証し、提案や導入支援を行う業務に従事
・CISSP
・AWS Speciality - Security
・Cisco CCNP Security
・Palo Alto Networks PCNSE

• 
• 

ナレッジセンターを検索する