Terraform-provider-aws: 功能请求：添加对 CreateVPCAssociationAuthorization AWS API 的支持

@RyanJarv我不知道自从提供商拆分后您是否看过这里。 如果您想帮助解决此问题，请告诉我。

应该只需要针对特定​​区域创建授权资源，以及源 vpc id 和源 vpc 区域的参数输入。

很想看到这个实现。

编辑：刚刚意识到这最终可能难以实施。 在我看来，区域所有者帐户必须创建授权，然后 VPC 所有者帐户必须执行关联，但随后无权描述关联。 如果手动创建授权，然后使用terraform创建关联； 将创建关联，但应用将失败，所有后续计划和应用都将失败，因为为了刷新资源，必须描述区域，但没有权限这样做。

@josephholsten嘿，对不起，是的，那太棒了，我只是很忙，不知道什么时候才能有时间回到这个

值得一提的是，这实际上目前确实可以用于创建授权，但就像@Zordrak指出关联资源无法描述 route53 区域并且当前失败。 这在https://github.com/hashicorp/terraform/pull/12553

如果我们不介意当前协同工作的关联和授权资源，这可能会与一些添加的文档和有关该问题的注释合并。

有人仍然有兴趣尝试推出此功能吗？

提前清理了一下，并在https://github.com/terraform-providers/terraform-provider-aws/pull/2005 中添加了文档

惊人的！ 这将非常有用！ 感谢您的辛勤工作！

同意。 解决这个问题会非常有帮助。 同时，我使用 AWS CLI 将 Route53 VPC 关联从位于一个 AWS 账户中的 VPC 关联到位于不同 AWS 账户中的 Route53 托管区域。 以下是步骤： https :

在一个 AWS 账户中创建的托管区域与在第二个 AWS 账户中创建的 VPC 之间创建关联时，Route 53 API 的工作方式存在问题。

此 Terraform 代码（遵循此处的步骤，并基于此代码）

provider "aws" {
  // Zone creator's credentials.
}

provider "aws" {
  alias = "bar"
  // VPC creator's credentials.
  access_key = "XXXXXXXXXXXXXXXXXXXX"
  secret_key = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}

resource "aws_vpc" "foo" {
  cidr_block           = "10.6.0.0/16"
  enable_dns_hostnames = true
  enable_dns_support   = true
}

resource "aws_route53_zone" "foo" {
  name   = "example.com"
  vpc_id = "${aws_vpc.foo.id}"
}

resource "aws_vpc" "bar" {
  provider = "aws.bar"

  cidr_block           = "10.7.0.0/16"
  enable_dns_hostnames = true
  enable_dns_support   = true
}

resource "aws_route53_zone_association_authorization" "foo" {
  zone_id = "${aws_route53_zone.foo.id}"
  vpc_id  = "${aws_vpc.bar.id}"
}

resource "aws_route53_zone_association" "bar" {
  provider = "aws.bar"

  zone_id = "${aws_route53_zone_association_authorization.foo.zone_id}"
  vpc_id  = "${aws_vpc.bar.id}"
}

应该在两个不同的 AWS 账户中创建 VPC，并将它们都与在第一个 AWS 账户中创建的托管区域相关联。 事实上它正是这样做的，但报告了一个错误：

terraform apply
aws_vpc.bar: Creating...
  assign_generated_ipv6_cidr_block: "" => "false"
  cidr_block:                       "" => "10.7.0.0/16"
  default_network_acl_id:           "" => "<computed>"
  default_route_table_id:           "" => "<computed>"
  default_security_group_id:        "" => "<computed>"
  dhcp_options_id:                  "" => "<computed>"
  enable_classiclink:               "" => "<computed>"
  enable_classiclink_dns_support:   "" => "<computed>"
  enable_dns_hostnames:             "" => "true"
  enable_dns_support:               "" => "true"
  instance_tenancy:                 "" => "<computed>"
  ipv6_association_id:              "" => "<computed>"
  ipv6_cidr_block:                  "" => "<computed>"
  main_route_table_id:              "" => "<computed>"
aws_vpc.foo: Creating...
  assign_generated_ipv6_cidr_block: "" => "false"
  cidr_block:                       "" => "10.6.0.0/16"
  default_network_acl_id:           "" => "<computed>"
  default_route_table_id:           "" => "<computed>"
  default_security_group_id:        "" => "<computed>"
  dhcp_options_id:                  "" => "<computed>"
  enable_classiclink:               "" => "<computed>"
  enable_classiclink_dns_support:   "" => "<computed>"
  enable_dns_hostnames:             "" => "true"
  enable_dns_support:               "" => "true"
  instance_tenancy:                 "" => "<computed>"
  ipv6_association_id:              "" => "<computed>"
  ipv6_cidr_block:                  "" => "<computed>"
  main_route_table_id:              "" => "<computed>"
aws_vpc.bar: Creation complete after 6s (ID: vpc-951bcaec)
aws_vpc.foo: Creation complete after 5s (ID: vpc-b018c9c9)
aws_route53_zone.foo: Creating...
  comment:        "" => "Managed by Terraform"
  force_destroy:  "" => "false"
  name:           "" => "example.com"
  name_servers.#: "" => "<computed>"
  vpc_id:         "" => "vpc-b018c9c9"
  vpc_region:     "" => "<computed>"
  zone_id:        "" => "<computed>"
aws_route53_zone.foo: Still creating... (10s elapsed)
aws_route53_zone.foo: Still creating... (20s elapsed)
aws_route53_zone.foo: Still creating... (30s elapsed)
aws_route53_zone.foo: Creation complete after 35s (ID: Z3UMIQBZQ9Y13C)
aws_route53_zone_association_authorization.foo: Creating...
  vpc_id:     "" => "vpc-951bcaec"
  vpc_region: "" => "<computed>"
  zone_id:    "" => "Z3UMIQBZQ9Y13C"
aws_route53_zone_association_authorization.foo: Creation complete after 0s (ID: Z3UMIQBZQ9Y13C:vpc-951bcaec)
aws_route53_zone_association.bar: Creating...
  vpc_id:     "" => "vpc-951bcaec"
  vpc_region: "" => "<computed>"
  zone_id:    "" => "Z3UMIQBZQ9Y13C"
aws_route53_zone_association.bar: Still creating... (10s elapsed)
aws_route53_zone_association.bar: Still creating... (20s elapsed)
aws_route53_zone_association.bar: Still creating... (30s elapsed)
Error applying plan:

1 error(s) occurred:

* aws_route53_zone_association.bar: 1 error(s) occurred:

* aws_route53_zone_association.bar: AccessDenied: User: arn:aws:iam::000000000000:user/kit is not authorized to access this resource
    status code: 403, request id: c1f53cc1-f6fe-11e7-8456-41d8d6fcb1f8

Terraform does not automatically rollback in the face of errors.
Instead, your Terraform state file has been partially updated with
any resources that successfully completed. Please address the error
above and apply again to incrementally change your infrastructure.

和随后的terraform plan s 得到相同的错误：

terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

aws_vpc.bar: Refreshing state... (ID: vpc-951bcaec)
aws_vpc.foo: Refreshing state... (ID: vpc-b018c9c9)
aws_route53_zone.foo: Refreshing state... (ID: Z3UMIQBZQ9Y13C)
aws_route53_zone_association_authorization.foo: Refreshing state... (ID: Z3UMIQBZQ9Y13C:vpc-951bcaec)
aws_route53_zone_association.bar: Refreshing state... (ID: Z3UMIQBZQ9Y13C:vpc-951bcaec)
Error refreshing state: 1 error(s) occurred:

* aws_route53_zone_association.bar: 1 error(s) occurred:

* aws_route53_zone_association.bar: aws_route53_zone_association.bar: AccessDenied: User: arn:aws:iam::000000000000:user/kit is not authorized to access this resource
    status code: 403, request id: 22ab1eca-f700-11e7-aa35-9bd7d0c4ca7d

问题在于在关联器（即不是创建托管区域的 AWS 帐户）凭证下运行的代码正在读取区域关联https://github.com/terraform-providers/terraform-provider的状态
由于没有与 AWS 区域相关的资源，因此会查询区域本身，当从未创建区域的 AWS 账户调用时，会因 _AccessDenied_ 错误而失败。

@ewbankkit是的，这是 aws_route53_zone_association 的一个问题，并在我的 PR 中记录在https://github.com/terraform-providers/terraform-provider-aws/pull/2005/files#diff -f048cbf19e0fc509e5df5d05254f5bdb1

这也是我暂时推迟制作 PR 的原因，有些人无论如何都要求它，所以缺少更好的解决方案，我添加了关于该问题的注释（尽管现在查看它应该添加到aws_route53_zone_association文档也是如此）。 我确信这可以以某种方式解决，但是当时我没有想出任何让我觉得不舒服的东西。

问题的核心是无法枚举连接到VPC的Route53区域，因此aws_route53_zone_association资源通过在Route53区域上使用GetHostedZone来检查VPC是否连接，而需要进行关联的帐户通常不会可使用。

@RyanJarv
嗨，您是否考虑过需要第二个提供程序来进行 R53 api 调用？

如果它不是 TF 编码反模式/否，我很乐意为资源指定两个提供者。 我希望与上面示例中的关联同时创建授权，因此无论如何第二个提供程序都应该可用。

我有第二个想法，但从 AssociateVPCWithHostedZone API 参考中答案似乎并不明显，当尝试将已关联的 VPC 与区域关联时，您会得到什么错误/响应？ 响应是否适合用于确定 VPC 是否已经关联，而不是必须从区域获取 vpc 列表？

如果这些是明显的不，请原谅我的天真！ 😄

干杯，
乔希

@JoshiiSinfield如果我正确阅读了以上内容，那么@ewbankkit已经尝试过这样做（因此他的 TF 代码顶部有两个provider "aws"语句。

通过使用 aws cli，从记忆中，我认为当区域已经关联时，您确实会收到不同的消息。

@psyvision
是的，他有，只是我正在将第二个提供程序传递到 zone_association 资源中。

像这样的东西（假设使用了@ewbankkit的其余代码）::

resource "aws_route53_zone_association" "bar" {
  provider = "aws.bar"
  r53_zone_provider = "aws"

  zone_id = "${aws_route53_zone_association_authorization.foo.zone_id}"
  vpc_id  = "${aws_vpc.bar.id}"
}

这样，您就明确授予 zone_association 对 R53 区域的访问权限以调用 GetHostedZones。

我想我记得曾经考虑过类似的事情，
不确定我是不是认为这是不可能的，或者不确定如何去做
实施它。
如果它可行，虽然看起来是一个很好的解决方法。 但我可能
需要从这个 PR 中退后一步，如果有人是，那就太好了
能够在这里带头。

2018 年 3 月 12 日，星期一，凌晨 4:19，Josh Sinfiel

@psyvision[1]
是的，他有，但我正在考虑将第二个提供者传递给
zone_association 资源。>

像这样的东西（假设使用其余的
@ewbankkit[2] 的代码）::

资源“aws_route53_zone_association”“bar”{ provider =“aws.bar”
r53_zone_provider = "aws" zone_id =
"${aws_route53_zone_association_authorization.foo.zone_id}" vpc_id =
“${aws_vpc.bar.id}”}

— 您收到此消息是因为有人提到了您。 回复这个
直接发送电子邮件，在 GitHub 上查看[3]，或将线程静音[4]。>

链接：

1. https://github.com/psyvision
2. https://github.com/ewbankkit
3. https://github.com/terraform-providers/terraform-provider-aws/issues/384#issuecomment -372276327
4. https://github.com/notifications/unsubscribe-auth/AD5BQ8LoaLqV7ZM15A-91pD7c6H0tp5iks5tdlnYgaJpZM4N43FQ

相关：#585 和 #8593

大家好，还没来得及再研究这个，但确实想把它留在这里，结果 API 问题也有点安全问题。 大约两年前，当我最初从事此工作时，我向 AWS 安全部门报告了此问题，但不确定修复它的任何时间表。

https://blog.ryanjarv.sh/2019/05/24/backdooring-route53-with-cross-account-dns.html

大家好，我们已经决定目前在 API 限制范围内没有一种方法可以让我们很高兴地做到这一点。 请不要立即为该资源提交新的 PR。 我将把票作为上游问题打开，以重新考虑是否有变化。

对于解决方法，您可以改用 cli 说明： https :

嗨，我看到你们不想继续这个 PR，因为 API 没有一个好的方法来允许帐户查看它不拥有的 route53 区域上的 vpc 关联。 我认为该资源仍有用途，并且没有理由认为关联 API 中的限制会阻止您实现授权 API。 所有的碎片都在那里。 谁知道呢，也许一旦人们掌握了这一点，由 terraform 管理的全跨帐户 route53 关联的路径将更加清晰。

嗨，我能够使用多个数据源和资源来解决这个限制。 请让我知道这是否会被接受，因为那样我需要额外的时间来测试覆盖率。

@krogon这个问题以前可能已经解决了，这个问题充其量只是一个 hacky。 如果您认为自己有一个很好的解决方案并且在某处提供代码，我很乐意查看它。

为什么不简单地将其拆分为具有延迟功能的两个资源？ 那么为 auth 资源指定一个提供者和为关联资源指定另一个提供者会很容易吗？ 当 99% 的基础设施都在 TF 中时，我们仍然需要执行一些 CLI 调用，这只是蹩脚！！！

@ipnextgen我现在对这些类型的解决方法是使用https://github.com/scottwinkler/terraform-provider-shell。

地形最终变得非常简单。 以下是安全中心邀请的示例。 基本上你调用资源并告诉它调用什么脚本。

resource "shell_script" "security_hub_membership" {
  lifecycle_commands {
    create = "./scripts/security_hub_invitation.sh create ${data.aws_caller_identity.security.account_id} ${local.account_info.id} ${local.account_info.email}"
    read   = "./scripts/security_hub_invitation.sh read ${data.aws_caller_identity.security.account_id} ${local.account_info.id}"
    delete = "./scripts/security_hub_invitation.sh delete ${data.aws_caller_identity.security.account_id} ${local.account_info.id}"
  }

  working_directory = path.module
}

然后我像这样构建了我所有的脚本

#!/usr/bin/env bash
set -e -x -o pipefail

## Goal: Provide a script that terraform shell provider can use to manage security hub invitations.

## Helpful function to assume a role and run an AWS command
## arguments:
## 1 -> account id
## 2..n -> aws cli arguments
function AWS_RUN_CMD_AS {
    ##Get temporary credentials for the account we were given
    CREDENTIALS=$(aws sts assume-role --role-arn arn:aws:iam::$1:role/YourRoleName \
        --role-session-name enable-security-hub)

    ##Setup the proper temp credentials and invoke the aws cli with the provided args
    AWS_ACCESS_KEY_ID=$(echo $CREDENTIALS | jq -r '.Credentials.AccessKeyId') \
    AWS_SECRET_ACCESS_KEY=$(echo $CREDENTIALS | jq -r '.Credentials.SecretAccessKey') \
    AWS_SESSION_TOKEN=$(echo $CREDENTIALS | jq -r '.Credentials.SessionToken') \
    aws "${@:2}"
}

## arguments:
## 1 -> Security account id
## 2 -> id of account to create membership for
## 3 -> email of account to create membership for
function create {
  ## implement create function
}

## arguments:
## 1 -> Security account id
## 2 -> account id to check status for
function read {
  ## implement read function
}

function update {
  echo "Update is not implemented."
  exit 6
}

## arguments:
## 1 -> Security account id
## 2 -> account id to delete membership
function delete {
  ##Implement delete function
}

case $1 in
  create)
    create "${@:2}"
    ;;
  read)
    read "${@:2}"
    ;;
  update)
    update "${@:2}"
    ;;
  delete)
    delete "${@:2}"
    ;;
  *)
    echo "Unrecognized command $1"
    exit 5
    ;;
esac

我不喜欢过多地使用 shell 提供程序，但这里的主要好处是我们可以获得正常的 CRUD 操作。 这允许我们做普通的 terraform 事情，而使用内置的 local-exec 实际上只允许您创建和删除（有点）。

创建一个脚本来运行 CLI 命令来创建/读取/删除 route53 授权应该非常简单。 读取操作的 json 输出像任何其他资源一样在 terraform 中可用，因此这应该非常无缝地适合您现有的设置。

@ipnextgen你误解了这个问题。

澄清一下，它一直是两个独立的部分。 核心问题是其中一个需要基本上使用两个提供程序，据我所知，没有一种方法可以很好地映射到当前使用 terraform 的方式。 将其分解为单独的资源，我相信这意味着让一个负责一半的 CRUD 操作，第二个负责另一个..这可能吗？ 我想？ 老实说，不知道这将如何工作。 如果您认为自己找到了一种有意义的方法，我很乐意查看与此相关的任何 PR。

编辑：好的，我想我之前说过这在技术上是可行的。 我不记得我当时在想什么。 不过，我现在可能会停止回应这个问题。

Edit2：如果有人想使用此功能，我可能会建议查看 Web 控制台如何获取相关区域的信息。 根据我的理解，虽然此信息无法通过非托管区域帐户的 API 获得，但它以某种方式通过 Web 控制台获得。

我刚打开这了这里的terraform回购＃24286，但并没有意识到这是已经在这里。

我想这只需要 2 个类似于如何设置对等连接的资源。
尊敬：
aws_vpc_peering_connection
aws_vpc_peering_connection_accepter

也许：
aws_route53_zone_authorization（新资源）如上所述
aws_route53_zone_association

目前，您可以使用 cli 手动完成此操作：

应用等价物

aws route53 create-vpc-association-authorization \
--hosted-zone-id ZAZAPAPAXAXAXAXAXA10 \
--vpc VPCRegion=us-east-1,VPCId=vpc-000bb00bb00bb00bb \
--profile profile_with_access_to_private_hosted_zone

aws route53 associate-vpc-with-hosted-zone \
--hosted-zone-id ZAZAPAPAXAXAXAXAXA10 \
--vpc VPCRegion=us-east-1,VPCId=vpc-000bb00bb00bb00bb \
--profile profile_with_access_to_vpc_in_secondary_account



md5-983ba3afd84f66ba433b9753f00800f5



```sh
aws route53 disassociate-vpc-from-hosted-zone \
--hosted-zone-id ZAZAPAPAXAXAXAXAXA10 \
--vpc VPCRegion=us-east-1,VPCId=vpc-000bb00bb00bb00bb \
--profile profile_with_access_to_vpc_in_secondary_account



md5-5e3a484a75e2d6f8cafa05260518a9a5



 module.associate_vpc_2_zone.aws_route53_zone_association.env: Creating...
 module.associate_vpc_2_zone.aws_route53_zone_association.env: Still creating... [10s elapsed]
 module.associate_vpc_2_zone.aws_route53_zone_association.env: Still creating... [20s elapsed]
 module.associate_vpc_2_zone.aws_route53_zone_association.env: Still creating... [30s elapsed]
 Error: AccessDenied: User: arn:aws:sts::333333333333:assumed-role/SomeRole/terraform is not authorized to access this resource
    status code: 403, request id: ae42ae42-ae42-ae42-ae42-ae42ae42ae42

但是，这会导致 vpc 成功关联到区域。
@RyanJarv是否会改变您对如何解决此问题的看法？

@RyanJarv是否会改变您对如何解决此问题的看法？

每次我看这篇文章时，我都有点忘记问题到底是什么，所以可能值得对我在这里所说的一切持保留态度。

关联需要在托管区域账户iirc中运行，所以报错是因为这个账户无法枚举当前关联。 似乎这仍然是我相信的问题？

这听起来不对，可能最好忽略我。 不过，我会尽快再次研究这个问题。

编辑：快速更新，我认为倒退了。 因此授权由托管区域帐户完成，关联由 VPC 帐户完成。 它失败了，因为 terraform 试图首先确定一个区域是否关联，但是您不能使用 API 来做到这一点，您没有读取该区域的权限。 如果该信息存储在本地，那么您应该能够执行此操作，但除此之外您无法知道您的帐户状态（我想我一直对 terraform 与安全部分感到困惑）。 因此，如果您取出关联资源上 CRUD 内容的读取部分，这应该可以工作（？）

如果资源是在 terraform 之外管理的，你会遇到问题。 也许这没问题，我不太确定。 我认为这主要是决定我们不想这样做，但也许这部分以前不清楚（实际上很确定这在以前并不明显，不过我需要阅读此线程）。

您在另一篇文章中提到了有关传递角色的内容（在我的手机上很难看），如果您能以某种方式授予读取该区域的访问权限，并且可能将其包含在应该如何使用的示例中，也许这也能起作用.

Edit2：另一部分是AWS建议在关联完成后删除授权。 但是 tbh 我不确定我是否理解这样做的原因，或者为什么您不希望重新关联 VPC。 我认为只是在文档中记下它可能没问题，我认为在线程中的某处对此进行了讨论，但现在没有看到它。

如果我在这里遗漏了什么，请告诉我。

@RyanJarv

因此，如果您取出关联资源上 CRUD 内容的读取部分，这应该可以工作（？）

是否正在解决我上面提到的 403 错误？ 我相信是这样。

如果资源是在 terraform 之外管理的，你会遇到问题。

我们严格来说只是将 VPC-Account B 关联到私有托管区域-Account A..​​ 我认为这没问题。

如果您可以以某种方式授予读取区域的访问权限，并且可以将其包含在示例中
这应该被使用，也许这也能工作。

如果没有在资源/模块（角色感知）中假设超过 1 个配置文件/别名的想法，这对于 terraform/aws 似乎不可行。 尽管仅指定了一个配置文件，但我质疑上述命令如何正常工作。 Route53 和 VPC 没有等效的 s3 存储桶策略功能，您可以在其中授予对不同账户中的 IAM 用户/角色的访问权限。

aws route53 associate-vpc-with-hosted-zone \
--hosted-zone-id ZAZAPAPAXAXAXAXAXA10 \
--vpc VPCRegion=us-east-1,VPCId=vpc-000bb00bb00bb00bb \
--profile profile_with_access_to_vpc_in_secondary_account

我主要指向我上面引用的 cli 命令。 用于应用和销毁工作的两种手动案例都非常完美，每个命令仅使用 1 个配置文件。 我想这会转化为 API .. 鉴于它只有我提供的输入。
在已关联后再次运行关联 cli 命令时。 我明白了。

An error occurred (ConflictingDomainExists) when calling the AssociateVPCWithHostedZone operation: The VPC that you chose, vpc-00000000000 in region us-east-1, is already associated with another private hosted zone that has an overlapping name space, somedomain.com..

这意味着它在知道它已经关联的情况下做得很好。 这来自无法直接访问“route53”帐户中的私有托管区域的 VPC 帐户的配置文件。

另一部分是 AWS 建议在关联完成后删除授权。 但是 tbh 我不确定我是否理解这样做的原因，或者为什么您不希望重新关联 VPC。

这是因为在关联之后，您不再需要对其进行授权。 我想就像你提到的，这可以在文档中注明......并且可能被忽略。

我想指出。

似乎这是@rginev于 2016 年 11 月 17 日（大约 3.5 年前）首次报道的
https://github.com/hashicorp/terraform/issues/10208

自那以后：

https://github.com/hashicorp/terraform/issues/11174（已关闭 -> ^10208）
https://github.com/hashicorp/terraform/issues/12804（已关闭 -> #617）
https://github.com/hashicorp/terraform/issues/20841（关闭无解决方案）
https://github.com/hashicorp/terraform/issues/22780（已关闭 -> #9453）
https://github.com/hashicorp/terraform/issues/24286（已关闭 -> 此处为 #384）

https://github.com/hashicorp/terraform/pull/12553 （@RyanJarv你的PR）

https://github.com/terraform-providers/terraform-provider-aws/issues/384（此处）
https://github.com/terraform-providers/terraform-provider-aws/issues/585（开放）
https://github.com/terraform-providers/terraform-provider-aws/issues/617（开放）
https://github.com/terraform-providers/terraform-provider-aws/pull/2005（关闭无解决方案）
https://github.com/terraform-providers/terraform-provider-aws/issues/7805（关闭无解决方案）
https://github.com/terraform-providers/terraform-provider-aws/issues/7812（已关闭-> #7805）
https://github.com/terraform-providers/terraform-provider-aws/issues/8593 （开放）
https://github.com/terraform-providers/terraform-provider-aws/issues/9453 （开放）

我可能错过了更多，我只是想指出这已经有一段时间了。

@ewbankkit @FransUrbo似乎都有很多与此相关的历史，并且可能仍然对此感兴趣？
@bflad （维护者？）
这也出现在一些研究中：
https://forums.aws.amazon.com/thread.jspa?threadID=271250

不久前我对此进行了很多思考，我的结论是在资源中捕获此 API 的行为与 AWS 提供商的工作方式不匹配 - 即单个资源的交互是在配置的单个 AWS 身份下完成的在资源中。
一种解决方案可能是创建包含此新资源的单独提供程序，并且此新提供程序配置有两个 AWS 身份。 复杂性都在于为底层 AWS 开发工具包配置这些身份的无数选项。
https://github.com/hashicorp/aws-sdk-go-base可能包含一些可重复使用的部分。

@ewbankkit

单个资源的交互是在资源中配置的单个 AWS 身份下完成的。

我不明白这个问题 tbh。
浏览：
API_CreateVPCAAssociationAuthorization
和
API_AssociateVPCWithHostedZone

似乎每个资源/api 调用/cli cmd 只需要一个 aws 身份。
我引用了第二个链接。

Use the AWS account that created the private hosted zone to submit a 
CreateVPCAssociationAuthorization request. Then use the account that created the VPC to submit
 an AssociateVPCWithHostedZone request.

If a subnet in the VPC was shared with another account, you can use the account that the subnet 
was shared with to submit an AssociateVPCWithHostedZone request. For more information about 
sharing subnets, see Working with Shared VPCs.

听起来它遵循我上面发布的命令。 https://github.com/terraform-providers/terraform-provider-aws/issues/384#issuecomment -595276897

你能解释一下具体是什么问题吗？

想在这个@ewbankkit上撞你，也许还有@RyanJarv
有什么想法吗？ 当您有许多帐户使用另一个帐户中的私有托管区域时，这有点难以管理。

有没有人知道 terraform 中的任何示例，其中跳过了 CRUD 的读取部分，而让其他操作仅依赖于状态文件中的数据？

我遇到了同样的问题，并希望看到一个解决方案，或者至少有一些额外的文档来概述这个场景，然后更多的人最终运行它并找到这个问题。

或者，是否可以有一个 IAM 策略，允许 VPC 的账户在托管区域的账户上列出托管区域作为解决方法？

我也遇到了这个问题，我认为任何试图通过 terraform 跨帐户使用私有托管区域的人都会遇到这个问题。 管理多个 aws 帐户在大公司中是一个非常常见的用例，并且 aws 似乎建议将其作为组织内的架构。 看到这个问题多年来没有得到解决，真是令人失望。

只是自己遇到这个问题。

有使用解析器端点的方法（在 _phz-provider_ 入站，在 _phz-consumer_ 出站），但这些端点由 aws 单独收费，最好避免使用“直接”phz 收取额外费用 <-> vpc 关联替代。

根据这篇知识库文章，它展示了如何通过 cli 完成授权。

我可以/将尝试自己，但我想我会在这个线程中向有经验的参与者提出这个问题：

假设 __authorization__ 部分是在 _phz-provider_ 帐户的上下文中手动完成的，在 _phz-consumer_ 帐户的上下文中使用aws_route53_zone_association 会起作用吗？

大家好， @miketwenty1指出您可以从重复调用该 API 后返回的错误消息中获取aws_route53_zone_association的状态后，我再次研究了这个问题。

我在https://github.com/terraform-providers/terraform-provider-aws/compare/master...RyanJarv :cross-account-hostedzone-association 中整理了一些东西来测试这一点。

现在这只是一个测试，所以这里的任何想法都值得赞赏。 在该分支中，我在aws_route53_zone_association资源上使用 cross_account 属性来更改读取和等待部分完成方式的行为。

所以在那个分支 if cross_account = true ：

• 我们只依赖本地状态来读取函数
• 我们没有调用 get-wait 来确定何时创建完成，而是重复调用 AssociateVPCWithHostedZone 并等待错误消息通知我们该区域已关联。

这似乎工作正常，但目前但存在以下问题：

• 无法检测aws_route53_zone_association资源的漂移。
• 关联授权的工作流程仍然不会遵循此处的第 7 步https://aws.amazon.com/premiumsupport/knowledge-center/private-hosted-zone-different-account/。

我不认为第二个真的是一个问题，但想提一下，因为它之前被提出过。
对于第一个，可能能够处理一些事情，例如在计划期间总是显示更改，并以某种方式表明它实际上可能不会导致更改。 这种行为也可能通过 cross_account 选项之类的东西来切换。

现在主要想发布这个，看看是否有人对我链接的分支中的这种行为有任何意见，以及关于处理漂移的任何想法。

@evandam

或者，是否可以有一个 IAM 策略，允许 VPC 的账户在托管区域的账户上列出托管区域作为解决方法？

使用假设角色是的，但是 terraform afik 并非旨在连接到单个资源中的多个帐户。 如果可以在没有假设角色的情况下做到这一点，这将更可行。 我无法弄清楚这些选项中的任何一个，但至少以一种有意义的方式。

@托尼-克尔兹

假设授权部分是在 phz-provider 帐户的上下文中手动完成的，那么在 phz-consumer 帐户的上下文中使用 aws_route53_zone_association 会起作用吗？

这不起作用，在大多数情况下 aws_route53_zone_association 是问题所在。 如果您想尝试我上一篇文章中可能对您有用的分支（警告：尚未对其进行太多测试）。

我们也遇到过这个问题。 试图建立一个拥有 DNS 的临时组织被证明是一个相当大的挑战。

这... _bug_？ 随着 IAC 时代产生的企业逐渐融入多账户架构，我可能会在 AWS 的建议下补充说，这些企业将变得越来越相关！

我也很想看到这个问题的干净解决方案，我知道这是一个复杂的问题！

我尝试使用 null_resource 来调用 CLI 并进行关联。 问题在于，当您创建区域时，您无法指定其他帐户 VPC 或出现错误，因此在第一次运行所有内容并且 VPC 与区域关联后，terraforms 试图从托管区。 目前这一切都很难处理。

现在处理此问题的一种半“干净”方法是创建一个公共托管区域并记录指向私有 DNS。 与上面的解析器端点解决方案一样，当然根据域的选择，实施成本更高。

对于任何感兴趣的人，我最终实施的方式如下：

# new private zone in account_a
resource "aws_route53_zone" "private" {
  name     = local.zone_name
  tags     = local.tags
}

# This is run in context of account_a which has the hosted zone
resource "null_resource" "associate_zone_to_account_b" {
  triggers = {
      always = timestamp()
  }
  provisioner "local-exec" {
    command = "New-R53VPCAssociationAuthorization -HostedZoneId ${aws_route53_zone.private.id} -VPC_VPCId ${local.account_b_id} -VPC_VPCRegion ${var.account_b_region}"
    interpreter = ["PowerShell", "-Command"]
  }
}

# This is run in context of account_b which has the vpc - using STS
resource "null_resource" "associate_zone_to_account_b_authorise" {
  triggers = {
    resource_id = null_resource.associate_zone_to_account_b.id
  }
  provisioner "local-exec" {
    command = ". ${path.module}\\R53HostedZoneAssociation.ps1 ; Register-HostedZoneWithOtherAccountVpc -VpcId ${local.account_b_id} -VpcRegion ${local.account_b_region} -HostedZoneId ${aws_route53_zone.private.id} -STSRole ${local.sts_role}"
    interpreter = ["PowerShell", "-Command"]
  }
}

以上的效果是我可以重新运行这个 terraform 并达到与 account_b VPC 关联的区域的相同结果。 这并不漂亮，因为在每次运行时它都会删除关联然后重新添加，但它有效。
New-R53VPCAssociationAuthorization调用 CreateVPCAssociationAuthorization API 操作
Register-HostedZoneWithOtherAccountVpc使用提供的角色对 account_b 进行身份验证，然后调用 AssociateVPCWithHostedZone API 操作。

您需要具有脚本可以承担的适当权限的角色。

https://aws.amazon.com/about-aws/whats-new/2020/06/amazon-route-53-launches-new-api-action-to-list-private-hosted-zones-related-with-你的亚马逊 vpcs 🎉

需要AWS SDK v1.32.5 ：

• https://github.com/terraform-providers/terraform-provider-aws/pull/13803

@tdmalone发布

有可能很快将其添加到提供程序中吗？ 给出的解决方法对 aws cli 使用本地 exec，这是我们在使用 Terraform Enterprise 时极力避免的事情。 此外，我们现在将进入 100 多个帐户 - 对外部的依赖越少越好:)

@arnvid在上述 PR 上复制 Brian 的更新：

在我们在接下来的一两周内完成 3.0 的工作后立即将其标记为正确，尽管审核周期可能会在 3.1 之后进行实际发布。 👍

所以，这很快就会有希望！ 🎉

通过新的aws_route53_vpc_association_authorization资源和更新的aws_route53_zone_association资源处理对 Route 53 跨账户 VPC 关联的支持已合并，并将与 Terraform AWS Provider 的 3.1.0 版一起发布，可能在今天晚些时候发布。 感谢@goakley和@RyanJarv的实施。 👍

这已在 Terraform AWS provider 的 3.1.0 版中发布。 请参阅有关提供程序版本控制的

有关此功能的更多功能请求或错误报告，请按照分类模板创建新的 GitHub 问题。 谢谢！

我将锁定此问题，因为它已关闭 _30 天_⏳。 这有助于我们的维护人员找到并关注活跃的问题。

如果你觉得这个问题应该重新打开，我们鼓励创建一个新的问题，链接回这个问题以增加上下文。 谢谢！