terraform 提供程序块中的动态变量答案

【问题标题】：Dynamic variable in terraform provider blockterraform 提供程序块中的动态变量
【发布时间】：2021-05-03 03:32:59
【问题描述】：

我有这个sn-p：

provider "aws" {
   region = "eu-west-1"
   
   assume_role {
       role_arn = "arn:aws:iam::123456789011:role/MyRole"
   }

}

我想知道是否有某种方法可以从创建它的 cloudformation 堆栈动态获取此角色。澄清一下，类似这样的事情（我知道这行不通）

    data "aws_iam_role" "myrole" {
      name = "MyRole"
    }

    provider "aws" {
   region = "eu-west-1"
   
   assume_role {
       role_arn = data.aws_iam_role.myrole.arn
   }

}

我可以通过数据块获取此信息，但不能在提供程序内部，因为它会导致循环（这是有道理的），但提供程序必须在执行任何操作之前执行该角色的假设角色。

有没有办法在提供者被实例化后立即触发承担角色？

p.s 由于某些架构原因，我无法修改触发 terraform 的方式，因此从命令行传递角色 arn 作为参数是不可行的。

谢谢！

【问题讨论】：

要使其正常工作，您已经需要有工作的提供者才能访问 aws。在创建提供程序之前如何访问 aws？
是的，这就是我的意思。我知道我不能这样做。真正的问题是：我如何才能为我的提供者触发 aws -> 假设角色，突然之后提供者被启用？（aws 帐户的凭据由触发 terraform 的管道自动获取）

标签： terraform terraform-provider-aws

【解决方案1】：

如果您使用来自 AWS 提供商的数据源，您必须拥有 IAM 角色才能访问该账户。所以这条路是行不通的。

如果将这些 ARN 放在文件或变量中，您可以获取它们。如果您在每个环境中有不同的 AWS 账户，并且您希望基础设施保持干燥。你可以使用Terragrunt。

【讨论】：

好的，谢谢。我也有同样的想法，但我正在寻找确认：D

【解决方案2】：

对 AWS 的任何 API 请求都需要某种凭证，因此不可能完全消除有关凭证的假设。

但是，这里有一个可能的折衷方案：您可以为所有有权担任此角色的用户/角色提供一个额外的限制策略，仅允许查找角色。我认为这将是一项 IAM 政策，其行动具体为 iam:GetRole。然后，您可以使用替代（别名）提供程序配置来进行查找，然后使用结果填充默认提供程序配置：

provider "aws" {
  alias = "role_lookup"

  region = "us-west-1"
}

data "aws_iam_role" "assume" {
  provider = aws.role_lookup

  name = "MyRole"
}

provider "aws" {
  region = "us-west-1"

  assume_role {
    role_arn = data.aws_iam_role.assume.arn
  }
}

这不是典型的 Terraform 模式——一个提供者配置依赖于它自身的另一个实例并不常见——但它应该作为 Terraform 如何处理提供者之间依赖关系的逻辑扩展。

还值得注意的是，角色 ARN 完全系统地从角色名称和帐户 ID 派生，因此如果您愿意硬编码该假设（这似乎不太可能改变），那么上面还有另一个变体不需要主凭证具有查找 IAM 角色的特殊访问权限：

provider "aws" {
  alias = "identity"

  region = "us-west-1"
}

data "aws_caller_identity" "current" {
  provider = aws.identity
}

provider "aws" {
  region = "us-west-1"

  assume_role {
    role_arn = "arn:aws:iam::${data.aws_caller_identity.current.account_id}:role/MyRole"
  }
}

此方法的工作原理是获取与主凭据关联的帐户 ID，然后将该帐户 ID 插入 ARN，同时对角色名称进行硬编码。

在这两种情况下，我都假设您承担的角色与承担它的原则属于同一帐户。跨账户代入角色不会以这种方式工作，因为无法自动推断目标账户 ID，因此始终需要单独提供，例如通过输入变量。

【讨论】：