次の方法で共有

Azure Kubernetes Service (AKS) でのカスタム証明機関 (CA) (プレビュー)

  • [アーティクル]

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

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

また、カスタム証明機関を作成することで、Azure Kubernetes Service (AKS) クラスターと、プライベート レジストリ、プロキシ、ファイアウォールなどのワークロードとの間の信頼を確立することができます。 証明機関の情報は Kubernetes シークレットが格納し、その後でそれはクラスター内のすべてのノードに渡されます。 この機能はノード プールごとに適用されるため、新規および既存のノード プールで有効にする必要があります。

この記事では、カスタム CA を作成し、それらを AKS クラスターに適用する方法について説明します。

前提条件

  • Azure サブスクリプション。 Azure サブスクリプションをお持ちでない場合は、無料アカウントを作成してください。
  • Azure CLI のインストール (バージョン 2.43.0 以上)。
  • base64 でエンコードされた証明書文字列、または証明書を含むテキスト ファイル。

制限事項

  • この機能は現在は Windows のノード プールでサポートされていません。

aks-preview Azure CLI 拡張機能をインストールする

重要

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

  1. az extension add コマンドを使用して aks-preview 拡張機能をインストールします。

    az extension add --name aks-preview

  2. az extension update コマンドを使って拡張機能の最新バージョンに更新します。

    az extension update --name aks-preview

CustomCATrustPreview 機能フラグを登録する

  1. az feature register コマンドを使用して、CustomCATrustPreview 機能フラグを登録します。

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

    状態が [登録済み] と表示されるまでに数分かかります。

  2. az feature show コマンドを使用して、登録の状態を確認します。

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

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

    az provider register --namespace Microsoft.ContainerService

AKS ノード プールへのカスタム CA のインストール

AKS ノード プールに CA をインストールする

  • 環境で、正しいプロビジョニングのためにカスタム CA をノード信頼ストアに追加する必要がある場合は、空白行で区切られた最大 10 個の証明書を含むテキスト ファイルを az aks create または az aks update の操作中に渡す必要があります。 テキスト ファイルの例:

    -----BEGIN CERTIFICATE-----
cert1
-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----
cert2
-----END CERTIFICATE-----

ノード プールの作成中に CA をインストールする

  • ノード プールの作成時に [az aks create][az-aks-create] command and specifying your text file for the --custom-ca-trust-certificates' パラメーターを使用して CA をインストールします。

    az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --node-count 2 \
    --enable-custom-ca-trust \
    --custom-ca-trust-certificates pathToFileWithCAs \
    --generate-ssh-keys

ノード プールの起動中に可用性を確保するための CA ローテーション

  • az aks update コマンドを使用し、--custom-ca-trust-certificates パラメーターにテキスト ファイルを指定して、起動時にクラスターに渡された CA を更新します。

    az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --custom-ca-trust-certificates pathToFileWithCAs

    Note

    この操作はモデル更新のトリガーとなり、新しいノードが正しいプロビジョニングに必要な最新の CA を持つことになります。 AKS が追加のノードを作成し、既存のものをドレインし、それらを削除してから、新しい CA のセットがインストールされているノードに置き換えます。

ノード プールの作成後に CA をインストールする

カスタム CA なしで環境を正常にプロビジョニングできる場合は、kube-system 名前空間にシークレットをデプロイすることで CA を提供することができます。 この方法では、ノードを再作成することなく証明書のローテーションが可能です。

  • [Kubernetes シークレット][kubernetes-secrets] YAML マニフェストを作成し、base64 でエンコードされた証明書文字列を data フィールドで指定します。

    apiVersion: v1
kind: Secret
metadata: 
    name: custom-ca-trust-secret
    namespace: kube-system
type: Opaque
data:
    ca1.crt: |
      {base64EncodedCertStringHere}
    ca2.crt: |
      {anotherBase64EncodedCertStringHere}

    このシークレットのデータは、すべてのノードで CA を更新するために使われます。 シークレットの名前が custom-ca-trust-secret で、kube-system 名前空間に作成されていることを確認します。 kube-system 名前空間でシークレットを使用して CA をインストールすることで、ノードを再作成せずに CA のローテーションが可能になります。 CA を更新または削除するには、YAML マニフェストを編集して適用できます。 クラスターは変更をポーリングし、それに応じてノードを更新します。 変更が適用されるまでに数分かかる場合があります。

    Note

    CA を適切に取得するためには、ノードで containerd の再起動が必要になる場合があります。 CA がノードの信頼ストアに正しく追加されていないように見える場合は、ノードのシェルから次のコマンドを使用して再起動をトリガーすることができます。

    systemctl restart containerd

カスタム CA を使用するように新しい AKS クラスターを構成する

  • --enable-custom-ca-trust パラメーターを指定した az aks create コマンドを使用して、新しい AKS クラスターがカスタム CA を使うように構成します。

    az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --node-count 2 \
    --enable-custom-ca-trust \
    --generate-ssh-keys

ノードが起動する前に CA がインストールされた状態でカスタム CA を使用するよう新しい AKS クラスターを構成する

  • ノードが起動する前に CA がインストールされた状態でカスタム CA を使用するように新しい AKS クラスターを構成するには、--enable-custom-ca-trust および --custom-ca-trust-certificates パラメーターを指定した az aks create コマンドを実行します。

    az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --node-count 2 \
    --enable-custom-ca-trust \
    --custom-ca-trust-certificates pathToFileWithCAs \
    --generate-ssh-keys

ノードが起動する前にカスタム CA がインストールされるように既存の AKS クラスターを構成する

  • --custom-ca-trust-certificates パラメーターを指定した az aks update コマンドを使用して、ノードが起動する前にその信頼ストアにカスタム CA が追加されるように既存の AKS クラスターを構成します。

    az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --custom-ca-trust-certificates pathToFileWithCAs

カスタム CA を使用するように新しいノード プールを構成する

  • --enable-custom-ca-trust パラメーターを指定した az aks nodepool add コマンドを使用して、カスタム CA を使うように新しいノード プールを構成します。

    az aks nodepool add \
    --cluster-name myAKSCluster \
    --resource-group myResourceGroup \
    --name myNodepool \
    --enable-custom-ca-trust \
    --os-type Linux

    この機能が有効になっているノード プールが他にない場合、クラスターは変更を有効にするためにその設定を調整する必要があります。 この操作は、AKS の調整ループの一部として自動的に行われます。 操作の前に、デーモン セットとポッドはクラスターに表示されません。 az aks update コマンドを使用して、即時調整操作をトリガーできます。 デーモン セットとポッドは、更新が完了した後に表示されます。

カスタム CA を使用するように既存のノード プールを構成する

  • --enable-custom-trust-ca パラメーターを指定した az aks nodepool update コマンドを使用して、カスタム CA を使うように既存のノード プールを構成します。

    az aks nodepool update \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name myNodepool \
    --enable-custom-ca-trust

    この機能が有効になっているノード プールが他にない場合、クラスターは変更を有効にするためにその設定を調整する必要があります。 この操作は、AKS の調整ループの一部として自動的に行われます。 操作の前に、デーモン セットとポッドはクラスターに表示されません。 az aks update コマンドを使用して、即時調整操作をトリガーできます。 デーモン セットとポッドは、更新が完了した後に表示されます。

トラブルシューティング

機能が有効になり、CA によるシークレットが追加されるが、"X.509 不明な機関によって署名された証明書" エラーで操作が失敗する

シークレットで渡された形式が正しくない証明書

AKS では、ユーザーが作成したシークレットで渡された証明書を適切に書式設定し、base64 でエンコードする必要があります。 渡した CA が適切に base64 でエンコードされていることと、CA を含むファイルに CRLF 改行がないことを確認します。 --custom-ca-trust-certificates に渡される証明書は、base64 でエンコードしないでください。

containerd が新しい証明書を取得していない

ノードのシェルから、systemctl restart containerd を実行します。 containerd が再起動すると、新しい証明書はコンテナー ランタイムによって適切に取得されます。

次のステップ

AKS のセキュリティのベスト プラクティスについて詳しくは、「Azure Kubernetes Service (AKS) でのクラスターのセキュリティとアップグレードに関するベスト プラクティス」をご覧ください。