Delen via

GMSA's maken voor Windows-containers

  • Artikel

Van toepassing op: Windows Server 2025, Windows Server 2022, Windows Server 2019

Windows-netwerken maken vaak gebruik van Active Directory (AD) om verificatie en autorisatie tussen gebruikers, computers en andere netwerkbronnen te vergemakkelijken. Bedrijfstoepassingsontwikkelaars ontwerpen hun apps vaak als AD-geïntegreerd en worden uitgevoerd op servers die lid zijn van een domein om te profiteren van geïntegreerde Windows-verificatie, waardoor gebruikers en andere services zich eenvoudig automatisch en transparant met hun identiteit kunnen aanmelden bij de toepassing. In dit artikel wordt uitgelegd hoe u beheerde serviceaccounts voor Active Directory-groepen gebruikt met Windows-containers.

Hoewel Windows-containers niet aan een domein kunnen worden toegevoegd, kunnen ze nog steeds Active Directory-domeinidentiteiten gebruiken om verschillende verificatiescenario's te ondersteunen. Hiervoor kunt u een Windows-container configureren die wordt uitgevoerd met een groep Managed Service Account (gMSA), een speciaal type serviceaccount dat is geïntroduceerd in Windows Server 2012 en is ontworpen om meerdere computers een identiteit te laten delen zonder dat u het wachtwoord hoeft te kennen. Windows-containers kunnen niet aan een domein worden toegevoegd, maar veel Windows-toepassingen die worden uitgevoerd in Windows-containers hebben nog steeds AD-verificatie nodig. Als u Active Directory (AD)-verificatie wilt gebruiken, kunt u een Windows-container configureren om te draaien met een groepsbeleid beheerd serviceaccount (gMSA).

Toen gMSA voor Windows-containers in eerste instantie werd geïntroduceerd, moest de containerhost lid worden van een domein, waardoor gebruikers veel overhead hebben gemaakt om Windows-werkknooppunten handmatig aan een domein toe te voegen. Deze beperking is opgelost met gMSA voor Windows-containersondersteuning voor niet-domein-gekoppelde containerhosts. We blijven de oorspronkelijke gMSA-functionaliteit ondersteunen voor het gebruik van een containerhost die lid is van een domein.

Verbeteringen in gMSA bij het gebruik van een niet-domein-gekoppelde containerhost zijn onder andere:

  • De vereiste om Windows-werkknooppunten handmatig aan een domein toe te voegen, wordt geëlimineerd omdat dit veel overhead voor gebruikers heeft veroorzaakt. Voor het schalen van scenario's vereenvoudigt het gebruik van een containerhost die geen lid is van een domein.
  • In scenario's voor rolling updates moeten gebruikers het knooppunt niet meer opnieuw toevoegen aan een domein.
  • Het beheren van de werkknooppuntcomputeraccounts voor het ophalen van wachtwoorden voor gMSA-serviceaccounts is een eenvoudiger proces.
  • Het configureren van gMSA met Kubernetes is een minder gecompliceerd end-to-end proces.

Notitie

Zie gMSA-configureren voor meer informatie over hoe de Kubernetes-community ondersteuning biedt voor het gebruik van gMSA met Windows-containers.

gMSA-architectuur en verbeteringen

Om de beperkingen van de eerste implementatie van gMSA voor Windows-containers aan te pakken, maakt nieuwe gMSA-ondersteuning voor niet-domein-gekoppelde containerhosts gebruik van een draagbare gebruikersidentiteit in plaats van een hostcomputeraccount om gMSA-referenties op te halen. Daarom is het handmatig koppelen van Windows-werkknooppunten aan een domein niet meer nodig, hoewel dit nog steeds wordt ondersteund. De gebruikersidentiteit/referenties worden opgeslagen in een geheim archief dat toegankelijk is voor de containerhost (bijvoorbeeld als een Kubernetes-geheim) waar geverifieerde gebruikers het kunnen ophalen.

diagram van beheerde serviceaccounts van groep twee

gMSA-ondersteuning voor niet-domein-gekoppelde containerhosts biedt de flexibiliteit van het maken van containers met gMSA zonder dat het hostknooppunt aan het domein wordt toegevoegd. Vanaf Windows Server 2019 wordt ccg.exe ondersteund, waardoor een invoegtoepassingsmechanisme gMSA-referenties kan ophalen uit Active Directory. U kunt die identiteit gebruiken om de container te starten. Zie de interface ICcgDomainAuthCredentials interfacevoor meer informatie over dit invoegtoepassingsmechanisme.

Notitie

In Azure Kubernetes Service in Azure Stack HCI kunt u de invoegtoepassing gebruiken om te communiceren van ccg.exe naar AD en vervolgens de gMSA-referenties op te halen. Zie groep Managed Service Account configureren met AKS in Azure Stack HCIvoor meer informatie.

Bekijk het onderstaande diagram om de stappen van het Container Credential Guard-proces te volgen:

  1. Met behulp van een CredSpec--bestand als invoer wordt het ccg.exe proces gestart op de knooppunthost.

  2. ccg.exe gebruikt informatie in het bestand CredSpec om een invoegtoepassing te starten en vervolgens de accountreferenties op te halen in de geheime opslag verbonden met de invoegtoepassing.

  3. ccg.exe gebruikt de opgehaalde accountreferenties om het gMSA-wachtwoord op te halen uit AD.

  4. ccg.exe maakt het gMSA-wachtwoord beschikbaar voor een container die referenties heeft aangevraagd.

  5. De container wordt geverifieerd bij de domeincontroller met behulp van het gMSA-wachtwoord om een Kerberos-Ticket-Granting-ticket (TGT) op te halen.

  6. Toepassingen die als netwerkservice of lokaal systeem in de container worden uitgevoerd, kunnen nu domeinbronnen verifiëren en openen, zoals de gMSA.

    diagram van het ccg.exe proces

Voorwaarden

Als u een Windows-container wilt uitvoeren met een door een groep beheerd serviceaccount, hebt u het volgende nodig:

  • Een Active Directory-domein met ten minste één domeincontroller met Windows Server 2012 of hoger. Er zijn geen vereisten op forest- of domeinfunctionaliteitsniveau voor het gebruik van gMSA's, maar de gMSA-wachtwoorden kunnen alleen worden gedistribueerd door domeincontrollers met Windows Server 2012 of hoger. Zie Active Directory-vereisten voor gMSA'svoor meer informatie.
  • Machtiging voor het maken van een gMSA-account. Als u een gMSA-account wilt maken, moet u een Domeinbeheerder zijn of een account gebruiken dat de machtiging msDS-GroupManagedServiceAccount-objecten maken heeft gekregen.
  • Toegang tot internet om de CredentialSpec PowerShell-module te downloaden. Als u in een niet-verbonden omgeving werkt, kunt u de module opslaan op een computer met internettoegang en deze kopiëren naar uw ontwikkelcomputer of containerhost.

Eenmalige voorbereiding van Active Directory

Als u nog geen gMSA in uw domein hebt gemaakt, moet u de hoofdsleutel van de Key Distribution Service (KDS) genereren. De KDS is verantwoordelijk voor het maken, roteren en vrijgeven van het gMSA-wachtwoord voor geautoriseerde hosts. Wanneer een containerhost de gMSA moet gebruiken om een container uit te voeren, neemt deze contact op met de KDS om het huidige wachtwoord op te halen.

Als u wilt controleren of de KDS-hoofdsleutel al is gemaakt, voert u de volgende PowerShell-cmdlet uit als domeinbeheerder op een domeincontroller of lid van het domein waarop de AD PowerShell-hulpprogramma's zijn geïnstalleerd:

Get-KdsRootKey

Als de opdracht een sleutel-id retourneert, bent u klaar en kunt u verdergaan naar de een door een groep beheerd serviceaccount sectie maken. Anders gaat u verder met het maken van de KDS-hoofdsleutel.

Belangrijk

U moet slechts één KDS-hoofdsleutel per forest maken. Als er meerdere KDS-hoofdsleutels worden gemaakt, zal de gMSA falen nadat het gMSA-wachtwoord is geroteerd.

Voer in een productieomgeving of testomgeving met meerdere domeincontrollers de volgende cmdlet uit in PowerShell als domeinbeheerder om de KDS-hoofdsleutel te maken.

# For production environments
Add-KdsRootKey -EffectiveImmediately

Hoewel de opdracht impliceert dat de sleutel onmiddellijk van kracht is, moet u 10 uur wachten voordat de KDS-hoofdsleutel wordt gerepliceerd en beschikbaar is voor gebruik op alle domeincontrollers.

Als u slechts één domeincontroller in uw domein hebt, kunt u het proces versnellen door de sleutel 10 uur geleden in te stellen.

Belangrijk

Gebruik deze techniek niet in een productieomgeving.

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

Een beheerd serviceaccount voor een groep maken

Elke container die gebruikmaakt van geïntegreerde Windows-verificatie heeft ten minste één gMSA nodig. De primaire gMSA wordt gebruikt wanneer apps die worden uitgevoerd als systeem- of netwerkservice toegang hebben tot bronnen op het netwerk. De naam van de gMSA wordt de naam van de container in het netwerk, ongeacht de hostnaam die aan de container is toegewezen. Containers kunnen ook worden geconfigureerd met extra gMSA's, voor het geval u een service of toepassing in de container wilt uitvoeren als een andere identiteit dan het containercomputeraccount.

Wanneer u een gMSA maakt, maakt u ook een gedeelde identiteit die tegelijkertijd op veel verschillende computers kan worden gebruikt. Toegang tot het gMSA-wachtwoord wordt beveiligd door een Active Directory-toegangsbeheerlijst. U wordt aangeraden een beveiligingsgroep te maken voor elk gMSA-account en de relevante containerhosts toe te voegen aan de beveiligingsgroep om de toegang tot het wachtwoord te beperken.

Ten slotte moet u, omdat containers geen SERVICE Principal Names (SPN) automatisch registreren, handmatig een host-SPN maken voor uw gMSA-account.

Normaal gesproken wordt de host of http SPN geregistreerd met dezelfde naam als het gMSA-account, maar mogelijk moet u een andere servicenaam gebruiken als clients toegang hebben tot de containertoepassing achter een load balancer of een DNS-naam die verschilt van de gMSA-naam.

Als het gMSA-account bijvoorbeeld 'WebApp01' heet, maar uw gebruikers toegang hebben tot de site op mysite.contoso.com, moet u een http/mysite.contoso.com SPN registreren voor het gMSA-account.

Voor sommige toepassingen zijn mogelijk extra SPN's vereist voor hun unieke protocollen. SQL Server vereist bijvoorbeeld de MSSQLSvc/hostname SPN.

De volgende tabel bevat de vereiste kenmerken voor het maken van een gMSA.

gMSA-eigenschap Vereiste waarde Voorbeeld
Naam Elke geldige accountnaam. WebApp01
DnsHostName De domeinnaam die is toegevoegd aan de accountnaam. WebApp01.contoso.com
ServicePrincipalNames Stel ten minste de host-SPN in en voeg indien nodig andere protocollen toe. 'host/WebApp01', 'host/WebApp01.contoso.com'
PrincipalsDieBevoegdZijnOmBeheerdWachtwoordOpTeHalen De beveiligingsgroep die uw containerhosts bevat. WebApp01Hosts

Nadat u de naam voor uw gMSA hebt besloten, voert u de volgende cmdlets uit in PowerShell om de beveiligingsgroep en gMSA te maken.

Tip

U moet een account gebruiken dat deel uitmaakt van de Domeinadministrators beveiligingsgroep of waaraan de Create msDS-GroupManagedServiceAccount objects machtiging is gedelegeerd om de volgende opdrachten uit te voeren. De cmdlet New-ADServiceAccount maakt deel uit van de AD PowerShell Tools van Remote Server Administration Tools.

U wordt aangeraden afzonderlijke gMSA-accounts te maken voor uw ontwikkel-, test- en productieomgevingen.

Gebruiksscenario voor het aanmaken van een gMSA-account voor domeingebonden containerhosts

# 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$"

Usecase voor het maken van een gMSA-account voor container-hosts die niet lid zijn van een domein

Wanneer u gMSA gebruikt voor containers met niet-domein-gekoppelde hosts, moet u in plaats van containerhosts toe te voegen aan de WebApp01Hosts beveiligingsgroep, een standaardgebruikersaccount maken en toevoegen.

# 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"

Uw containerhost voorbereiden

Gebruiksvoorbeeld voor het voorbereiden van de containerhost voor een domein-gebonden containerhost.

Elke containerhost waarop een Windows-container met een gMSA wordt uitgevoerd, moet lid zijn van een domein en toegang hebben om het gMSA-wachtwoord op te halen.

  1. Voeg uw computer toe aan uw Active Directory-domein.

  2. Zorg ervoor dat uw host deel uitmaakt van de beveiligingsgroep die de toegang tot het gMSA-wachtwoord beheert.

  3. Start de computer opnieuw op om het nieuwe groepslidmaatschap op te halen.

  4. Stel Docker Desktop in voor Windows 10 of Docker voor Windows Server.

  5. (Aanbevolen) Controleer of de host het gMSA-account kan gebruiken door Test-ADServiceAccount-uit te voeren. Als de opdracht Falseretourneert, volgt u de instructies voor het oplossen van problemen .

    # 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

Gebruiksscenario voor het voorbereiden van de containerhost voor een niet-domeingebonden containerhost

Wanneer u gMSA voor Windows-containers gebruikt op niet-domein-gekoppelde containerhosts, moet elke containerhost een invoegtoepassing hebben voor ccg.exe geïnstalleerd die wordt gebruikt om het draagbare gebruikersaccount en de referenties op te halen die in de vorige stap zijn opgegeven. Invoegtoepassingen zijn uniek voor het geheime archief dat wordt gebruikt om de gebruikersaccountgegevens te beschermen. Er zijn bijvoorbeeld verschillende invoegtoepassingen nodig om accountreferenties op te slaan in Azure Key Vault versus in een Kubernetes-geheimarchief.

Windows biedt momenteel geen ingebouwde, standaardinvoegtoepassing. Installatie-instructies voor invoegtoepassingen zijn implementatiespecifiek. Zie ICcgDomainAuthCredentials interfacevoor meer informatie over het maken en registreren van invoegtoepassingen voor ccg.exe.

Een referentiespecificatie maken

Een referentiespecificatiebestand is een JSON-document dat metagegevens bevat over de gMSA-accounts die u wilt gebruiken in een container. Door de identiteitsconfiguratie gescheiden te houden van de containerimage, kunt u eenvoudig veranderen welke gMSA de container gebruikt door simpelweg het referentiespecificatiebestand te wisselen. Er zijn geen codewijzigingen nodig.

Het referentiespecificatiebestand wordt gemaakt met behulp van de CredentialSpec PowerShell-module op een computer die lid is van een domein. Nadat u het bestand hebt gemaakt, kunt u het kopiëren naar andere containerhosts of naar uw containerorchestrator. Het referentiespecificatiebestand bevat geen geheimen, zoals het gMSA-wachtwoord, omdat de containerhost de gMSA namens de container ophaalt.

Docker verwacht dat het referentiespecificatiebestand wordt gevonden onder de map CredentialSpecs in de Docker-gegevensmap. In een standaardinstallatie vindt u deze map op C:\ProgramData\Docker\CredentialSpecs.

Een referentiespecificatiebestand maken op uw containerhost:

  1. Installeer de RSAT AD PowerShell-hulpprogramma's

    • Voer voor Windows Server Install-WindowsFeature RSAT-AD-PowerShell-uit.
    • Voer voor Windows 10 versie 1809 of hoger Add-WindowsCapability -Online -Name 'Rsat.ActiveDirectory.DS-LDS.Tools~~~~~0.0.1.0'uit.
    • Zie https://aka.ms/rsatvoor oudere versies van Windows 10.

  2. Voer de volgende cmdlet uit om de nieuwste versie van de CredentialSpec PowerShell-module te installeren:

    Install-Module CredentialSpec

    Als u geen internettoegang hebt op de containerhost, voert u Save-Module CredentialSpec uit op een computer met internetverbinding en kopieert u de modulemap naar C:\Program Files\WindowsPowerShell\Modules of naar een andere locatie in $env:PSModulePath op de containerhost.

  3. Voer de volgende cmdlet uit om het nieuwe referentiespecificatiebestand te maken:

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

    Standaard maakt de cmdlet een referentiespecificatie met behulp van de opgegeven gMSA-naam, waarbij deze als computeraccount voor de container dient. Het bestand wordt opgeslagen in de map Docker CredentialSpecs met behulp van het gMSA-domein en de accountnaam voor de bestandsnaam.

    Als u het bestand wilt opslaan in een andere map, gebruikt u de parameter -Path:

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

    U kunt ook een referentiespecificatie maken die extra gMSA-accounts bevat als u een service of proces uitvoert als een secundaire gMSA in de container. Gebruik hiervoor de parameter -AdditionalAccounts:

    New-CredentialSpec -AccountName WebApp01 -AdditionalAccounts LogAgentSvc, OtherSvc

    Voer Get-Help New-CredentialSpec -Fulluit voor een volledige lijst met ondersteunde parameters.

  4. U kunt een lijst met alle referentiespecificaties en hun volledige pad weergeven met de volgende cmdlet:

    Get-CredentialSpec

Dit is een voorbeeld van een referentiespecificatie:

{
    "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"
            }
        ]
    }
}

Aanvullende configuratie van credential spec voor een gebruiksscenario met een niet aan een domein gekoppelde containerhost

Wanneer u gMSA gebruikt met niet-domein-gekoppelde containerhosts, moet informatie over de ccg.exe-invoegtoepassing die u gaat gebruiken, worden toegevoegd aan de referentiespecificatie. Dit wordt toegevoegd aan een sectie van de referentiespecificatie met de naam HostAccountConfig. De sectie HostAccountConfig bevat drie velden die moeten worden ingevuld:

  • PortableCcgVersion: dit moet worden ingesteld op '1'.
  • PluginGUID: de COM CLSID voor de ccg.exe-invoegtoepassing. Dit is uniek voor de gebruikte invoegtoepassing.
  • PluginInput: Invoegtoepassing-specifieke invoer voor het ophalen van de gebruikersaccountgegevens uit de geheime opslag.

Dit is een voorbeeld van een referentiespecificatie met de sectie HostAccountConfig toegevoegd:

{
    "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>"
        }
    }
}

Volgende stappen

Nu u uw gMSA-account hebt ingesteld, kunt u het volgende doen:

Als u problemen ondervindt tijdens de installatie, raadpleegt u onze gids voor probleemoplossing voor mogelijke oplossingen.

Aanvullende informatiebronnen

  • Om meer te leren over gMSA's, zie het overzicht van groepsbeheerde serviceaccounts .