Direkt zum Inhalt

Wie behebe ich die Meldung „ResourceInitializationError“, wenn ich versuche, Secrets oder die Amazon ECR-Authentifizierung für ECS-Aufgaben abzurufen?

Lesedauer: 9 Minute
0

Wenn ich eine Amazon Elastic Container Service (Amazon ECS)-Aufgabe starte, erhalte ich die Meldung „ResourceInitializationError“.

Kurzbeschreibung

Wenn du eine Amazon ECS-Aufgabe mit dem Starttyp Fargate startest, erhältst du möglicherweise eine der folgenden Fehlermeldungen:

  • „ResourceInitializationError: unable to pull secrets or registry auth: pull command failed: : signal: killed“
  • „ResourceInitializationError: unable to pull secrets or registry auth: execution resource retrieval failed: unable to retrieve secret from asm: service call has been retried.“
  • „ResourceInitializationError: unable to pull secrets or registry auth: execution resource retrieval failed: unable to retrieve ecr registry auth: service call has been retried 3 time(s): RequestError: send request failed caused by: Post "https://api.ecr..amazonaws.com/": dial tcp …443: i/o timeout. Please check your task network configuration.“
  • „ResourceInitializationError: unable to pull secrets or registry auth: execution resource retrieval failed: unable to retrieve secret from asm: service call has been retried 5 time(s): failed to fetch secret arn:aws:secretsmanager…“
  • „ResourceInitializationError: unable to pull secrets or registry auth: execution resource retrieval failed: unable to retrieve secret from asm: service call has been retried 1 time(s): failed to fetch secret arn:aws:secretsmanager:<region>:<accountID>:secret:<secretName> from secrets manager: InvalidParameter: 1 validation error(s) found. – (minimum field size of 32/ maximum field size of 64), GetSecretValueInput.VersionId.“
  • „ResourceInitializationError: unable to pull secrets or registry auth: execution resource retrieval failed: unable to retrieve secret from asm: service call has been retried 1 time(s): failed to fetch secret rn:aws:secretsmanager:<region>:<accountID>:secret:<secretName> from secrets manager: AccessDeniedException: User: arn:aws:sts::<accountID>::assumed-role/<roleName> is not authorized to perform: secretsmanager:GetSecretValue on resource: rn:aws:secretsmanager:<region>:<accountID>:secret:<secretName> because no identity-based policy allows the secretsmanager:GetSecretValue action status code: 400“

AWS Fargate-Version 1.4.0 verwendet die Task Elastic Network-Schnittstelle, um das Bild und die Secrets abzurufen. Der gesamte Netzwerkverkehr fließt über die Netzwerkschnittstelle innerhalb deiner Amazon Virtual Private Cloud (Amazon VPC). Du kannst VPC Flow Logs verwenden, um den Datenverkehr anzuzeigen. Die Aufgabe verwendet jedoch deine Netzwerkkonfiguration, da Fargate die Netzwerkschnittstellen in deiner Amazon VPC platziert.

Der Amazon ECS-Container-Agent verwendet die AWS Identity and Access Management (IAM)-Rolle zur Aufgabenausführung, um Informationen aus dem Parameter Store, einer Funktion von AWS Systems Manager, und AWS Secrets Manager zu erhalten.

Für Daten, die du mit einem vom Kunden verwalteten AWS Key Management Service (AWS KMS)-Schlüssel verschlüsselst, erteilst du der IAM-Rolle für die Aufgabenausführung die folgenden Berechtigungen:

  • ssm:GetParameters
  • secretsmanager:GetSecretValue
  • kms:Decrypt

Lösung

Hinweis: Wenn du beim Ausführen von AWS Command Line Interface (AWS CLI)-Befehlen Fehlermeldungen erhältst, findest du weitere Informationen dazu unter Problembehandlung bei der AWS CLI. Stelle außerdem sicher, dass du die neueste Version von AWS CLI verwendest.

Verwenden des Runbook TroubleshootECSTaskFailedToStart

Verwende das Runbook AWSSupport-TroubleshootECSTaskFailedToStart, um Fehler bei Amazon ECS-Aufgaben zu beheben, die nicht gestartet werden können.

Wichtig: Verwende das Runbook in derselben AWS-Region, in der sich deine ECS-Cluster-Ressourcen befinden. Verwende die zuletzt fehlgeschlagene Aufgaben-ID, damit die Aufgabenstatusbereinigung die Analyse nicht unterbricht. Wenn die fehlgeschlagene Aufgabe Teil des Amazon ECS-Service ist, verwende die zuletzt fehlgeschlagene Aufgabe im Service. Die fehlgeschlagene Aufgabe muss in ECS:DescribeTasks sichtbar sein, wenn du die Automatisierung ausführst. Standardmäßig sind gestoppte ECS-Aufgaben 1 Stunde lang sichtbar, nachdem sie den Status Gestoppt erreicht haben.

Führe die folgenden Schritte aus, um das Runbook AWSSupport-TroubleshootECSTaskFailedToStart auszuführen:

  1. Öffne die AWS-Systems-Manager-Konsole.
  2. Wähle im Navigationsbereich unter Management ändern die Option Automatisierung aus.
  3. Wähle Automatisierung ausführen aus.
  4. Wähle die Registerkarte Owned by Amazon aus.
  5. Gib unter Automatisierungsdokument TroubleshootECSTaskFailedToStart in die Suchleiste ein.
  6. Wähle die Karte AWSSupport-TroubleshootECSTaskFailedToStart aus.
    Hinweis: Wähle nicht den mit einem Hyperlink versehenen Automatisierungsnamen aus.
  7. Wähle Weiter aus.
  8. Wähle bei Automatisierungsdokument ausführen die Option Einfache Ausführung.
  9. Gib im Abschnitt Eingabeparameter für AutomationAssumeRole den ARN der Rolle ein, die es der Automatisierung erlaubt, Aktionen durchzuführen.
    Hinweis: Stelle sicher, dass entweder die Servicerolle oder der IAM-Benutzer oder die IAM-Rolle über die erforderlichen IAM-Berechtigungen verfügt, um das Runbook AWSSupport-TroubleshootECSTaskFailedToStart auszuführen. Wenn du keine IAM-Rolle angibst, verwendet die Automatisierung die Berechtigungen des IAM-Benutzers oder der IAM-Rolle, die das Runbook ausführt. Informationen über die Erstellung der Servicerolle für die Automatisierung findest du unter Aufgabe 1: Erstelle eine Servicerolle für Automation.
  10. Gib für ClusterName den Namen des Clusters ein, in dem die Aufgabe nicht gestartet werden konnte.
  11. Gib für TaskId die Identifikation der zuletzt fehlgeschlagenen Aufgabe ein.
  12. Wähle Ausführen aus.
    Hinweis: Nach der Ausführung werden die Analyseergebnisse in den Abschnitt Globale Ausgabe eingetragen. Warte jedoch, bis der Status des Dokuments auf Erfolgreich wechselt. Prüfe außerdem den Abschnitt Ausgabe auf etwaige Ausnahmen.

Du kannst das Problem auch manuell beheben.

Überprüfen der Routen von deinen Subnetzen zum Internet

Wenn sich deine Fargate-Aufgabe in einem öffentlichen Subnetz befindet, überprüfe, ob du der Aufgabe eine öffentliche IP-Adresse zugewiesen hast. Stelle außerdem sicher, dass die Aufgabe eine Standardroute (0.0.0.0/0) zu einem Internet-Gateway hat. Wenn du eine neue Aufgabe startest oder einen neuen Dienst erstellst, aktiviere Öffentlich automatisch zuweisen.

Wenn du einen AWS CloudFormation-Stack zum Erstellen deines Amazon ECS-Services verwendet hast, ändere die NetworkConfiguration-Eigenschaft für AWS::ECS::Service, um den Service zu aktualisieren. Um die Konfiguration für bestehende Services zu aktualisieren, verwende CloudFormation, um den Parameter AssignPublicIp zu aktivieren. Alternativ kannst du den folgenden AWS CLI-Befehl update-service ausführen:

aws ecs update-service --service serviceName --region regionName "awsvpcConfiguration={subnets=[subnet-123,subnet-456],securityGroups=[sg-123,sg-456],assignPublicIp=ENABLED}"

Hinweis: Ersetze regionName durch deine Region.

Wenn du die folgenden Konfigurationen verwendest, verwende nicht das Internet-Gateway im öffentlichen Subnetz, um den Secrets Manager oder Systems Manager zu erreichen:

  • Die VPC-Endpunkte von Secrets Manager oder Systems Manager befinden sich in einem öffentlichen Subnetz.
  • Du hast AmazonProvidedDNS in den DHCP-Einstellungen deiner Amazon VPC aktiviert.

Verwende stattdessen einen Amazon VPC-Endpunkt.

Hinweis: Du kannst Öffentlich automatisch zuweisen für vorhandene Aufgaben nicht aktivieren. Verwende zum Neukonfigurieren bestehender Services die AWS CLI und nicht die AWS-Managementkonsole.

Wenn deine Fargate-Aufgabe in einem privaten Subnetz ist, stelle sicher, dass deine Aufgabe über eine Standardroute (0.0.0.0/0) zur Internetverbindungsquelle verfügt.

Die Internetverbindungsquelle kann ein NAT-Gateway, AWS PrivateLink oder ein benutzerdefinierter Domain-Server sein.

Wenn du ein NAT-Gateway verwendest, platziere dein NAT-Gateway in einem öffentlichen Subnetz. Weitere Informationen findest du unter Architektur mit einem Internet-Gateway und einem NAT-Gateway mit AWS Network Firewall. Wenn du PrivateLink verwendest, überprüfe, ob die Sicherheitsgruppen der Amazon VPC-Endpunkte den Verkehr zu den Fargate-Aufgaben zulassen. Wenn du einen Domain-Server mit benutzerdefiniertem Namen verwendest, bestätige die Einstellungen der DNS-Abfrage. Die Abfrage muss über den Anschluss 53 ausgehen und das UDP- und TCP-Protokoll verwenden. Die Abfrage muss außerdem über einen HTTPS-Zugang auf Port 443 verfügen.

Überprüfen der Einstellungen deiner Netzwerk-ACL und Sicherheitsgruppe

Stelle sicher, dass deine Netzwerkzugriffskontrollliste (Netzwerk-ACL) und Sicherheitsgruppen den ausgehenden Zugriff auf Port 443 aus dem Subnetz nicht blockieren. Weitere Informationen findest du unter Datenverkehr zu deinen AWS-Ressourcen mithilfe von Sicherheitsgruppen steuern.

**Hinweis:**Fargate-Aufgaben müssen ausgehenden Zugriff auf Port 443 haben, um ausgehenden Datenverkehr zu ermöglichen und auf Amazon ECS-Endpunkte zuzugreifen.

Überprüfen deiner Amazon VPC-Endpunkte

Wenn du PrivateLink verwendest, musst du die folgenden erforderlichen Endpunkte für Fargate-Plattformversionen 1.4.0 oder höher erstellen:

  • com.amazonaws.region.ecr.dkr
  • com.amazonaws.region.ecr.api
  • S3 Gateway-Endpunkt
  • com.amazonaws.region.logs

Weitere Informationen findest du unter Überlegungen zu VPC-Endpunkten von Amazon Elastic Container Registry (Amazon ECR).

Hinweis: Wenn deine Aufgabendefinition Secrets Manager, Parameter Store oder Amazon CloudWatch Logs verwendet, dann vergewissere dich, dass du Endpunkte definierst. Weitere Informationen findest du unter Verwendung eines AWS Secrets Manager VPC-Endpunkts und Erstellen der VPC-Endpunkte für Amazon ECS.

Prüfe für PrivateLink, ob die Sicherheitsgruppe von Amazon VPC Datenverkehr aus der Fargate-Task-Sicherheitsgruppe oder dem VPC-CIDR-Bereich auf dem TCP-Anschluss 443 zulässt.

Um zu bestätigen, dass die Fargate-Infrastruktur Service-Zugriff hat, überprüfe die VPC-Endpunktrichtlinien und Amazon Simple Storage Service (Amazon S3)-Endpunktrichtlinien.

Überprüfen deiner IAM-Rollen und -Berechtigungen

Die Rolle „Aufgabenausführung“ erteilt dem Amazon ECS-Container und den Fargate-Agents die erforderlichen Berechtigungen, um API-Aufrufe für die Aufgabe durchzuführen.

Fargate benötigt die Rolle der Aufgabenausführung, wenn du die folgenden Aktionen durchführst:

  • Rufe ein Container-Image aus Amazon ECR ab.
  • Verwende den awslogs-Protokolltreiber.
  • Verwende die private Registrierungsauthentifizierung.
  • Verwende Secrets Manager-Secrets oder Parameter Store-Parameter, um auf vertrauliche Daten zu verweisen.

Definiere in den vorangegangenen Szenarien die erforderlichen Berechtigungen in deiner Aufgabenausführungsrolle. Wenn du auf Secrets Manager-Secrets oder Parameter Store-Parameter zugreifst, um die sensiblen Daten abzurufen, bestätige, dass du die erforderlichen secretsmanager:GetSecretValue- oder ssm:GetParameters-Berechtigungen hast. Eine Liste der erforderlichen Berechtigungen findest du unterBerechtigungen für Secrets Manager oder Systems Manager.

Überprüfe die sensiblen Daten in der Amazon ECS-Aufgabendefinition

Stelle sicher, dass die Namen des Secrets und der Parameter mit den referenzierten Namen in deiner Amazon ECS-Aufgabendefinition übereinstimmen. Überprüfe dann, ob die Werte in der Container-Definition mit den Werten in deiner Amazon ECS-Aufgabendefinition übereinstimmen. Weitere Informationen findest du unter Wie kann ich in einer Amazon ECS-Aufgabe geheime oder vertrauliche Informationen sicher an Container weitergeben?

Vergewissere dich, dass du das Secret oder den Parameter mit demselben ARN oder Namen konfigurierst, der in der Aufgabendefinition angegeben ist. Wenn die Ressource in einer anderen Region existiert, musst du den vollständigen ARN angeben.

Verwende den Parameter VersionId in GetSecretValueInput, um die Version des abgerufenen geheimen Werts anzugeben. Wenn du keine bestimmte Version benötigst, kannst du das Feld VersionId löschen. Secrets Manager ruft standardmäßig die neueste Version ab.

Wenn sich der Parameter Store-Parameter und die Aufgabe in derselben Region befinden, verwende den vollständigen ARN oder den Namen des Secrets. Wenn der Parameter in einer anderen Region vorhanden ist, musst du den vollständigen ARN angeben.

Führe die folgenden Schritte aus, um den Parameternamen und den ARN zu überprüfen:

  1. Öffne die AWS Systems Manager-Konsole.
  2. Wähle im Navigationsbereich Parameter Store und bestätige dann den Parameter Store-Namen.
  3. Um den ARN des Parameters abzurufen, führe den folgenden AWS CLI-Befehl get-parameter aus:
    aws ssm get-parameter --name name_of_parameter_store_secret --with-decryption
    Hinweis: Ersetze name_of_parameter_store_secret durch den Secret-Namen deines Parameter Stores. Parameter, die Secrets des Secrets Manager referenzieren, können die Versions- oder Verlaufs-Features des Parameter Stores nicht verwenden. Weitere Informationen findest du unter Einschränkungen.

Ähnliche Informationen

Anzeigen von Fehlern bei gestoppten Amazon ECS-Aufgaben

Amazon ECS-Aufgabennetzwerkoptionen für den Starttyp Fargate

Amazon ECR interface VPC endpoints (AWS PrivateLink)

Verwenden von CloudWatch-Protokollen mit VPC-Schnittstellen-Endpunkten