Windows コンテナー用に gMSA を作成する

  • [アーティクル]

適用対象: Windows Server 2022、Windows Server 2019

Windows ベースのネットワークは、一般的に、Active Directory (AD) を使用して、ユーザー、コンピューター、およびその他のネットワーク リソース間の認証と承認を容易にしています。 エンタープライズ アプリケーション開発者は、多くの場合、アプリケーションを AD に統合し、ドメインに参加しているサーバーで実行するように設計して、統合 Windows 認証を利用しています。これにより、ユーザーや他のサービスは、ID を使用してアプリケーションに自動的かつ透過的にサインインできます。 この記事では、Windows コンテナーで Active Directory グループ管理サービス アカウントを使い始める方法について説明します。

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

Windows コンテナー用の gMSA が最初に導入されたときは、コンテナー ホストをドメインに参加させる必要がありました。このため、Windows ワーカー ノードをドメインに手動で参加させるのに、ユーザーに多くのオーバーヘッドが発生していました。 この制限は、ドメインに参加していないコンテナー ホストに対する Windows コンテナー用 gMSA のサポートによって対処されています。 ドメインに参加しているコンテナー ホストを使用する元の gMSA 機能も引き続きサポートされます。

ドメインに参加していないコンテナー ホストを使用する場合の gMSA の機能強化には、次のようなものがあります。

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

Note

Kubernetes コミュニティが Windows コンテナーでの gMSA の使用をサポートしている方法については、gMSA の構成に関するページを参照してください。

gMSA のアーキテクチャと改善点

Windows コンテナー用の gMSA の初期実装の制限に対処するために、ドメインに参加させていないコンテナー ホストに対する新しい gMSA サポートでは、ホスト コンピューター アカウントではなくポータブル ユーザー ID を使用して gMSA の資格情報を取得します。 そのため、Windows ワーカー ノードをドメインに手動で参加させる必要はなくなりましたが、これは引き続きサポートされています。 ユーザーの ID や資格情報は、コンテナー ホストが (たとえば、Kubernetes シークレットとして) アクセスできるシークレット ストアに格納され、認証されたユーザーが取得できます。

Diagram of group Managed Service Accounts version two

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

注意

Azure Kubernetes Service on Azure Stack HCI では、このプラグインを使用して ccg.exe から AD に通信し、gMSA の資格情報を取得できます。 詳細については、「AKS on Azure Stack HCI を使用してグループ管理サービス アカウントを構成する」を参照してください。

以下の図を参考に、Container Credential Guard の手順を実行してください。

  1. CredSpec ファイルを入力として使用すると、ノード ホストで ccg.exe のプロセスが開始されます。

  2. ccg.exe によって、CredSpec ファイルの情報が使用されてプラグインが起動され、その後そのプラグインに関連付けられているシークレット ストアのアカウントの資格情報が取得されます。

  3. ccg.exe によって取得したアカウントの資格情報が使用され、AD から gMSA のパスワードが取得されます。

  4. ccg.exe によって、資格情報が要求されたコンテナーで gMSA のパスワードを使用できるようになります。

  5. コンテナーで、gMSA のパスワードを使用してドメイン コントローラーに対して認証が行われることで、Kerberos チケット保証チケット (TGT) が取得されます。

  6. コンテナーでネットワーク サービスまたはローカル システムとして実行されているアプリケーションで、gMSA などのドメイン リソースに対して認証を行い、アクセスできるようになりました。

    Diagram of the ccg.exe process

前提条件

グループ管理サービス アカウントを使用して Windows コンテナーを実行するには、次のものが必要です。

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

Active Directory の 1 回限りの準備

ドメインで gMSA をまだ作成していない場合は、Key Distribution Service (KDS) ルート キーを生成する必要があります。 KDS は、gMSA パスワードの作成、ローテーション、および承認済みホストへのリリースの役割を担います。 コンテナー ホストで gMSA を使用してコンテナーを実行する必要がある場合は、KDS に接続して現在のパスワードを取得します。

KDS ルート キーが既に作成されているかどうかを確認するには、AD PowerShell ツールがインストールされているドメイン コントローラーまたはドメイン メンバー上でドメイン管理者として次の PowerShell コマンドレットを実行します。

Get-KdsRootKey

コマンドからキー ID が返される場合は準備が完了しているので、「グループ管理サービス アカウントを作成する」セクションに進みます。 それ以外の場合は、KDS ルート キーの作成に進みます。

重要

フォレストごとに作成する KDS ルート キーは 1 つだけです。 複数の KDS ルート キーが作成されると、gMSA パスワードのローテーション後に gMSA が失敗し始めます。

複数のドメイン コントローラーを使用する運用環境またはテスト環境では、PowerShell で次のコマンドレットをドメイン管理者として実行し、KDS ルート キーを作成します。

# For production environments
Add-KdsRootKey -EffectiveImmediately

キーがすぐに有効になることを意味するコマンドですが、KDS ルート キーがレプリケートされ、すべてのドメイン コントローラーで使用できるようになるまでに 10 時間かかります。

ドメイン内にドメイン コントローラーが 1 つしかない場合は、10 時間前にキーを有効になるように設定すると、プロセスを迅速にすることができます。

重要

運用環境ではこの手法を使用しないでください。

# For single-DC test environments only
Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)

グループ管理サービス アカウントを作成する

統合 Windows 認証を使用するすべてのコンテナーには、少なくとも 1 つの gMSA が必要です。 System または Network Service として実行されているアプリからネットワーク上のリソースにアクセスする場合は常に、プライマリ gMSA が使用されます。 コンテナーに割り当てられたホスト名に関係なく、gMSA の名前はネットワーク上のコンテナーの名前になります。 コンテナー コンピューター アカウントとは異なる ID としてコンテナーでサービスまたはアプリケーションを実行する場合に備えて、追加の gMSA を使用してコンテナーを構成することもできます。

gMSA を作成するときは、複数の異なるマシンで同時に使用できる共有 ID も作成します。 gMSA パスワードへのアクセスは、Active Directory アクセス制御リストによって保護されています。 gMSA アカウントごとにセキュリティ グループを作成し、関連するコンテナー ホストをセキュリティ グループに追加して、パスワードへのアクセスを制限することをお勧めします。

最後に、コンテナーにはサービス プリンシパル名 (SPN) が自動的に登録されないため、gMSA アカウント用に少なくともホスト SPN を手動で作成する必要があります。

通常、ホストまたは http SPN は gMSA アカウントと同じ名前を使用して登録されますが、クライアントがロード バランサーの背後からコンテナー化されたアプリケーションにアクセスする場合、または gMSA 名とは異なる DNS 名を使用する場合は、別のサービス名の使用が必要になる可能性があります。

たとえば、gMSA アカウントの名前が "WebApp01" で、ユーザーが mysite.contoso.com のサイトにアクセスする場合は、gMSA アカウントに http/mysite.contoso.com SPN を登録する必要があります。

アプリケーションによっては、独自のプロトコルのために追加の SPN が必要になる場合があります。 たとえば、SQL Server には MSSQLSvc/hostname SPN が必要です。

gMSA を作成するために必要な属性を次の表に示します。

gMSA のプロパティ 必須の値 例
名前 任意の有効なアカウント名。 WebApp01
DnsHostName アカウント名に付加されるドメイン名。 WebApp01.contoso.com
ServicePrincipalNames 少なくともホスト SPN を設定し、必要に応じて他のプロトコルを追加します。 'host/WebApp01', 'host/WebApp01.contoso.com'
PrincipalsAllowedToRetrieveManagedPassword コンテナー ホストを含むセキュリティ グループ。 WebApp01Hosts

gMSA の名前を決定したら、PowerShell で次のコマンドレットを実行して、セキュリティ グループと gMSA を作成します。

ヒント

次のコマンドを実行するには、Domain Admins セキュリティ グループに属するアカウントか、msDS-GroupManagedServiceAccount オブジェクトの作成アクセス許可が委任されているアカウントを使用する必要があります。 New-ADServiceAccount コマンドレットは、リモート サーバー管理ツールの AD PowerShell Tools の一部です。

開発、テスト、運用の各環境用に個別の gMSA アカウントを作成することをお勧めします。

ドメインに参加しているコンテナー ホストの gMSA アカウントの作成のユース ケース

# Replace 'WebApp01' and 'contoso.com' with your own gMSA and domain names, respectively.

# To install the AD module on Windows Server, run Install-WindowsFeature RSAT-AD-PowerShell
# To install the AD module on Windows 10 version 1809 or later, run Add-WindowsCapability -Online -Name 'Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0'
# To install the AD module on older versions of Windows 10, see https://aka.ms/rsat

# Create the security group
New-ADGroup -Name "WebApp01 Authorized Hosts" -SamAccountName "WebApp01Hosts" -GroupScope DomainLocal

# Create the gMSA
New-ADServiceAccount -Name "WebApp01" -DnsHostName "WebApp01.contoso.com" -ServicePrincipalNames "host/WebApp01", "host/WebApp01.contoso.com" -PrincipalsAllowedToRetrieveManagedPassword "WebApp01Hosts"

# Add your container hosts to the security group
Add-ADGroupMember -Identity "WebApp01Hosts" -Members "ContainerHost01$", "ContainerHost02$", "ContainerHost03$"

ドメインに参加していないコンテナー ホストの gMSA アカウントの作成のユース ケース

ドメインに参加していないホストを持つコンテナー用に gMSA を使用する場合は、コンテナー ホストを WebApp01Hosts セキュリティ グループに追加するのではなく、標準ユーザー アカウントを作成して追加します。

# Replace 'WebApp01' and 'contoso.com' with your own gMSA and domain names, respectively.

# To install the AD module on Windows Server, run Install-WindowsFeature RSAT-AD-PowerShell
# To install the AD module on Windows 10 version 1809 or later, run Add-WindowsCapability -Online -Name 'Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0'
# To install the AD module on older versions of Windows 10, see https://aka.ms/rsat

# Create the security group
New-ADGroup -Name "WebApp01 Authorized Accounts" -SamAccountName "WebApp01Accounts" -GroupScope DomainLocal

# Create the gMSA
New-ADServiceAccount -Name "WebApp01" -DnsHostName "WebApp01.contoso.com" -ServicePrincipalNames "host/WebApp01", "host/WebApp01.contoso.com" -PrincipalsAllowedToRetrieveManagedPassword "WebApp01Accounts"

# Create the standard user account. This account information needs to be stored in a secret store and will be retrieved by the ccg.exe hosted plug-in to retrieve the gMSA password. Replace 'StandardUser01' and 'p@ssw0rd' with a unique username and password. We recommend using a random, long, machine-generated password.
New-ADUser -Name "StandardUser01" -AccountPassword (ConvertTo-SecureString -AsPlainText "p@ssw0rd" -Force) -Enabled 1

# Add your container hosts to the security group
Add-ADGroupMember -Identity "WebApp01Accounts" -Members "StandardUser01"

コンテナー ホストを準備する

ドメインに参加しているコンテナー ホスト用にコンテナー ホストを準備するユース ケース

gMSA を使用して Windows コンテナーを実行する各コンテナー ホストは、ドメインに参加し、gMSA パスワードを取得できるアクセス権を持っている必要があります。

  1. コンピューターを Active Directory ドメインに参加させます。

  2. ホストが gMSA パスワードへのアクセスを制御するセキュリティ グループに属していることを確認します。

  3. コンピューターを再起動して、新しいグループ メンバーシップを取得します。

  4. Docker Desktop for Windows 10 または Docker for Windows Server を設定します。

  5. (推奨) Test-ADServiceAccount を実行して、ホストで gMSA アカウントを使用できることを確認します。 コマンドから False が返される場合は、トラブルシューティングの手順に従ってください。

    # To install the AD module on Windows Server, run Install-WindowsFeature RSAT-AD-PowerShell
# To install the AD module on Windows 10 version 1809 or later, run Add-WindowsCapability -Online -Name 'Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0'
# To install the AD module on older versions of Windows 10, see https://aka.ms/rsat

Test-ADServiceAccount WebApp01

ドメインに参加していないコンテナー ホスト用にコンテナー ホストを準備するユース ケース

ドメインに参加していないコンテナー ホストで Windows コンテナー用の gMSA を使用する場合、各コンテナー ホストには ccg.exe 用のプラグインがインストールされている必要があります。これは、前の手順で指定されたポータブル ユーザー アカウントと資格情報を取得するために使用されます。 プラグインは、ポータブル ユーザー アカウントの資格情報を保護するために使用されるシークレット ストアに固有のものです。 たとえば、アカウントの資格情報を Azure Key Vault に格納する場合と Kubernetes シークレット ストアに格納する場合では、異なるプラグインが必要になります。

現在、Windows では、組み込みの既定のプラグインが提供されていません。 プラグインのインストール手順は、実装固有のものになります。 ccg.exe のプラグインの作成と登録の詳細については、ICcgDomainAuthCredentials インターフェイスに関する記事を参照してください。

資格情報の指定を作成する

資格情報の指定ファイルは、コンテナーで使用する gMSA アカウントに関するメタデータを含む JSON ドキュメントです。 ID 構成をコンテナー イメージから分離しておくと、資格情報の指定ファイルを交換するだけで、コンテナーに使用する gMSA を変更できます。コードを変更する必要はありません。

資格情報の指定ファイルを作成するには、ドメインに参加しているマシンで CredentialSpec PowerShell モジュールを使用します。 ファイルを作成したら、それを他のコンテナー ホストまたはコンテナー オーケストレーターにコピーできます。 コンテナーに代わってコンテナー ホストによって gMSA が取得されるため、資格情報の指定ファイルには gMSA パスワードなどのシークレットは含まれていません。

Docker では、Docker データ ディレクトリ内の CredentialSpecs ディレクトリ以下に資格情報の指定ファイルがあると想定されています。 既定のインストールでは、このフォルダーは C:\ProgramData\Docker\CredentialSpecs にあります。

コンテナー ホスト上で資格情報の指定ファイルを作成するには、次の手順を実行します。

  1. RSAT AD PowerShell ツールをインストールする

    • Windows サーバーの場合は、Install-WindowsFeature RSAT-AD-PowerShell を実行します。
    • Windows 10 バージョン 1809 以降の場合、Add-WindowsCapability -Online -Name 'Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0' を実行します。
    • 以前のバージョンの Windows 10 については、https://aka.ms/rsat を参照してください。

  2. 次のコマンドレットを実行して、CredentialSpec PowerShell モジュールの最新バージョンをインストールします。

    Install-Module CredentialSpec

    コンテナー ホストでインターネットにアクセスできない場合は、インターネットに接続されたマシンで Save-Module CredentialSpec を実行し、そのモジュール フォルダーをコンテナー ホスト上で C:\Program Files\WindowsPowerShell\Modules または $env:PSModulePath の別の場所にコピーします。

  3. 次のコマンドレットを実行して、新しい資格情報の指定ファイルを作成します。

    # Replace 'WebApp01' with your own gMSA
New-CredentialSpec -AccountName WebApp01

    このコマンドレットを実行すると、既定では、指定した gMSA 名がコンテナーのコンピューター アカウントとして使用され、資格情報の指定が作成されます。 このファイルは、gMSA ドメインとファイル名のアカウント名を使用して、Docker CredentialSpecs ディレクトリに保存されます。

    ファイルを別のディレクトリに保存する場合は、-Path パラメーターを使用します。

    New-CredentialSpec -AccountName WebApp01 -Path "C:\MyFolder\WebApp01_CredSpec.json"

    コンテナーでセカンダリ gMSA としてサービスまたはプロセスを実行している場合は、追加の gMSA アカウントを含む資格情報の指定を作成することもできます。 そのためには、-AdditionalAccounts パラメーターを使用します。

    New-CredentialSpec -AccountName WebApp01 -AdditionalAccounts LogAgentSvc, OtherSvc

    サポートされているパラメーターの完全な一覧については、Get-Help New-CredentialSpec -Full を実行します。

  4. 次のコマンドレットを使用して、すべての資格情報の指定とその完全なパスの一覧を表示できます。

    Get-CredentialSpec

資格情報の指定の例を次に示します。

{
    "CmsPlugins": [
        "ActiveDirectory"
    ],
    "DomainJoinConfig": {
        "Sid": "S-1-5-21-702590844-1001920913-2680819671",
        "MachineAccountName": "webapp01",
        "Guid": "56d9b66c-d746-4f87-bd26-26760cfdca2e",
        "DnsTreeName": "contoso.com",
        "DnsName": "contoso.com",
        "NetBiosName": "CONTOSO"
    },
    "ActiveDirectoryConfig": {
        "GroupManagedServiceAccounts": [
            {
                "Name": "webapp01",
                "Scope": "contoso.com"
            },
            {
                "Name": "webapp01",
                "Scope": "CONTOSO"
            }
        ]
    }
}

ドメインに参加していないコンテナー ホストのユース ケースに向けた追加の資格情報の指定の構成

ドメインに参加していないコンテナー ホストで gMSA を使用する場合は、使用する ccg.exe プラグインに関する情報を資格情報の指定に追加する必要があります。これは、HostAccountConfig という資格情報の指定のセクションに追加されます。 HostAccountConfig セクションでは、次の 3 つのフィールドを設定する必要があります。

  • PortableCcgVersion: これは "1" に設定する必要があります。
  • PluginGUID: ccg.exe プラグインの COM CLSID。 これは、使用されているプラグインに固有のものです。
  • PluginInput: シークレット ストアからユーザー アカウント情報を取得するためのプラグイン固有の入力。

HostAccountConfig セクションが追加された資格情報の指定の例を次に示します。

{
    "CmsPlugins": [
        "ActiveDirectory"
    ],
    "DomainJoinConfig": {
        "Sid": "S-1-5-21-702590844-1001920913-2680819671",
        "MachineAccountName": "webapp01",
        "Guid": "56d9b66c-d746-4f87-bd26-26760cfdca2e",
        "DnsTreeName": "contoso.com",
        "DnsName": "contoso.com",
        "NetBiosName": "CONTOSO"
    },
    "ActiveDirectoryConfig": {
        "GroupManagedServiceAccounts": [
            {
                "Name": "webapp01",
                "Scope": "contoso.com"
            },
            {
                "Name": "webapp01",
                "Scope": "CONTOSO"
            }
        ],
        "HostAccountConfig": {
            "PortableCcgVersion": "1",
            "PluginGUID": "{GDMA0342-266A-4D1P-831J-20990E82944F}",
            "PluginInput": "contoso.com:gmsaccg:<password>"
        }
    }
}

次の手順

gMSA アカウントを設定したので、これを使用して次のことを実行できます。

設定中に問題が発生した場合は、トラブルシューティング ガイドで考えられる解決策をご確認ください。

その他の資料