#amazon-web-services #terraform #infrastructure-as-code
#amazon-веб-сервисы #terraform #инфраструктура как код
Вопрос:
Я новичок в terraform, и все же мне поручено управлять довольно сложным проектом, который включает в себя несколько учетных записей и сред, у нас много файлов tf и много строк в каждом файле. Очевидно, что есть несколько вещей, которые не выполняются в наилучшей практике. Например, у нас есть следующая конфигурация для поставщика:
provider "aws" {
region = var.region
access_key = "my-access-key"
secret_key = "my-secret-key"
assume_role {
role_arn = "arn:aws:iam::xxxxxxxxxxx:role/aaaaaaaaaaaaa"
}
}
У нас есть учетные данные для жесткого кода в файле конфигурации! Итак, я решил, что мне нужно заменить ее чем-то вроде следующего:
provider "aws" {
region = var.region
shared_credentials_file = "/home/jerry/.aws/credentials"
assume_role {
role_arn = "arn:aws:iam::xxxxxxxxxxx:role/aaaaaaaaaaaaa"
}
}
Это работает хорошо, без проблем. Поскольку у нас есть команда, я решил использовать pathexpand, чтобы каждый в команде мог использовать свои собственные учетные данные:
provider "aws" {
region = var.region
shared_credentials_file = pathexpand("~/.aws/credentials")
assume_role {
role_arn = "arn:aws:iam::xxxxxxxxxxx:role/aaaaaaaaaaaaa"
}
}
Однако это больше не работает. Я получил следующую ошибку:
Error: The role "arn:aws:iam::xxxxxxxxxxx:role/aaaaaaaaaaaaa" cannot be assumed.
There are a number of possible causes of this - the most common are:
* The credentials used in order to assume the role are invalid
* The credentials do not have appropriate permission to assume the role
* The role ARN is not valid
Я попытался запустить новый тестовый проект, используя очень простую конфигурацию, он работает с расширением пути, без проблем. но это просто не будет работать с (большим) проектом, с которым мне было поручено.
Может быть, где-то есть какая-то конфигурация, которая запрещает использовать функцию pathexpand? или есть какие-то переменные среды, которые изменяют поведение? Я изучал это в течение целого дня и не смог найти ответ.
Пожалуйста, помогите, любая информация приветствуется!
Комментарии:
1. Вы проверили, что
~/.aws/credentials
существует и пользователю разрешено выполнять эту роль?2. Если вы используете типичные способы получения учетных данных SDK, вам вообще не нужно указывать это, чтобы вы могли полностью удалить
shared_credentials_file
параметр, поскольку это значение по умолчанию для SDK в любом случае. Для дальнейшей отладки вам следует попробовать выполнить,aws sts get-caller-identity
чтобы проверить, что вы принимаете учетные данные вашего пользователя через файл учетных данных, а затем попытаться принять вашу роль с помощьюaws sts assume-role
. Затем вам следует отредактировать свой вопрос, чтобы включить в него результаты, подвергнутые цензуре.3. @rkm да, конечно, все будет работать с /home/my_id/.aws/credentials, но не с ~/.aws/credentials.
4. @ydaetskcoR Учетные данные есть, и они будут работать с командой aws sts assume-role. Проблема, похоже, в том, что pathexpand (~/.aws / credentials) не удается развернуть до правильного пути, как мне выполнить трассировку на месте, действительно ли работает pathexpand (~/.aws /credentials)?
5. Я не понимаю, почему это приведет к сбою, но, как уже упоминалось, в этом нет необходимости. Вы можете просто удалить строку и вместо этого полагаться на обычную цепочку учетных данных для обнаружения учетных данных в
~/.aws/credentials
.