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 ECS i container Amazon 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, puoi usare ECS Exec per interagire facilmente con vari processi nei tuoi contenitori e risolvere i problemi delle tue applicazioni. Inoltre, negli scenari di produzione, è possibile utilizzarlo per ottenere un accesso ininterrotto ai contenitori per il debug dei problemi.

Puoi eseguire comandi in un contenitore Linux o Windows in esecuzione utilizzando ECS Exec da Amazon ECSAPI, AWS Command Line Interface (AWS CLI) o AWS CLI Copilot. AWS SDKs Per informazioni dettagliate sull'uso di ECS Exec e per una guida video sull'utilizzo di Copilot, consulta Copilot AWS CLI GitHub documentazione.

È inoltre possibile 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 CloudTrail per controllare chi ha avuto accesso a un contenitore.

Considerazioni

Per questo argomento, è necessario conoscere i seguenti aspetti relativi all'uso di Exec: ECS

Prerequisiti

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

Architettura

ECSExec 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 montando in bind i binari degli SSM agenti necessari nel contenitore. L'Amazon ECS o l' AWS Fargate agente è responsabile dell'avvio dell'agente SSM principale 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.

Usare Exec ECS

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. Questo rimuove tutti i processi secondari di Zombie SSM Agent trovati. 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"
}

ECSAttivazione di Exec per le attività e i 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: create-service,, o. update-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 attivato ECS Exec per un'operazione, è possibile eseguire il comando seguente per confermare che l'attività è pronta per essere utilizzata. 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 Exec ECS

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 supporta ECS solo l'avvio di sessioni interattive, quindi è necessario utilizzare il --interactive flag.

Il comando seguente eseguirà un /bin/sh comando interattivo su un contenitore denominato in base container-name a un'attività con un ID ditask-id.

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 Exec ECS

Attivazione della registrazione delle attività e dei servizi

Amazon ECS fornisce una configurazione predefinita per i comandi di registrazione eseguiti con ECS Exec inviando i log a CloudWatch Logs 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.

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 logging proprietà determina il comportamento della funzionalità di registrazione di Exec: ECS

IAMautorizzazioni richieste per Amazon CloudWatch Logs o Amazon S3 Logging

Per abilitare la registrazione, il ruolo dell'ECSattività di Amazon a cui si fa riferimento nella definizione dell'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/*"
        }
    ]
   }

IAMautorizzazioni necessarie per la crittografia utilizzando la propria 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 KMS chiave, è necessario creare una KMS chiave e aggiungere l'kms:Decryptautorizzazione al proprio IAM ruolo di attività. Questa autorizzazione sarà utilizzata dal tuo container per decrittare i dati. Per ulteriori informazioni sulla creazione di una KMS chiave, consulta Creazione di chiavi.

Aggiungi la seguente politica in linea al tuo IAM ruolo di attività che richiede le AWS KMS autorizzazioni. Per ulteriori informazioni, consulta ECSAutorizzazioni Exec.

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

Affinché i dati vengano crittografati utilizzando la propria KMS chiave, è necessario concedere l'autorizzazione all'utente o al gruppo che utilizza l'execute-commandkms:GenerateDataKeyazione.

La seguente politica di esempio per l'utente o il gruppo contiene l'autorizzazione richiesta per utilizzare la propria KMS chiave. Devi specificare l'Amazon Resource Name (ARN) della tua KMS chiave.

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

Utilizzo IAM di politiche per limitare l'accesso a ECS Exec

È possibile limitare l'accesso degli utenti all'APIazione execute-command utilizzando una o più delle seguenti chiavi relative alle condizioni della policy: IAM

Con la seguente IAM policy di esempio, gli utenti possono eseguire comandi in contenitori in esecuzione all'interno di attività con un tag contenente una environment chiave e un development valore e 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 il seguente esempio di IAM policy, gli utenti non possono utilizzare execute-command API quando il nome del contenitore èproduction-app.

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

Con la seguente IAM politica, gli utenti possono avviare le attività 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"
                }
            }
        }
    ]
}

Per ulteriori informazioni sulle chiavi delle condizioni delle IAM politiche, consulta Azioni, risorse e chiavi di condizione per Amazon Elastic Container Service nel Service Authorization Reference.

Limitazione dell'accesso all'operazione Avvia sessione

Sebbene sia possibile avviare SSM sessioni sul contenitore al di fuori di ECS Exec, ciò potrebbe potenzialmente comportare la mancata registrazione delle sessioni. Anche le sessioni avviate al di fuori di ECS Exec vengono conteggiate nella quota di sessione. Ti consigliamo di limitare questo accesso negando l'ssm:start-sessionazione direttamente per le tue ECS attività su Amazon utilizzando una IAM politica. Puoi negare l'accesso a tutte le ECS attività di Amazon o ad attività specifiche in base ai tag utilizzati.

Di seguito è riportato un esempio di IAM politica che nega l'accesso all'ssm:start-sessionazione per le attività in tutte le regioni con un nome di 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 IAM politica che nega l'accesso all'ssm:start-sessionazione sulle risorse in tutte le regioni contrassegnate con la chiave del tag Task-Tag-Key e il valore del 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.