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 inserire una shell in un contenitore in esecuzione su un' EC2istanza Amazon 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. Inoltre, negli scenari di produzione, è possibile utilizzarlo per ottenere un accesso ininterrotto ai container per eseguire il debug dei 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) o dalla CLI AWS SDKs AWS Copilot. 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

È inoltre possibile utilizzare ECS Exec per mantenere policy di controllo degli accessi più severe. 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, è possibile utilizzare ECS Exec per visualizzare quali attività sono state eseguite e per verificare chi ha effettuato l'accesso a un contenitore. CloudTrail

Considerazioni

Considera le informazioni seguenti durante l'utilizzo di ECS Exec:

Architecture

ECS Exec utilizza AWS Systems Manager (SSM) Session Manager per stabilire una connessione con il contenitore in esecuzione e utilizza le politiche 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.

Configurazione di ECS Exec

Per utilizzare ECS Exec, devi prima attivare la funzionalità per le tue attività e i tuoi servizi e poi eseguire i comandi nei container.

Modifiche facoltative alla definizione di attività

Se imposti il parametro di definizione dell'attività da initProcessEnabled a true, questo avvia il processo di init all'interno del container. In questo modo, vengono rimossi 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

È possibile attivare la funzionalità ECS Exec per i servizi e le attività autonome specificando il --enable-execute-command flag quando si utilizza uno dei seguenti AWS CLI comandi: create-service,, o. update-servicestart-taskrun-task

Ad esempio, se esegui il seguente comando, 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

Registrazione tramite ECS Exec

È possibile configurare la registrazione per le sessioni ECS Exec per acquisire i comandi e il relativo output a fini di controllo e risoluzione dei problemi.

Attivazione della registrazione nelle attività e nei servizi

Amazon ECS fornisce una configurazione predefinita per i comandi di registrazione eseguiti utilizzando ECS Exec. L'impostazione predefinita prevede l'invio dei log a CloudWatch Logs utilizzando il driver di awslogs log configurato nella definizione dell'attività. Se si desidera fornire una configurazione personalizzata, AWS CLI supporta un --configuration flag sia per i comandi che per. create-cluster update-cluster L'immagine del contenitore richiede script e cat deve essere installata per poter caricare correttamente i log dei comandi su Amazon S3 CloudWatch o Logs. Per ulteriori informazioni sulla creazione dei cluster, consulta create-cluster.

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:

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:us-east-1:111122223333: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.

È necessario aggiungere la seguente policy in linea al ruolo IAM del processo che richiede le autorizzazioni AWS KMS . Per ulteriori informazioni, consulta Autorizzazioni ACS Exec.

JSON

{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "kms:Decrypt"
            ],
            "Resource": "arn:aws:kms:us-east-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab"
        }
    ]
}

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.

JSON

{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "kms:GenerateDataKey"
            ],
            "Resource": "arn:aws:kms:us-east-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab"
        }
    ]
}

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

Puoi limitare l'accesso utente all'operazione API execute-command utilizzando una o più delle seguenti chiavi di condizione delle policy IAM:

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.

JSON

{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ecs:ExecuteCommand",
                "ecs:DescribeTasks"
            ],
            "Resource": [
                   "arn:aws:ecs:us-east-1:111122223333:task/cluster-name/*",
                   "arn:aws:ecs:us-east-1:111122223333:cluster/cluster-name"
            ],
            "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.

JSON

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

JSON

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

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.

JSON

{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "ssm:StartSession",
            "Resource": [
                   "arn:aws:ecs:us-east-1:111122223333:task/cluster-name/*"
            ]
        }
    ]
}

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.

JSON

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

Risoluzione dei problemi relativi a ECS Exec

Per ulteriore supporto nella risoluzione dei problemi, consulta Risoluzione dei problemi con Exec.