Monitora i contenitori Amazon ECS con ECS Exec - Amazon Elastic Container Service
Considerazioni Prerequisiti ArchitetturaUtilizzo di ECS ExecRegistrazione tramite ECS ExecUtilizzo delle policy IAM per limitare l'accesso a ECS Exec

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

Monitora i contenitori Amazon ECS con ECS Exec

Con Amazon ECS Exec, puoi interagire direttamente con i container senza dover prima interagire con il sistema operativo del container host, aprire le porte in entrata o gestire le chiavi SSH. Puoi usare ECS Exec per eseguire comandi o ottenere una shell in un container in esecuzione su un'istanza Amazon EC2 o su AWS Fargate. In questo modo è più semplice raccogliere informazioni diagnostiche e risolvere rapidamente gli errori. Ad esempio, in un contesto di sviluppo, è possibile utilizzare ECS Exec per interagire facilmente con vari processi nei container e risolvere i problemi delle applicazioni. E negli scenari di produzione, puoi usarlo per ottenere un accesso ininterrotto ai contenitori per risolvere i problemi.

Puoi eseguire comandi in un contenitore Linux o Windows in esecuzione utilizzando ECS Exec dall'API Amazon ECS, AWS Command Line Interface (AWS CLI), dagli AWS SDK o dalla CLI di Copilot. AWS Per i dettagli sull'uso di ECS Exec e per una guida video sull'utilizzo della AWS CLI di Copilot, consulta la documentazione di Copilot. GitHub

Puoi anche utilizzare ECS Exec per mantenere politiche di controllo degli accessi più rigorose. Attivando selettivamente questa funzionalità, è possibile controllare chi può eseguire comandi e quali processi possono eseguire tali comandi. Con un registro di ogni comando e del relativo output, puoi usare ECS Exec per visualizzare quali attività sono state eseguite e puoi usarlo per controllare chi ha avuto accesso CloudTrail a un contenitore.

Considerazioni

Per questo argomento, è necessario acquisire familiarità con i seguenti aspetti relativi all'utilizzo di ECS Exec:

  • ECS Exec non è attualmente supportato utilizzando. AWS Management Console

  • ECS Exec è supportato per le attività eseguite sulla seguente infrastruttura:

    • Container Linux su Amazon EC2 su qualsiasi AMI ottimizzata per Amazon ECS, tra cui Bottlerocket

    • Contenitori Linux e Windows su istanze esterne (Amazon ECS Anywhere)

    • Contenitori Linux e Windows su AWS Fargate

    • Container Windows su Amazon EC2 per le seguenti AMI Windows ottimizzate per Amazon ECS (con la versione dell'agente del container 1.56 o successive):

      • AMI Windows Server 2022 Full ottimizzata per Amazon ECS

      • AMI Windows Server 2022 Core ottimizzata per Amazon ECS

      • AMI Windows Server 2019 Full ottimizzata per Amazon ECS

      • AMI Windows Server 2019 Core ottimizzata per Amazon ECS

      • AMI Windows Server 20H2 Core ottimizzata per Amazon ECS

  • ECS Exec e Amazon VPC

  • ECS Exec e SSM

    • Quando un utente esegue comandi su un container utilizzando ECS Exec, questi comandi vengono eseguiti come utente root. SSM Agent e i relativi processi figlio vengono eseguiti come root anche quando si specifica un ID utente per il container.

    • L'agente SSM richiede la possibilità di scrivere sul file system del contenitore per creare le directory e i file richiesti. Pertanto, la specifica del file system root di sola lettura utilizzando il parametro di definizione di attività readonlyRootFilesystem, o qualsiasi altro metodo, non è supportata.

    • Sebbene l'avvio di sessioni di SSM al di fuori dell'operazione execute-command sia possibile, le sessioni non saranno registrate e saranno conteggiate rispetto al limite di sessione. Si consiglia di limitare questo accesso negando l'operazione ssm:start-session con una policy IAM. Per ulteriori informazioni, consulta Limitazione dell'accesso all'operazione Avvia sessione.

  • Le seguenti funzionalità funzionano come contenitore sidecar. Pertanto, è necessario specificare il nome del contenitore su cui eseguire il comando.

    • Monitoraggio del runtime

    • Service Connect

  • Gli utenti possono eseguire tutti i comandi disponibili nel contesto del container. Le seguenti operazioni potrebbero causare processi orfani e zombie: terminare il processo principale del container, terminare l'agente dei comandi ed eliminare le dipendenze. Per ripulire i processi zombie, ti consigliamo di aggiungere il flag initProcessEnabled alla definizione di attività.

  • ECS Exec utilizza parte della CPU e della memoria. Sarà necessario adattare questi valori quando si specificano le allocazioni di risorse CPU e memoria nella definizione di attività.

  • È necessario utilizzare la AWS CLI versione 1.22.3 o successiva o la AWS CLI versione 2.3.6 o successiva. Per informazioni su come aggiornare il AWS CLI, vedere Installazione o aggiornamento della versione più recente di AWS CLI nella Guida per l'AWS Command Line Interface utente versione 2.

  • Puoi avere solo una sessione ECS Exec per ogni spazio dei nomi dell'ID processo (PID). Se condividi uno spazio dei nomi PID in un'attività, puoi avviare le sessioni ECS Exec solo in un container.

  • La sessione di ECS Exec ha un valore di timeout di inattività pari a 20 minuti. Questo valore non può essere modificato.

  • Non è possibile attivare ECS Exec per le attività esistenti. Il servizio può essere attivato solo per le nuove attività.

  • Non è possibile utilizzare ECS Exec quando si avvia un'attività su un cluster che utilizza la scalabilità gestita con posizionamento asincrono (avvia un'attività senza istanza). run-task

  • Non è possibile eseguire ECS Exec su contenitori Microsoft Nano Server.

Prerequisiti

Prima di iniziare a utilizzare ECS Exec, assicurati di aver completato queste azioni:

  • Istalla e configura la AWS CLI. Per ulteriori informazioni, consulta Get started with the. AWS CLI

  • Installa il plug-in Session Manager per AWS CLI. Per ulteriori informazioni, consulta Installazione del plug-in Session Manager per AWS CLI.

  • Devi utilizzare un ruolo attività con le autorizzazioni appropriate per ECS Exec. Per ulteriori informazioni, consulta Ruolo IAM dell'attività.

  • ECS Exec ha requisiti di versione a seconda che i tuoi processi siano ospitati su Amazon EC2 o AWS Fargate:

    • Se utilizzi Amazon EC2, devi utilizzare un'AMI ottimizzata per Amazon ECS rilasciata dopo il 20 gennaio 2021, con una versione dell'agente 1.50.2 o successiva. Per ulteriori informazioni, consulta AMI ottimizzate per Amazon ECS.

    • Se si utilizza AWS Fargate, è necessario utilizzare una versione della piattaforma 1.4.0 o superiore (Linux) o 1.0.0 (Windows). Per ulteriori informazioni, consulta Versioni della piattaforma AWS Fargate.

Architettura

ECS Exec utilizza AWS Systems Manager (SSM) Session Manager per stabilire una connessione con il contenitore in esecuzione e utilizza le policy AWS Identity and Access Management (IAM) per controllare l'accesso ai comandi in esecuzione in un contenitore in esecuzione. Ciò è reso possibile collegando i file binari di SSM Agent necessari nel container. L'Amazon ECS o AWS Fargate l'agente è responsabile dell'avvio dell'agente principale SSM all'interno del contenitore insieme al codice dell'applicazione. Per ulteriori informazioni, consulta Systems Manager Session Manager.

Puoi controllare quale utente ha effettuato l'accesso al contenitore utilizzando l'ExecuteCommandevento AWS CloudTrail e registrare ogni comando (e il relativo output) su Amazon S3 o Amazon CloudWatch Logs. Per crittografare i dati tra il client locale e il contenitore con la tua chiave di crittografia, devi fornire la chiave AWS Key Management Service ()AWS KMS.

Utilizzo di ECS Exec

Modifiche facoltative alla definizione di attività

Se si imposta il parametro di definizione dell'attività initProcessEnabled sutrue, viene avviato il processo di inizializzazione all'interno del contenitore. Ciò rimuove tutti i processi secondari rilevati dall'agente SSM zombie. Il seguente comando fornisce un esempio.

{
    "taskRoleArn": "ecsTaskRole",
    "networkMode": "awsvpc",
    "requiresCompatibilities": [
        "EC2",
        "FARGATE"
    ],
    "executionRoleArn": "ecsTaskExecutionRole",
    "memory": ".5 gb",
    "cpu": ".25 vcpu",
    "containerDefinitions": [
        {
            "name": "amazon-linux",
            "image": "amazonlinux:latest",
            "essential": true,
            "command": ["sleep","3600"],
            "linuxParameters": {
                "initProcessEnabled": true
            }
        }
    ],
    "family": "ecs-exec-task"
}

Attivazione di ECS Exec per attività e servizi

Puoi attivare la funzionalità ECS Exec per i tuoi servizi e le tue attività autonome specificando il --enable-execute-command flag quando usi uno dei seguenti AWS CLI comandi:,, o. create-serviceupdate-servicestart-taskrun-task

Ad esempio, se si esegue il comando seguente, la funzionalità ECS Exec viene attivata per un servizio appena creato che viene eseguito su Fargate. Per ulteriori informazioni sulla creazione dei servizi, consulta create-service.

aws ecs create-service \
    --cluster cluster-name \
    --task-definition task-definition-name \
    --enable-execute-command \
    --service-name service-name \
    --launch-type FARGATE \
     --network-configuration "awsvpcConfiguration={subnets=[subnet-12344321],securityGroups=[sg-12344321],assignPublicIp=ENABLED}" \
    --desired-count 1

Dopo aver abilitato ECS Exec per un'attività, è possibile emettere il comando seguente per confermare che l'attività è pronta per l'uso. Se la proprietà lastStatus di ExecuteCommandAgent è riportata come RUNNING e la proprietà enableExecuteCommand è impostata su true, allora il processo è pronto.

aws ecs describe-tasks \
    --cluster cluster-name \
    --tasks task-id

Il seguente frammento di output è un esempio di cosa potresti vedere.

{
    "tasks": [
        {
            ...
            "containers": [
                {
                    ...
                    "managedAgents": [
                        {
                            "lastStartedAt": "2021-03-01T14:49:44.574000-06:00",
                            "name": "ExecuteCommandAgent",
                            "lastStatus": "RUNNING"
                        }
                    ]
                }
            ],
            ...
            "enableExecuteCommand": true,
            ...
        }
    ]
}

Esecuzione di comandi tramite ECS Exec

Dopo aver confermato che ExecuteCommandAgent è in esecuzione, è possibile aprire una shell interattiva sul container utilizzando il seguente comando. Se i processo contiene più container, è necessario specificare il nome del container utilizzando il flag --container. Amazon ECS supporta solo l'avvio di sessioni interattive, pertanto è necessario utilizzare il flag --interactive.

Il comando seguente eseguirà un /bin/sh comando interattivo su un contenitore denominato container-name per un'attività con un ID task-id.

Il task-id è l'Amazon Resource Name (ARN) dell'attività.

aws ecs execute-command --cluster cluster-name \
    --task task-id \
    --container container-name \
    --interactive \
    --command "/bin/sh"

Registrazione tramite ECS Exec

Attivazione della registrazione delle attività e dei servizi

Importante

Per ulteriori informazioni sui CloudWatch prezzi, consulta la sezione Prezzi. CloudWatch Amazon ECS offre anche parametri di monitoraggio che vengono forniti senza costi aggiuntivi. Per ulteriori informazioni, consulta Monitora Amazon ECS utilizzando CloudWatch .

Amazon ECS fornisce una configurazione predefinita per i comandi di registrazione eseguiti con ECS Exec inviando i log ai CloudWatch log utilizzando il driver di awslogs log configurato nella definizione dell'attività. Se desideri fornire una configurazione personalizzata, la AWS CLI supporta --configuration per entrambi i comandi create-cluster e update-cluster. È anche importante sapere che l'immagine del contenitore richiede script e deve essere installata cat per poter caricare correttamente i log dei comandi su Amazon S3 CloudWatch o Logs. Per ulteriori informazioni sulla creazione dei cluster, consulta create-cluster.

Nota

Questa configurazione gestisce solo la registrazione della sessione execute-command. Non influisce sulla registrazione della tua applicazione.

L'esempio seguente crea un cluster e quindi registra l'output nei tuoi CloudWatch Logs LogGroup named cloudwatch-log-group-name e nel tuo bucket Amazon S3 denominato. s3-bucket-name

È necessario utilizzare una chiave gestita AWS KMS dal cliente per crittografare il gruppo di log quando si imposta l'opzione su. CloudWatchEncryptionEnabled true Per informazioni su come crittografare il gruppo di log, consulta Crittografare i dati di registro in CloudWatch Logs using AWS Key Management Service, nella Guida per l'utente.Amazon CloudWatch Logs 

aws ecs create-cluster \
    --cluster-name cluster-name \
    --configuration executeCommandConfiguration="{ \
        kmsKeyId=string, \
        logging=OVERRIDE, \
        logConfiguration={ \
            cloudWatchLogGroupName=cloudwatch-log-group-name, \
            cloudWatchEncryptionEnabled=true, \
            s3BucketName=s3-bucket-name, \
            s3EncryptionEnabled=true, \
            s3KeyPrefix=demo \
        } \
    }"

La proprietà logging determina il comportamento della funzionalità di registrazione di ECS Exec:

  • NONE: la registrazione è disattivata.

  • DEFAULT: i log vengono inviati al driver awslogs configurato. Se il driver non è configurato, non viene salvato alcun registro.

  • OVERRIDE: i log vengono inviati al bucket Amazon CloudWatch Logs fornito LogGroup, Amazon S3 o a entrambi.

Autorizzazioni IAM richieste per Amazon CloudWatch Logs o Amazon S3 Logging

Per abilitare la registrazione, il ruolo del processo Amazon ECS a cui si fa riferimento nella definizione di attività deve disporre di autorizzazioni aggiuntive. Queste autorizzazioni aggiuntive possono essere aggiunte al ruolo del processo sotto forma di policy. Sono diversi a seconda che tu indirizzi i log ad Amazon CloudWatch Logs o Amazon S3.

Amazon CloudWatch Logs

La seguente policy di esempio aggiunge le autorizzazioni Amazon CloudWatch Logs richieste.

{
   "Version": "2012-10-17",
   "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "logs:DescribeLogGroups"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
               "logs:CreateLogStream",
               "logs:DescribeLogStreams",
               "logs:PutLogEvents"
            ],
            "Resource": "arn:aws:logs:region:account-id:log-group:/aws/ecs/cloudwatch-log-group-name:*"
        }
   ]
}
Amazon S3

La policy dell'esempio seguente aggiunge le autorizzazioni Amazon S3 necessarie.

{
   "Version": "2012-10-17",
   "Statement": [
        {
            "Effect": "Allow",
            "Action": [
               "s3:GetBucketLocation"
            ],
            "Resource": "*"
        },
        {
           "Effect": "Allow",
           "Action": [
               "s3:GetEncryptionConfiguration"
           ],
           "Resource": "arn:aws:s3:::s3-bucket-name"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject"
            ],
            "Resource": "arn:aws:s3:::s3-bucket-name/*"
        }
    ]
   }

Autorizzazioni IAM necessarie per la crittografia utilizzando le proprie AWS KMS key (chiave KMS)

Per impostazione predefinita, i dati trasferiti tra il client locale e il contenitore utilizzano la crittografia TLS 1.2 che fornisce. AWS Per crittografare ulteriormente i dati utilizzando la propria chiave KMS, è necessario creare una chiave KMS e aggiungere l'autorizzazione kms:Decrypt al ruolo IAM del processo. Questa autorizzazione sarà utilizzata dal tuo container per decrittare i dati. Per ulteriori informazioni sulla creazione di una chiave KMS, consulta Creazione di chiavi.

Aggiungi la seguente policy in linea al tuo ruolo Task IAM che richiede le AWS KMS autorizzazioni. Per ulteriori informazioni, consulta Autorizzazioni ECS Exec.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "kms:Decrypt"
            ],
            "Resource": "kms-key-arn"
        }
    ]
}

Per crittografare i dati utilizzando la propria chiave KMS, all'utente o al gruppo che utilizza l'operazione execute-command deve essere concessa l'autorizzazione kms:GenerateDataKey.

La seguente policy di esempio per l'utente o il gruppo contiene l'autorizzazione necessaria per utilizzare la propria chiave KMS. È necessario specificare l'Amazon Resource Name (ARN) della chiave KMS.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "kms:GenerateDataKey"
            ],
            "Resource": "kms-key-arn"
        }
    ]
}

Utilizzo delle policy IAM per limitare l'accesso a ECS Exec

Limiti l'accesso degli utenti all'azione dell'API execute-command utilizzando una o più delle seguenti chiavi di condizione della policy IAM:

  • aws:ResourceTag/clusterTagKey

  • ecs:ResourceTag/clusterTagKey

  • aws:ResourceTag/taskTagKey

  • ecs:ResourceTag/taskTagKey

  • ecs:container-name

  • ecs:cluster

  • ecs:task

  • ecs:enable-execute-command

Con la seguente policy IAM di esempio, gli utenti possono eseguire comandi in container in esecuzione all'interno di processi con un tag che dispone di una chiave environment e un valore development in un cluster denominato cluster-name.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ecs:ExecuteCommand",
                "ecs:DescribeTasks"
            ],
         "Resource": [
                "arn:aws:ecs:region:aws-account-id:task/cluster-name/*",
                "arn:aws:ecs:region:aws-account-id:cluster/*"
            ],
            "Condition": {
                "StringEquals": {
                    "ecs:ResourceTag/environment": "development"
                }
            }
        }
    ]
}

Con l'esempio di policy IAM riportato di seguito, gli utenti non possono utilizzare l'API execute-command quando il nome del container è production-app.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": [
                "ecs:ExecuteCommand"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {                    
                    "ecs:container-name": "production-app"
                }
            }
        }
    ]
}

Con le seguenti policy IAM, gli utenti possono avviare i processi solo quando ECS Exec è disattivato.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ecs:RunTask",
                "ecs:StartTask",
                "ecs:CreateService",
                "ecs:UpdateService"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {                    
                    "ecs:enable-execute-command": "false"
                }
            }
        }
    ]
}
Nota

Perché l'operazione API execute-command contiene solo risorse di processo e cluster in una richiesta, vengono valutati solo i tag di cluster e processo.

Per ulteriori informazioni sulle chiavi di condizione della policy IAM, consulta Operazioni, risorse e chiavi di condizione per Amazon Elastic Container Service in Service Authorization Reference.

Limitazione dell'accesso all'operazione Avvia sessione

Mentre è possibile avviare sessioni SSM sul container al di fuori di ECS Exec, ciò potrebbe causare potenzialmente la mancata registrazione delle sessioni. Anche le sessioni avviate al di fuori di ECS Exec vengono conteggiate per la quota di sessione. Si consiglia di limitare questo accesso negando l'operazione ssm:start-session direttamente per i processi Amazon ECS con una policy IAM. Puoi negare l'accesso a tutti i processi Amazon ECS o a processi specifici in base ai tag utilizzati.

Di seguito è riportato un esempio di policy IAM che nega l'accesso all'operazione ssm:start-session per i processi in tutte le regioni con un nome cluster specificato. Facoltativamente puoi includere un carattere jolly con cluster-name.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "ssm:StartSession",
            "Resource": [
                "arn:aws:ecs:region:aws-account-id:task/cluster-name/*",
                "arn:aws:ecs:region:aws-account-id:cluster/*"
            ]
        }
    ]
}

Di seguito è riportato un esempio di policy IAM che nega l'accesso all'operazione ssm:start-session sulle risorse in tutte le regioni con chiave di tag Task-Tag-Key e valore di tag Exec-Task.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "ssm:StartSession",
            "Resource": "arn:aws:ecs:*:*:task/*",
            "Condition": {
                "StringEquals": {
                    "aws:ResourceTag/Task-Tag-Key": "Exec-Task"
                }
            }
        }
    ]
}

Per assistenza su eventuali problemi che potresti riscontrare durante l'utilizzo di Amazon ECS Exec, consulta Risoluzione dei problemi con Exec.