Windows Server 上の Azure Kubernetes Service を使用して Windows コンテナーのグループ管理サービス アカウント (gMSA) を構成する

適用対象: Windows Server 上の AKS

AD 認証を使用するために、Windows コンテナー用のグループ管理サービス アカウント (gMSA) を構成して、ドメインに参加していないホストを使用して実行できます。 グループ管理サービス アカウントは、複数のコンピューターでパスワードを知ることなく ID を共有できるように設計された、Windows Server 2012 で導入された特殊な種類のサービス アカウントです。 Windows コンテナーはドメインに参加できませんが、Windows コンテナーで実行される多くの Windows アプリケーションには引き続き AD 認証が必要です。

ドメインに参加していないホストを使用するコンテナーの gMSA のアーキテクチャ

ドメインに参加していないホストを使用するコンテナーの gMSA では、ホスト ID ではなく移植可能なユーザー ID を使用して gMSA 資格情報を取得します。 そのため、Windows ワーカー ノードをドメインに手動で参加させる必要はありません。 ユーザー ID は、Kubernetes にシークレットとして保存されます。 次の図は、ドメインに参加していないホストを持つコンテナーに対して gMSA を構成するプロセスを示しています。

ドメインに参加していないホストを使用するコンテナーの gMSA は、ホスト ノードをドメインに参加させることなく gMSA でコンテナーを作成するという柔軟性を提供します。 Windows Server 2019 以降では、ccg.exeがサポートされています。これにより、プラグイン メカニズムで Active Directory から gMSA 資格情報を取得できます。 この ID を使用して、コンテナーを起動できます。 ccg.exe の詳細については、「ICcgDomainAuthCredentials インターフェイス」を参照してください。

ドメインに参加していないホストを使用するコンテナーとドメインに参加しているホストを使用するコンテナーの gMSA の比較

gMSA が導入された当初は、コンテナー ホストをドメインに参加させる必要がありました。これにより、ユーザーが Windows ワーカー ノードをドメインに手動で参加させるための大量のオーバーヘッドが発生していました。 この制限は、ドメインに参加していないホストを持つコンテナーの gMSA で対処されたため、ドメインに参加していないホストで gMSA を使用できるようになりました。 gMSA のその他の機能強化には、次の機能があります。

• Windows ワーカー ノードをドメインに手動で参加させる必要がなくなります。 スケーリング シナリオでは、この簡略化が役立ちます。
• ローリング アップデートのシナリオでは、ノードをドメインに再参加させる必要がなくなりました。
• ワーカー ノードのマシン アカウントを管理して gMSA サービス アカウントのパスワードを取得するためのプロセスがより簡単になりました。
• Kubernetes で gMSA を構成するためのエンドツーエンドのプロセスがそれほど複雑でなくなりました。

開始する前に

グループ管理サービス アカウントで Windows コンテナーを実行するには、次の前提条件が必要です。

• Windows Server 2012 以降を実行しているドメイン コントローラーが少なくとも 1 つある Active Directory ドメイン。 gMSA を使用するためのフォレストまたはドメインの機能レベルの要件はありませんが、gMSA パスワードを配布できるのは Windows Server 2012 以降を実行しているドメイン コントローラーのみです。 詳細については、Active Directory の gMSA に関する要件に関するページを参照してください。
• gMSA アカウントを作成するためのアクセス許可。 gMSA アカウントを作成するには、ドメイン管理者であるか、 msDS-GroupManagedServiceAccount オブジェクトを作成するアクセス許可を持つアカウントを使用する必要があります。
• インターネットにアクセスして、CredentialSpec PowerShell モジュールをダウンロードします。 切断された環境で作業している場合は、インターネットにアクセスできるコンピューターにモジュールを保存して、開発マシンまたはコンテナー ホストにコピーできます。
• gMSA と AD 認証が確実に機能するには、Windows Server クラスター ノードがドメイン コントローラーまたはその他のタイム ソースと時刻を同期するように構成されていることを確認します。 また、Hyper-V がどの仮想マシンに対しても時刻を同期するように構成されていることも確認する必要があります。

ドメイン コントローラー内に gMSA を準備する

ドメイン コントローラーで gMSA を準備するには、次の手順に従います。

1. ドメイン コントローラーで Active Directory を準備し、gMSA アカウントを作成します。

2. ドメイン ユーザー アカウントを作成します。 このユーザー アカウントとパスワードの資格情報を Kubernetes シークレットとして保存します。 これらの資格情報を使用して、gMSA パスワードを取得します。

3. gMSA アカウントを作成し、手順 2 で作成した gMSA アカウントのパスワードを読み取るアクセス許可を付与するには、次の New-ADServiceAccount PowerShell コマンドを実行します。

    New-ADServiceAccount -Name "<gmsa account name>" -DnsHostName "<gmsa account name>.<domain name>.com" -ServicePrincipalNames "host/<gmsa account name>", "host/<gmsa account name>.<domain name>.com" -PrincipalsAllowedToRetrieveManagedPassword <username you created earlier> 
   

   -PrincipalsAllowedToRetrieveManagedPasswordでは、次の例に示すように、前に作成したドメイン ユーザー名を指定します。

   New-ADServiceAccount -Name "WebApp01" -DnsHostName "WebApp01.akshcitest.com" -ServicePrincipalNames "host/WebApp01", "host/WebApp01.akshcitest.com" -PrincipalsAllowedToRetrieveManagedPassword "testgmsa"
   

gMSA 資格情報の仕様 JSON ファイルを準備する

gMSA 資格情報の仕様 JSON ファイルを準備するには、資格情報の仕様を作成する手順に従います。

クラスターで Windows ポッドおよびコンテナーの gMSA を構成する

Kubernetes コミュニティでは、gMSA のドメイン参加済み Windows ワーカー ノードが既にサポートされています。 Windows Server 上の AKS で Windows ワーカー ノードをドメインに参加させる必要はありませんが、他の構成手順を完了する必要があります。 これらの手順には、webhook、カスタム リソース定義 (CRD)、資格情報の仕様のインストール、ロールベースのアクセス制御 (RBAC ロール) の有効化が含まれます。 次の手順では、構成プロセスを簡略化する PowerShell コマンドを使用します。

次の手順を完了する前に、 AksHci PowerShell モジュールをインストールし、 kubectl クラスターに接続できることを確認してください。

1. Webhook をインストールするには、次の Install-AksHciGmsaWebhook PowerShell コマンドを実行します。

   Install-AksHciGMSAWebhook -Name <cluster name>
   

   Webhook ポッドが実行されていることを検証するには、次のコマンドを実行します。

   kubectl get pods -n kube-system | findstr gmsa
   

   gmsa-webhook プレフィックスが付いた、実行中のポッドが 1 つ表示されます。

2. Active Directory ユーザー資格情報を格納するシークレット オブジェクトを作成します。 次の構成データを完了し、設定を secret.yaml という名前のファイルに保存します。

   apiVersion: v1
   kind: Secret
   metadata:
      name: <secret-name>
      namespace: <secret under namespace other than the default>
   type: Opaque
   stringData:
      domain: <FQDN of the domain, for example: akshcitest.com>
      username: <domain user who can retrieve the gMSA password>
      password: <password>
   

   次に、以下のコマンドを実行してシークレット オブジェクトを作成します。

   kubectl apply -f secret.yaml
   

   注

   既定以外の名前空間の下にシークレットを作成する場合は、デプロイの名前空間を必ず同じ名前空間に設定してください。

3. Add-AksHciGMSACredentialSpec PowerShell コマンドレットを使用して gMSA CRD を作成し、ロールベースのアクセス制御 (RBAC) を有効にしてから、特定の gMSA 資格情報スペック ファイルを使用するようにサービス アカウントにロールを割り当てます。 これらの手順の詳細については、Kubernetes の記事「Configure gMSA for Windows pods and containers」 (Windows ポッドとコンテナーの gMSA の構成) をご覧ください。

   次の PowerShell コマンドの入力として、JSON 資格情報の仕様を使用します (アスタリスク * の付いたパラメーターは必須です)。

   Add-AksHciGMSACredentialSpec -Name <cluster name>*  
     -credSpecFilePath <path to JSON credspec>* 
     -credSpecName <name for credspec as the k8s GMSACredentialSpec object>* 
     -secretName <name of secret>* 
     -secretNamespace <namespace of secret>  
     -serviceAccount <name of service account to bind to clusterrole>  
     -clusterRoleName <name of clusterrole to use the credspec>*  
     -overwrite 
   

   例を表示するには、次のコードを参照してください。

   Add-AksHciGMSACredentialSpec -Name mynewcluster 
     -credSpecFilePath .\credspectest.json 
     -credSpecName credspec-mynewcluster 
     -secretName mysecret 
     -clusterRoleName clusterrole-mynewcluster
   

アプリケーションを展開する

次の設定例を使用して、デプロイの YAML ファイルを作成します。 必須のエントリとしては、serviceAccountName、gmsaCredentialSpecName、volumeMounts、および dnsconfig があります。

1. サービス アカウントを追加します。

   serviceAccountName: default
      securityContext: 
        windowsOptions: 
          gmsaCredentialSpecName:
   

2. 資格情報の仕様オブジェクトを追加します。

   securityContext: 
        windowsOptions: 
          gmsaCredentialSpecName: <cred spec name>
   

3. デプロイのシークレットをマウントします。

   volumeMounts:
        - name: <volume name>
          mountPath: <vmount path>
          readOnly: true
      volumes:
        - name: <volume name>
          secret:
            secretName: <secret name>
            items:
              - key: username
                path: my-group/my-username
   

4. ドメイン コントローラーの IP アドレスとドメイン名を dnsConfig に追加します。

   dnsConfig: 
        nameservers:
          - <IP address for domain controller>
        searches: 
          - <domain>
   

コンテナーが gMSA で動作していることを確認する

コンテナーをデプロイしたら、次の手順を使用して、それが動作していることを確認します。

1. 次のコマンドを実行して、デプロイのコンテナー ID を取得します。

   kubectl get pods
   

2. PowerShell を開き、次のコマンドを実行します。

   kubectl exec -it <container id> powershell
   

3. コンテナーに入ったら、次のコマンドを実行します。

   Nltest /parentdomain 
   Nltest /sc_verify:<domain> 
   

   Connection Status = 0 0x0 NERR_Success The command completed successfully. 
   

   この出力は、コンピューターがドメイン コントローラーによって認証され、クライアント コンピューターとドメイン コントローラーの間にセキュリティで保護されたチャネルが存在することを示しています。

4. コンテナーが有効な Kerberos Ticket Granting Ticket (TGT) を取得できるかどうかを確認します。

   klist get krbtgt
   

   A ticket to krbtgt has been retrieved successfully
   

クラスターの gMSA 設定をクリーンアップする

gMSA 設定をクリーンアップする必要がある場合は、次のアンインストール手順を使用します。

資格情報の仕様をアンインストールする

アンインストールするには、次の Remove-AksHcigmsaCredentialSpec PowerShell コマンドを実行します。

Remove-AksHciGMSACredentialSpec -Name <cluster name> -credSpecName <cred spec object name> -clusterRoleName <clusterrole object name> -serviceAccount <serviceaccount object name> -secretNamespace <namespace of the secret object>

Webhook をアンインストールする

Webhook をアンインストールするには、次の Uninstall-AksHciGMSAWebhook PowerShell コマンドを実行します。

Uninstall-AksHciGMSAWebhook -Name <cluster name>

次のステップ

• Kubernetes クラスターで永続ボリュームを使用する
• Windows Server クラスターでの AKS の監視