#amazon-web-services #docker #boto3 #amazon-iam #aws-secrets-manager
#amazon-веб-сервисы #docker #boto3 #amazon-iam #aws-секреты-менеджер
Вопрос:
Ограничения:
- Я не хочу включать свой конфигурационный файл aws в контейнер docker
- Я хочу, чтобы это работало как в prod, так и в среде разработки.
Что я пробовал:
- Я использовал роли IAM, но это работает только в prod, а не в среде разработки.
- Я использовал конфигурационный файл aws, но он работает на хосте, а не в контейнере docker. И я не хочу копировать его в контейнер.
Есть какие-нибудь рекомендации о том, как это сделать?
Обновление: Чтобы прояснить вопрос: Моя проблема заключается в том, чтобы найти общий способ предоставления учетных данных aws как в среде разработки, так и в производстве, используя docker. Под «Я использовал роли IAM, но это работает только на prod» я имел в виду, что я использовал taskRoleArn для определения задачи cloudformation, но это влияет только на prod, а не на среду разработки. Итак, мне нужно установить учетные данные другим способом (например, aws config) в среде разработки.
Комментарии:
1. Используете ли вы ECS? Также что означает, что «это работает только на prod, а не в среде разработки»?
2. С какой конкретной проблемой вы столкнулись? Как получить правильные учетные данные в контейнере? Подключение к сети? Что-то еще?
3. Какая проблема у вас возникла с ролями IAM в разработке?
4. Моя проблема заключалась в том, чтобы найти общий способ предоставления учетных данных aws как в среде разработки, так и в производственной среде с использованием docker. Под «Я использовал роли IAM, но это работает только на prod» я имел в виду, что я использовал taskRoleArn для определения задачи cloudformation, но это влияет только на prod, а не на среду разработки. Итак, мне нужно установить учетные данные другим способом (например, aws config) в среде разработки.
Ответ №1:
Наилучшая практика взаимодействия со службами AWS — всегда использовать роли IAM там, где это возможно, особенно там, где используются производственные среды.
Если вы хотите имитировать, как это работает в локальной ситуации (например, при разработке), вы используете переменные окружения в сочетании с учетными данными пользователя IAM.
При использовании официального SDK / CLI будут выполняться поиски официально именованных переменных среды, поэтому ваш код не нужно будет модифицировать, чтобы он работал по-разному в каждой среде.
Как я упоминал выше, я бы настоятельно рекомендовал использовать роли IAM в вашей производственной среде.
Ответ №2:
Роли IAM — это самый простой способ предоставить вашему контейнеру необходимые разрешения. Это работает в любой среде. Это, безусловно, лучшая практика.
Ответ №3:
Для всех, кому интересно, я решил свою проблему, следуя приведенным здесь инструкциям по тестированию ролей IAM: https://aws.amazon.com/blogs/compute/a-guide-to-locally-testing-containers-with-amazon-ecs-local-endpoints-and-docker-compose/ Смотрите раздел, связанный с «Конечными точками локального контейнера ECS»