

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 senza dominio gMSA utilizzando AWS CLI
<a name="tutorial-gmsa-windows"></a>

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.

**Topics**
+ [Prerequisiti](#tutorial-gmsa-windows-prerequisites)
+ [Fase 1: creazione e configurazione dell'account gMSA su Active Directory Domain Services (AD DS)](#tutorial-gmsa-windows-step1)
+ [Fase 2: caricamento delle credenziali in Secrets Manager](#tutorial-gmsa-windows-step2)
+ [Fase3: modifica del codice JSON CredSpec per includere informazioni relative a gMSA senza dominio](#tutorial-gmsa-windows-step3)
+ [Fase 4: caricamento di CredSpec su Amazon S3](#tutorial-gmsa-windows-step4)
+ [Fase 5: creazione di un cluster Amazon ECS (facoltativo)](#tutorial-gmsa-windows-step5)
+ [Fase 6: creazione di un ruolo IAM per le istanze di container](#tutorial-gmsa-windows-step6)
+ [Fase 7: creazione di un ruolo di esecuzione dell'attività personalizzata](#tutorial-gmsa-windows-step7)
+ [Fase 8: creazione di un ruolo dell'attività per Amazon ECS Exec](#tutorial-gmsa-windows-step8)
+ [Fase 9: registrazione di una definizione di attività che utilizza gMSA senza dominio](#tutorial-gmsa-windows-step9)
+ [Fase 10: registrazione di un'istanza di container Windows nel cluster](#tutorial-gmsa-windows-step10)
+ [Fase 11: verifica dell'istanza di container](#tutorial-gmsa-windows-step11)
+ [Fase 12: esecuzione di un'attività di Windows](#tutorial-gmsa-windows-step12)
+ [Fase 13: verifica che il container disponga delle credenziali gMSA](#tutorial-gmsa-windows-step13)
+ [Fase 14: pulizia](#tutorial-gmsa-windows-step14)
+ [Debug di gMSA senza dominio in Amazon ECS per i container Windows](#tutorial-gmsa-windows-debugging)

## Prerequisiti
<a name="tutorial-gmsa-windows-prerequisites"></a>

Questo tutorial presuppone che siano stati soddisfatti i prerequisiti seguenti:
+ Hai completato le fasi descritte in [Configurazione per l'uso di Amazon ECS](get-set-up-for-amazon-ecs.md).
+ L'utente IAM ha le autorizzazioni necessarie specificate nell'esempio di policy IAM [AmazonECS\$1 FullAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-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](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) di. AWS Command Line Interface
**Nota**  
Puoi utilizzare gli endpoint del servizio dual-stack per interagire con Amazon ECS da AWS CLI, SDKs e l'API Amazon ECS su entrambi e. IPv4 IPv6 Per ulteriori informazioni, consulta [Utilizzo degli endpoint dual-stack Amazon ECS](dual-stack-endpoint.md).
+ Configura un dominio Active Directory con le risorse a cui desideri che i tuoi container accedano. Amazon ECS supporta le configurazioni seguenti:
  + Un Active Directory. Directory Service Directory Service è un Active Directory AWS gestito ospitato su Amazon EC2. Per ulteriori informazioni, vedere Guida [introduttiva a AWS Managed Microsoft AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_getting_started.html) nella *Guida all'AWS Directory Service amministrazione*.
  + Una Active Directory on-premises. Devi assicurarti che l'istanza di container Linux di Amazon ECS possa essere aggiunta al dominio. Per ulteriori informazioni, consulta [AWS Direct Connect](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/aws-direct-connect-network-to-amazon.html).
+ 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.    
<a name="gmsa-table"></a>[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/tutorial-gmsa-windows.html)
+ (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](https://docs.aws.amazon.com/cloudshell/latest/userguide/welcome.html) nella *Guida AWS CloudShell per l'utente*.

## Fase 1: creazione e configurazione dell'account gMSA su Active Directory Domain Services (AD DS)
<a name="tutorial-gmsa-windows-step1"></a>

Crea e configura un account gMSA nel dominio Active Directory.

**Nota**  
Questa fase crea due account separati: un account di servizio gestito del gruppo (gMSA) che fornisce l'identità per i container e un account utente normale utilizzato per l'autenticazione del dominio. Questi account hanno scopi diversi e devono avere nomi diversi.

1. 

**Genera una chiave principale del servizio di distribuzione delle chiavi**
**Nota**  
Se lo stai utilizzando 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](https://learn.microsoft.com/en-us/powershell/module/activedirectory/?view=windowsserver2022-ps) 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.

1. 

**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. Sostituire `ExampleAccount` con il nome desiderato per l'account gMSA e sostituire `example-domain` con il nome del dominio Active Directory (ad esempio, se il dominio è `contoso.com`, utilizzare `contoso`).

   1. 

      ```
      PS C:\> Install-WindowsFeature RSAT-AD-PowerShell
      ```

   1. 

      ```
      PS C:\> New-ADGroup -Name "ExampleAccount Authorized Hosts" -SamAccountName "ExampleAccountHosts" -GroupScope DomainLocal
      ```

   1. 

      ```
      PS C:\> New-ADServiceAccount -Name "ExampleAccount" -DnsHostName "example-domain" -ServicePrincipalNames "host/ExampleAccount", "host/example-domain" -PrincipalsAllowedToRetrieveManagedPassword "ExampleAccountHosts"
      ```

   1. Crea un utente con una password permanente senza scadenza. Queste credenziali vengono archiviate Gestione dei segreti AWS e utilizzate da ogni attività per accedere al dominio. Si tratta di un account utente separato dall'account gMSA creato in precedenza. Sostituire `ExampleServiceUser` con il nome desiderato per questo account utente di servizio.

      ```
      PS C:\> New-ADUser -Name "ExampleServiceUser" -AccountPassword (ConvertTo-SecureString -AsPlainText "Test123" -Force) -Enabled 1 -PasswordNeverExpires 1
      ```

   1. 

      ```
      PS C:\> Add-ADGroupMember -Identity "ExampleAccountHosts" -Members "ExampleServiceUser"
      ```

   1. 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
      ```

   1. 

      ```
      PS C:\> New-CredentialSpec -AccountName ExampleAccount
      ```

1. 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](#tutorial-gmsa-windows-step3).

## Fase 2: caricamento delle credenziali in Secrets Manager
<a name="tutorial-gmsa-windows-step2"></a>

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. Utilizzare il nome dell'account utente di servizio (non il nome dell'account gMSA) come nome utente. Mantieni l'ARN del segreto da utilizzare nella fase successiva, [Fase3: modifica del codice JSON CredSpec per includere informazioni relative a gMSA senza dominio](#tutorial-gmsa-windows-step3)

  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\":\"ExampleServiceUser\",\"password\":\"Test123\",\"domainName\":\"contoso.com\"}"
  ```

## Fase3: modifica del codice JSON CredSpec per includere informazioni relative a gMSA senza dominio
<a name="tutorial-gmsa-windows-step3"></a>

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](https://learn.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/manage-serviceaccounts#additional-credential-spec-configuration-for-non-domain-joined-container-host-use-case) 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\"`.

1. 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": "example-domain",
       "DnsName": "example-domain",
       "NetBiosName": "example-domain"
     },
     "ActiveDirectoryConfig": {
       "GroupManagedServiceAccounts": [
         {
           "Name": "ExampleAccount",
           "Scope": "example-domain"
         },
         {
           "Name": "ExampleAccount",
           "Scope": "example-domain"
         }
       ],
       "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
<a name="tutorial-gmsa-windows-step4"></a>



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 .

1. 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)
<a name="tutorial-gmsa-windows-step5"></a>

Per impostazione predefinita, l'account dispone di un cluster Amazon ECS denominato `default`. Questo cluster viene utilizzato per impostazione predefinita in AWS CLI SDKs, e 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 da Console di gestione AWS AWS CLI, SDKs, o 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
<a name="tutorial-gmsa-windows-step6"></a>

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](instance_IAM_role.md). Il ruolo `ecsInstanceRole` predefinito dispone di autorizzazioni sufficienti per completare questo tutorial.

## Fase 7: creazione di un ruolo di esecuzione dell'attività personalizzata
<a name="tutorial-gmsa-windows-step7"></a>

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, vedere [SEC03- BP02 Garantire l'accesso con il minimo privilegio](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_permissions_least_privileges.html) nel Well-Architected AWS Framework.*

1. Per creare un ruolo di esecuzione dell'attività, consulta [Creazione del ruolo di esecuzione attività](task_execution_IAM_role.md#create-task-execution-role). 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.

1. 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`.

------
#### [ JSON ]

****  

   ```
   {
       "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:us-east-1:111122223333:secret:gmsa-plugin-AbCdEf"
           }
       ]
   }
   ```

------

## Fase 8: creazione di un ruolo dell'attività per Amazon ECS Exec
<a name="tutorial-gmsa-windows-step8"></a>

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 ACS Exec](task-iam-roles.md#ecs-exec-required-iam-permissions).

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, segui questi passaggi.

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

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Effect": "Allow",
               "Principal": {
                   "Service": "ecs-tasks.amazonaws.com"
               },
               "Action": "sts:AssumeRole"
           }
       ]
   }
   ```

------

1. 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`.

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

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Effect": "Allow",
               "Action": [
                   "ssmmessages:CreateControlChannel",
                   "ssmmessages:CreateDataChannel",
                   "ssmmessages:OpenControlChannel",
                   "ssmmessages:OpenDataChannel"
               ],
               "Resource": "*"
           }
       ]
   }
   ```

------

1. 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
<a name="tutorial-gmsa-windows-step9"></a>



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

1. 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
<a name="tutorial-gmsa-windows-step10"></a>

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 Console di gestione AWS. [Avvio di un'istanza di container Windows di Amazon ECS](launch_window-container_instance.md) Fermati alla fase relativa ai *dati utente*.

1. 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>
   ```

1. 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
<a name="tutorial-gmsa-windows-step11"></a>

Puoi verificare la presenza di un'istanza di container nel cluster utilizzando la Console di gestione AWS. Tuttavia, gMSA necessita di funzionalità aggiuntive indicate come *attributi*. Questi attributi non sono visibili in Console di gestione AWS, 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.

1. 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.

1. 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
<a name="tutorial-gmsa-windows-step12"></a>

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.

1. 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
<a name="tutorial-gmsa-windows-step13"></a>

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.

1. 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
<a name="tutorial-gmsa-windows-step14"></a>

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](#tutorial-gmsa-windows-step12).

   ```
   $ aws ecs stop-task --task MyTaskID
   ```

1. 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](#tutorial-gmsa-windows-step11) .i-10a64379è un esempio di ID dell'istanza EC2.

   ```
   $ aws ec2 terminate-instances --instance-ids MyInstanceID
   ```

1. 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
   ```

1. 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
   ```

1. 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
      ```

   1. Elimina la definizione di attività.

      ```
      $ aws ecs delete-task-definitions --task-definition windows-gmsa-domainless-task:1
      ```

1. (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
<a name="tutorial-gmsa-windows-debugging"></a>



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à Console di gestione AWS, 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, consulta[Visualizza gli errori relativi alle attività interrotte in Amazon ECS](stopped-task-errors.md). Console di gestione AWS 

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 contenitori g MSAs for Windows sul](https://learn.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/gmsa-troubleshooting#non-domain-joined-container-hosts-use-event-logs-to-identify-configuration-issues) 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.