Share via

機密コンテナーと既定のポリシーを含んだ AKS クラスターをデプロイする

  • [アーティクル]

この記事では、Azure CLI を使用し、Azure Kubernetes Service (AKS) クラスターのデプロイと、既定のセキュリティ ポリシーを含んだ機密コンテナー (プレビュー) の構成を行います。 次に、アプリケーションを機密コンテナーとしてデプロイします。 詳細については、「AKS 機密コンテナーの概要」を参照してください。

AKS 機密コンテナーの使用を開始するための一般的な手順は以下のとおりです。

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

前提条件

  • Azure CLI、バージョン 2.44.1 以降。 az --version を実行してバージョンを見つけ、az upgrade を実行してバージョンをアップグレードします。 インストールまたはアップグレードする必要がある場合は、Azure CLI のインストールに関するページを参照してください。

  • aks-preview Azure CLI 拡張機能バージョン 0.5.169 以降。

  • confcom Confidential Container Azure CLI 拡張機能 0.3.3 以降。 confcom は、セキュリティ ポリシーを生成するために必要です。

  • Azure サブスクリプションに Preview 機能を登録すること。

  • AKS は、バージョン 1.25.0 以降で機密コンテナー (プレビュー) をサポートしています。

  • ワークロード ID とフェデレーション ID 資格情報。 Kubernetes アプリケーションは、ワークロード ID 資格情報により、注釈付きサービス アカウントに基づく Microsoft Entra ID を使用して Azure リソースに安全にアクセスできます。 Microsoft Entra ワークロード ID の十分な知識がない方は、Microsoft Entra ワークロード ID の概要と、ワークロード ID を AKS で使用する方法に関する説明を参照してください。

  • クラスターの作成に使用している ID には、適切な最小限のアクセス許可が与えられています。 AKS のアクセスと ID の情報については、「Azure Kubernetes Service (AKS) でのアクセスと ID オプション」を参照してください。

  • Kubernetes クラスターを管理するには、Kubernetes のコマンドライン クライアントである kubectl を使用します。 Azure Cloud Shell には kubectl が付属しています。 az aks install-cli コマンドを使用して kubectl をローカルにインストールできます。

  • AKS 上の機密コンテナーは、構成証明とセキュアなキー発行のためのサイドカー オープン ソース コンテナーとして機能します。 このサイドカーは、Azure Key Vault などのキー管理サービス (KMS) との統合により、検証完了後にコンテナー グループへのキー発行を担います。 Azure Key Vault Managed HSM (ハードウェア セキュリティ モジュール) は、必須ではありませんが、コンテナー レベルの整合性と構成証明をサポートするためにデプロイすることをお勧めします。 Managed HSM のデプロイについては、「Managed HSM のプロビジョニングとアクティブ化」を参照してください。

aksプレビューの Azure CLI 拡張機能をインストールする

重要

AKS のプレビュー機能は、セルフサービスのオプトイン単位で利用できます。 プレビューは、"現状有姿のまま" および "利用可能な限度" で提供され、サービス レベル アグリーメントおよび限定保証から除外されるものとします。 AKS プレビューは、ベストエフォート ベースでカスタマー サポートによって部分的にカバーされます。 そのため、これらの機能は、運用環境での使用を意図していません。 詳細については、次のサポート記事を参照してください。

aksプレビュー拡張機能をインストールして、次のコマンドを実行します：

az extension add --name aks-preview

次のコマンドを実行して、リリースされた最新バージョンの拡張機能に更新します：

az extension update --name aks-preview

confcom Azure CLI 拡張機能をインストールする

confcom 拡張機能をインストールするには、次のコマンドを実行します。

az extension add --name confcom

次のコマンドを実行して、リリースされた最新バージョンの拡張機能に更新します：

az extension update --name confcom

KataCcIsolationPreview 機能フラグを登録する

KataCcIsolationPreview 機能フラグは、次の例のとおり、KataCcIsolationPreview コマンドを使用して登録します。

az feature register --namespace "Microsoft.ContainerService" --name "KataCcIsolationPreview"

状態が [登録済み] と表示されるまでに数分かかります。 登録の状態は、az feature show コマンドで確認します。

az feature show --namespace "Microsoft.ContainerService" --name "KataCcIsolationPreview"

状態が Registered と表示されたら、az provider register コマンドを使用して Microsoft.ContainerService リソース プロバイダーの登録を最新の情報に更新します。

az provider register --namespace "Microsoft.ContainerService"

新しいクラスターをデプロイする

  1. az aks create コマンドを使用し、次のパラメーターを指定して、AKS クラスターを作成します。

    • --os-sku: AzureLinux。 このプレビュー リリースでは、Azure Linux OS SKU のみがこの機能をサポートします。
    • --node-vm-size: 第 2 世代 VM であり、入れ子になった仮想化をサポートする任意の Azure VM サイズが機能します。 たとえば、Standard_DC8as_cc_v5 VM などが該当します。
    • --enable-workload-identity: ポッドで Kubernetes ID を使用可能にする Microsoft Entra ワークロード ID の作成を有効にします。
    • --enable-oidc-issuer: OpenID Connect (OIDC) 発行者を有効にします。 Microsoft Entra ID やその他のクラウド プロバイダー ID およびアクセス管理プラットフォームが、API サーバーの公開署名キーを検出できるようになります。

    次の例では、"myAKSCluster" というクラスターを更新し、"myResourceGroup" 内にシステム ノード プールを 1 つ作成します。

    az aks create --resource-group myResourceGroup --name myAKSCluster --kubernetes-version <1.25.0 and above> --os-sku AzureLinux --node-vm-size Standard_DC4as_cc_v5 --node-count 1 --enable-oidc-issuer --enable-workload-identity --generate-ssh-keys

    数分後、コマンドが完了し、クラスターに関する情報が JSON 形式で返されます。 前の手順で作成したクラスターには、ノード プールが 1 つあります。 この次の手順では、クラスターに 2 つ目のノード プールを追加します。

  2. クラスターの準備ができたら、az aks get-credentials コマンドでクラスターの資格情報を取得します。

    az aks get-credentials --resource-group myResourceGroup --name myAKSCluster

  3. az aks nodepool add コマンドを実行して、"myResourceGroup" の "nodepool2" にある "myAKSCluster" に、2 つのノードを持つユーザー ノード プールを追加します。 次のパラメーターを指定します。

    • --workload-runtime : "KataCcIsolation" を指定し、ノード プールに対して機密コンテナー機能を有効にします。 このパラメーターにより、次の他のパラメーターが次の要件を満たすようになります。 ない場合、コマンドは失敗し、対応するパラメーターに関する問題を報告します。
    • --os-sku: AzureLinux。 このプレビュー リリースでは、Azure Linux OS SKU のみがこの機能をサポートします。
    • --node-vm-size: 第 2 世代 VM であり、入れ子になった仮想化をサポートする任意の Azure VM サイズが機能します。 たとえば、Standard_DC8as_cc_v5 VM などが該当します。
    az aks nodepool add --resource-group myResourceGroup --name nodepool2 --cluster-name myAKSCluster --node-count 2 --os-sku AzureLinux --node-vm-size Standard_DC4as_cc_v5 --workload-runtime KataCcIsolation

数分後、コマンドが完了し、クラスターに関する情報が JSON 形式で返されます。

既存のクラスターにデプロイする

既存の AKS クラスターでこの機能を使用するには、次の要件を満たす必要があります。

次のコマンドを実行して、機密コンテナー (プレビュー) をホストするノード プールを作成し、機密コンテナー (プレビュー) を有効にします。

  1. az aks nodepool add コマンドを使用して、AKS クラスターにノード プールを追加します。 次のパラメーターを指定します。

    • --resource-group: AKS クラスターを作成する既存のリソース グループの名前を入力します。
    • クラスター名: AKS クラスターの一意の名前 ("myAKSCluster" など) を入力します。
    • --name: "nodepool2" などのクラスター ノード プールの一意の名前を入力します。
    • --workload-runtime: "KataCcIsolation" を指定し、ノード プールに対して機能を有効にします。 --workload-runtime パラメーターにより、次の他のパラメーターが次の要件を満たすようになります。 ない場合、コマンドは失敗し、対応するパラメーターに関する問題を報告します。
    • --os-sku: AzureLinux。 このプレビュー リリースでは、Azure Linux OS SKU のみがこの機能をサポートします。
    • --node-vm-size: 第 2 世代 VM であり、入れ子になった仮想化をサポートする任意の Azure VM サイズが機能します。 たとえば、Standard_DC8as_cc_v5 VM などが該当します。

    次の例では、"myResourceGroup" の "nodepool2" にある "myAKSCluster" に、2 つのノードを持つユーザー ノード プールを 追加します。

    az aks nodepool add --resource-group myResourceGroup --name nodepool2 –-cluster-name myAKSCluster --node-count 2 --os-sku AzureLinux --node-vm-size Standard_DC4as_cc_v5 --workload-runtime KataCcIsolation

    数分後、コマンドが完了し、クラスターに関する情報が JSON 形式で返されます。

  2. az aks update コマンドを実行し、クラスターに対して機密コンテナー (プレビュー) を有効にします。

    az aks update --name myAKSCluster --resource-group myResourceGroup

    数分後、コマンドが完了し、クラスターに関する情報が JSON 形式で返されます。

  3. クラスターの準備ができたら、az aks get-credentials コマンドでクラスターの資格情報を取得します。

    az aks get-credentials --resource-group myResourceGroup --name myAKSCluster

コンテナーを構成する

Azure Key Vault およびシークレットに対するアクセスの構成と、機密コンテナーとしてのアプリケーション デプロイを実行するには、ワークロード ID の構成作業が完了している必要があります。

ワークロード ID を構成するには、ワークロード ID をデプロイして構成する方法についての記事で説明されているとおり、以下の手順を実行します。

  • OIDC 発行者 URL を取得する
  • マネージド ID の作成
  • Kubernetes サービス アカウントを作成する
  • フェデレーション ID 資格情報を確立する

重要

このチュートリアルを最後まで続けるには、ワークロード ID のデプロイと構成に関する記事の「環境変数をエクスポートします」セクションから、"環境変数" を設定する必要があります。 ワークロード ID を構成する前に、忘れずに変数 SERVICE_ACCOUNT_NAMESPACE を kafka に設定してコマンド kubectl create namespace kafka を実行してください。

kata-cc と構成証明コンテナーを使用し、信頼されたアプリケーションをデプロイする

以下の手順では、Azure Managed Hardware Security Modules (mHSM) によって管理される暗号化キーを使用し、Kafka メッセージのエンドツーエンド暗号化を構成します。 このキーは、Kafka コンシューマーが機密コンテナー内で、ポッドに挿入された Azure 構成証明シークレット プロビジョニング コンテナーを使用して実行されている場合にのみ解放されます。

この構成は以下 4 つのコンポーネントに基づいています。

  • Kafka クラスター: クラスター上の Kafka 名前空間にデプロイされた単純な Kafka クラスター。
  • Kafka プロデューサー: バニラ Kubernetes ポッドとして実行され、公開キーで暗号化されたユーザー構成のメッセージを Kafka トピックへと送信する Kafka プロデューサー。
  • Kafka コンシューマー: セキュアなキー発行コンテナーを備え、kata-cc ランタイムで実行される Kafka コンシューマー ポッド。Kafka メッセージを復号化する秘密キーの取得と、Web UI へのメッセージ レンダリングを行います。

このプレビュー リリースでは、テストおよび評価目的のために、Azure Key Vault Premium レベルの新規作成リソースまたは既存リソースを使用してハードウェア セキュリティ モジュール (HSM) へのキー格納をサポートすることをお勧めします。 運用環境用キー コンテナーの使用はお勧めしません。 まだ Azure Key Vault を使用していない場合は、「Azure CLI を使用してキー コンテナーを作成する」を参照してください。

  1. 前に作成したマネージド ID と自分のアカウントに、キー コンテナーへのアクセス権を付与します。 これら両方の ID に、Azure RBAC の Key Vault Crypto Officer ロールと Key Vault Crypto User ロールを割り当てます。

    Note

    • マネージド ID は、USER_ASSIGNED_IDENTITY_NAME 変数に代入した値です。

    • ロールの割り当てを追加するには、Key Vault データ アクセス管理者、ユーザー アクセス管理者、所有者など、Microsoft.Authorization/roleAssignments/write と Microsoft.Authorization/roleAssignments/delete のアクセス許可が必要です。

    • HSM で保護されたキーをサポートするには、Key Vault Premium SKU を使う必要があります。

    次のコマンドを実行して、スコープを設定します。

    AKV_SCOPE=$(az keyvault show --name <AZURE_AKV_RESOURCE_NAME> --query id --output tsv)

    次のコマンドを実行して、Key Vault Crypto Officer ロールを割り当てます。

    az role assignment create --role "Key Vault Crypto Officer" --assignee "${USER_ASSIGNED_IDENTITY_NAME}" --scope $AKV_SCOPE

    次のコマンドを実行して、Key Vault Crypto User ロールを割り当てます。

    az role assignment create --role "Key Vault Crypto User" --assignee "${USER_ASSIGNED_IDENTITY_NAME}" --scope $AKV_SCOPE

  2. 次のコマンドを実行して、Kafka クラスターを Kafka 名前空間にインストールします。

    kubectl create -f 'https://strimzi.io/install/latest?namespace=kafka' -n kafka

  3. 次のコマンドを実行して、kafka クラスター CR ファイルを適用します。

    kubectl apply -f https://strimzi.io/examples/latest/kafka/kafka-persistent-single.yaml -n kafka

  4. GitHub のこのワークロード用の Bash スクリプトを使用して、RSA 暗号化/解読キーを準備します。 このファイルを setup-key.sh として保存します。

  5. 次のコマンドを実行して、MAA_ENDPOINT 環境変数に構成証明 URI の FQDN を設定します。

    export MAA_ENDPOINT="$(az attestation show --name "myattestationprovider" --resource-group "MyResourceGroup" --query 'attestUri' -o tsv | cut -c 9-)"

    構成証明 URI の FQDN が正しい形式かどうかを確認します (MAA_ENDPOINT にプレフィックス "https://" が含まれていてはなりません)。

    echo $MAA_ENDPOINT

    Note

    Microsoft Azure Attestation の設定については、「クイックスタート: Azure CLI を使用して Azure Attestation を設定する」をご覧ください。

  6. 次の YAML マニフェストをコピーし、consumer.yaml として保存します。

    apiVersion: v1
kind: Pod
metadata:
  name: kafka-golang-consumer
  namespace: kafka
  labels:
    azure.workload.identity/use: "true"
    app.kubernetes.io/name: kafka-golang-consumer
spec:
  serviceAccountName: workload-identity-sa
  runtimeClassName: kata-cc-isolation
  containers:
    - image: "mcr.microsoft.com/aci/skr:2.7"
      imagePullPolicy: Always
      name: skr
      env:
        - name: SkrSideCarArgs
          value: ewogICAgImNlcnRjYWNoZSI6IHsKCQkiZW5kcG9pbnRfdHlwZSI6ICJMb2NhbFRISU0iLAoJCSJlbmRwb2ludCI6ICIxNjkuMjU0LjE2OS4yNTQvbWV0YWRhdGEvVEhJTS9hbWQvY2VydGlmaWNhdGlvbiIKCX0gIAp9
      command:
        - /bin/skr
      volumeMounts:
        - mountPath: /opt/confidential-containers/share/kata-containers/reference-info-base64
          name: endor-loc
    - image: "mcr.microsoft.com/acc/samples/kafka/consumer:1.0"
      imagePullPolicy: Always
      name: kafka-golang-consumer
      env:
        - name: SkrClientKID
          value: kafka-encryption-demo
        - name: SkrClientMAAEndpoint
          value: sharedeus2.eus2.test.attest.azure.net
        - name: SkrClientAKVEndpoint
          value: "myKeyVault.vault.azure.net"
        - name: TOPIC
          value: kafka-demo-topic
      command:
        - /consume
      ports:
        - containerPort: 3333
          name: kafka-consumer
      resources:
        limits:
          memory: 1Gi
          cpu: 200m
  volumes:
    - name: endor-loc
      hostPath:
        path: /opt/confidential-containers/share/kata-containers/reference-info-base64
---
apiVersion: v1
kind: Service
metadata:
  name: consumer
  namespace: kafka
spec:
  type: LoadBalancer
  selector:
    app.kubernetes.io/name: kafka-golang-consumer
  ports:
    - protocol: TCP
      port: 80
      targetPort: kafka-consumer

    Note

    ポッド環境変数 SkrClientAKVEndpoint の値を、お使いの Azure Key Vault の URL と一致するように更新します (プロトコルの値 https:// は除きます)。 現在値のプレースホルダー値は myKeyVault.vault.azure.net です。 ポッド環境変数 SkrClientMAAEndpoint の値を MAA_ENDPOINT の値で更新します。 MAA_ENDPOINT の値は、コマンド echo $MAA_ENDPOINT またはコマンド az attestation show --name "myattestationprovider" --resource-group "MyResourceGroup" --query 'attestUri' -o tsv | cut -c 9- を実行して確認できます。

  7. 次のコマンドを実行して、Kafka コンシューマー YAML マニフェストのセキュリティ ポリシーを生成し、WORKLOAD_MEASUREMENT 変数に格納されているセキュリティ ポリシーのハッシュを取得します。

    export WORKLOAD_MEASUREMENT=$(az confcom katapolicygen -y consumer.yaml --print-policy | base64 -d | sha256sum | cut -d' ' -f1)

  8. RSA 非対称キーの組 (公開キーと秘密キー) を生成するために、次のコマンドで setup-key.sh スクリプトを実行します。 <Azure Key Vault URL> の箇所は、<your-unique-keyvault-name>.vault.azure.net の値に置き換えます。

    export MANAGED_IDENTITY=${USER_ASSIGNED_CLIENT_ID}
bash setup-key.sh "kafka-encryption-demo" <Azure Key Vault URL>

    Note

    • bash スクリプト setup-key.sh では、環境変数 MANAGED_IDENTITY が必要です。

    • 公開キーは、bash スクリプトの実行後に kafka-encryption-demo-pub.pem として保存されます。

    重要

    ForbiddenByRbac というエラーが発生する場合は、マネージド ID のバックエンド サービスがリソース URI ごとに最大 24 時間キャッシュを維持しているため、最大 24 時間待つ必要があります。 「Azure RBAC のトラブルシューティング」もご覧ください。

  9. キーをキー コンテナーに正常にアップロードできたことを確認するには、次のコマンドを実行します。

    az account set --subscription <Subscription ID>
az keyvault key list --vault-name <KeyVault Name> -o table

  10. 次の YAML マニフェストをコピーし、producer.yaml として保存します。

    apiVersion: v1
kind: Pod
metadata:
  name: kafka-producer
  namespace: kafka
spec:
  containers:
    - image: "mcr.microsoft.com/acc/samples/kafka/producer:1.0"
      name: kafka-producer
      command:
        - /produce
      env:
        - name: TOPIC
          value: kafka-demo-topic
        - name: MSG
          value: "Azure Confidential Computing"
        - name: PUBKEY
          value: |-
            -----BEGIN PUBLIC KEY-----
            MIIBojAN***AE=
            -----END PUBLIC KEY-----
      resources:
        limits:
          memory: 1Gi
          cpu: 200m

    Note

    文字列 -----BEGIN PUBLIC KEY----- で始まって文字列 -----END PUBLIC KEY----- で終わる値を、前のステップで作成した kafka-encryption-demo-pub.pem の内容で更新します。

  11. 前に保存しておいたファイルを使用し、consumer と producer の YAML マニフェストをデプロイします。

    kubectl apply -f consumer.yaml

    kubectl apply -f producer.yaml

  12. 次のコマンドを使用して、Web サービスの IP アドレスを取得します。

    kubectl get svc consumer -n kafka

  13. コンシューマー サービスの外部 IP アドレスをコピーしてブラウザに貼り付け、復号化されたメッセージを確認します。

    コマンドの出力は、次の例のようになります。

    Welcome to Confidential Containers on AKS!
Encrypted Kafka Message:
Msg 1: Azure Confidential Computing

  14. さらに、skr container と kata-cc runtime class の指定を削除することにより、コンシューマーを通常の Kubernetes ポッドとして実行してみることをお勧めします。コンシューマーの実行に kata-cc ランタイム クラスを使用しなくなると、以後、このポリシーは必要ありません。

  15. ポリシー全体を削除し、ワークロードを再デプロイした後、ブラウザーでメッセージを再度確認してください。 秘密暗号化キーを取得できず、メッセージは base64 でエンコードされた暗号化テキストとして表示されます。 これは、コンシューマーの実行環境が機密環境ではなくなり、skr container がないため、キーを取得できずメッセージを復号化できなくなったことを示しています。

クリーンアップ

この機能の評価が完了したら、Azure の料金を回避するために、不要なリソースをクリーンアップします。 評価またはテストの一部として新しいクラスターをデプロイした場合は、az aks delete コマンドを使用してクラスターを削除できます。

az aks delete --resource-group myResourceGroup --name myAKSCluster

既存のクラスターに対して機密コンテナー (プレビュー) を有効にした場合は、kubectl delete pod コマンドでポッドを削除できます。

kubectl delete pod pod-name

次のステップ

  • ハードウェアの分離と Azure プラットフォームのメンテナンス イベントの制御を使用するための、AKS クラスターを持つノード用の Azure 専用ホストの詳細について確認します。