次の方法で共有


Azure Kubernetes Service (AKS) クラスター上の Windows Server ノードでグループ管理サービス アカウント (GMSA) を有効にする

グループ管理サービス アカウント (GMSA) は、パスワードの自動管理、簡略化されたサービス プリンシパル名 (SPN) の管理、および管理を他の管理者に委任する機能を提供する複数のサーバーのマネージド ドメイン アカウントです。 Azure Kubernetes Service (AKS) を使用すると、Windows Server ノードで GMSA を有効にする機能が提供されます。これにより、Windows Server ノード上で実行されているコンテナーを GMSA と統合して GMSA で管理できます。

前提条件

  • Kubernetes 1.19 以上。 バージョンを確認するには、「利用可能なアップグレードを確認する」を参照してください。 バージョンをアップグレードするには、「AKS クラスターをアップグレードする」を参照してください。
  • Azure CLI バージョン 2.35.0 以降。 バージョンを確認するには、az --version を実行します。 インストールまたはアップグレードする必要がある場合は、Azure CLI のインストールに関するページを参照してください。
  • AKS クラスターで有効にされたマネージド ID
  • Azure Key Vault を作成または更新するためのアクセス許可。
  • Active Directory ドメイン サービスまたはオンプレミスの Active Directory で GMSA を構成するためのアクセス許可。
  • ドメイン コントローラーで Active Directory Web サービスが有効になっている必要があります。また、AKS クラスターからポート 9389 に到達できる必要があります。

注意

また、Microsoft には、AKS で gMSA を構成するための専用の PowerShell モジュールも用意されています。 詳細については、「Azure Kubernetes Service の gMSA」を参照してください。

Active Directory ドメイン コントローラーに GMSA を構成する

AKS で GMSA を使用するには、ドメイン コントローラーに構成されている GMSA 資格情報にアクセスするために、標準のドメイン ユーザーの資格情報が必要です。 ドメイン コントローラーに GMSA を構成するには、グループ管理サービス アカウントの概要に関する記事を参照してください。 標準のドメイン ユーザーの資格情報の場合は、GMSA の資格情報にアクセスできる限り、既存のユーザーを使用するか、新しいユーザーを作成できます。

重要

Active Directory Domain Services またはオンプレミスの Active Directory を使用する必要があります。 現時点では、Microsoft Entra ID を使って AKS クラスターで GMSA を構成することはできません。

標準のドメイン ユーザーの資格情報を Azure Key Vault に格納する

AKS クラスターでは、標準のドメイン ユーザーの資格情報を使用して、ドメイン コントローラーから GMSA の資格情報にアクセスします。 AKS クラスターにそれらの資格情報への安全なアクセスを提供するには、それらの資格情報を Azure Key Vault に格納する必要があります。

  1. Azure key vault がまだない場合は、az keyvault create コマンドを使用して作成します。

    az keyvault create --resource-group myResourceGroup --name myGMSAVault
    
  2. 標準のドメイン ユーザーの資格情報をシークレットとして az keyvault secret set コマンドを使用するキー コンテナーに格納します。 次の例では、ドメイン ユーザーの資格情報を myGMSAVault キー コンテナーにキー GMSADomainUserCred で格納します。

    az keyvault secret set --vault-name myGMSAVault --name "GMSADomainUserCred" --value "$Domain\\$DomainUsername:$DomainUserPassword"
    

    Note

    ドメインに完全修飾ドメイン名を使用していることを確認してください。

オプション: カスタム DNS を持つカスタム VNet を使用する

AKS クラスターから到達できるように、DNS を使用してドメイン コントローラーを構成する必要があります。 AKS クラスターの外部にネットワークと DNS を構成して、クラスターからドメイン コントローラーにアクセスできるようすることができます。 または、AKS クラスターでカスタム DNS を持つカスタム VNet を構成し、ドメイン コントローラーへのアクセスを提供するために Azure CNI を使用することもできます。 詳細については、「Azure Kubernetes サービス (AKS) で Azure CNI ネットワークを構成する」を参照してください。

省略可能: 複数の DNS サーバーを構成する

AKS クラスターで Windows GMSA 用に複数の DNS サーバーを構成する場合は、--gmsa-dns-server または v--gmsa-root-domain-name を指定しないでください。 代わりに、[カスタム DNS] を選択し、DNS サーバーを追加することで、VNet に複数の DNS サーバーを追加できます。

オプション: クラスターに独自の kubelet ID を使用する

AKS クラスターからキー コンテナーにアクセスできるようにするには、クラスターの kubelet ID でキー コンテナーにアクセスする必要があります。 マネージド ID が有効になっているクラスターを作成すると、kubelet ID が既定で自動的に作成されます。

クラスターの作成後に ID のキー コンテナーへのアクセス許可を付与するか、次の手順を使用して、クラスターの作成前に使用する独自の ID を作成できます。

  1. az identity create コマンドを使用して、kubelet ID を作成します。

    az identity create --name myIdentity --resource-group myResourceGroup
    
  2. az identity list コマンドを使用して ID を取得し、それを MANAGED_ID という名前の変数に設定します。

    MANAGED_ID=$(az identity list --query "[].id" -o tsv)
    
  3. az keyvault set-policy コマンドを使用するキー コンテナーに ID のアクセス権を付与します。

    az keyvault set-policy --name "myGMSAVault" --object-id $MANAGED_ID --secret-permissions get
    

新しい AKS クラスターで GMSA を有効にする

  1. クラスターの作成時に使用する管理者資格情報を作成します。 次のコマンドを実行すると、ユーザー名の入力が求められ、後のコマンドで使用できるように WINDOWS_USERNAME と設定されます。

    echo "Please enter the username to use as administrator credentials for Windows Server nodes on your cluster: " && read WINDOWS_USERNAME 
    
  2. 次のパラメーターを指定した az aks create コマンドを使用して AKS クラスターを作成します。

    • --enable-windows-gmsa: クラスターの GMSA を有効にします。
    • --gmsa-dns-server: DNS サーバーの IP アドレス。
    • --gmsa-root-domain-name: DNS サーバーのルート ドメイン名。
    DNS_SERVER=<IP address of DNS server>
    ROOT_DOMAIN_NAME="contoso.com"
    
    az aks create \
        --resource-group myResourceGroup \
        --name myAKSCluster \
        --vm-set-type VirtualMachineScaleSets \
        --network-plugin azure \
        --load-balancer-sku standard \
        --windows-admin-username $WINDOWS_USERNAME \
        --enable-windows-gmsa \
        --gmsa-dns-server $DNS_SERVER \
        --gmsa-root-domain-name $ROOT_DOMAIN_NAME \
        --generate-ssh-keys
    

    Note

    • カスタム VNet を使用している場合は、vnet-subnet-id パラメーターを使用して VNet ID を指定する必要があります。また、構成によっては、docker-bridge-addressdns-service-ip、および service-cidr パラメーターも追加することが必要になる場合があります。

    • kubelet ID 用に独自の ID を作成した場合は、assign-kubelet-identity パラメーターを使って ID を指定します。

    • --gmsa-dns-server--gmsa-root-domain-name パラメーターを指定すると、kube-system/coredns ConfigMap に DNS 転送規則が追加されます。 この規則は、$ROOT_DOMAIN_NAME に対する DNS 要求をポッドから $DNS_SERVER に転送します。

      $ROOT_DOMAIN_NAME:53 {
          errors
          cache 30
          log
          forward . $DNS_SERVER
      }
      
  3. az aks nodepool add コマンドを使用して、Windows Server ノード プールを追加します。

    az aks nodepool add \
        --resource-group myResourceGroup \
        --cluster-name myAKSCluster \
        --os-type Windows \
        --name npwin \
        --node-count 1
    

既存のクラスターで GMSA を有効にする

  • az aks update コマンドを使用して、Windows Server ノードとマネージド ID が有効になっている既存のクラスターで GMSA を有効にします。

    az aks update \
        --resource-group myResourceGroup \
        --name myAKSCluster \
        --enable-windows-gmsa \
        --gmsa-dns-server $DNS_SERVER \
        --gmsa-root-domain-name $ROOT_DOMAIN_NAME
    

kubelet ID のキー コンテナーへのアクセス許可を付与する

Note

kubelet ID に独自の ID を指定した場合は、この手順をスキップします。

  • az keyvault set-policy コマンドを使用して kubelet ID のキー コンテナーへのアクセス許可を付与します。

    MANAGED_ID=$(az aks show -g myResourceGroup -n myAKSCluster --query "identityProfile.kubeletidentity.objectId" -o tsv)
    az keyvault set-policy --name "myGMSAVault" --object-id $MANAGED_ID --secret-permissions get
    

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

  1. az aks get-credentials コマンドを使用して、Kubernetes クラスターに接続するように kubectl を構成します。

    az aks get-credentials --resource-group myResourceGroup --name myAKSCluster
    
  2. gmsa-spec.yaml という名前の新しい YAML を作成し、次の YAML に貼り付けます。 プレースホルダーは必ず、独自の値で置き換えてください。

    apiVersion: windows.k8s.io/v1
    kind: GMSACredentialSpec
    metadata:
      name: aks-gmsa-spec  # This name can be changed, but it will be used as a reference in the pod spec
    credspec:
      ActiveDirectoryConfig:
        GroupManagedServiceAccounts:
        - Name: $GMSA_ACCOUNT_USERNAME
          Scope: $NETBIOS_DOMAIN_NAME
        - Name: $GMSA_ACCOUNT_USERNAME
          Scope: $DNS_DOMAIN_NAME
        HostAccountConfig:
          PluginGUID: '{CCC2A336-D7F3-4818-A213-272B7924213E}'
          PortableCcgVersion: "1"
          PluginInput: "ObjectId=$MANAGED_ID;SecretUri=$SECRET_URI"  # SECRET_URI takes the form https://$akvName.vault.azure.net/secrets/$akvSecretName
      CmsPlugins:
     - ActiveDirectory
      DomainJoinConfig:
        DnsName: $DNS_DOMAIN_NAME
        DnsTreeName: $DNS_ROOT_DOMAIN_NAME
        Guid:  $AD_DOMAIN_OBJECT_GUID
        MachineAccountName: $GMSA_ACCOUNT_USERNAME
        NetBiosName: $NETBIOS_DOMAIN_NAME
        Sid: $GMSA_SID
    

Note

AKS は、リリース v20230903 で、GMSACredentialSpecapiVersionwindows.k8s.io/v1alpha1 から windows.k8s.io/v1 にアップグレードしました。

  1. gmsa-role.yaml という名前の新しい YAML を作成し、次の YAML に貼り付けます。

    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRole
    metadata:
      name: aks-gmsa-role
    rules:
    - apiGroups: ["windows.k8s.io"]
      resources: ["gmsacredentialspecs"]
      verbs: ["use"]
      resourceNames: ["aks-gmsa-spec"]
    
  2. gmsa-role-binding.yaml という名前の新しい YAML を作成し、次の YAML に貼り付けます。

    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: allow-default-svc-account-read-on-aks-gmsa-spec
      namespace: default
    subjects:
    - kind: ServiceAccount
      name: default
      namespace: default
    roleRef:
      kind: ClusterRole
      name: aks-gmsa-role
      apiGroup: rbac.authorization.k8s.io
    
  3. kubectl apply コマンドを使用して、gmsa-spec.yamlgmsa-role.yamlgmsa-role-binding.yaml から変更を適用します。

    kubectl apply -f gmsa-spec.yaml
    kubectl apply -f gmsa-role.yaml
    kubectl apply -f gmsa-role-binding.yaml
    

GMSA のインストールを確認する

  1. gmsa-demo.yaml という名前の新しい YAML を作成し、次の YAML に貼り付けます。

    ---
    kind: ConfigMap
    apiVersion: v1
    metadata:
      labels:
       app: gmsa-demo
      name: gmsa-demo
      namespace: default
    data:
      run.ps1: |
       $ErrorActionPreference = "Stop"
    
       Write-Output "Configuring IIS with authentication."
    
       # Add required Windows features, since they are not installed by default.
       Install-WindowsFeature "Web-Windows-Auth", "Web-Asp-Net45"
    
       # Create simple ASP.NET page.
       New-Item -Force -ItemType Directory -Path 'C:\inetpub\wwwroot\app'
       Set-Content -Path 'C:\inetpub\wwwroot\app\default.aspx' -Value 'Authenticated as <B><%=User.Identity.Name%></B>, Type of Authentication: <B><%=User.Identity.AuthenticationType%></B>'
    
       # Configure IIS with authentication.
       Import-Module IISAdministration
       Start-IISCommitDelay
       (Get-IISConfigSection -SectionPath 'system.webServer/security/authentication/windowsAuthentication').Attributes['enabled'].value = $true
       (Get-IISConfigSection -SectionPath 'system.webServer/security/authentication/anonymousAuthentication').Attributes['enabled'].value = $false
       (Get-IISServerManager).Sites[0].Applications[0].VirtualDirectories[0].PhysicalPath = 'C:\inetpub\wwwroot\app'
       Stop-IISCommitDelay
    
       Write-Output "IIS with authentication is ready."
    
       C:\ServiceMonitor.exe w3svc
    ---
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      labels:
        app: gmsa-demo
      name: gmsa-demo
      namespace: default
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: gmsa-demo
      template:
        metadata:
          labels:
            app: gmsa-demo
        spec:
          securityContext:
            windowsOptions:
              gmsaCredentialSpecName: aks-gmsa-spec
          containers:
          - name: iis
            image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
            imagePullPolicy: IfNotPresent
            command:
             - powershell
            args:
              - -File
              - /gmsa-demo/run.ps1
            volumeMounts:
              - name: gmsa-demo
                mountPath: /gmsa-demo
          volumes:
          - configMap:
              defaultMode: 420
              name: gmsa-demo
            name: gmsa-demo
          nodeSelector:
            kubernetes.io/os: windows
    ---
    apiVersion: v1
    kind: Service
    metadata:
      labels:
        app: gmsa-demo
      name: gmsa-demo
      namespace: default
    spec:
      ports:
      - port: 80
        targetPort: 80
      selector:
        app: gmsa-demo
      type: LoadBalancer
    
  2. kubectl apply コマンドを使用して gmsa-demo.yaml から変更を適用します。

    kubectl apply -f gmsa-demo.yaml
    
  3. kubectl get service コマンドを使用して、サンプル アプリケーションの IP アドレスを取得します。

    kubectl get service gmsa-demo --watch
    

    最初に、gmsa-demo サービスの EXTERNAL-IP保留中として表示されます。

    NAME               TYPE           CLUSTER-IP   EXTERNAL-IP   PORT(S)        AGE
    gmsa-demo          LoadBalancer   10.0.37.27   <pending>     80:30572/TCP   6s
    
  4. EXTERNAL-IP アドレスが "保留中" から実際のパブリック IP アドレスに変わったら、CTRL-C を使って kubectl ウォッチ プロセスを停止します。

    次の出力例は、サービスに割り当てられている有効なパブリック IP アドレスを示しています。

    gmsa-demo  LoadBalancer   10.0.37.27   EXTERNAL-IP   80:30572/TCP   2m
    
  5. Web ブラウザーで gmsa-demo サービスの外部 IP アドレスを開きます。

  6. $NETBIOS_DOMAIN_NAME\$AD_USERNAME とパスワードを使用して認証し、Authenticated as $NETBIOS_DOMAIN_NAME\$AD_USERNAME, Type of Authentication: Negotiate が表示されることを確認します。

既存のクラスターで GMSA を無効にする

  • az aks update コマンドを使って、Windows Server ノードを含む既存のクラスターで GMSA を有効にします。

    az aks update \
        --resource-group myResourceGroup \
        --name myAKSCluster \
        --disable-windows-gmsa 
    

Note

az aks update コマンドを使うと、既存のクラスターで GMSA をもう一度有効にすることができます。

トラブルシューティング

ページを読み込むときに認証を求められない

ページが読み込まれても認証を求めるメッセージが表示されない場合は、kubectl logs POD_NAME コマンドを使用してポッドのログを表示し、認証が完了した IIS の準備ができていることを確認します。

Note

既定では、Windows コンテナーには kubectl に関するログは表示されません。 Windows コンテナーでログを表示できるようにするには、Windows イメージにログ モニター ツールを埋め込む必要があります。 詳細については、「Windows コンテナー ツール」を参照してください。

ページの読み込み時に接続がタイムアウトする

ページを読み込もうとしたときに接続タイムアウトが発生した場合は、kubectl get pods --watch コマンドを使用してサンプル アプリが実行されていることを確認します。 サンプル アプリ ポッドが実行される前に、サンプル アプリ サービスの外部 IP アドレスが使用できる場合があります。

ポッドの起動に失敗し、ポッド イベントに "winapi エラー" が表示される

kubectl get pods --watch コマンドを実行してから数分待ってもポッドが起動しない場合は、kubectl describe pod POD_NAME コマンドを使用します。 ポッド イベントに "winapi エラー" が表示される場合は、GMSA 資格情報の仕様の構成でエラーが発生している可能性があります。 gmsa-spec.yaml で置き換えたすべての値が正しいことを確認し、kubectl apply -f gmsa-spec.yaml を再実行して、サンプル アプリケーションを再デプロイします。

次のステップ

詳しくは、Azure Kubernetes Service (AKS) での Windows コンテナーの考慮事項に関する記事を参照してください。