Опять же, если говорить о gitlab, можно запихать yaml с секретами в CI variable типа file и распарсить yaml из полученного пути.

спасибо, попробую и так

Поддерживаю

пробую работать с variable file и появилось пару вопросов:

1. какие преимущества использования именно файла для хранения переменных? кроме как хранения всех переменных в одной записи не вижу плюсов
2. как понимаю, его нельзя замаскировать в логах? так как не соответствует требованиям к masked variable https://gitlab.com/help/ci/variables/README#masked-variable-requirements. для секретов это важно, не светиться в логах
3. возможно, я неправильно готовлю file variable. могли бы скинуть пример?

как хранить переменную?

так https://www.terraform.io/docs/configuration/functions/yamldecode.html#examples?

"{\"hello\": \"world\"}"

или так?

KEY:                value
ANOTHER_KEY:        another_value

Вопрос, у меня в TFE есть вариабл воркспейса a=1, из этого воркспейса я вызываю модуль. Будет ли в этом модуле доступна var.a?

надо будет пробрасывать до модуля

по дефолту не будет? нужен проброс?

module "blah" { a = var.a }

я понял. спасибо.

"{\"hello\": \"world\"}"

KEY:                value
ANOTHER_KEY:        another_value

Маскировать файл не надо, потому что его содержимое не попадает в логи. Содержимое файла волшебным образом в переменные не запишется. Речь шла о том, что массивы секретов не нужно гонять через переменные окружения, а лучше передать их файлом. yamldecode распарсит файл в мапу и в манифесте можно будет с этой мапой работать. Например, чтобы передать хеши паролей, на стороне gitlab можно сделать переменную типа file c именем TF_VAR_pwhash_file и содержимым вроде

alise: $h$ash1
bob: $h$ash2

а на стороне терраформа

variable "pwhash_file" {}

locals {
  pwhash = yamldecode(file(var.pwhash_file))
  alise_hash = local.pwhash["alise"]
}

alise: $h$ash1
bob: $h$ash2

variable "pwhash_file" {}

locals {
  pwhash = yamldecode(file(var.pwhash_file))
  alise_hash = local.pwhash["alise"]
}

спасибо, стало понятнее

AWS Cross Account assume role - нормальная практика?

вроде best practices - в чем вопрос?

политики только внимательно нужно смотреть

и trusted document

Короче у меня нет доступа к мастер аккаунту. Но есть права на  ассюм роль администратор

С = секьюрити

как терраформ понимает, какие ресурсы нужно дестроить https://www.terraform.io/docs/commands/destroy.html#usage ?

если This command accepts all the arguments and flags that the apply command accepts, with the exception of a plan file argument

не могу задестроить ресурсы, артефакты все на месте

$ terraform destroy -auto-approve

Destroy complete! Resources: 0 destroyed.

там же ниже написано The behavior of any terraform destroy command can be previewed at any time with an equivalent terraform plan -destroy command.

все что описано в ТФ коде и есть в стейте