機密コンピューティングは、信頼できる実行環境 (TEE) を活用して使用中のメモリーを保護します。これは、保存中、転送中、使用中のデータを暗号化するのに役立ちます。 機密コンテナ (CoCo) は TEE と Kubernetes デプロイメントを組み合わせたものです。TEE を Pod レベルでデプロイすることで、クラスタ上の他のワークロードだけでなく、クラスタ管理者からもワークロードを強力に分離できます。

機密コンテナの課題は、実際に使い始める際に関するものです。Pod を機密コンテナにデプロイするかどうかは、Pod マニフェストの 1 行を変更するだけで指定できますが、実際に使い始めるには多数のコンポーネントを (理想的には複数のクラスタに) 正常にデプロイできる必要があります。Red Hat は先日、Red Hat OpenShift Sandboxed Container Operator v1.9 以降における Microsoft Azure での機動コンテナのサポートと、Red Hat ビルドの Trustee によるリモート・アテステーションのサポートを発表しました。

この記事では、検証済みパターンを使用して次の 3 つの目標を達成する方法について説明します。

1. OpenShift Sandboxed Containers Operator と Azure 上の Red Hat ビルドの Trustee を使用して、機密コンテナ (CoCo) の導入を単純化する
2. ベストプラクティスに沿ったデプロイを可能にする、CoCo の一貫性のある宣言型の基盤を提供する
3. CoCo を使ってアプリケーションをデプロイする方法を実証する

検証済みパターンの概要 

検証済みパターンは、マルチクラウドやハイブリッドクラウドのさまざまなユースケースに対応する、稼働中のコードアーキテクチャです。各パターンはテストされ、成熟段階に達すると、Red Hat の継続的インテグレーション (CI) システムに追加されます。これにより、最新バージョンの Operator や OpenShift リリースに対して、また複数のパブリッククラウド環境間でテストを実施できるようになります。

Red Hat の検証済みパターンのリポジトリはいずれも、サービスから基盤のインフラストラクチャに至るまで、ハイブリッドクラウド・スタックを宣言的かつ包括的に記述する Kubernetes リソース (Helm チャート、kustomize、プリミティブオブジェクト) の形式で、ビジネスユースケースを示します。 検証済みパターンは、複雑で再現性の高いデプロイメントを容易にし、GitOps の運用プラクティスに沿ってこれらのデプロイメントを大規模に運用するのに最適です。

検証済みパターンを使用する理由 

複雑なビジネスソリューションのデプロイには複数の手順が必要です。各ステップを検証せずに実行すると、エラーや効率の低下につながる可能性があります。検証済みパターンは、事前に検証済みの自動化されたデプロイメントプロセスを提供して、この問題に対処します。このプロセスには以下の特徴があります。

• GitOps モデルを使用してユースケースをコードとして提供する
• 特定のニーズに合わせて修正された概念実証 (PoC) として開始し、実際のデプロイメントへと展開できる
• 再現性が高いため、大規模な運用に最適である
• 検証済みパターンについてのコラボレーションが可能。Git リポジトリはすべてアップストリームであるため、誰でも改善を提案したり、貢献したり、使用したりできる
• 検証済みパターンはそれぞれ、特定のニーズに合わせて変更できる。コンポーネントを入れ替える (たとえば S3 ではなく Ceph ストレージを使用する) 作業は、設定のセクションをコメントアウトして別のリポジトリを含めるだけで終わるほど手軽です。
• テスト済みである。検証済みパターンが作成されると、ユースケースは Red Hat の CI に組み込まれる。パターンが有効な間は、そのユースケースが複数の製品バージョンでテストされる。

検証済みパターンは「すぐに使えるタイプ」のソリューションです。パターンフレームワークをどこから開始するにせよ、コアおよびコンポーネントの構成可能なセットの両方が、すぐに使える状態で提供されます。この記事では、機密コンテナを簡単に使い始める方法を可能にするために検証済みのパターンを使用しています。

パターンのデプロイ方法

検証済みパターンの Web サイトには、検証済みパターンの使用方法に関する豊富なドキュメントが揃っています。ベストプラクティスには以下のものが必要です。

1. パターンの Git リポジトリ (パターンのフォークなど)。検証済みパターンは GitOps を使用するので、使用するリポジトリを管理する必要があります。
2. oc、Git、Podman がインストールされた開発者のノートパソコン
3. パターン Operator がクラスタを「管理」する空の OpenShift クラスタ

これらの要件の相互関係を以下に示します。

この構成では、クラスタ上のものが検証済みパターンの管理下に置かれるため、単一の場所で開始できます。

機密コンテナ用の検証済みパターンを使用する

Red Hat OpenShift サンドボックスコンテナは Kata Container をベースとして構築されており、機密コンテナを実行するための追加機能を提供します。機密コンテナとは、分離されたハードウェアエンクレーブ内にデプロイされたコンテナで、クラウドやクラスタ管理者などの特権ユーザーからデータとコードを保護するのに役立ちます。CNCF の機密コンテナプロジェクトは、OpenShift CoCo ソリューションの土台となっています。

機密コンピューティングは、専用のハードウェアベースのソリューションを活用して、使用中のデータを保護します。ハードウェアを使用して、自らが所有する分離された環境を作成でき、実行中のワークロードのデータ (使用中のデータ) を不正アクセスや改ざんから保護できます。

CoCo は、複数のハードウェア・プラットフォームとそれをサポートするテクノロジーを使用して、クラウドネイティブな機密コンピューティングを可能にします。CoCo は、機密コンピューティングを Pod レベルで標準化し、Kubernetes 環境での使用を単純化することを目指しています。これにより、機密コンピューティングの基盤技術について深く理解していない Kubernetes ユーザーでも、使い慣れたワークフローとツールを使用して CoCo ワークロードをデプロイできます。

詳細については、「OpenShift 機密コンテナ・ソリューションについて」参照してください。 

機密コンテナのアーキテクチャ 

Red Hat の機密コンテナソリューションは、次の 2 つの主要な Operator をベースとしています。

• Red Hat OpenShift 機密コンテナ：Red Hat OpenShift sandbox containers Operator に追加された機能で、ハードウェアが提供する TEE 内で実行されるワークロード (Pod) と機密仮想マシン (CVM) を接続するための基本的な構成要素をデプロイします。
• リモート認証：Red Hat ビルドの Trustee で、Red Hat OpenShift クラスタに Key Broker Service (KBS) をデプロイして管理します。

詳細については、「機密コンテナ Trustee の概要：認証サービス・ソリューションの概要とユースケース」についてご覧ください。

CoCo には通常、信頼できるゾーンと信頼できないゾーンの 2 つの環境があります。これらのゾーンには、Trustee とサンドボックスコンテナ Operator がそれぞれデプロイされています。 

これに関して、どのような課題があるでしょうか。実際に使用するには、使用しているクラウドやオンプレミス・インフラストラクチャを理解し、具体的に詳細な点を把握しておく必要があります。たとえば、どのリージョンにいるか、どのチップセット (インテル、AMD、IBM Power、s390) とハイパーバイザーをターゲットにするかなどの、いくつかの点を確認しておく必要があります。 

CoCo のデプロイに関する追加情報については、「Red Hat OpenShift 機密コンテナ・ソリューションのデプロイに関する考慮事項」を参照してください。

機密コンテナの検証済みパターンの概要

機密コンテナの検証済みパターンの目的は、使用開始を容易にすることであり、機密コンテナのデプロイ方法を理解できるようにすることです。検証済みパターン・アーキテクチャを使用して、以下を実行できます。

1. CoCo の実行に必要な Operator をデプロイする
2. 証明書など、周辺のバックグラウンド・コンポーネントを設定する (必要に応じて Let’s Encrypt を使用)
3. Red Hat Advanced Cluster Manager などのツールを使用して、クラウドからクラスタに CoCo をデプロイするユーザーを抽象化する
4. 一連のサンプルアプリケーションをデプロイして、CoCo の操作など、機密コンテナのさまざまな機能を実証する

現時点で、パターンは、1 つの検証済みパターンからすべてのコンポーネントが派生する形式で、Microsoft Azure 上に単一のクラスタにデプロイされています (今後、デプロイメントが追加される予定です)。

仕組み

検証済みパターン Operator を活用して Argo CD をデプロイします。次に、Argo CD が追加の必要な Operator をデプロイします。 

問題となるのは、init-data および kata-policy を含む peer-pods 設定マップが、Trusted Key Broker Service (KBS) を指すように設定する必要がある点です。この情報は動的であり、ユーザーは Azure CLI を使用するか、Azure ポータルにアクセスする必要があります。セキュリティと可視性の観点からは、init-data と kata-policy も同様の難点があります。設定マップにプッシュされる前に base64 でシリアライズされるため、ユーザーが状況を確認することが難しくなります。

 

ただし、これらの課題は、検証済みパターン Operator によって挿入されたメタデータを使用することで解決できます。これにより、クラスタに関する情報にアプリケーションで簡単にアクセスできます。高度なクラスタ・マネージャーのポリシーは、クラウド・コントローラー・マネージャーによって定義された情報を収集する目的や、それをサンドボックスコンテナ Operator の適切な設定マップおよびシークレットに注入する目的で使用されます。

Hashicorp Vault は、検証済みパターンのシークレット構成のあるクラスタ内で KMS として使用されます。これにより、ユーザーは開発者ワークステーション環境から Vault を一貫した方法でブートストラップできます。これを使用すると、Trustee にシークレットを提供し、このシークレットは外部シークレット Operator を使用して同期されます。

これらの機能を組み合わせることで、1 つのコマンドでのインストールが可能になります。その内容を以下に示します。 

要件 

現在、プラットフォームとしての Azure の使用は制限されており、simple パターントポロジーが 単一の OpenShift クラスタとなっています。

ユーザーは、Azure Red Hat OpenShift クラスタ、または Azure 上のセルフマネージド OpenShift クラスタのいずれかを使用できます。パターンには、openshift-install を使用してクラスタをビルドする方法に関するドキュメントが含まれます。クラスタと Azure アカウントは、リージョン内の Azure CVM にアクセスして使用できる必要があります。現在のパターンでは、機密コンテナに DCasv5 クラスの仮想マシンを想定していますが、これはカスタマイズ可能です。

Azure で必要となる追加設定は、ワーカーノードのサブネットに NAT ゲートウェイをデプロイすることだけです。これは自動的に行われます。

開発者ワークステーションには、oc と podman がインストールされた POSIX ワークステーション (Mac OS または Linux) が必要です。

具体的な手順

必要なステップはわずか 3 つです。

1.フォークを作成する

まず、組織内に検証済みパターン GitHub リポジトリのフォークを作成します。Argo CD の最終的な整合性を考慮すると、検証済みパターンリポジトリを直接使用するのは安全ではありません。

git clone https://github.com/(YOUR ORG}/coco-pattern.git

2.ランダムキーを生成する

次に、ベースラインシークレットを生成します。パターンには、ランダムキーを生成するスクリプトが含まれています。

sh scripts/gen-secrets.sh

3.インストールする

oc ログインを使用してクラスタにログインし、パターンインストールを実行します。

./pattern.sh make install

これで完了です。システムがオンラインになるまで待ち、デプロイされたアプリケーションを確認します。

デプロイされたアプリケーションを確認する

パターンでは、OpenShift Web コンソールの 9 のボックスメニューに Simple ArgoCD という Argo CD インスタンスをデプロイします。多数のアプリケーションがデプロイされますがここで注目できる 2 つの重要なアプリケーションは hello-openshift とkbs-access です。

hello-openshift アプリケーションは Web アプリケーションを次のように 3 回デプロイします。 

• 標準の Pod としてデプロイ
• kata Pod としてデプロイ (ユーザーが Pod で実行できるように、エージェント設定は意図的にオーバーライドされる)
• 「セキュア」なアプリケーションとしてデプロイ (CoCo 強化機能が有効にされる)

kbs-access アプリケーションは、init コンテナを使用して Trustee からシークレットを取得するシンプルなデモです。KBS アクセスにより、Web API を介してシークレットにアクセスできるため、システムを介してシークレットの変更がどのように伝播するかを確認できます。init コンテナを使ってシークレットを取得するこの手法は、既存のアプリケーションのセキュリティを向上させる際に便利です。コードを開発する場所がどこであっても、Trustee を必要とせずにシークレットを取得できるからです。

CoCo パターンをデプロイする際のセキュリティに関する考慮事項 

機密コンテナの主な目的はセキュリティであるため、機密コンテナの検証済みパターンのセキュリティ体制を配慮することが重要になります。このパターンについては、主に次の 2 つ点を考慮する必要があります。

• このパターンでは、単純な参照値を使用する。RATS アテステーション・フローについて確認し、貴社のセキュリティニーズとシステムのリスクプロファイルに適したポリシーを策定することをお勧めします。
• Trustee デプロイメントを分離する。これは最初の考慮事項とも関連していますが、Trustee のアテステーション・サービスは「信頼できる別のセキュリティゾーンで運用される」という原則を前提にしています。これは理想的には、オンプレミスや別のクラウドプロバイダーといった異なる環境のことを指しています。

以下の図は、機密コンテナの検証済みパターンを使用して、分離された環境に Trustee をデプロイするためのアーキテクチャを示しています。

CoCo パターンの今後について 

現在の CoCo 検証済みパターンは、十分に使い始めることができます。これは、単一のクラスタと環境での機能を十分に検証してから、テストを開始することに重点を置いています。Red Hat の目下の焦点は、より実用的な例を増やして、機密コンテナの活用し続けられるようにすることにあります。

また、マルチクラスタのハブアンドスポーク・デプロイメントをサポートして、Trustee を Red Hat Advanced Cluster Management を使用してハブにデプロイできるようにし、スポーククラスタを機密ワークロードが実行される場所に配置できるようにすることを検討しています。

また、シークレット管理に Trustee を使用する実用的な例も紹介する予定です。今回は簡単な例を紹介しましたが、今後の開発における優先事項は、TEE 内での管理されたストレージの暗号化、Trustee を認識しないアプリケーション向けのシークレットの初期化、および VPN 設定などです。

また、CoCo と Trustee をデプロイするために他の環境もサポートし、オンプレミスや複数のクラウドサービスプロバイダー上のリソース間で信頼性を強化できるようにしたいと考えています。

まとめ 

機密コンテナの検証済みパターンは、CoCo を使い始めるためのシンプルなメカニズムを提供します。これは、実験を開始し、Argo CD で標準化された App-of-Apps GitOps アプローチを活用して、単一のリポジトリに独自の自己完結型アプリケーションをフォークしてデプロイするのにも役立ちます。前述のように、git clone と make install を実行するだけの簡単な操作で使い始められます。