Condividi tramite

Creare gMSA per contenitori Windows

  • Articolo

Si applica a: Windows Server 2025, Windows Server 2022, Windows Server 2019

Le reti basate su Windows usano in genere Active Directory (AD) per facilitare l'autenticazione e l'autorizzazione tra utenti, computer e altre risorse di rete. Gli sviluppatori di applicazioni aziendali spesso progettano le proprie app in modo che siano integrate e eseguite in server aggiunti a un dominio per sfruttare l'autenticazione integrata di Windows, semplificando l'accesso automatico e trasparente dell'applicazione agli utenti e ad altri servizi con le proprie identità. Questo articolo illustra come iniziare a usare gli account del servizio gestito del gruppo di Active Directory con i contenitori di Windows.

Anche se i contenitori di Windows non possono essere aggiunti a un dominio, possono comunque usare le identità di dominio di Active Directory per supportare vari scenari di autenticazione. A tale scopo, è possibile configurare un contenitore windows da eseguire con un account del servizio gestito di gruppo (gMSA), che è un tipo speciale di account del servizio introdotto in Windows Server 2012 e progettato per consentire a più computer di condividere un'identità senza dover conoscere la password. I contenitori di Windows non possono essere aggiunti a un dominio, ma molte applicazioni Windows eseguite nei contenitori di Windows richiedono ancora l'autenticazione di Active Directory. Per utilizzare l'autenticazione di Active Directory, è possibile configurare un contenitore di Windows per funzionare con un gruppo Managed Service Account (gMSA).

Quando il gMSA per i contenitori Windows è stato inizialmente introdotto, era necessario che l'host del contenitore fosse aggiunto a un dominio, il che ha comportato un sovraccarico significativo poiché costringeva gli utenti ad aggiungere manualmente i nodi di lavoro di Windows a un dominio. La limitazione è stata affrontata con il supporto di gMSA per i contenitori Windows su host contenitore non appartenenti a un dominio. Continueremo a supportare la funzionalità gMSA originale per utilizzare un host di contenitori collegato a un dominio.

I miglioramenti apportati al gMSA quando si utilizza un container host non associato a un dominio includono:

  • Il requisito di aggiungere manualmente i nodi di lavoro di Windows a un dominio viene eliminato perché ha causato un notevole sovraccarico per gli utenti. Per gli scenari di ridimensionamento, l'uso di un host contenitore non aggiunto a un dominio semplifica il processo.
  • Negli scenari di aggiornamento in sequenza, gli utenti non devono più ricongiundere il nodo a un dominio.
  • La gestione degli account del computer del nodo di lavoro per recuperare le password dell'account del servizio gMSA è un processo più semplice.
  • Configurare un gMSA con Kubernetes è un processo end-to-end meno complesso.

Nota

Per informazioni su come la community di Kubernetes supporta l'uso di gMSA con contenitori Windows, vedere configurazione di gMSA.

Architettura e miglioramenti gMSA

Per risolvere le limitazioni dell'implementazione iniziale del gMSA per i contenitori Windows, il nuovo supporto gMSA per gli host di contenitori non collegati a un dominio utilizza un'identità utente portabile anziché un account del computer host per ottenere le credenziali gMSA. Di conseguenza, l'aggiunta manuale dei nodi di lavoro di Windows a un dominio non è più necessaria, anche se è ancora supportata. L'identità utente/le credenziali vengono archiviate in un archivio segreto accessibile all'host del contenitore , ad esempio come segreto Kubernetes, in cui gli utenti autenticati possono recuperarlo.

Diagramma degli account del servizio gestito di gruppo versione 2

Il supporto gMSA per host di contenitori non appartenenti a un dominio offre la flessibilità di creare contenitori utilizzando gMSA senza che il nodo host sia unito al dominio. A partire da Windows Server 2019, è supportato il ccg.exe che consente a un meccanismo plug-in di recuperare le credenziali gMSA da Active Directory. È possibile usare tale identità per avviare il contenitore. Per altre informazioni su questo meccanismo di plug-in, vedere l'interfaccia ICcgDomainAuthCredentials.

Nota

Nel servizio Azure Kubernetes su Azure Stack HCI, puoi utilizzare il plug-in per comunicare da ccg.exe ad AD e quindi recuperare le credenziali gMSA. Per ulteriori informazioni, vedere configurare l'Account del Servizio Gestito di Gruppo con AKS su Azure Stack HCI.

Visualizzare il diagramma seguente per seguire i passaggi del processo di Container Credential Guard:

  1. Usando un file CredSpec come input, il processo di ccg.exe viene avviato nell'host del nodo.

  2. ccg.exe usa le informazioni nel file CredSpec per avviare un plug-in e quindi recuperare le credenziali dell'account nell'archivio segreto associato al plug-in.

  3. ccg.exe utilizza le credenziali dell'account recuperate per ottenere la password di gMSA da AD.

  4. ccg.exe rende disponibile la password gMSA a un contenitore che ha richiesto credenziali.

  5. Il contenitore esegue l'autenticazione al controller di dominio usando la password del servizio gestito del gruppo per ottenere un ticket kerberos Ticket-Granting Ticket (TGT).

  6. Le applicazioni in esecuzione come Servizio di rete o Sistema locale all'interno del contenitore possono ora autenticarsi e accedere alle risorse di dominio, come il gMSA.

    Diagramma del processo di ccg.exe

Prerequisiti

Per eseguire un contenitore di Windows con un account del servizio gestito del gruppo, sono necessari gli elementi seguenti:

  • Un dominio di Active Directory con almeno un controller di dominio che esegue Windows Server 2012 o versione successiva. Non esistono requisiti a livello di funzionalità di foresta o dominio per l'uso degli account di servizio gestito di gruppo (gMSA), ma le password dei gMSA possono essere distribuite solo dai controller di dominio che utilizzano Windows Server 2012 o versioni successive. Per altre informazioni, vedere requisiti di Active Directory per i gMSA.
  • Autorizzazione per creare un account gMSA (account del servizio gestito del gruppo). Per creare un account gMSA, è necessario essere un amministratore di dominio o utilizzare un account a cui è stata delegata l'autorizzazione (con tag ) di creare oggetti msDS-GroupManagedServiceAccount (tag).
  • Accedere a Internet per scaricare il modulo PowerShell CredentialSpec. Se si usa un ambiente disconnesso, è possibile salvare il modulo in un computer con accesso a Internet e copiarlo nell'host del contenitore o del computer di sviluppo.

Preparazione unica di Active Directory

Se non hai già creato un gMSA (account del servizio gestito del gruppo) nel tuo dominio, sarà necessario generare la chiave radice del Servizio di Distribuzione delle Chiavi (KDS). KDS è responsabile della creazione, rotazione e rilascio della password del gMSA agli host autorizzati. Quando un host contenitore deve utilizzare il gMSA per eseguire un contenitore, contatta il KDS per recuperare la password corrente.

Per verificare se la chiave radice KDS è già stata creata, eseguire il cmdlet di PowerShell seguente come amministratore di dominio in un controller di dominio o membro di dominio con gli strumenti di PowerShell di AD installati:

Get-KdsRootKey

Se il comando restituisce un ID chiave, sei a posto e puoi saltare alla sezione creare un account di servizio gestito di gruppo. In caso contrario, continuare a creare la chiave radice KDS.

Importante

È consigliabile creare una sola chiave radice KDS per ogni foresta. Se vengono create più chiavi radice KDS, il gMSA inizierà a fallire dopo la rotazione della sua password.

In un ambiente di produzione o in un ambiente di test con più controller di dominio eseguire il cmdlet seguente in PowerShell come amministratore di dominio per creare la chiave radice KDS.

# For production environments
Add-KdsRootKey -EffectiveImmediately

Anche se il comando implica che la chiave sarà effettiva immediatamente, sarà necessario attendere 10 ore prima che la chiave radice KDS venga replicata e disponibile per l'uso in tutti i controller di dominio.

Se nel dominio è presente un solo controller di dominio, è possibile accelerare il processo impostando la chiave in modo che sia effettiva 10 ore fa.

Importante

Non usare questa tecnica in un ambiente di produzione.

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

Creare un account di servizio gestito di gruppo

Ogni contenitore che utilizza l'autenticazione integrata di Windows richiede almeno un gMSA. L'gMSA primario viene utilizzato ogni volta che le app eseguite come Sistema o Servizio di Rete accedono alle risorse della rete. Il nome del gMSA diventerà il nome del contenitore nella rete, indipendentemente dal nome host assegnato al contenitore. I contenitori possono anche essere configurati con account di servizio gestito di gruppo aggiuntivi (gMSAs), nel caso in cui si voglia eseguire un servizio o un'applicazione nel contenitore utilizzando un'identità diversa da quella dell'account computer del contenitore.

Quando si crea una gMSA, si crea anche un'identità condivisa che può essere usata simultaneamente su molte macchine diverse. L'accesso alla password del gMSA è protetto da un elenco di controllo di accesso di Active Directory. È consigliabile creare un gruppo di sicurezza per ogni account del servizio gestito di gruppo (gMSA) e aggiungere gli host contenitori rilevanti per limitare l'accesso alla password.

Infine, poiché i contenitori non registrano automaticamente Nomi Principali del Servizio (SPN), sarà necessario creare manualmente almeno un SPN host per l'account gMSA.

In genere, l'host o il nome SPN HTTP viene registrato usando lo stesso nome dell'account del servizio gestito del gruppo, ma potrebbe essere necessario usare un nome di servizio diverso se i client accedono all'applicazione in contenitori da dietro un servizio di bilanciamento del carico o un nome DNS diverso dal nome dell'account del servizio gestito del gruppo.

Ad esempio, se l'account gMSA è denominato "WebApp01", ma gli utenti accedono al sito in mysite.contoso.com, è necessario registrare un SPN http/mysite.contoso.com sull'account gMSA.

Alcune applicazioni possono richiedere spn aggiuntivi per i protocolli univoci. Ad esempio, SQL Server richiede l'SPN (Service Principal Name) MSSQLSvc/hostname.

Nella tabella seguente sono elencati gli attributi necessari per la creazione di un account del servizio gestito del gruppo (gMSA).

proprietà di gMSA Valore obbligatorio Esempio
Nome Qualsiasi nome di account valido. WebApp01
DnsHostName Nome di dominio aggiunto al nome dell'account. WebApp01.contoso.com
NomiPrincipaliDeiServizi Impostare almeno l'SPN dell'host, aggiungere altri protocolli secondo necessità. 'host/WebApp01', 'host/WebApp01.contoso.com'
PrincipalsAllowedToRetrieveManagedPassword Gruppo di sicurezza contenente gli host dei container. WebApp01Hosts

Dopo aver deciso il nome per il gMSA, eseguire i cmdlet seguenti in PowerShell per creare il gruppo di sicurezza e il gMSA.

Suggerimento

È necessario usare un account appartenente al gruppo di sicurezza Domain Admins o a cui è stata delegata l'autorizzazione di creare oggetti msDS-GroupManagedServiceAccount per eseguire i seguenti comandi. Il cmdlet New-ADServiceAccount fa parte di AD PowerShell Tools da Strumenti di amministrazione remota del server.

Si consiglia di creare account gMSA separati per gli ambienti di sviluppo, test e produzione.

Caso d'uso per la creazione di un account gMSA per host contenitore uniti a un dominio

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

Caso d'uso per la creazione di un account gMSA per host di container non collegati a un dominio

Quando si utilizza gMSA per i contenitori con host non uniti al dominio, invece di aggiungere gli host dei contenitori al gruppo di sicurezza WebApp01Hosts, creare e aggiungere un account utente standard.

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

Preparare l'host del container

Caso d'uso per preparare un host di contenitore collegato a un dominio

Ogni host contenitore che eseguirà un contenitore Windows con gMSA deve appartenere a un dominio e avere accesso per recuperare la password del gMSA.

  1. Aggiungere il computer al dominio di Active Directory.

  2. Assicurati che il tuo host appartenga al gruppo di sicurezza che controlla l'accesso alla password gMSA.

  3. Riavviare il computer per ottenere la nuova appartenenza al gruppo.

  4. Configurare Docker Desktop per Windows 10 o Docker per Windows Server.

  5. (Scelta consigliata) Verificare che l'host possa usare l'account del servizio gestito del gruppo eseguendo Test-ADServiceAccount. Se il comando restituisce False, seguire le istruzioni per la risoluzione dei problemi .

    # 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

Caso d'uso per preparare l'host del contenitore per un host di contenitori non collegato a un dominio

Quando si usa gMSA per contenitori Windows su host di contenitori non aggiunti a un dominio, ogni host contenitore deve disporre di un plug-in per ccg.exe installato, che verrà utilizzato per recuperare l'account utente e le credenziali specificate nel passaggio precedente. I plug-in sono specifici del deposito sicuro usato per proteggere le credenziali dell'account utente mobili. Ad esempio, sarebbero necessari plug-in diversi per archiviare le credenziali dell'account in Azure Key Vault rispetto a un archivio segreti Kubernetes.

Windows non offre attualmente un plug-in predefinito. Le istruzioni di installazione per i plug-in saranno specifiche dell'implementazione. Per altre informazioni sulla creazione e la registrazione di plug-in per ccg.exe, vedere interfaccia ICcgDomainAuthCredentials.

Creare una specifica di credenziali

Un file di specifiche delle credenziali è un documento JSON che contiene metadati sugli account gMSA che si desidera utilizzare in un contenitore. Mantenendo la configurazione dell'identità separata dall'immagine del contenitore, è possibile modificare l'account del servizio gestito di gruppo (gMSA) utilizzato dal contenitore semplicemente sostituendo il file delle specifiche delle credenziali, senza necessità di modifiche al codice.

Il file delle specifiche delle credenziali viene creato usando il modulo powerShell CredentialSpec in un computer aggiunto a un dominio. Dopo aver creato il file, è possibile copiarlo in altri host contenitore o nell'agente di orchestrazione del contenitore. Il file delle specifiche di credenziali non contiene segreti, come la password gMSA, poiché l'host del contenitore recupera la gMSA per conto del contenitore.

Docker si aspetta di trovare il file delle specifiche delle credenziali nella directory CredentialSpecs all'interno della directory dei dati di Docker. In un'installazione predefinita, questa cartella è disponibile in C:\ProgramData\Docker\CredentialSpecs.

Per creare un file di specifiche di credenziali nell'host contenitore:

  1. Installare gli strumenti PowerShell di RSAT per Active Directory

    • Per Windows Server, eseguire Install-WindowsFeature RSAT-AD-PowerShell.
    • Per Windows 10 versione 1809 o successiva, eseguire Add-WindowsCapability -Online -Name 'Rsat.ActiveDirectory.DS-LDS.Tools~~~~~0.0.1.0'.
    • Per le versioni precedenti di Windows 10, vedi https://aka.ms/rsat.

  2. Eseguire il cmdlet seguente per installare la versione più recente del modulo powerShell CredentialSpec:

    Install-Module CredentialSpec

    Se non si ha accesso a Internet nell'host contenitore, eseguire Save-Module CredentialSpec in un computer connesso a Internet e copiare la cartella del modulo in C:\Program Files\WindowsPowerShell\Modules o in un'altra posizione in $env:PSModulePath nell'host contenitore.

  3. Eseguire il cmdlet seguente per creare il nuovo file di specifiche di credenziali:

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

    Per impostazione predefinita, il cmdlet creerà una specifica di credenziali utilizzando il nome gMSA fornito come account computer per il contenitore. Il file verrà salvato nella directory Docker CredentialSpecs usando il dominio gMSA e il nome dell'account per il nome file.

    Per salvare il file in un'altra directory, usare il parametro -Path:

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

    È inoltre possibile creare una specifica di credenziali che includa account gMSA aggiuntivi se si esegue un servizio o un processo come gMSA secondario nel contenitore. A tale scopo, usare il parametro -AdditionalAccounts:

    New-CredentialSpec -AccountName WebApp01 -AdditionalAccounts LogAgentSvc, OtherSvc

    Per un elenco completo dei parametri supportati, eseguire Get-Help New-CredentialSpec -Full.

  4. È possibile visualizzare un elenco di tutte le specifiche delle credenziali e il relativo percorso completo con il cmdlet seguente:

    Get-CredentialSpec

Di seguito è riportato un esempio di specifica delle credenziali:

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

Configurazione aggiuntiva delle specifiche di credenziali per il caso d'uso dell'host contenitore non aggiunto a un dominio

Quando si usa gMSA con host contenitore non appartenenti a un dominio, è necessario aggiungere informazioni sul plug-in ccg.exe che verrà usato alla specifica delle credenziali. Verrà aggiunto a una sezione della specifica delle credenziali denominata HostAccountConfig. La sezione HostAccountConfig include tre campi che devono essere popolati:

  • PortableCcgVersion: deve essere impostato su "1".
  • PluginGUID: CLSID COM per il plug-in ccg.exe. Questo è univoco per il plug-in utilizzato.
  • PluginInput: input specifico del plug-in per recuperare le informazioni sull'account utente dall'archivio segreto.

Questo è un esempio di specifica delle credenziali con la sezione HostAccountConfig aggiunta:

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

Passaggi successivi

Dopo aver configurato il tuo account gMSA (Group Managed Service Account), puoi usarlo per:

Se si verificano problemi durante l'installazione, consultare la guida alla risoluzione dei problemi per le possibili soluzioni.

Risorse aggiuntive

  • Per ulteriori informazioni sugli account di servizio gestiti del gruppo (gMSAs), vedere la panoramica degli account di servizio gestiti del gruppo .