Пароль Terraform и открытый текст в файле (удаленного) состояния

В репозитории Terraform по этой проблеме открыто много проблем с Git, с множеством интересных комментариев, но на данный момент я все еще не вижу решения этой проблемы.

Terraform хранит текстовые значения, включая пароли, в файлах tfstate.

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

Так как же скрыть свои пароли?

Кто-нибудь здесь использует Terraform для производства? Вы храните пароли в виде простого текста? У вас есть специальный рабочий процесс, чтобы удалить или скрыть их? Что происходит тогда, когда вы запускаете terraform apply?

Я рассмотрел следующие варианты:

  • храните их в Consul - я не использую Consul
  • удалите их из файла состояния - это требует, чтобы каждый раз выполнялся другой процесс, и я не знаю, как Terraform будет обрабатывать ресурс с пустым / нечитаемым / неработающим паролем
  • сохранить пароль по умолчанию, который затем будет изменен (поэтому Terraform будет иметь нерабочий пароль в файле tfstate) - то же, что и выше
  • использовать ресурс Vault - похоже, это еще не полный рабочий процесс
  • хранить их в Git с помощью git-repo-crypt - Git тоже не вариант
  • глобально зашифровать корзину S3 - это не помешает людям видеть пароли в виде простого текста, если у них есть доступ к AWS на уровне «менеджера», но пока это кажется лучшим вариантом

С моей точки зрения, это то, что я хотел бы видеть:

  • файл состояния не включает пароли
  • файл состояния зашифрован
  • пароли в файле состояния являются «указателями» на другие ресурсы, например «vault: backend-type: / path / to / password»
  • каждый запуск Terraform будет собирать необходимые пароли от указанного провайдера

Это просто желание.

Но вернемся к вопросу - как вы используете Terraform в продакшене?


terraform hashicorp-vault
person Prune    schedule 06.02.2017    source источник

Ответы (2)


arrow_upward
8
arrow_downward

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

  • Установите начальный пароль для RDS, игнорируйте разницу с ловушкой жизненного цикла и измените его позже. Способ игнорировать разницу заключается в следующем:

     resource "aws_db_instance" "db_instance" {
   ...
   password = "hoge"

   lifecycle {
     ignore_changes = ["password"]
   }
 }

  • Пользователи IAM управляются Terraform, но профили входа в IAM, включая пароли, нет. Я считаю, что паролем IAM должны управлять отдельные лица, а не администратор.

  • Ключи API, используемые приложениями, также не управляются Terraform. Они зашифрованы с помощью AWS KMS (служба управления ключами), а зашифрованные данные сохраняются в репозитории git приложения или в корзине S3. Преимущество шифрования KMS заключается в том, что разрешениями на расшифровку можно управлять с помощью роли IAM. Нет необходимости управлять ключами для расшифровки.

  • Хотя я еще не пробовал, недавно я заметил, что aws ssm put-parameter --key-id можно использовать как простое хранилище значений ключей, поддерживающее шифрование KMS, так что это также может быть хорошей альтернативой.

Я надеюсь, это поможет вам.

person minamijoyo    schedule 07.02.2017
comment
Re: aws ssm, Я вытаскиваю из ssm скрипт-оболочку, который запускает приложение в докере, и это было великолепно. Я всегда ненавидел даже зашифрованные секреты в системе контроля версий. - person voxobscuro; 04.12.2017

arrow_upward
4
arrow_downward

Вся информация об удаленном состоянии переработана для версии 0.9 который должен открыть возможности для блокировки удаленного состояния и потенциально шифрование всего файла состояния / только секретов.

До тех пор мы просто используем несколько учетных записей AWS и записываем состояние данных, которые поступают в эту учетную запись, в корзину S3 в этой учетной записи. В нашем случае мы не особо заботимся о секретах, которые там оказываются, потому что если у вас есть доступ для чтения корзины, то обычно у вас есть достаточный объем доступа к этой учетной записи. Кроме того, наши единственные настоящие секреты, хранящиеся в файлах состояния, - это пароли базы данных RDS, и мы ограничиваем доступ на уровне группы безопасности только экземплярам приложений и экземплярам Jenkins, которые создают все, поэтому в любом случае нет прямого доступа из командной строки на рабочих станциях людей.

Я также предлагаю добавить шифрование в состоянии покоя в ведре S3 (просто потому, что оно в основном бесплатное) и управление версиями, чтобы при необходимости вы могли получить более старые файлы состояния.

Чтобы продолжить, если вы беспокоитесь о людях, имеющих доступ для чтения к вашим корзинам S3, содержащим состояние, вы можете добавить политику корзины, которая явно запрещает доступ кому-либо, кроме некоторых ролей / пользователей из белого списка, которые затем будут приняты во внимание сверх любых Доступ к IAM. Расширение примера из связанное сообщение в блоге AWS, у нас может быть политика корзины, которая выглядит примерно так:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::MyTFStateFileBucket",
        "arn:aws:s3:::MyTFStateFileBucket/*"
      ],
      "Condition": {
        "StringNotLike": {
          "aws:userId": [
            "AROAEXAMPLEID:*",
            "AIDAEXAMPLEID"
          ]
        }
      }
    }
  ]
}

Где AROAEXAMPLEID представляет собой пример ID роли, а AIDAEXAMPLEID представляет собой пример ID пользователя. Их можно найти, запустив:

aws iam get-role -–role-name ROLE-NAME

а также

aws iam get-user -–user-name USER-NAME

соответственно.

Если вы действительно хотите полностью отказаться от шифрования файла состояния, вам нужно будет написать сценарий оболочки, который заставляет Terraform взаимодействовать с файлом состояния локально (а не удаленно), а затем ваш сценарий оболочки управляет удаленным состоянием, шифруя его. перед загрузкой в ​​S3 и расшифровкой по мере извлечения.

person ydaetskcoR    schedule 07.02.2017