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 del gMSA per container EC2 Linux su Amazon ECS Amazon ECS supporta l'autenticazione di Active Directory per i container Linux su EC2 tramite un tipo speciale di account di servizio chiamato *account di servizio gestito del gruppo* (gMSA). Le applicazioni di rete basate su Linux, ad esempio le applicazioni .NET Core, possono utilizzare Active Directory per facilitare l'autenticazione e la gestione delle autorizzazioni tra utenti e servizi. Puoi utilizzare questa funzionalità progettando applicazioni che si integrano con Active Directory e vengono eseguite su server aggiunti al dominio. Tuttavia, poiché i container Linux non possono essere aggiunti a un dominio, è necessario configurare un container Linux da eseguire con gMSA. Un container Linux che viene eseguito con gMSA si basa sul daemon `credentials-fetcher` che viene eseguito sull'istanza Amazon EC2 host del container. Quindi, il daemon recupera le credenziali gMSA dal controller di dominio Active Directory e successivamente le trasferisce all'istanza di container. Per ulteriori informazioni sugli account di servizio, consulta [Crea gMSAs per i container Windows](https://learn.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/manage-serviceaccounts) nel sito Web Microsoft Learn. ## Considerazioni Prima di utilizzare gMSA per i container Linux, valuta quanto segue: + Se i container vengono eseguiti su EC2, puoi utilizzare gMSA per i container Windows e Linux. Per informazioni su come utilizzare il gMSA per container Linux su Fargate, consultare [Utilizzo del gMSA per i container Linux su Fargate](fargate-linux-gmsa.md). + Potrebbe essere necessario un computer Windows aggiunto al dominio per completare i prerequisiti. Ad esempio, potresti aver bisogno di un computer Windows aggiunto al dominio per creare gMSA in Active Directory con PowerShell. Gli PowerShell strumenti RSAT Active Director sono disponibili solo perWindows. Per ulteriori informazioni, consulta [Installazione degli strumenti di amministrazione Active Directory](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_install_ad_tools.html). + 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. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/linux-gmsa.html) ## Prerequisiti Prima di utilizzare la funzionalità gMSA per container Linux con Amazon ECS, assicurati di completare le seguenti operazioni: + Configura un dominio Active Directory con le risorse a cui desideri che i tuoi container accedano. Amazon ECS supporta le configurazioni seguenti: + Un Directory Service Active Directory. 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.html). + Disponi di un account gMSA nell'Active Directory. Per ulteriori informazioni, consulta [Utilizzo del gMSA per container EC2 Linux su Amazon ECS](#linux-gmsa). + Hai installato e stai eseguendo il daemon `credentials-fetcher` su un'istanza di container Amazon ECS Linux. Inoltre, hai aggiunto un set iniziale di credenziali al daemon `credentials-fetcher` per l'autenticazione con Active Directory. **Nota** Il daemon `credentials-fetcher` è disponibile solo per Amazon Linux 2023 e Fedora 37 e versioni successive. Il daemon non è disponibile per Amazon Linux 2. Per ulteriori informazioni, consulta [aws/credentials-fetcher](https://github.com/aws/credentials-fetcher) su. GitHub + Configuri le credenziali per l'autenticazione del daemon `credentials-fetcher` con Active Directory. Le credenziali devono essere membri del gruppo di sicurezza di Active Directory che ha accesso all'account gMSA. Sono disponibili diverse opzioni in [Decidi se aggiungere le istanze al dominio o utilizzare gMSA senza dominio.](#linux-gmsa-initial-creds). + Hai aggiunto le autorizzazioni IAM richieste. Le autorizzazioni richieste dipendono dai metodi scelti per le credenziali iniziali e per l'archiviazione della specifica delle credenziali: + Se utilizzi *domainless gMSA* per le credenziali iniziali, sono necessarie le autorizzazioni IAM per il ruolo di esecuzione dell'attività. Gestione dei segreti AWS + Se archivi la specifica delle credenziali nell'archivio dei parametri SSM, le autorizzazioni IAM per l'archivio dei parametri Systems Manager per Amazon EC2 sono necessarie per il ruolo di esecuzione dell'attività. + Se archivi la specifica delle credenziali in Amazon S3, le autorizzazioni IAM per Amazon Simple Storage Service sono necessarie per il ruolo di esecuzione delle attività. ## Configurazione di container Linux compatibili con gMSA in Amazon ECS **Preparazione dell'infrastruttura** I passaggi seguenti sono considerazioni e configurazioni che vengono eseguite una sola volta. Dopo aver completato questi passaggi, puoi automatizzare la creazione delle istanze di container per riutilizzare questa configurazione. Decidi come fornire le credenziali iniziali e configura i dati utente EC2 in un modello di avvio EC2 riutilizzabile per installare il daemon `credentials-fetcher`. 1. **Decidi se aggiungere le istanze al dominio o utilizzare gMSA senza dominio.** + **Aggiunta di istanze EC2 al dominio di Active Directory** + **Aggiunta delle istanze in base ai dati dell'utente** Completa i passaggi per aggiungere il dominio Active Directory ai dati utente EC2 in un modello di avvio EC2. Più gruppi con Amazon EC2 Auto Scaling possono utilizzare lo stesso modello di avvio. Puoi utilizzare questi passaggi [Aggiunta di un Active Directory o a un dominio FreeIPA](https://docs.fedoraproject.org/en-US/quick-docs/join-active-directory-freeipa/) in Fedora Docs. + **Creazione di un utente Active Directory per gMSA senza dominio** Il daemon `credentials-fetcher` ha una funzionalità chiamata *gMSA senza dominio*. Questa funzionalità richiede un dominio, ma l'istanza EC2 non deve essere aggiunta al 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. Al contrario, fornisci il nome di un segreto in Gestione dei segreti AWS nel file CredSpec. Il segreto deve contenere un nome utente, una password e un dominio a cui accedere. Questa funzionalità è supportata e può essere utilizzata con container Linux e Windows. Questa funzionalità è simile alla funzionalità *gMSA support for non-domain-joined container hosts*. Per ulteriori informazioni sulla funzionalità di Windows, consulta [Architettura e miglioramenti di gMSA](https://learn.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/manage-serviceaccounts#gmsa-architecture-and-improvements) sul sito Web Microsoft Learn. 1. Crea un utente nel dominio di Active Directory. L'utente di Active Directory deve disporre dell'autorizzazione per accedere agli account del servizio di gMSA utilizzati nelle attività. 1. Crea un account segreto Gestione dei segreti AWS, dopo aver creato l'utente in Active Directory. Per ulteriori informazioni, consulta [Creare un Gestione dei segreti AWS segreto](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html). 1. Inserisci il nome utente, la password e il dominio dell'utente nelle coppie chiave-valore JSON denominate rispettivamente `username`, `password` e `domainName`. ``` {"username":"username","password":"passw0rd", "domainName":"example.com"} ``` 1. Aggiungi la configurazione al file CredSpec per l'account del servizio. Il `HostAccountConfig` aggiuntivo contiene il nome della risorsa Amazon (ARN) del segreto in Secrets Manager. In Windows, `PluginGUID` deve corrispondere al GUID nel seguente frammento di codice esemplificativo. In Linux, `PluginGUID` viene ignorato. Sostituisci `MySecret` con l'esempio del nome della risorsa Amazon (ARN) del segreto. ``` "ActiveDirectoryConfig": { "HostAccountConfig": { "PortableCcgVersion": "1", "PluginGUID": "{859E1386-BDB4-49E8-85C7-3070B13920E1}", "PluginInput": { "CredentialArn": "arn:aws:secretsmanager:aws-region:111122223333:secret:MySecret" } } ``` 1. La funzionalità *gMSA senza dominio* richiede autorizzazioni aggiuntive nel ruolo di esecuzione dell'attività. Segui il passaggio [(Facoltativo) segreto gMSA senza dominio](#linux-gmsa-domainless-secret). 1. **Configurazione delle istanze e installazione del daemon `credentials-fetcher`** Puoi installare il daemon `credentials-fetcher` con uno script di dati utente nel tuo modello di avvio Amazon EC2. Gli esempi seguenti mostrano due tipi di dati utente, `cloud-config` YAML o lo script bash. Questi esempi sono per Amazon Linux 2023 (AL2023). Sostituisci `MyCluster` con il nome del cluster Amazon ECS a cui desideri che si aggiungano queste istanze. + **`cloud-config` YAML** ``` Content-Type: text/cloud-config package_reboot_if_required: true packages: # prerequisites - dotnet - realmd - oddjob - oddjob-mkhomedir - sssd - adcli - krb5-workstation - samba-common-tools # https://github.com/aws/credentials-fetcher gMSA credentials management for containers - credentials-fetcher write_files: # configure the ECS Agent to join your cluster. # replace MyCluster with the name of your cluster. - path: /etc/ecs/ecs.config owner: root:root permissions: '0644' content: | ECS_CLUSTER=MyCluster ECS_GMSA_SUPPORTED=true runcmd: # start the credentials-fetcher daemon and if it succeeded, make it start after every reboot - "systemctl start credentials-fetcher" - "systemctl is-active credentials-fetcher && systemctl enable credentials-fetcher" ``` + **Script bash** Se hai più dimestichezza con gli script bash e disponi di più variabili da scrivere per `/etc/ecs/ecs.config`, utilizza il seguente formato `heredoc`. Questo formato scrive tutti gli elementi nel file di configurazione, inserendoli tra le righe **cat** ed `EOF`. ``` #!/usr/bin/env bash set -euxo pipefail # prerequisites timeout 30 dnf install -y dotnet realmd oddjob oddjob-mkhomedir sssd adcli krb5-workstation samba-common-tools # install https://github.com/aws/credentials-fetcher gMSA credentials management for containers timeout 30 dnf install -y credentials-fetcher # start credentials-fetcher systemctl start credentials-fetcher systemctl is-active credentials-fetcher && systemctl enable credentials-fetcher cat <<'EOF' >> /etc/ecs/ecs.config ECS_CLUSTER=MyCluster ECS_GMSA_SUPPORTED=true EOF ``` Esistono variabili di configurazione opzionali per il daemon `credentials-fetcher` che puoi impostare in `/etc/ecs/ecs.config`. Consigliamo di impostare le variabili nei dati utente nel blocco YAML o `heredoc` in modo simile agli esempi precedenti. In questo modo si evitano problemi di configurazione parziale che possono verificarsi quando si modifica un file più volte. Per ulteriori informazioni sulla configurazione dell'agente ECS, consulta [Amazon ECS Container Agent on.](https://github.com/aws/amazon-ecs-agent/blob/master/README.md#environment-variables) GitHub + Facoltativamente, puoi utilizzare la variabile `CREDENTIALS_FETCHER_HOST` se modifichi la configurazione del daemon `credentials-fetcher` per spostare il socket in un'altra posizione. **Configurazione di autorizzazioni e segreti** Esegui i passaggi seguenti una volta per ogni applicazione e ogni definizione dell'attività. Consigliamo di utilizzare la best practice di concedere il privilegio minimo e limitare le autorizzazioni utilizzate nella policy. In questo modo, ogni attività può leggere solo i segreti di cui ha bisogno. 1. **(Facoltativo) segreto gMSA senza dominio** Se utilizzi il metodo senza dominio in cui l'istanza non è aggiunta al dominio, segui questo passaggio. Inoltre, devi aggiungere le autorizzazioni seguenti come policy inline al ruolo di esecuzione dell'attività del ruolo IAM. In questo modo il daemon `credentials-fetcher` accede al segreto di Secrets Manager. Sostituisci l'esempio `MySecret` con il nome della risorsa Amazon (ARN) del segreto nell'elenco `Resource`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "secretsmanager:GetSecretValue" ], "Resource": "arn:aws:secretsmanager:us-east-1:123456789012:secret:my-secret-AbCdEf" } ] } ``` ------ **Nota** Se utilizzi la tua chiave KMS per crittografare il tuo segreto, devi aggiungere le autorizzazioni necessarie a questo ruolo e aggiungere questo ruolo alla policy chiave. AWS KMS 1. **Decidere se utilizzare SSM Parameter Store o S3 per archiviare il CredSpec** Amazon ECS supporta i seguenti modi per fare riferimento al percorso del file nel campo `credentialSpecs` di una definizione di attività. Se unisci le istanze a un singolo dominio, utilizza il prefisso `credentialspec:` all'inizio dell'ARN nella stringa. Se utilizzi gMSA senza dominio, usa `credentialspecdomainless:`. Per ulteriori informazioni su CredSpec, consulta [File di specifica delle credenziali](#linux-gmsa-credentialspec). + **Bucket Amazon S3** Aggiungi le specifiche delle credenziali a un bucket Amazon S3. Quindi, fai riferimento al nome della risorsa Amazon (ARN) del bucket Amazon S3 nel campo `credentialSpecs` della definizione di attività. ``` { "family": "", "executionRoleArn": "", "containerDefinitions": [ { "name": "", ... "credentialSpecs": [ "credentialspecdomainless:arn:aws:s3:::${BucketName}/${ObjectName}" ], ... } ], ... } ``` Devi aggiungere le seguenti autorizzazioni come policy inline al ruolo IAM di esecuzione delle attività Amazon ECS per consentire alle attività l'accesso al bucket Amazon S3. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "VisualEditor", "Effect": "Allow", "Action": [ "s3:Get*", "s3:List*" ], "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket", "arn:aws:s3:::amzn-s3-demo-bucket/{object}" ] } ] } ``` ------ + **Parametro dell'archivio parametri di SSM** Aggiungi la specifica delle credenziali a un parametro SSM Parameter Store. Quindi, fai riferimento al nome della risorsa Amazon (ARN) del parametro SSM Parameter Store nel campo `credentialSpecs` della definizione delle attività. ``` { "family": "", "executionRoleArn": "", "containerDefinitions": [ { "name": "", ... "credentialSpecs": [ "credentialspecdomainless:arn:aws:ssm:aws-region:111122223333:parameter/parameter_name" ], ... } ], ... } ``` Aggiungi le seguenti autorizzazioni come policy inline al ruolo IAM di esecuzione delle attività Amazon ECS per consentire alle attività l'accesso al parametro SSM Parameter Store. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ssm:GetParameters" ], "Resource": "arn:aws:ssm:us-east-1:123456789012:parameter/my-parameter" } ] } ``` ------ ## File di specifica delle credenziali 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 Linux. Genera il file CredSpec e fai riferimento a esso nel campo `credentialSpecs` della definizione delle attività. Il file CredSpec non contiene segreti. Di seguito è riportato un esempio del file CredSpec. ``` { "CmsPlugins": [ "ActiveDirectory" ], "DomainJoinConfig": { "Sid": "S-1-5-21-2554468230-2647958158-2204241789", "MachineAccountName": "WebApp01", "Guid": "8665abd4-e947-4dd0-9a51-f8254943c90b", "DnsTreeName": "example.com", "DnsName": "example.com", "NetBiosName": "example" }, "ActiveDirectoryConfig": { "GroupManagedServiceAccounts": [ { "Name": "WebApp01", "Scope": "example.com" } ], "HostAccountConfig": { "PortableCcgVersion": "1", "PluginGUID": "{859E1386-BDB4-49E8-85C7-3070B13920E1}", "PluginInput": { "CredentialArn": "arn:aws:secretsmanager:aws-region:111122223333:secret:MySecret" } } } } ``` **Creazione di una CredSpec** Crea un file CredSpec utilizzando il modulo PowerShell CredSpec su un computer Windows che fa parte del dominio. Segui i passaggi descritti in [Creazione di una specifica delle credenziali](https://learn.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/manage-serviceaccounts#create-a-credential-spec) sul sito Web Microsoft Learn.