Wie behebe ich die Fehlermeldung „Unable to pull secrets or registry auth“ in Amazon ECS?

Lesedauer: 7 Minute

Ich erhalte die Fehlermeldung „Unable to pull secrets or registry auth“, wenn ich eine Amazon Elastic Container Service (Amazon ECS)-Aufgabe starte.

Kurzbeschreibung

Wenn du eine Amazon ECS-Aufgabe startest, erhältst du 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.“

Die AWS Fargate-Plattform-Version 1.4.0 verwendet die Task Elastic Network-Schnittstelle, um das Image und die Geheimnisse abzurufen. Der gesamte Netzwerkverkehr fließt über die elastische Netzwerkschnittstelle innerhalb deiner Amazon Virtual Private Cloud (Amazon VPC). Diesen Datenverkehr in deinen Amazon VPC Flow-Protokollen einsehen. Die Aufgabe verwendet jedoch deine Netzwerkkonfiguration, da sich die elastischen Netzwerkschnittstellen in deiner Amazon VPC befinden.

Der Amazon ECS-Container-Agent verwendet die Rolle „AWS Identity and Access Management“ (IAM) zur Aufgabenausführung, um Informationen von den folgenden Diensten abzurufen:

AWS Systems Manager Parameter Store
AWS Secrets Manager

Wenn du Daten mithilfe eines vom Kunden verwalteten AWS Key Management Service (AWS KMS)-Schlüssels verschlüsselst, erteile der IAM-Rolle für die Aufgabenausführung die folgenden Berechtigungen:

ssm:GetParameters
secretsmanager:GetSecretValue
kms:Decrypt

Behebung

Verwende das Runbook AWSSupport-TroubleshootECSTaskFailedToStart, um Fehler bei Amazon ECS-Aufgaben zu beheben, die nicht gestartet werden können. Wenn die Ausgabe des Runbooks keine Empfehlungen enthält, verwende die manuellen Ansätze zur Fehlerbehebung in den folgenden Abschnitten.

Wichtig:

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

Verwenden des Runbook TroubleshootECSTaskFailedToStart

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

Öffne die AWS-Systems-Manager-Konsole.
Wähle im Navigationsbereich unter Management ändern die Option Automatisierung aus.
Wähle Automatisierung ausführen aus.
Wähle die Registerkarte Owned by Amazon aus.
Suche unter Automatisierungsdokument nach TroubleshootECSTaskFailedToStart.
Wähle die Karte AWSSupport-TroubleshootECSTaskFailedToStart aus.
**Hinweis:**Stelle sicher, dass du das Optionsfeld auf der Karte auswählst und nicht den mit dem Hyperlink verknüpften Automatisierungsnamen.
Wähle Weiter 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. Achte außerdem auf Ausnahmen im Abschnitt Ausgabe.
Wähle bei Automatisierungsdokument ausführen die Option Einfache Ausführung.
Gib im Abschnitt Eingabeparameter für AutomationAssumeRole den ARN der Rolle ein, die Systems Manager Automation das Ausführen von Aktionen ermöglicht.
Hinweis: Stelle sicher, dass entweder der AutomationAssumeRole- 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 Systems Manager Automation die Berechtigungen des IAM-Benutzers oder der IAM-Rolle, die das Runbook ausführt. Weitere Informationen zum Erstellen der zu übernehmenden Rolle für Systems Manager Automation findest du unter Aufgabe 1: Erstelle eine Servicerolle für Automation.
Gib für ClusterName den Namen des Clusters ein, in dem die Aufgabe nicht gestartet werden konnte.
Gib für TaskId die Identifikation der zuletzt fehlgeschlagenen Aufgabe ein.
Wähle Ausführen.

Verwende auf der Grundlage der Ergebnisse der Automatisierung einen der folgenden manuellen Schritte zur Fehlerbehebung.

Überprüfen der Routen von deinen Subnetzen zum Internet

Wenn du eine Fargate-Aufgabe in einem öffentlichen Subnetz hast, stelle sicher, dass deiner Aufgabe eine öffentliche IP-Adresse zugewiesen ist. 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 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 die AWS Command Line Interface (AWS CLI), um bestehende Services neu zu konfigurieren. Verwende die AWS-Managementkonsole nicht. Wenn du einen AWS CloudFormation-Stack zum Erstellen deines Amazon ECS-Dienstes verwendet hast, ändere die NetworkConfiguration-Eigenschaft für AWS::ECS::Service, um den Dienst zu aktualisieren.

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 eine andere Quelle 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.
Wenn du PrivateLink verwendest, stelle sicher, dass deine Fargate-Infrastruktur die Sicherheitsgruppen für deine Amazon VPC-Endpunkte verwenden kann.
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. Außerdem muss HTTPS-Zugriff auf Anschluss 443 vorhanden sein.

Ü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 erforderlichen Endpunkte erstellen. Die folgenden Endpunkte sind für die Fargate-Plattformversionen 1.4.0 oder höher erforderlich:

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, Systems Manager-Parameter oder Amazon CloudWatch Logs verwendet, musst du möglicherweise Endpunkte definieren. Weitere Informationen findest du in der folgenden Dokumentation:

Prüfe für PrivateLink, ob die Sicherheitsgruppe von Amazon VPC Datenverkehr aus der Fargate-Task-Sicherheitsgruppe oder dem Fargate-Task-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 Endpunktrichtlinien für Amazon Simple Storage Service (Amazon S3).

Ü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 diese Rolle, wenn du die folgenden Aktionen ausführstn:

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

Wenn dein Anwendungsfall eines der oben genannten Szenarien beinhaltet, definiere die erforderlichen Berechtigungen in deiner Rolle „Aufgabenausführung“. Eine vollständige Liste der erforderlichen Berechtigungen findest du unter IAM-Rolle für die Amazon ECS-Aufgabenausführung.

Überprüfen der referenzierten vertraulichen Informationen in der Amazon ECS-Aufgabendefinition

**Hinweis:**Wenn du beim Ausführen von Befehlen in AWS CLI Fehlermeldungen erhältst, findest du weitere Informationen unter Beheben von AWS CLI-Fehlern. Stelle außerdem sicher, dass du die neueste Version der AWS CLI verwendest.

Überprüfe, ob die Namen des Geheimnisses 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?

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

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

Öffne die AWS-Systems-Manager-Konsole.
Wähle im Navigationsbereich Parameter Store und bestätige dann den Namen deines Parameter Stores.
Um den ARN des Parameters zu erhalten, führe mit der AWS CLI den folgenden Befehl aus. Ersetze name_of_parameter_store_secret durch den geheimen Namen deines Parameter Stores:
```
$ aws ssm get-parameter —name <name_of_parameter_store_secret> —with-decryption
```
Hinweis: Parameter, die Secrets des Secrets Manager referenzieren, können die Versionsverwaltung oder die Verlaufs-Features des Parameter Stores nicht verwenden. Weitere Informationen findest du unter Einschränkungen.