HashiCorp Terraform 如何基于表达式动态启停策略语句内的condition块

问题1：Terraform是否支持直接用表达式控制单个condition块的启停？ #

不支持。
原因如下：

• Terraform的配置块本身是静态结构定义，不存在内置的enabled类开关参数来临时跳过某个配置块的生成；
• 以AWS Provider中IAM策略的condition块为例，它只接受test、variable、values三个固定参数，手动在块内写enabled = var.xxx这类自定义属性会直接触发配置校验报错，完全无法运行。

问题2：实现动态启停condition块的等效可行方案 #

最贴合需求、无副作用的标准实现方式是使用Terraform内置的dynamic嵌套块语法——这个功能的设计初衷就是用来动态控制嵌套子块的生成/省略，完全匹配你对condition块做运行时启停的需求。

实现代码参考 #

statement {
  sid = "DevOnlyPrincipalRestriction"
  effect = "Deny"
  actions = ["s3:PutObject"]

  # 静态的、不受动态逻辑影响的condition块直接保留即可
  condition {
    test     = "StringEquals"
    variable = "s3:x-amz-acl"
    values   = ["public-read"]
  }

  # 需要动态启停的condition块替换为dynamic生成逻辑
  dynamic "condition" {
    # 循环集合的判断逻辑直接控制块的生成数量：满足dev环境则生成1个，不满足则生成0个
    for_each = var.environment == "dev" ? [1] : []

    # 原来的condition块内容完全写在content块内即可，和手写结构无差异
    content {
      test     = "ArnNotEquals"
      variable = "aws:PrincipalArn"
      values   = [var.needed_arn]
    }
  }
}

方案效果说明 #

• 当判断条件不满足（非dev环境）时，for_each返回空集合，Terraform不会在最终生成的策略JSON中输出对应的condition块，和手动删除该块的效果完全一致；
• 当判断条件满足（dev环境）时，dynamic块会正常生成和手写结构完全一致的condition配置，IAM引擎的解析逻辑没有任何区别。

常见踩坑提醒 #

要避开一个常见误区：别想着靠把condition的values设成空数组、或者把匹配规则改成永远命中的方式来假装禁用块。因为只要块本身还存在于策略结构里，IAM引擎对空值condition的处理逻辑和块彻底不存在的状态是完全不一样的，轻则导致策略行为不符合预期，重则引发权限配置的安全问题。

内容的提问来源于stack exchange，提问作者Sergey Shafiev