次の方法で共有

Azure Kubernetes Service (AKS) クラスターでの証明書ローテーション

Azure Kubernetes Service (AKS) では、そのコンポーネントの多くで認証に証明書が使用されています。 2022 年 3 月以降に作成された Azure ロールベースのアクセス制御 (Azure RBAC) を持つクラスターは、証明書の自動ローテーションで有効になります。 セキュリティまたはポリシー上の理由から、これらの証明書を定期的にローテーションすることが必要になる場合があります。 たとえば、すべての証明書を 90 日ごとにローテーションするポリシーがあるとします。

注

証明書の自動ローテーションは、RBAC が有効な AKS クラスターに対してのみ既定で有効になっています。

この記事では、AKS クラスターでの証明書のローテーションのしくみについて説明します。

開始する前に

この記事では、Azure CLI バージョン 2.0.77 以降が必要です。 バージョンを確認するには az --version を実行します。 インストールまたはアップグレードする必要がある場合は、「Azure CLI のインストール」を参照してください。

AKS 証明書、証明機関、サービス アカウント

AKS では、次の証明書、証明機関 (CA)、サービス アカウント (SA) が生成されて使用されます:

  • AKS API サーバーでは、クラスター CA と呼ばれる CA が作成されます。
  • API サーバーには、API サーバーから kubelets への一方向の通信に使用する証明書に署名するクラスター CA があります。
  • 各 kubelet では、kubelet から API サーバーへの通信のために証明書署名要求 (CSR) が作成され、クラスター CA によって署名されます。
  • API アグリゲーターでは、他の API との通信に証明書を発行するためにクラスター CA が使用されます。 API アグリゲーターでは、これらの証明書を発行するための独自の CA を持つこともできますが、現在はクラスター CA が使用されています。
  • 各ノードでは、クラスター CA が署名した SA トークンが使われます。
  • kubectl クライアントには、AKS クラスターと通信するための証明書があります。

クラスター証明書を除き、このセクションで説明されているすべての証明書は Microsoft によって管理されます。

注

  • 2019 年 5 月より "前" に作成された AKS クラスターには、2 年後に期限切れになる証明書があります。
  • 2019 年 5 月より "後" に作成された AKS クラスターには、30 年後に期限切れになるクラスター CA 証明書があります。

クラスターがいつ作成されたかは、kubectl get nodes コマンドを使用して確認できます。このコマンドでは、ノード プールの "使用年数" が示されます。

証明書の有効期限を確認する

クラスター証明書の有効期限を確認する

  • kubectl config view コマンドを使用してクラスター証明書の有効期限を確認します。

    kubectl config view --raw -o jsonpath="{.clusters[?(@.name == '')].cluster.certificate-authority-data}" | base64 -d | openssl x509 -text | grep -A2 Validity

API サーバー証明書の有効期限を確認する

  • 次の curl コマンドを使用して API サーバー証明書の有効期限を確認します。

    curl https://{apiserver-fqdn} -k -v 2>&1 | grep expire

VMAS エージェント ノード証明書の有効期限を確認する

  • az vm run-command invoke コマンドを使用して VMAS エージェント ノード証明書の有効期限を確認します。

    az vm run-command invoke --resource-group MC_rg_myAKSCluster_region --name vm-name --command-id RunShellScript --query 'value[0].message' -otsv --scripts "openssl x509 -in /etc/kubernetes/certs/apiserver.crt -noout -enddate"

仮想マシン スケール セット エージェント ノードの証明書の有効期限を確認する

  • az vmss run-command invoke コマンドを使用して仮想マシン スケール セット エージェント ノード証明書の有効期限を確認します。

    az vmss run-command invoke --resource-group "MC_rg_myAKSCluster_region" --name "vmss-name" --command-id RunShellScript --instance-id 1 --scripts "openssl x509 -in  /var/lib/kubelet/pki/kubelet-client-current.pem -noout -enddate" --query "value[0].message"

証明書の自動ローテーション

AKS で非 CA 証明書を自動的にローテーションするには、クラスターに TLS ブートストラップが必要です。これは既定ですべての Azure リージョンで有効になります。

注

  • 既存のクラスターがある場合は、そのクラスターをアップグレードして、証明書の自動ローテーションを有効にする必要があります。
  • ブートストラップを無効にして、自動ローテーションを有効にしたままにしないでください。
  • 証明書の自動ローテーションの間にクラスターが停止状態になっていると、コントロール プレーンの証明書のみがローテーションされます。 この場合、証明書のローテーションの後でノード プールを作成し直して、ノード プール証明書のローテーションを開始する必要があります。

2022 年 3 月以降に作成またはアップグレードされた AKS クラスターの場合、Azure Kubernetes Service は、クラスターのダウンタイムなしで期限切れになる前に、クライアント証明書の有効期間の 80% 以内にコントロール プレーンとエージェント ノードの両方で非 CA 証明書を自動的にローテーションします。

現在のエージェント ノード プールで TLS ブートストラップが有効かどうかを確認する方法

  1. 次のいずれかのパスを参照することで、お使いのクラスターで TLS ブートストラップが有効になっているかどうかを確認します:

    • Linux ノードの場合: /var/lib/kubelet/bootstrap-kubeconfig または /host/var/lib/kubelet/bootstrap-kubeconfig
    • Windows ノードの場合: C:\k\bootstrap-config

    詳しくは、「メンテナンスまたはトラブルシューティングのために Azure Kubernetes Service (AKS) クラスター ノードに接続する」をご覧ください。

    注

    Kubernetes のバージョンが進化すると、ファイル パスが変更される可能性があります。

  2. リージョンが構成されたら、新しいクラスターを作成するか、既存のクラスターをアップグレードして、クラスター証明書の自動ローテーションを設定します。 この機能を有効にするには、コントロール プレーンとノード プールをアップグレードする必要があります。

クラスター証明書を手動でローテーションする

警告

az aks rotate-certs を使用して証明書をローテーションすると、すべてのノード、仮想マシン スケール セット、ディスクが再作成され、AKS クラスターで最大 "30 分間のダウンタイム" が発生する可能性があります。

  1. az aks get-credentials コマンドを使用してクラスターに接続します。

    az aks get-credentials --resource-group $RESOURCE_GROUP_NAME --name $CLUSTER_NAME

  2. az aks rotate-certs を使用して、クラスターのすべての証明書、CA、SA をローテーションします。

    az aks rotate-certs --resource-group $RESOURCE_GROUP_NAME --name $CLUSTER_NAME

    重要

    az aks rotate-certsが完了するまでに最大 30 分かかる場合があります。 コマンドが完了する前に失敗した場合は、az aks show を使用して、クラスターの状態が "証明書のローテーション中" になっていることを確認します。 クラスターがエラー状態になっている場合は、az aks rotate-certs を再実行して、証明書をもう一度ローテーションします。

  3. kubectl get nodes などの任意の kubectl コマンドを使用して、古い証明書が無効になっていることを確認します。

    kubectl get nodes

    kubectl で使用されている証明書を更新していない場合は、次の出力例のようなエラーが表示されます:

    Unable to connect to the server: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "ca")

  4. az aks get-credentials コマンドと --overwrite-existing フラグを使用して、kubectl で使われている証明書を更新します。

    az aks get-credentials --resource-group $RESOURCE_GROUP_NAME --name $CLUSTER_NAME --overwrite-existing

  5. kubectl get コマンドを使用して、証明書が更新されたことを確認します。

    kubectl get nodes

    注

    AKS 上で実行されるサービスがある場合は、それらの証明書の更新が必要になることがあります。

Kubelet サービング証明書のローテーション

Kubelet サービング証明書のローテーションを使用すると、AKS はクラスター CA によって署名されたサービング証明書のブートストラップとローテーションの両方に kubelet サーバーの TLS ブートストラップを利用できます。

制限事項

  • Kubernetes バージョン 1.27 以降でサポートされています。
  • ノード プールが、 202501.12.0より古いノード イメージに基づいてノード プール スナップショットを使用している場合はサポートされません。
  • この機能を手動で有効にすることはできません。 既存のノード プールでは、kubernetes バージョン 1.27 以降への最初のアップグレードを実行するときに、証明書ローテーションを提供する kubelet が既定で有効になります。 kubernetes バージョン 1.27 以降の新しいノード プールでは、kubelet サービス証明書のローテーションが既定で有効になります。 Kubelet サービス証明書のローテーションがリージョンで有効になっているかどうかを確認するには、 AKS リリースを参照してください。

kubelet サービス証明書のローテーションが有効になっていることを確認する

機能が有効になっている各ノードには、ラベル kubernetes.azure.com/kubelet-serving-ca=clusterが自動的に与えられます。 kubectl get nodes -L kubernetes.azure.com/kubelet-serving-ca コマンドを使用して、ラベルが設定されたことを確認します。

kubectl get nodes -L kubernetes.azure.com/kubelet-serving-ca

kubelet が TLS ブートストラップ プロセスを通過するかどうかを確認する

この機能を有効にすると、ノードを実行する各 kubelet では、サービング TLS ブートストラップ プロセスを実行する必要があります。

kubectl get コマンドを使用して、クラスター内の現在の CSR オブジェクトを取得することで、ブートストラップ プロセスが実行されていることを確認します。

kubectl get csr --field-selector=spec.signerName=kubernetes.io/kubelet-serving

すべてのサービス CSR が Approved,Issued 状態である必要があります。これは、CSR が承認され、署名された証明書が発行されたことを示します。 サービング CSP の署名者名は kubernetes.io/kubelet-serving です。

   NAME        AGE    SIGNERNAME                                    REQUESTOR                    REQUESTEDDURATION   CONDITION
csr-8mx4w   113s   kubernetes.io/kube-apiserver-client-kubelet   system:bootstrap:uoxr9r      none              Approved,Issued
csr-bchlj   111s   kubernetes.io/kubelet-serving                 system:node:akswinp7000000   none              Approved,Issued
csr-sb4wz   46m    kubernetes.io/kubelet-serving                 system:node:akswinp6000000   none              Approved,Issued
csr-zc4wt   46m    kubernetes.io/kube-apiserver-client-kubelet   system:bootstrap:ho7zyu      none              Approved,Issued

kubelet がサーバー TLS ブートストラップから取得した証明書を使用されていることを確認する

ノードの kubelet がクラスター CA によって署名されたサービス証明書を使用しているかどうかを確認するには、[kubectl debug][kubectl-debug] を使用して、kubelet の PKI ディレクトリの内容を調べます。

kubectl debug node/<node> -ti --image=mcr.microsoft.com/azurelinux/base/core:3.0 -- ls -l /host/var/lib/kubelet/kubelet-server-current.pem

kubelet-server-current.pemシンボリック リンクが存在する場合、kubelet は TLS ブートストラップ プロセスを介して独自のサービス証明書をブートストラップまたはローテーションし、クラスター CA によって署名されます。

証明書のローテーションを提供する kubelet を無効にする

az aks nodepool update コマンドを使用してノード プールを更新してタグaks-disable-kubelet-serving-certificate-rotation=trueを指定し、ノードを再イメージ化することで、kubelet サービス証明書のローテーションを無効にすることができます。 ノードの再イメージ化は、 ノード イメージのアップグレード を使用するか、プールを 0 インスタンスにスケーリングしてから、目的の値にバックアップすることで行うことができます。

az aks nodepool update --cluster-name myCluster --resource-group myResourceGroup --name mynodepool --tags aks-disable-kubelet-serving-certificate-rotation=true

次のステップ

この記事では、クラスターの証明書、CA、SA を手動および自動でローテーションする方法について説明しました。 詳細情報は、「Azure Kubernetes Service (AKS) でのクラスターのセキュリティとアップグレードに関するベスト プラクティス」を参照してください。