Модули Terraform имеют переменные для разных частей. Вещи, которые не должны меняться, должны быть жестко закодированы как лучшая практика.
В противном случае вы будете создавать модули, которые ничего не делают и принимают код в качестве ввода.
Любые достаточно сложные [ Dynami c Модуль Terraform] содержит ad ho c, неофициально определенный, с ошибками, медленная реализация половины [самой Terraform] ..
ремикс десятого Гринспуна rule
data "aws_iam_policy_document" "assume_role_policy" {
statement {
sid = "AllowAssumeRole"
effect = "Allow"
actions = [
"sts:AssumeRole",
]
resources = var.trusted_arns
}
}
Вы можете предоставить доступ к набору AWS сегментов в виде переменной, подобной этой:
statement {
sid = "AllowS3Access"
effect = "Allow"
actions = [
"s3:GetBucketLocation",
"s3:ListBucket",
"s3:ListBucketMultipartUploads",
"s3:GetObject",
"s3:ListMultipartUploadParts",
"s3:AbortMultipartUpload",
]
resources = var.allowed_read_only_s3_bucket_arns
}
Если вы хотите создать динамику c Политики, которые вы можете сделать так:
data "aws_iam_policy_document" "meta_policy" {
dynamic "statement" {
for_each = var.statements
content {
sid = each.key
effect = each.value.effect
actions = each.value.actions
resources = each.value.resources
}
}
}
Будет использоваться с такой переменной:
variable "statements" {
description = "I didn't want to use resources, so I made meta-Terraform"
type = map(object(
{
sid = string
effect = string
actions = list(string)
resources = list(string)
}
))
}
Кто-то, глядя на такой модуль, не сможет узнать, что ему нужно, и полагаться исключительно на входные переменные. Может быть, это подходит для вашего случая использования, но я рекомендую против этого.
Ваши коллеги, в том числе и ваше будущее я, будут вам благодарны, если вы примете на вооружение вещи, которые на самом деле не меняются.