方法: KMS プロバイダーを使用して Kubernetes シークレットのシークレット暗号化を有効にする

適用対象: AKS on Azure Local

Kubernetes クラスターは、 シークレット と呼ばれる小さな情報を永続的な Kubernetes シークレット ストア (etcd) に格納します。 多くの場合、これらのシークレットには、K8s にデプロイされたアプリケーションの操作に不可欠な、パスワード、トークン、証明書などの機密データが含まれています。 既定では、この情報はエンコードされますが、保存時に暗号化されません。つまり、承認されていないユーザーが基になるストレージにアクセスすると、これらのシークレットがデコードされる可能性があります。 KMS プロバイダーは、基になるデータを暗号化することで、このギャップに対処します。 シークレット ストア内の各シークレットは、最初に K8s API サーバーによって生成された一意のデータ暗号化キー (DEK) で暗号化されます。 この DEK は一時的にメモリに保持され、ディスクに書き込まれることはありません。 その後、API サーバーは、KMS プロバイダーがキー暗号化キー (KEK) を使用して DEK を暗号化することを要求します。 最終的な暗号化されたシークレットには、暗号化されたデータと暗号化された DEK の両方が含まれており、KEK なしでシークレットが安全でアクセスできないようにします。

AKS on Azure Local には、KMS プロバイダーを使用した etcd シークレットの暗号化が付属しています。 2510 リリースより前の Azure Local のすべての Kubernetes クラスターでは、組み込みの KMS v1 プロバイダーが既定で有効になっています。 このプロバイダーは 、キー暗号化キー (KEK) を生成し、30 日ごとに自動的にローテーションします。

2510 AKS on Azure Local リリース以降、新しいクラスターデプロイでは KMS v2 が既定で有効になります。 既存のクラスターでは引き続き KMS v1 が使用されます。 KMS v2 プロバイダーの詳細については、 公式のガイダンスを参照してください。

この記事では、KMS プロバイダー、暗号化の検証、KEK ローテーション後のシークレットの更新に関する情報を提供します。 詳細については、 KMS プロバイダーの Kubernetes の公式ドキュメントを参照してください。

Azure Local 2510 以降の KMS v2

KMS v1 は Kubernetes v1.28 で非推奨となりました。KMS v2 に移行することをお勧めします。 KMS v2 標準では、クラスターの起動時にシリアル暗号化解除を行う必要がなくなり、API 呼び出しのオーバーヘッドが削減され、外部キー サービスレートの制限が回避されるため、KMS v1 で見られるパフォーマンスのボトルネックが解消されます。 これにより、クラスターの初期化が高速化され、アプリケーションの起動がスムーズになります。 その他の利点としては、信頼性の向上、2,000 個を超えるシークレットのスケーラビリティ、豊富な正常性チェックによる監視の強化などがあります。

KMS プロバイダー v2 は、AKS Arc で作成するすべての新しいクラスターに対して自動的に有効になります。実行する必要はありません。 プロバイダーは新しい KEK をすぐに生成し、30 日ごとに自動的にローテーションし、キー侵害のリスクを軽減します。 各ローテーションの後、この新しい KEK を使用して、作成した後続のシークレットの DEK を暗号化します。 クラスター内の既存のシークレットは自動的に再暗号化されません。 現時点では、既存のクラスターでは引き続き KMS v1 プロバイダーが使用されます。

開始する前に

開始する前に、次の前提条件を満たしていることを確認してください。

• Kubernetesクラスターと対話するには、kubectl と kubelogin をインストールする必要があります。
• シークレットを表示または管理するには、シークレットにアクセスするために必要な権限があることを確認してください。 詳細については、「 アクセスと ID」を参照してください。
• Azure Local 2510 に新しい Kubernetes クラスターをデプロイする必要があります。 詳細については、 Azure ローカル クラスターを作成する手順を参照してください。

Microsoft Entra 対応クラスターにアクセスする

az aksarc get-credentials コマンドを使用して、クラスターにアクセスするためのユーザー資格情報を取得します。 Azure Kubernetes Service Arc クラスター ユーザー ロールのアクセス許可に含まれている Microsoft.HybridContainerService/provisionedClusterInstances/listUserKubeconfig/action リソースが必要です。

az aksarc get-credentials --resource-group $resource_group --name $aks_cluster_name

KMS プロバイダーが有効になっていることを確認する (省略可能)

KMS プロバイダーが有効になっていることを確認する場合、この手順は省略可能です。 次のコマンドを実行し、 kms プロバイダー の正常性状態が OK であることを確認します。

kubectl get --raw='/readyz?verbose'

[+]ping ok
[+]Log ok
[+]etcd ok
[+]kms-providers ok
[+]poststarthook/start-encryption-provider-config-automatic-reload ok

データが暗号化されていることを確認する (省略可能)

シークレットとデータが KMS プロバイダーを使用して暗号化されたことを確認する場合、この手順は省略可能です。 Kubernetes のドキュメントを参照してください。 次のコマンドを使用して、データが暗号化されていることを確認できます。

kubectl exec --stdin --tty <etcd pod name> -n kube-system --etcdctl --cacert /etc/kubernetes/pki/etcd/ca.crt --key /etc/kubernetes/pki/etcd/server.key --cert /etc/kubernetes/pki/etcd/server.crt get /registry/secrets/default/db-user-pass -w fields

• kubectl exec: これは、実行中のポッド内でコマンドを実行するために使用される kubectl コマンドです。 これにより、ポッドのコンテナ内でコマンドを実行できます。

• --stdin: このフラグを使用すると、ポッド内で実行しているコマンドに入力 (stdin) を送信できます。

• --tty: このフラグは、コマンドに TTY (ターミナル) を割り当て、ターミナル セッションと対話しているかのように動作します。

• <etcd pod name>: etcd ポッド名を見つけるには、次のコマンドを実行します。

  kubectl get pods -n kube-system | findstr etcd-moc
  

• -n kube-system: ポッドが配置されている名前空間を指定します。 kube-system は、etcdやその他のコントロールプレーンサービスなどのシステムコンポーネントにKubernetesが使用するデフォルトの名前空間です。

• --etcdctl: etcd からシークレットを読み込みます。 追加のフィールドは、etcd にアクセスする前の認証に使用されます。

コマンド出力では、次のフィールドが返されます。

"ClusterID" : <cluster id> 
"MemberID" : <member id> 
"Revision" : <revision number> 
"RaftTerm" : 2 
"Key" : <path to the key>
"CreateRevision" : <revision number at the time the key was created> 
"ModRevision" :  <revision number at the time the key was modified> 
"Version" : <version of the key-value pair in etcd> 
"Value" : "k8s:enc:kms:v1:kms-plugin: <encrypted secret value>"  
"Lease" : <lease associated with the secret> 
"More" : <indicates if there are more results> 
"Count" : <number of key-value pairs returned> 

コマンドを実行した後、ターミナル・ウィンドウの出力の Value フィールドを調べます。 この出力は、このキーの etcd シークレットストアに格納されている値 (シークレットの暗号化された値) を示しています。 値は KMS プロバイダーを使用して暗号化されます。 k8s:enc:kms:v1: プレフィックスは、Kubernetes が KMS v1 プロバイダーを使用して暗号化された形式でシークレットを格納していることを示します。

KEK のローテーション後にシークレットを更新する方法

KEK は 30 日ごとに自動的に更新されます。 この時点で、各シークレットは、作成時に使用されていた KEK で暗号化されたままになります。 次にシークレットを更新すると、現在の KEK で再暗号化されます。 通常のプロセスの一部としてシークレット値を定期的に更新しない場合は、30 日ごとに (同じ値で) 再書き込みを検討してください。 これにより、 Kubernetes のベスト プラクティス に従い、すべてのシークレットが最新の KEK で暗号化されます。 大規模なクラスターの場合は、各名前空間のシークレットを順番に更新するか、スクリプトやその他の自動化を開発してプロセスを効率化することを検討してください。

kubectl get secrets --all-namespaces -o json | kubectl replace -f - 

トラブルシューティング

KMS プロバイダーでエラーが発生した場合は、[ トラブルシューティング] ページ の手順に従って問題のトラブルシューティングを行います。

次のステップ

• Azure Arc で有効になっている AKS のセキュリティブックのガイダンスに従って、クラスターを他の方法で保護する方法を説明します。
• Kubernetes クラスターの作成
• Kubernetes クラスター に Linux アプリケーションをデプロイする