Utilizzo di contenitori Amazon ECS Windows con modalità domainless gMSA utilizzando AWS CLI - Amazon Elastic Container Service

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Utilizzo di contenitori Amazon ECS Windows con modalità domainless gMSA utilizzando AWS CLI

Il tutorial seguente mostra come creare un'attività Amazon ECS che esegue un container Windows con credenziali per accedere ad Active Directory con la AWS CLI. Utilizzando gMSA senza dominio, l'istanza di container non viene aggiunta al dominio, le altre applicazioni sull'istanza non possono utilizzare le credenziali per accedere al dominio e le attività che si uniscono a domini diversi possono essere eseguite sulla stessa istanza.

Prerequisiti

Questo tutorial presuppone che siano stati soddisfatti i prerequisiti seguenti:

  • Hai completato le fasi descritte in Configurazione per l'uso di Amazon ECS.

  • AWS L'utente dispone delle autorizzazioni richieste specificate nell'esempio di policy IAM. AmazonECS_ FullAccess

  • La versione più recente di AWS CLI è installata e configurata. Per ulteriori informazioni sull'installazione o l'aggiornamento di AWS CLI, vedere Installazione di. AWS Command Line Interface

  • Configura un dominio Active Directory con le risorse a cui desideri che i tuoi container accedano. Amazon ECS supporta le configurazioni seguenti:

    • Un AWS Directory Service Active Directory. AWS Directory Service è un Active Directory AWS gestito ospitato su Amazon EC2. Per ulteriori informazioni, vedere Guida introduttiva a AWS Managed Microsoft AD nella Guida all'AWS Directory Service amministrazione.

    • Una Active Directory on-premise. Devi assicurarti che l'istanza di container Linux di Amazon ECS possa essere aggiunta al dominio. Per ulteriori informazioni, consulta AWS Direct Connect.

  • Disponi di un VPC e delle sottoreti in grado di risolvere il nome di dominio Active Directory.

  • Hai scelto tra la modalità gMSA senza dominio e l'aggiunta di ogni istanza in un unico dominio. Utilizzando gMSA senza dominio, l'istanza di container non viene aggiunta al dominio, le altre applicazioni sull'istanza non possono utilizzare le credenziali per accedere al dominio e le attività che si uniscono a domini diversi possono essere eseguite sulla stessa istanza.

    Quindi, scegli l'archiviazione di dati per CredSpec e, facoltativamente, per le credenziali utente di Active Directory per gMSA senza dominio.

    Amazon ECS utilizza un file di specifica delle credenziali di Active Directory (CredSpec). Questo file contiene i metadati gMSA utilizzati per propagare il contesto dell'account gMSA al container. Il file CredSpec viene generato e quindi archiviato in una delle opzioni di archiviazione di CredSpec nella tabella seguente, specifica del sistema operativo delle istanze di container. Per utilizzare il metodo senza dominio, una sezione facoltativa del file CredSpec può specificare le credenziali in una delle opzioni di archiviazione domainless user credentials riportate nella tabella seguente, in base al sistema operativo delle istanze di container.

    Opzioni di archiviazione di dati gMSA per sistema operativo
    Posizione di archiviazione Linux Windows
    Amazon Simple Storage Service CredSpec CredSpec
    AWS Secrets Manager credenziali utente senza dominio credenziali utente senza dominio
    Archivio dei parametri Systems Manager per Amazon EC2 CredSpec CredSpec, credenziali utente senza dominio
    File locale N/D CredSpec
  • (Facoltativo) AWS CloudShell è uno strumento che offre ai clienti una riga di comando senza la necessità di creare la propria istanza EC2. Per ulteriori informazioni, consulta Cos'è? AWS CloudShell nella Guida AWS CloudShell per l'utente.

Fase 1: creazione e configurazione dell'account gMSA su Active Directory Domain Services (AD DS)

Crea e configura un account gMSA nel dominio Active Directory.

  1. Genera una chiave principale del servizio di distribuzione delle chiavi
    Nota

    Se lo stai utilizzando AWS Directory Service, puoi saltare questo passaggio.

    La chiave principale KDS e le autorizzazioni gMSA sono configurate con Microsoft AD gestito da AWS .

    Se non hai ancora creato un account del sevizio gMSA nel tuo dominio, dovrai prima generare una chiave principale del servizio di distribuzione delle chiavi (KDS). Il KDS è responsabile della creazione, della rotazione e del rilascio della password gMSA agli host autorizzati. Quando ccg.exe ha bisogno di recuperare le credenziali gMSA, contatta KDS per recuperare la password attuale.

    Per verificare se la chiave radice KDS è già stata creata, esegui il seguente PowerShell cmdlet con privilegi di amministratore di dominio su un controller di dominio utilizzando il modulo. ActiveDirectory PowerShell Per ulteriori informazioni sul modulo, vedere ActiveDirectory Module nel sito Web Microsoft Learn.

    PS C:\> Get-KdsRootKey

    Se il comando restituisce un ID chiave, puoi ignorare il resto della procedura. In caso contrario, crea la chiave principale KDS eseguendo il comando seguente:

    PS C:\> Add-KdsRootKey -EffectiveImmediately

    Sebbene l'argomento EffectiveImmediately del comando implichi l'efficacia immediata della chiave, devi attendere 10 ore prima che la chiave principale KDS venga replicata e sia disponibile per l'uso su tutti i controller di dominio.

  2. Crea l'account gMSA

    Per creare l'gMSAaccount e consentire il ccg.exe recupero della gMSA password, esegui i seguenti PowerShell comandi da un server o client Windows con accesso al dominio. Sostituisci ExampleAccount con il nome che desideri assegnare all'account gMSA.

    1. PS C:\> Install-WindowsFeature RSAT-AD-PowerShell
    2. PS C:\> New-ADGroup -Name "ExampleAccount Authorized Hosts" -SamAccountName "ExampleAccountHosts" -GroupScope DomainLocal
    3. PS C:\> New-ADServiceAccount -Name "ExampleAccount" -DnsHostName "contoso" -ServicePrincipalNames "host/ExampleAccount", "host/contoso" -PrincipalsAllowedToRetrieveManagedPassword "ExampleAccountHosts"
    4. Crea un utente con una password permanente senza scadenza. Queste credenziali vengono archiviate AWS Secrets Manager e utilizzate da ogni attività per accedere al dominio.

      PS C:\> New-ADUser -Name "ExampleAccount" -AccountPassword (ConvertTo-SecureString -AsPlainText "Test123" -Force) -Enabled 1 -PasswordNeverExpires 1
    5. PS C:\> Add-ADGroupMember -Identity "ExampleAccountHosts" -Members "ExampleAccount"
    6. Installa il PowerShell modulo per la creazione di CredSpec oggetti in Active Directory e genera il codice CredSpec JSON.

      PS C:\> Install-PackageProvider -Name NuGet -Force
      PS C:\> Install-Module CredentialSpec
    7. PS C:\> New-CredentialSpec -AccountName ExampleAccount
  3. Copia l'output JSON del comando precedente in un file denominato gmsa-cred-spec.json. Si tratta del file CredSpec che viene utilizzato nella fase 3, Fase3: modifica del codice JSON CredSpec per includere informazioni relative a gMSA senza dominio.

Fase 2: caricamento delle credenziali in Secrets Manager

Copia le credenziali di Active Directory in un sistema di archiviazione sicuro delle credenziali, in modo che ogni attività possa recuperarle. Questo è il metodo gMSA senza dominio. Utilizzando gMSA senza dominio, l'istanza di container non viene aggiunta al dominio, le altre applicazioni sull'istanza non possono utilizzare le credenziali per accedere al dominio e le attività che si uniscono a domini diversi possono essere eseguite sulla stessa istanza.

Questo passaggio utilizza il. AWS CLI Puoi eseguire questi comandi in AWS CloudShell nella shell (interprete di comandi) predefinita, ovvero bash.

  • Esegui il AWS CLI comando seguente e sostituisci il nome utente, la password e il nome di dominio in modo che corrispondano al tuo ambiente. Mantieni l'ARN del segreto da utilizzare nella fase successiva, Fase3: modifica del codice JSON CredSpec per includere informazioni relative a gMSA senza dominio

    Il comando seguente utilizza i caratteri di continuazione (barra rovesciata) utilizzati da sh e dalle shell compatibili. Questo comando non è compatibile con PowerShell. È necessario modificare il comando con cui utilizzarlo PowerShell.

    $ aws secretsmanager create-secret \ --name gmsa-plugin-input \ --description "Amazon ECS - gMSA Portable Identity." \ --secret-string "{\"username\":\"ExampleAccount\",\"password\":\"Test123\",\"domainName\":\"contoso.com\"}"

Fase3: modifica del codice JSON CredSpec per includere informazioni relative a gMSA senza dominio

Prima di caricare CredSpec su una delle opzioni di archiviazione, aggiungi le informazioni a CredSpec con l'ARN del segreto in Secrets Manager del passaggio precedente. Per ulteriori informazioni, vedi lo use case Additional Credential Spec Configuration for non-domain-joined Container Host nel sito Web Microsoft Learn.

  1. Aggiungi le seguenti informazioni al file CredSpec all'interno di ActiveDirectoryConfig. Sostituisci l'ARN con il segreto in Secrets Manager del passaggio precedente.

    Tieni presente che il valore PluginGUID deve corrispondere al GUID nel seguente frammento di codice esemplificativo ed è obbligatorio.

    "HostAccountConfig": { "PortableCcgVersion": "1", "PluginGUID": "{859E1386-BDB4-49E8-85C7-3070B13920E1}", "PluginInput": "{\"credentialArn\": \"arn:aws:secretsmanager:aws-region:111122223333:secret:gmsa-plugin-input\"}" }

    Puoi anche usare un segreto nell'archivio parametri SSM con l'ARN in questo formato: \"arn:aws:ssm:aws-region:111122223333:parameter/gmsa-plugin-input\".

  2. Il file CredSpec modificato sarà simile all'esempio seguente:

    { "CmsPlugins": [ "ActiveDirectory" ], "DomainJoinConfig": { "Sid": "S-1-5-21-4066351383-705263209-1606769140", "MachineAccountName": "ExampleAccount", "Guid": "ac822f13-583e-49f7-aa7b-284f9a8c97b6", "DnsTreeName": "contoso", "DnsName": "contoso", "NetBiosName": "contoso" }, "ActiveDirectoryConfig": { "GroupManagedServiceAccounts": [ { "Name": "ExampleAccount", "Scope": "contoso" }, { "Name": "ExampleAccount", "Scope": "contoso" } ], "HostAccountConfig": { "PortableCcgVersion": "1", "PluginGUID": "{859E1386-BDB4-49E8-85C7-3070B13920E1}", "PluginInput": "{\"credentialArn\": \"arn:aws:secretsmanager:aws-region:111122223333:secret:gmsa-plugin-input\"}" } } }

Fase 4: caricamento di CredSpec su Amazon S3

Questo passaggio utilizza il. AWS CLI Puoi eseguire questi comandi in AWS CloudShell nella shell (interprete di comandi) predefinita, ovvero bash.

  1. Copia il file CredSpec nel computer o nell'ambiente in cui esegui i comandi AWS CLI .

  2. Esegui il AWS CLI comando seguente per CredSpec caricarlo su Amazon S3. Sostituisci MyBucket con il nome del bucket Amazon S3. Puoi archiviare il file come oggetto in qualsiasi bucket e posizione, ma devi consentire l'accesso a tale bucket e tale posizione nella policy associata al ruolo di esecuzione dell'attività.

    Il comando seguente utilizza i caratteri di continuazione (barra rovesciata) utilizzati da sh e dalle shell compatibili. Questo comando non è compatibile con PowerShell. È necessario modificare il comando con cui utilizzarlo PowerShell.

    $ aws s3 cp gmsa-cred-spec.json \ s3://MyBucket/ecs-domainless-gmsa-credspec

Fase 5: creazione di un cluster Amazon ECS (facoltativo)

Per impostazione predefinita, l'account dispone di un cluster Amazon ECS denominato default. Questo cluster viene utilizzato per impostazione predefinita negli AWS CLI SDK e AWS CloudFormation. Puoi utilizzare cluster aggiuntivi per raggruppare e organizzare le attività e l'infrastruttura e assegnare impostazioni predefinite per alcune configurazioni.

È possibile creare un cluster dagli AWS Management Console, AWS CLI, SDK o. AWS CloudFormation Le impostazioni e la configurazione nel cluster non influiscono su gMSA.

Questo passaggio utilizza il. AWS CLI Puoi eseguire questi comandi in AWS CloudShell nella shell (interprete di comandi) predefinita, ovvero bash.

$ aws ecs create-cluster --cluster-name windows-domainless-gmsa-cluster
Importante

Se vuoi creare un cluster personalizzato, devi specificare --cluster clusterName per ogni comando che prevedi di usare con tale cluster.

Fase 6: creazione di un ruolo IAM per le istanze di container

Un'istanza di container è un computer host per l'esecuzione di container in attività ECS, ad esempio istanze Amazon EC2. Ogni istanza di container viene registrata in un cluster Amazon ECS. Prima di avviare le istanze Amazon EC2 e registrarle in un cluster, devi creare un ruolo IAM per le istanze di container da utilizzare.

Per creare il ruolo dell'istanza di container, consulta Ruolo IAM delle istanze di container Amazon ECS. Il ruolo ecsInstanceRole predefinito dispone di autorizzazioni sufficienti per completare questo tutorial.

Fase 7: creazione di un ruolo di esecuzione dell'attività personalizzata

Amazon ECS può utilizzare un ruolo IAM diverso per le autorizzazioni necessarie all'avvio di ogni attività, anziché il ruolo dell'istanza di container. Questo ruolo è il ruolo di esecuzione dell'attività. Ti consigliamo di creare un ruolo di esecuzione dell'attività con le sole autorizzazioni necessarie per l'esecuzione dell'attività da parte di ECS, note anche come autorizzazioni con privilegi minimi. Per ulteriori informazioni sul principio del privilegio minimo, consulta SEC03-BP02 Concessione dell'accesso con privilegio minimo nel Framework AWS Well-Architected.

  1. Per creare un ruolo di esecuzione dell'attività, consulta Creazione del ruolo di esecuzione attività. Le autorizzazioni predefinite consentono all'istanza del contenitore di estrarre le immagini dei contenitori da Amazon Elastic Container Registry stdout e stderr dalle tue applicazioni per registrarle su Amazon CloudWatch Logs.

    Poiché il ruolo richiede autorizzazioni personalizzate per questo tutorial, puoi assegnare al ruolo un nome diverso da ecsTaskExecutionRole. Questo tutorial utilizza ecsTaskExecutionRole nelle fasi successive.

  2. Aggiungi le seguenti autorizzazioni creando una policy personalizzata, una policy in linea che esiste solo per questo ruolo o una policy che puoi riutilizzare. Sostituisci l'ARN della Resource nella prima istruzione con il bucket e la posizione di Amazon S3 e la seconda Resource con l'ARN del segreto in Secrets Manager.

    Se esegui la crittografa del segreto in Secrets Manager con una chiave personalizzata, devi consentire anche kms:Decrypt per la chiave.

    Se al posto di Secrets Manager utilizzi l'archivio parametri SSM, devi consentire ssm:GetParameter per il parametro, anziché secretsmanager:GetSecretValue.

    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject" ], "Resource": "arn:aws:s3:::MyBucket/ecs-domainless-gmsa-credspec/gmsa-cred-spec.json" }, { "Effect": "Allow", "Action": [ "secretsmanager:GetSecretValue" ], "Resource": "arn:aws:secretsmanager:aws-region:111122223333:secret:gmsa-plugin-input" } ] }

Fase 8: creazione di un ruolo dell'attività per Amazon ECS Exec

Questo tutorial utilizza Amazon ECS Exec per verificare la funzionalità eseguendo un comando all'interno di un'attività in esecuzione. Per utilizzare ECS Exec, è necessario attivare ECS Exec nel servizio o nell'attività. Inoltre, il ruolo dell'attività (non il ruolo di esecuzione dell'attività) deve disporre delle autorizzazioni ssmmessages. Per informazioni sulla policy IAM richiesta, consulta Autorizzazioni ECS Exec.

Questo passaggio utilizza il. AWS CLI Puoi eseguire questi comandi in AWS CloudShell nella shell (interprete di comandi) predefinita, ovvero bash.

Per creare un ruolo di attività utilizzando il AWS CLI, procedi nel seguente modo.

  1. Crea un file denominato ecs-tasks-trust-policy.json con i seguenti contenuti:

    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "ecs-tasks.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }
  2. Crea un ruolo IAM. Puoi sostituire il nome ecs-exec-demo-task-role ma mantenerlo per i passaggi successivi.

    Il comando seguente utilizza i caratteri di continuazione (barra rovesciata) utilizzati da sh e dalle shell compatibili. Questo comando non è compatibile con PowerShell. È necessario modificare il comando con cui utilizzarlo PowerShell.

    $ aws iam create-role --role-name ecs-exec-demo-task-role \ --assume-role-policy-document file://ecs-tasks-trust-policy.json

    Puoi eliminare il file ecs-tasks-trust-policy.json.

  3. Crea un file denominato ecs-exec-demo-task-role-policy.json con i seguenti contenuti:

    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ssmmessages:CreateControlChannel", "ssmmessages:CreateDataChannel", "ssmmessages:OpenControlChannel", "ssmmessages:OpenDataChannel" ], "Resource": "*" } ] }
  4. Crea una policy IAM e collegala al ruolo della fase precedente.

    Il comando seguente utilizza i caratteri di continuazione (barra rovesciata) utilizzati da sh e dalle shell compatibili. Questo comando non è compatibile con PowerShell. È necessario modificare il comando con cui utilizzarlo PowerShell.

    $ aws iam put-role-policy \ --role-name ecs-exec-demo-task-role \ --policy-name ecs-exec-demo-task-role-policy \ --policy-document file://ecs-exec-demo-task-role-policy.json

    Puoi eliminare il file ecs-exec-demo-task-role-policy.json.

Fase 9: registrazione di una definizione di attività che utilizza gMSA senza dominio

Questo passaggio utilizza il AWS CLI. Puoi eseguire questi comandi in AWS CloudShell nella shell (interprete di comandi) predefinita, ovvero bash.

  1. Crea un file denominato windows-gmsa-domainless-task-def.json con i seguenti contenuti:

    { "family": "windows-gmsa-domainless-task", "containerDefinitions": [ { "name": "windows_sample_app", "image": "mcr.microsoft.com/windows/servercore/iis", "cpu": 1024, "memory": 1024, "essential": true, "credentialSpecs": [ "credentialspecdomainless:arn:aws:s3:::ecs-domainless-gmsa-credspec/gmsa-cred-spec.json" ], "entryPoint": [ "powershell", "-Command" ], "command": [ "New-Item -Path C:\\inetpub\\wwwroot\\index.html -ItemType file -Value '<html> <head> <title>Amazon ECS Sample App</title> <style>body {margin-top: 40px; background-color: #333;} </style> </head><body> <div style=color:white;text-align:center> <h1>Amazon ECS Sample App</h1> <h2>Congratulations!</h2> <p>Your application is now running on a container in Amazon ECS.</p>' -Force ; C:\\ServiceMonitor.exe w3svc" ], "portMappings": [ { "protocol": "tcp", "containerPort": 80, "hostPort": 8080 } ] } ], "taskRoleArn": "arn:aws:iam::111122223333:role/ecs-exec-demo-task-role", "executionRoleArn": "arn:aws:iam::111122223333:role/ecsTaskExecutionRole" }
  2. Registra la definizione di attività con il comando seguente:

    Il comando seguente utilizza i caratteri di continuazione (barra rovesciata) utilizzati da sh e dalle shell compatibili. Questo comando non è compatibile con PowerShell. È necessario modificare il comando con cui utilizzarlo PowerShell.

    $ aws ecs register-task-definition \ --cli-input-json file://windows-gmsa-domainless-task-def.json

Fase 10: registrazione di un'istanza di container Windows nel cluster

Avvia un'istanza Windows di Amazon EC2 ed esegui l'agente di container ECS per registrarla come istanza di container nel cluster. ECS esegue le attività sulle istanze di container registrate nel cluster in cui vengono avviate le attività.

  1. Per avviare un'istanza Windows di Amazon EC2 configurata per Amazon ECS in, consulta AWS Management Console. Avvio di un'istanza di container Windows di Amazon ECS Fermati alla fase relativa ai dati utente.

  2. Per quanto riguarda gMSA, i dati utente devono impostare la variabile di ambiente ECS_GMSA_SUPPORTED prima di avviare l'agente del container ECS.

    Per ECS Exec, l'agente deve iniziare con l'argomento -EnableTaskIAMRole.

    Per proteggere il ruolo IAM dell'istanza impedendo alle attività di raggiungere il servizio Web IMDS EC2 al fine di recuperare le credenziali del ruolo, aggiungi l'argomento -AwsvpcBlockIMDS. Ciò si applica solo alle attività che utilizzano la modalità di rete awsvpc.

    <powershell> [Environment]::SetEnvironmentVariable("ECS_GMSA_SUPPORTED", $TRUE, "Machine") Import-Module ECSTools Initialize-ECSAgent -Cluster windows-domainless-gmsa-cluster -EnableTaskIAMRole -AwsvpcBlockIMDS </powershell>
  3. Analizza un riepilogo della configurazione dell'istanza nel pannello Summary (Riepilogo) e, quando è tutto pronto, scegli Launch instance (Avvia istanza).

Fase 11: verifica dell'istanza di container

Puoi verificare la presenza di un'istanza di container nel cluster utilizzando la AWS Management Console. Tuttavia, gMSA necessita di funzionalità aggiuntive indicate come attributi. Questi attributi non sono visibili in AWS Management Console, quindi questo tutorial utilizza il. AWS CLI

Questo passaggio utilizza il AWS CLI. Puoi eseguire questi comandi in AWS CloudShell nella shell (interprete di comandi) predefinita, ovvero bash.

  1. Elenca le istanze di container nel cluster. Le istanze di container hanno un ID diverso dall'ID dell'istanza EC2.

    $ aws ecs list-container-instances

    Output:

    {
        "containerInstanceArns": [
            "arn:aws:ecs:aws-region:111122223333:container-instance/default/MyContainerInstanceID"
        ]
    }

    Ad esempio, 526bd5d0ced448a788768334e79010fd è un ID di istanza di container valido.

  2. Utilizza l'ID istanza di container della fase precedente per informazioni dettagliate sull'istanza di container. Sostituisci MyContainerInstanceID con l'ID.

    Il comando seguente utilizza i caratteri di continuazione (barra rovesciata) utilizzati da sh e dalle shell compatibili. Questo comando non è compatibile con PowerShell. È necessario modificare il comando con cui utilizzarlo PowerShell.

    $ aws ecs describe-container-instances \ ----container-instances MyContainerInstanceID

    Nota che l'output è molto lungo.

  3. Verifica che l'elenco attributes contenga un oggetto con la chiave denominata name e un valore ecs.capability.gmsa-domainless. Di seguito è mostrato un esempio dell'oggetto.

    Output:

    {
        "name": "ecs.capability.gmsa-domainless"
    }

Fase 12: esecuzione di un'attività di Windows

Esegui un'attività Amazon ECS. Se nel cluster è presente una sola istanza di container, puoi utilizzare run-task. Se sono presenti molte istanze di container diverse, potrebbe essere più semplice utilizzare start-task e specificare l'ID dell'istanza di container su cui eseguire l'attività piuttosto che aggiungere vincoli di posizionamento alla definizione di attività per controllare il tipo di istanza su cui eseguire l'attività.

Questo passaggio utilizza il AWS CLI. Puoi eseguire questi comandi in AWS CloudShell nella shell (interprete di comandi) predefinita, ovvero bash.

  1. Il comando seguente utilizza i caratteri di continuazione (barra rovesciata) utilizzati da sh e dalle shell compatibili. Questo comando non è compatibile con PowerShell. È necessario modificare il comando con cui utilizzarlo PowerShell.

    aws ecs run-task --task-definition windows-gmsa-domainless-task \ --enable-execute-command --cluster windows-domainless-gmsa-cluster

    Prendi nota dell'ID attività restituito dal comando.

  2. Esegui il comando seguente per verificare che l'attività sia stata avviata. Questo comando resta in attesa e non restituisce il prompt della shell (interprete di comandi) fino all'avvio dell'attività. Sostituisci MyTaskID con l'ID attività ottenuto nella fase precedente.

    $ aws ecs wait tasks-running --task MyTaskID

Fase 13: verifica che il container disponga delle credenziali gMSA

Verifica che il container dell'attività abbia un token Kerberos. gMSA

Questo passaggio utilizza il AWS CLI. Puoi eseguire questi comandi in AWS CloudShell nella shell (interprete di comandi) predefinita, ovvero bash.

  1. Il comando seguente utilizza i caratteri di continuazione (barra rovesciata) utilizzati da sh e dalle shell compatibili. Questo comando non è compatibile con PowerShell. È necessario modificare il comando con cui utilizzarlo PowerShell.

    $ aws ecs execute-command \ --task MyTaskID \ --container windows_sample_app \ --interactive \ --command powershell.exe

    L'output sarà un PowerShell prompt.

  2. Esegui il seguente comando nel PowerShell terminale all'interno del contenitore.

    PS C:\> klist get ExampleAccount$

    Tieni presente che il Principal presente nell'output è uguale a quello creato in precedenza.

Fase 14: pulizia

Una volta terminato questo tutorial, è necessario eliminare le risorse associate per evitare costi aggiuntivi per le risorse non utilizzate.

Questo passaggio utilizza il AWS CLI. Puoi eseguire questi comandi in AWS CloudShell nella shell (interprete di comandi) predefinita, ovvero bash.

  1. Interrompi l'attività. Sostituisci MyTaskID con l'ID attività della fase 12, Fase 12: esecuzione di un'attività di Windows.

    $ aws ecs stop-task --task MyTaskID
  2. Termina l'istanza Amazon EC2. Successivamente, l'istanza di container nel cluster verrà eliminata automaticamente dopo un'ora.

    Puoi individuare e terminare l'istanza mediante la console Amazon EC2 o puoi eseguire il comando seguente. Per eseguire il comando, trova l'ID dell'istanza EC2 nell'output del comando aws ecs describe-container-instances della fase 1, Fase 11: verifica dell'istanza di container .i-10a64379è un esempio di ID dell'istanza EC2.

    $ aws ec2 terminate-instances --instance-ids MyInstanceID
  3. Elimina il file CredSpec in Amazon S3. Sostituisci MyBucket con il nome del bucket Amazon S3.

    $ aws s3api delete-object --bucket MyBucket --key ecs-domainless-gmsa-credspec/gmsa-cred-spec.json
  4. Elimina il segreto da Secrets Manager. Se invece hai utilizzato l'archivio parametri SSM, elimina il parametro.

    Il comando seguente utilizza i caratteri di continuazione (barra rovesciata) utilizzati da sh e dalle shell compatibili. Questo comando non è compatibile con PowerShell. È necessario modificare il comando con cui utilizzarlo PowerShell.

    $ aws secretsmanager delete-secret --secret-id gmsa-plugin-input \ --force-delete-without-recovery
  5. Annulla la registrazione della definizione di attività ed eliminala. Dopo aver annullato la registrazione, la definizione di attività viene contrassegnata come inattiva, in modo che non possa essere utilizzata per avviare nuove attività. Puoi quindi eliminare la definizione di attività.

    1. Annulla la registrazione della definizione di attività specificando la versione. ECS crea automaticamente delle versioni delle definizioni di attività, numerate a partire da 1. Fai riferimento alle versioni nello stesso formato delle etichette sulle immagini di container, ad esempio :1.

      $ aws ecs deregister-task-definition --task-definition windows-gmsa-domainless-task:1
    2. Elimina la definizione di attività.

      $ aws ecs delete-task-definitions --task-definition windows-gmsa-domainless-task:1
  6. (Facoltativo) Elimina il cluster ECS, se ne hai creato uno.

    $ aws ecs delete-cluster --cluster windows-domainless-gmsa-cluster

Debug di gMSA senza dominio in Amazon ECS per i container Windows

Stato dell'attività di Amazon ECS

ECS tenta di avviare esattamente un'attività una volta. Se un'attività presenza un problema, viene interrotta e impostata nello stato STOPPED. Esistono due tipi comuni di problemi relativi alle attività. Innanzitutto, le attività che non possono essere avviate. In secondo luogo, le attività in cui l'applicazione si è interrotta all'interno di uno dei container. Nel campo Motivo interrotto dell'attività AWS Management Console, esamina il motivo per cui l'attività è stata interrotta. Nella AWS CLI, descrivi l'attività e osserva il campo stoppedReason. Per i passaggi da seguire AWS CLI, consultaVisualizzazione degli errori delle attività interrotte da Amazon ECS. AWS Management Console

Eventi Windows

Gli eventi di Windows per gMSA nei container vengono registrati nel file di log Microsoft-Windows-Containers-CCG e sono disponibili all'interno del Visualizzatore eventi nella sezione Applicazioni e servizi in Logs\Microsoft\Windows\Containers-CCG\Admin. Per ulteriori suggerimenti sul debug, consulta Risoluzione dei problemi relativi ai gMSA per i container Windows nel sito Web Microsoft Learn.

Plug-in gMSA per l'agente ECS

La registrazione del plug-in gMSA per l'agente ECS sull'istanza di container Windows si trova nella seguente directory, C:/ProgramData/Amazon/gmsa-plugin/. Verifica all'interno del log se le credenziali utente senza dominio sono state scaricate dalla posizione di archiviazione, ad esempio Secrets Manager, e se il formato delle credenziali è stato letto correttamente.