Функция Terraform pathexpand не работает в сложном проекте?

#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 .