次の方法で共有

Azure Kubernetes Service (AKS) の機密コンテナー (プレビュー)

  • [アーティクル]

機密コンテナーには、データ セキュリティ、データ プライバシー、ランタイム コード整合性のより高い目標を達成するために、標準コンテナー ワークロードをさらにセキュリティで保護する一連の機能が用意されています。 Azure Kubernetes Service (AKS) には、AKS 上の機密コンテナー (プレビュー) が含まれています。

機密コンテナーは、Kata Confidential Containers と、コンテナー メモリを暗号化するためのハードウェア ベースの暗号化に基づいて構築されています。 計算中にメモリ内のデータがクリア テキストで読み取り可能な形式にならないようにすることで、新たなレベルのデータ機密性が確立されます。 ハードウェア構成証明を通じてコンテナー内での信頼が得られ、信頼されたエンティティによる暗号化されたデータへのアクセスが許可されます。

ポッド サンドボックスと共に、Azure 内で分離された機密性の高いワークロードを実行して、データとワークロードを保護できます。 コンテナーを機密にする仕組み:

  • 透過性: 機密アプリケーションが共有されている機密コンテナー環境。安全かどうかを確認できます。 トラステッド コンピューティング ベース (TCB) のすべてのコンポーネントはオープン ソースになります。
  • 監査性: Linux ゲスト OS とすべてのコンポーネントを含む CoCo 環境パッケージの現在のバージョン確認できます。 Microsoft は、構成証明を使用して検証するために、ゲスト OS とコンテナー ランタイム環境にサインインします。 また、ゲスト OS ビルドのセキュリティで保護されたハッシュ アルゴリズム (SHA) をリリースして、文字列の読みやすさと制御のストーリーを構築します。
  • 完全な構成証明: TEE の一部であるものは、リモートで検証できる CPU によって完全に測定されます。 AMD SEV-SNP プロセッサからのハードウェア レポートには、構成証明要求を通じてコンテナー レイヤーとコンテナー ランタイム構成ハッシュが反映されます。 アプリケーションは、ゲスト OS イメージとコンテナー ランタイムを反映したレポートを含め、ハードウェア レポートをローカルでフェッチできます。
  • コードの整合性: ランタイムの実行は、不変ポリシーやコンテナー署名など、コンテナーとコンテナー構成に関する顧客定義のポリシーを通じて常に可能です。
  • オペレーターからの分離: 最小限の特権と、顧客/テナント管理者を含むすべての信頼されていない関係者からの最高の分離シールドを想定したセキュリティ設計。 これには、機密ポッドへの既存の Kubernetes コントロール プレーン アクセス (kubelet) の強化が含まれます。

他のセキュリティ対策またはデータ保護制御を全体的なアーキテクチャの一部として使用することで、これらの機能は、機密情報をセキュリティで保護するための規制、業界、またはガバナンスのコンプライアンス要件を満たすのに役立ちます。

この記事は、機密コンテナー機能と、以下を実装して構成する方法を理解するのに役立ちます。

  • Azure CLI を使用して AKS クラスターをデプロイまたはアップグレードする
  • ポッドの YAML に注釈を追加することで、機密コンテナーとして実行されるポッドのマークを付ける
  • ポッドの YAML にセキュリティ ポリシーを追加する
  • セキュリティ ポリシーの適用を有効にする
  • アプリケーションをコンフィデンシャル コンピューティング内にデプロイする

サポートされるシナリオ

機密コンテナー (プレビュー) は、機密データを含むデプロイ シナリオに適しています。 たとえば、個人を特定できる情報 (PII) や、規制コンプライアンスに必要な強力なセキュリティが適用されたデータなどです。 コンテナーの一般的なシナリオを次に示します。

  • 財務部門での不正パターン認識のために Apache Spark を使用してビッグ データ分析を実行する。
  • 継続的インテグレーションと継続的デプロイ (CI/CD) の DevOps プラクティスの一環として、コードに安全に署名するためのセルフホステッド GitHub ランナーを実行する。
  • 信頼できるソースからの暗号化されたデータ セットを使用した、ML モデルの機械学習推論とトレーニング。 機密性の高いコンテナー環境内でのみ暗号化が解除され、プライバシーが維持されます。
  • デジタル広告を使用した小売りなどの業界でのマルチパーティ計算の一環として、ID 照合用のビッグ データ クリーン ルームを構築する。
  • クラウドへのアプリケーション移行に関するプライバシー規制を満たすために、コンフィデンシャル コンピューティングのゼロ トラスト ランディング ゾーンを構築する。

考慮事項

機密コンテナーのこのプレビューに関する考慮事項を次に示します。

  • runc ポッドおよびカーネル分離ポッドと比較した、ポッドの起動時間の増加。
  • バージョン 1 のコンテナー イメージはサポートされていません。
  • シークレットと ConfigMap に対する更新はゲストに反映されません。
  • コンテナーへの exec、コンテナーからのログ出力、stdio (ReadStreamRequest と WriteStreamRequest) など、エフェメラル コンテナーとその他のトラブルシューティング方法には、ポリシーの変更と再デプロイが必要です。
  • ポリシー ジェネレーター ツールで cronjob デプロイの種類はサポートされていません。
  • コンテナー イメージ レイヤーの測定値はセキュリティ ポリシーでエンコードされているため、コンテナーを指定するときに latest タグを使用することはお勧めしません。
  • サービス、ロード バランサー、EndpointSlices では、TCP プロトコルのみがサポートされます。
  • クラスター上のすべてのポッド内のすべてのコンテナーを imagePullPolicy: Always に構成する必要があります。
  • ポリシー ジェネレーターでは、IPv4 アドレスを使用するポッドのみがサポートされます。
  • ポッドのデプロイ後に環境変数による方法を使用して設定する場合、ConfigMap とシークレットの値を変更することはできません。 それはセキュリティ ポリシーによって防止されます。
  • ポッド終了ログはサポートされていません。 ポッドの終了ログは、/dev/termination-log、またはポッド マニフェストで指定されている場合はカスタムの場所に書き込まれますが、host または kubelet でそれらのログを読み取ることはできません。 ゲストからそのファイルへの変更は、ホストには反映されません。

リソース割り当ての概要

このリリースでは、メモリとプロセッサのリソース割り当ての動作を理解しておくことが重要です。

  • CPU: shim は、ポッド内のベース OS に 1 つの vCPU を割り当てます。 リソースの limits が指定されていない場合、ワークロードには別個の CPU 共有が割り当てられず、vCPU はそのワークロードと共有されます。 CPU の制限が指定されている場合、CPU 共有はワークロードに明示的に割り当てられます。
  • メモリ: Kata-CC ハンドラーでは、UVM OS に 2 GB のメモリを使用しますが、YAML マニフェストで指定されている場合に X がリソース limits である場合は、X MB の追加メモリを使用します (制限がなければ、コンテナーの暗黙的なメモリなしで、2 GB の VM になります)。 Kata ハンドラーでは、UVM OS に 256 MB のメモリを使用しますが、YAML マニフェストにリソース limits が指定されている場合は、X MB の追加メモリを使用します。 制限が指定されていない場合は、1,792 MB の暗黙的な制限が追加され、コンテナー用に 2 GB の VM と 1,792 MB の暗黙的なメモリが追加されます。

このリリースでは、ポッド マニフェストでのリソース要求の指定はサポートされていません。 Kata コンテナーはポッド YAML マニフェストからのリソース要求を無視し、その結果、コンテナーから shim に要求は渡されません。 リソースの requests の代わりに、リソースの limit を使用して、ワークロードまたはコンテナーにメモリまたは CPU リソースを割り当てます。

VM メモリによってサポートされるローカル コンテナー ファイル システムでは、コンテナー ファイル システムへの書き込み (ログ記録を含む) によって、ポッドに提供される使用可能なメモリがいっぱいになる可能性があります。 この状態により、ポッドがクラッシュする可能性があります。

次のステップ