機密コンテナーと既定のポリシーを含んだ 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-previewAzure CLI 拡張機能バージョン 0.5.169 以降。confcomConfidential 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"
新しいクラスターをデプロイする
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 つ目のノード プールを追加します。
クラスターの準備ができたら、az aks get-credentials コマンドでクラスターの資格情報を取得します。
az aks get-credentials --resource-group myResourceGroup --name myAKSClusteraz 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 クラスターでこの機能を使用するには、次の要件を満たす必要があります。
- 説明に従って、KataCcIsolationPreview 機能フラグを登録する手順を実行します。
- クラスターで実行している Kubernetes のバージョンが 1.25.0 以降であることを確認します。
- クラスターに対してワークロード ID を有効にします (まだ有効にしていない場合)。
次のコマンドを実行して、機密コンテナー (プレビュー) をホストするノード プールを作成し、機密コンテナー (プレビュー) を有効にします。
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 形式で返されます。
az aks update コマンドを実行し、クラスターに対して機密コンテナー (プレビュー) を有効にします。
az aks update --name myAKSCluster --resource-group myResourceGroup数分後、コマンドが完了し、クラスターに関する情報が JSON 形式で返されます。
クラスターの準備ができたら、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 を使用してキー コンテナーを作成する」を参照してください。
前に作成したマネージド 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次のコマンドを実行して、Kafka クラスターを Kafka 名前空間にインストールします。
kubectl create -f 'https://strimzi.io/install/latest?namespace=kafka' -n kafka次のコマンドを実行して、
kafkaクラスター CR ファイルを適用します。kubectl apply -f https://strimzi.io/examples/latest/kafka/kafka-persistent-single.yaml -n kafkaGitHub のこのワークロード用の Bash スクリプトを使用して、RSA 暗号化/解読キーを準備します。 このファイルを
setup-key.shとして保存します。次のコマンドを実行して、
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_ENDPOINTNote
Microsoft Azure Attestation の設定については、「クイックスタート: Azure CLI を使用して Azure Attestation を設定する」をご覧ください。
次の 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-consumerNote
ポッド環境変数
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-を実行して確認できます。次のコマンドを実行して、Kafka コンシューマー YAML マニフェストのセキュリティ ポリシーを生成し、
WORKLOAD_MEASUREMENT変数に格納されているセキュリティ ポリシーのハッシュを取得します。export WORKLOAD_MEASUREMENT=$(az confcom katapolicygen -y consumer.yaml --print-policy | base64 -d | sha256sum | cut -d' ' -f1)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 のトラブルシューティング」もご覧ください。キーをキー コンテナーに正常にアップロードできたことを確認するには、次のコマンドを実行します。
az account set --subscription <Subscription ID> az keyvault key list --vault-name <KeyVault Name> -o table次の 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: 200mNote
文字列
-----BEGIN PUBLIC KEY-----で始まって文字列-----END PUBLIC KEY-----で終わる値を、前のステップで作成したkafka-encryption-demo-pub.pemの内容で更新します。前に保存しておいたファイルを使用し、
consumerとproducerの YAML マニフェストをデプロイします。kubectl apply -f consumer.yamlkubectl apply -f producer.yaml次のコマンドを使用して、Web サービスの IP アドレスを取得します。
kubectl get svc consumer -n kafkaコンシューマー サービスの外部 IP アドレスをコピーしてブラウザに貼り付け、復号化されたメッセージを確認します。
コマンドの出力は、次の例のようになります。
Welcome to Confidential Containers on AKS! Encrypted Kafka Message: Msg 1: Azure Confidential Computingさらに、
skr containerとkata-cc runtime classの指定を削除することにより、コンシューマーを通常の Kubernetes ポッドとして実行してみることをお勧めします。コンシューマーの実行に kata-cc ランタイム クラスを使用しなくなると、以後、このポリシーは必要ありません。ポリシー全体を削除し、ワークロードを再デプロイした後、ブラウザーでメッセージを再度確認してください。 秘密暗号化キーを取得できず、メッセージは 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 専用ホストの詳細について確認します。
Azure Kubernetes Service