Text=稲垣 達氏、上田 陽平、仲池 卓也(日本IBM)
本稿では、Kubernetesアプリケーションの秘密データを管理者から守る仕組みである、オープンソースプロジェクトの Confidential Containers について解説する。
Confidential Containers とは何か、なぜ重要なのか
近年、サイバー攻撃による企業からの情報漏洩が問題化している。攻撃の1つの手法として、攻撃対象となるアプリケーションを実行しているシステムの管理者権限を不正に取得し、アプリケーションのユーザーの秘密データを盗むというものがある。
このような攻撃を防ぐには、たとえ攻撃者にシステムの管理者権限を奪われたとしても、攻撃者が奪った管理者権限を使ってアプリケーションの秘密データを読み出せないような、強固なセキュリティ対策が必要である。
Confidential Containersは、Kubernetes 上でアプリケーションのデータを、Kubernetesのクラスタの管理者や、クラスタを実行しているクラウドの管理者から守ることを可能にする技術である。
現在、Cloud Native Computing Foundation傘下のオープンソースプロジェクトとして開発が進められており、Alibaba Cloud 、AMD 、Edgeless Systems、IBM 、Intel 、Microsoft 、Red Hat 、Rivos Inc. など多くの企業が参加している。
今日多くのアプリケーションが、オペレーティングシステムレベルの仮想化を利用したコンテナとして開発・運用されている。複数の計算機からなるクラスタ上でコンテナを管理する基盤として最も普及しているのが、Kubernetes である。
通常、オペレーティングシステムレベルの仮想化ではクラスタやクラウドの管理者はコンテナを含むすべてのクラスタ上の資源を読み書きできる。
Confidential Containers では、Kubernetes におけるアプリケーション管理の単位であるPodを、Trusted Execution Environment(以下、TEE) で実行することによって、アプリケーションのデータをクラスタやクラウドの管理者から守る。
図表1は、Cloud API Adaptor(後述)を使用したPeer Podアーキテクチャと呼ばれる構成を示す。
以下では、Confidential Containers が標準の Kubernetes に対して新たに追加する機能を紹介する。
RuntimeClass
Confidential Containers は、Kubernetes におけるコンテナ実行環境であるRuntimeClass として提供される。
アプリケーションの開発者がTEE内で Pod を実行するには、PodのruntimeClassName属性に、クラスタで使用可能なTEEに対応するRuntimeClass名を指定する。
Secret の暗号化
標準のKubernetesでは、パスワードや秘密鍵のような機密データはSecret と呼ばれるデータ構造でクラスタ内のデータベースに保管される。Secret は暗号化されないため、クラスタの管理者であれば内容を読み書きできてしまう。
これに対して、Confidential Containersでは、機密データを暗号化されたSealed Secret という形式で保存する。Sealed Secretは Confidential Containersを実行しているTEE 内でしか復号化できないため、管理者が内容を読み書きすることはできない。
コンテナイメージの暗号化
標準のKubernetesは、暗号化されたコンテナイメージを実行できる。しかし、復号鍵や復号化されたイメージはクラスタに保管されるため、クラスタの管理者が内容を読めてしまう。
Confidential Containersでは、復号鍵および復号化されたイメージはConfidential Containersを実行しているTEE内に保管されるため、クラスタの管理者が内容を読むことはできない。
コンテナ管理操作の制限
標準のKubernetesでは、クラスタの管理者はコンテナの生成や削除に加えて、コンテナ内での任意のコマンドの実行や、既存のPod に対するデバッグ用コンテナの追加など、コンテナ内部のデータを読み書きするような操作を実行できる。
これに対してConfidential Containers では、クラスタから送られるコンテナ管理操作の内容を検証し、機密データを読み書きするようなコンテナ管理操作を拒否できる。
Confidential Containersの仕組み
以下では、Confidential Containers を実現している技術を紹介する。
TEE
TEE は、以下の機能をプロセッサとファームウェアで実現する計算環境である。
① 計算環境の起動時の状態を検証できるEvidenceを作成する機能。Evidenceはハードウェアの構成、オペレーティングシステムの起動パラメータ、付与されたファイルシステムのハッシュ値などを含む電子データであり、ハードウェアに固有な秘密鍵で電子署名される。
② 実行時のメモリの内容を外部のアクセスから守る機能。暗号化やページ保護によって、クラウドの管理者やハイパーバイザーの管理者が外部からメモリの内容を読み出すことを防ぐ。
本稿執筆時の最新バージョンのConfidential Containersでは、TEE として Intel Trust Domain Extensions、AMD Secure Encrypted Virtualization-Secure Nested Paging 、IBM Secure Execution をサポートしている。
Kata Containers
Kata Containers はコンテナを各コンテナ専用の仮想機械内で実行できるコンテナ実行環境であり、コンテナの管理環境としてKubernetes をサポートしている。
Confidential ContainersはKata Containersの拡張として実装されており、現在 Confidential ContainersをKata Containersの本体に統合する作業が進行中である。
Remote Attestation
Remote Attestationは、TEEおよびその中で実行されているアプリケーションが改竄されていないことを検証する手続きである。
Confidential Containersでは、Internet Engineering Task Force (IETF) Remote ATtestation procedureS (RATS) Architectureのバックグラウンドチェックモデルに従って Remote Attestation を行う。
TEE内のPodが、暗号化されたコンテナイメージの復号鍵や、Sealed Secret の復号鍵などの秘密情報を必要とする際に、Kata Containersのエージェント (Kata Agent) が Attestation Agent に Remote Attestation を依頼する。
Attestation Agentは、信頼された外部のサービスであるTrustee に対してEvidence を送り、Remote Attestationを要求する。
Trusteeは、Intel Trust AuthorityなどのAttestation Serviceを用いてEvidenceの検証を行い、Evidence が有効であれば、Attestation Agentから依頼された秘密情報を返す (図表1)。
Attestation AgentとTrustee間の通信は、通信内容の暗号化とリプレイ攻撃の防止のため Request-Challenge-Attestation-Response と呼ばれる手順が用いられる。
Cloud API Adaptor
Kata Containers はもともと、Kubernetes のクラスタのベアメタルサーバーノードで動くハイパーバイザーを使って、Pod を実行する仮想機械を管理するように設計されていた。
しかし、クラウド環境でKubernetesのクラスタを稼働させる場合は、クラウドプロバイダーが提供するIaaS APIを使ってPodを実行する仮想サーバーを管理するほうが、仮想機械やネットワークの管理が容易である。
Cloud API Adaptorは、Kubernetes のコンテナ管理操作をクラウドプロバイダーのIaaS API呼び出しに変換するDaemonSet (クラスタの各ノードで1つだけ稼働する管理用のPod)である。
現在クラウドプロバイダーとしてAmazon Web Services、Microsoft Azure、IBM Cloud をサポートしている。
以上、本稿では Confidential Containers プロジェクトの動機、利点、要素技術を紹介した。
Confidential ContainersはRed Hat OpenShift Sandboxed Containers の新機能として利用できる。Red Hat OpenShift Sandboxed Containersは、Red Hat OpenShift上でKata ContainersをRuntimeClassとして使うことができる機能であり、Red Hatがtechnology preview として提供している。
筆者らは Confidential Containersプロジェクトの一員として、Peer Podアーキテクチャの開発に貢献している。興味を持たれた方は、ぜひプロジェクトコミュニティにてご意見を頂きたい。
著者
稲垣 達氏氏
日本アイ・ビー・エム株式会社
東京基礎研究所
スタッフ・リサーチ・サイエンティスト
TEC-J ワーキンググループ AIxノーコード、金融サービス入門、プログラミング言語動向のリーダーを担当。Kubernetesのセキュリティに関する研究開発に従事。過去、コンテナ、IBM Z、Javaの性能解析に従事。
著者
上田 陽平氏
日本アイ・ビー・エム株式会社
東京基礎研究所
スタッフ・リサーチ・サイエンティスト
IBM Z のソフトウェアスタックに関する性能・セキュリティ向上に関する研究に従事。Docker等のオープンソース・プロジェクトにも貢献。
著者
仲池 卓也氏
日本アイ・ビー・エム株式会社
東京基礎研究所
シニア・テクニカル・スタッフ・メンバー
TEC-J VP
IBM Z関連のシステムソフトウェアの研究に従事。Java Just-In-Timeコンパイラ、トランザクショナルメモリ、マイクロサービス等の研究を経て、現在ハイブリッドクラウド上での暗号資産のセキュリティの研究を推進。
*本記事は筆者個人の見解であり、IBMの立場、戦略、意見を代表するものではありません。
当サイトでは、TEC-Jメンバーによる技術解説・コラムなどを掲載しています。
TEC-J技術記事:https://www.imagazine.co.jp/tec-j/
[i Magazine・IS magazine]