Aws ecs fargate ResourceInitializationError: невозможно получить секреты или аутентификацию реестра

Сотрудник AWS здесь.

То, что вы видите, связано с изменением работы сети между платформой Fargate версии 1.3.0 и платформой Fargate версии 1.4.0. В рамках перехода от использования Docker к использованию containerd мы также внесли некоторые изменения в работу сети. В версии 1.3.0 и ниже каждая задача Fargate получила два сетевых интерфейса:

• Один сетевой интерфейс использовался для трафика приложения из контейнера (ов) вашего приложения, а также для журналов и извлечения уровня изображения контейнера.
• Вторичный сетевой интерфейс использовался самой платформой Fargate для получения учетных данных ECR-аутентификации и получения секретов.

Однако у этого вторичного сетевого интерфейса были некоторые недостатки. Этот вторичный трафик не отображался в журналах потоков VPC. Кроме того, хотя большая часть трафика оставалась в клиентском VPC, вторичный сетевой интерфейс отправлял трафик за пределы вашего VPC. Ряд клиентов жаловались, что у них не было возможности указать элементы управления на уровне сети на этом дополнительном сетевом интерфейсе и на то, к чему он мог подключаться.

Чтобы сделать сетевую модель менее запутанной и предоставить клиентам больший контроль, мы изменили в платформе Fargate версии 1.4.0 использование единого сетевого интерфейса и сохранение всего трафика внутри вашего VPC, даже трафика платформы Fargate. Трафик платформы Fargate для получения ECR-аутентификации и секретов задач теперь использует тот же сетевой интерфейс задачи, что и остальной трафик вашей задачи, и вы можете наблюдать за этим трафиком в журналах потоков VPC и контролировать этот трафик с помощью таблицы маршрутизации в вашем собственном AWS VPC. .

Однако с этой расширенной возможностью наблюдения и управления сетью платформы Fargate вы также берете на себя ответственность за то, чтобы в вашем VPC действительно был настроен сетевой путь, который позволяет задаче взаимодействовать с ECR и AWS Secrets Manager.

Есть несколько способов решить эту проблему:

• Запускать задачи в общедоступной подсети с общедоступным IP-адресом, чтобы они могли связываться с ECR и другими вспомогательными службами через интернет-шлюз.
• Запускать задачи в частной подсети с таблицей маршрутизации VPC, настроенной для маршрутизации исходящего трафика через шлюз NAT в общедоступной подсети. Таким образом, шлюз NAT может открыть соединение с ECR от имени задачи.
• Запускайте задачи в частной подсети и убедитесь, что в вашем VPC настроены конечные точки AWS PrivateLink для необходимых вам сервисов (ECR для аутентификации по запросу, S3 для слоев изображений и AWS Secrets Manager для секретов).

Вы можете узнать больше об этом изменении в этом официальном блоге, в разделе эластичный сетевой интерфейс задач (ENI) теперь запускает дополнительные потоки трафика.

https://aws.amazon.com/blogs/containers/aws-fargate-launches-platform-version-1-4/

Я не совсем уверен в вашей настройке, но после того, как я отключил NAT-шлюзы, чтобы сэкономить немного долларов, у меня появилось очень похожее сообщение об ошибке на платформе aws-ecs-fargate-1.4.0:

Stopped reason: ResourceInitializationError: unable to pull secrets or registry auth: execution resource retrieval failed: unable to retrieve ecr registry auth: service call has been retried 1 time(s): RequestError: send request failed caused by: Post https://api.ecr....

Оказалось, что мне пришлось создать конечные точки VPC для этих имен служб:

• com.amazonaws.REGION.s3
• com.amazonaws.REGION.ecr.dkr
• com.amazonaws.REGION.ecr.api
• com.amazonaws.REGION.logs
• com.amazonaws.REGION.ssm

И мне пришлось перейти на платформу aws-ecs-fargate-1.3.0. После перехода на более раннюю версию образы Docker можно было извлечь из ECR, и развертывания снова прошли успешно.

Если вы используете диспетчер секретов без NAT-шлюза, возможно, вам придется создать конечную точку VPC для com.amazonaws.REGION.secretsmanager.

Эта ошибка возникает, когда агенту Fargate не удается создать или загрузить ресурсы, необходимые для запуска контейнера, или если задача принадлежит. Эта ошибка возникает только при использовании платформы версии 1.4 или более поздней, скорее всего, , потому что версия 1.4 использует Task ENI (который находится в вашем VPC) вместо Fargate ENI (который находится в VPC AWS). Я думаю, это может быть вызвано некоторой потребностью в дополнительных разрешениях IAM, необходимых для извлечения изображения из ECR. Вы используете какую-нибудь приватную ссылку? Если да, вы можете ознакомиться с политиками для конечной точки ECR.

Я попытаюсь воспроизвести это, но я предлагаю открыть заявку в службу поддержки с AWS, если вы можете, чтобы они могли внимательнее изучить ваши ресурсы и лучше предложить.

Обеспечьте подключение к Интернету через IGW или NAT и убедитесь, что общедоступный IP-адрес включен, если его IGW находится в конфигурации сети Fargate Task / Service.

{
  "awsvpcConfiguration": {
    "subnets": ["string", ...],
    "securityGroups": ["string", ...],
    "assignPublicIp": "ENABLED"|"DISABLED"
  }
}

Поскольку агент ECS в FARGATE версии 1.4.0 использует задачу ENI для получения информации, запрос к диспетчеру секретов будет проходить через этот eni.

Вы должны убедиться, что трафик к api секретного менеджера (secretsmanager. {Region} .amazonaws.com) открыт:

• если ваша задача является частной, у вас должна быть либо конечная точка vpc (com.amazonaws. {region} .secretsmanager), либо шлюз NAT, а группа безопасности ENI задачи должна разрешать для нее исходящий трафик https.

• если ваша задача является общедоступной, группа безопасности должна разрешить исходящий трафик https на внешний (или общедоступные cidrs AWS).

Эта ошибка может произойти, если вы используете общедоступную подсеть и выбираете Не назначать общедоступный адрес.

То же самое применимо, если у вас есть частная подсеть и нет интернет-шлюза или шлюза NAT в вашем VPC. Ему нужен путь к Интернету.

Это одинаковое поведение во всей экосистеме AWS. Было бы здорово, если бы в таких случаях AWS отображал большой баннер с предупреждением.

У меня была точно такая же проблема с использованием Fargate в качестве типа запуска с версией платформы 1.4.0. В конце, поскольку я использовал общедоступные подсети, все, что мне нужно было сделать, это разрешить назначение общедоступного IP-адреса задачам, чтобы разрешить задаче доступ к исходящей сети для получения изображения.

Я получил подсказку, как решить эту проблему, когда я попытался создать службу с использованием версии платформы 1.3.0, и создание задачи не удалось с аналогичным, но к счастью задокументированная ошибка.

Я решил аналогичную проблему, обновив правила в группе безопасности ECS Service. Ниже конфигурация правил.

Inbound Rules:
* HTTP          TCP   80    0.0.0.0/0
Outbound Rules:
* All traffic   All   All   0.0.0.0/0

Если ваш Fargate работает в частной подсети без доступа к Интернету, технически внутри вашего vpc должна быть уже установлена ​​конечная точка dkr vpc, чтобы ваш Fargate (версии 1.3 и ниже) мог достичь этой конечной точки и развернуть контейнер. Для версии 1.4 Fargate просто нужна дополнительная конечная точка api ecr.

https://aws.amazon.com/blogs/containers/aws-fargate-launches-platform-version-1-4/

У меня только что возникла эта проблема, и причина, по которой я ее получил, заключалась в том, что я забыл добавить правила для входящего и исходящего трафика в группу безопасности, связанную с моей службой. (добавлены входящие из моего ALB и исходящие *)