Terraform创建关联多策略的IAM角色最佳实践及模块输出问题咨询

核心卡点的直接解法 #

之前卡在模块内无法返回聚合ARN列表，本质是对带count参数的Terraform资源集合类型理解不到位：只要资源块配置了count，该资源在Terraform的类型系统里天然就是一个列表类型的集合，不需要依赖模块内的count上下文做遍历，直接用属性展开语法就能收集所有实例的属性值，不需要额外写复杂聚合逻辑。

create_policy 模块内部实现 #

入参定义 #

模块需要声明两个固定入参，适配多分组调用的场景：

• policy_name_prefix：字符串类型，用来标识当前创建的策略归属，避免不同分组的策略命名冲突
• policy_documents：列表类型，每个元素是对应策略的JSON格式文档，由上层调用方传入

批量创建策略的资源块 #

resource "aws_iam_policy" "this" {
  count = length(var.policy_documents)

  name_prefix = "${var.policy_name_prefix}-${count.index}"
  policy      = var.policy_documents[count.index]
}

聚合返回ARN列表的Output配置 #

直接通过属性展开语法收集所有策略实例的ARN，无需额外循环逻辑：

output "policy_arns" {
  value       = aws_iam_policy.this[*].arn
  type        = list(string)
  description = "当前模块实例创建的所有IAM策略的ARN列表"
}

这里的[*]语法会自动遍历每个count索引对应的资源实例，把每个实例的arn属性收集为string类型的列表，完全匹配多策略批量创建的场景。

主调用侧的全流程串联 #

第一步：按资源分组整理策略文档源 #

按照规划，把两类资源对应的策略文档用独立的data源管理，分别匹配3个、4个的数量要求：

# 第一类资源的3个IAM策略文档
data "aws_iam_policy_document" "resource_type_a" {
  count = 3
  # 按count.index逐一定义每个策略的权限规则
}

# 第二类资源的4个IAM策略文档
data "aws_iam_policy_document" "resource_type_b" {
  count = 4
  # 按count.index逐一定义每个策略的权限规则
}

第二步：分模块实例创建两组独立策略 #

不要把两组策略混在同一个模块实例中创建，分别调用两次create_policy模块，从结构上避免权限串配：

# 为第一类资源创建专属策略
module "iam_policies_for_a" {
  source = "./modules/create_policy"

  policy_name_prefix = "res-type-a"
  policy_documents   = data.aws_iam_policy_document.resource_type_a[*].json
}

# 为第二类资源创建专属策略
module "iam_policies_for_b" {
  source = "./modules/create_policy"

  policy_name_prefix = "res-type-b"
  policy_documents   = data.aws_iam_policy_document.resource_type_b[*].json
}

此时两个模块实例的输出已经天然返回了对应分组的策略ARN列表：

• module.iam_policies_for_a.policy_arns 长度为3，对应第一类资源的全部策略
• module.iam_policies_for_b.policy_arns 长度为4，对应第二类资源的全部策略

第三步：创建独立角色并批量挂载策略 #

直接引用模块返回的ARN列表，通过count批量完成策略挂载：

# 第一类资源专属角色
resource "aws_iam_role" "resource_type_a" {
  name = "role-for-resource-type-a"
  assume_role_policy = jsonencode({
    # 角色信任关系配置
  })
}

# 批量挂载第一类资源的所有策略
resource "aws_iam_role_policy_attachment" "resource_type_a" {
  count = length(module.iam_policies_for_a.policy_arns)

  role       = aws_iam_role.resource_type_a.name
  policy_arn = module.iam_policies_for_a.policy_arns[count.index]
}

# 第二类资源专属角色
resource "aws_iam_role" "resource_type_b" {
  name = "role-for-resource-type-b"
  assume_role_policy = jsonencode({
    # 角色信任关系配置
  })
}

# 批量挂载第二类资源的所有策略
resource "aws_iam_role_policy_attachment" "resource_type_b" {
  count = length(module.iam_policies_for_b.policy_arns)

  role       = aws_iam_role.resource_type_b.name
  policy_arn = module.iam_policies_for_b.policy_arns[count.index]
}

落地最佳实践 #

• 统一命名规范：两类资源对应的所有策略、角色必须配置固定的专属前缀，比如第一类资源统一加res-a-前缀，第二类加res-b-前缀，降低后续权限审计的成本
• 避免count索引波动：使用count做批量资源管理时，新增策略必须往列表末尾追加，不要在列表中间插入新条目，否则会因为索引偏移触发Terraform批量销毁重建所有已有策略，引发线上权限短暂中断
• 公共权限抽离：如果存在两类资源都需要的通用权限（比如云服务日志上报权限），不要在两个分组里重复创建相同策略，单独通过公共模块创建一次，把返回的ARN分别加入两个角色的挂载列表，减少冗余资源
• 增加类型约束：所有涉及列表输出的模块配置，一定要显式声明type = list(string)，避免因为传参格式错误引发类型不匹配的运行时报错
• 结构隔离：从代码结构上严格分开两类资源的角色、策略配置逻辑，不要写共用的循环逻辑同时处理两类资源的权限，避免误配引发的权限蔓延风险

内容的提问来源于stack exchange，提问作者Farhad Kocharli