Terraform-provider-aws: طلب الميزة: إضافة دعم لـ CreateVPCAssociationAuthorization AWS API

RyanJarv لا أعرف ما إذا كنت قد بحثت هنا منذ انقسام الموفر. اسمحوا لي أن أعرف إذا كنتم تريدون المساعدة في حل هذه المشكلة معًا.

يجب أن يتطلب فقط إنشاء مورد تفويض مقابل منطقة معينة ، مع مدخلات المعلمات لمعرف vpc المصدر ومنطقة vpc المصدر.

أتمنى أن أرى هذا مطبق

تحرير: أدركت للتو مدى صعوبة تنفيذ ذلك. يبدو لي أن حساب مالك المنطقة يجب أن ينشئ ترخيصًا ، ويجب على حساب مالك VPC بعد ذلك إجراء الاقتران ، ولكن بعد ذلك ليس لديه إذن لوصف الاقتران. إذا قمت بإنشاء ترخيص يدويًا ثم استخدمت terraform لإنشاء الارتباط ؛ سيتم إنشاء الاقتران ولكن التطبيق سيفشل وستفشل جميع الخطط والتطبيقات اللاحقة لأنه من أجل تحديث المورد ، يجب وصف المنطقة ، لكن الإذن غير متاح للقيام بذلك.

josephholsten مرحبًا آسف ، نعم ، سيكون ذلك رائعًا ، لقد كنت مشغولًا جدًا ولست متأكدًا من الوقت الذي سيكون فيه لدي وقت للعودة إلى هذا.

تجدر الإشارة إلى أن هذا يعمل بالفعل حاليًا لإنشاء التراخيص ولكن مثل https://github.com/hashicorp/terraform/pull/12553

إذا كنا لا نمانع في عمل مورد الإقران والتفويض معًا حاليًا ، فمن المحتمل أن يتم دمج هذا مع بعض المستندات المضافة وملاحظة حول المشكلة.

هل لا يزال أي شخص مهتمًا بمحاولة إخراج هذه الميزة؟

تقدمت وقم بتنظيف هذا الأمر قليلاً وإضافة الوثائق في https://github.com/terraform-providers/terraform-provider-aws/pull/2005. آخر العلاقات العامة كانت قبل انقسام الريبو.

مذهل! وسيكون هذا مفيدا جدا! شكرا على العمل الشاق!

متفق. إصلاح هذا سيكون مفيدًا جدًا. في هذه الأثناء ، استخدمت AWS CLI لإجراء اقتران Route53 VPC من VPC الموجود في حساب AWS واحد إلى Route53 Hosted Zone الموجودة على حساب AWS مختلف. فيما يلي الخطوات: https://aws.amazon.com/premiumsupport/knowledge-center/private-hosted-zone-different-account/

هناك مشكلة في طريقة عمل Route 53 API عند إنشاء ارتباط بين منطقة مستضافة تم إنشاؤها في حساب AWS واحد و VPC تم إنشاؤه في حساب AWS ثانٍ.

كود 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}"
}

يجب إنشاء VPCs في حسابي AWS مختلفين وربطهما بمنطقة مستضافة تم إنشاؤها في حساب 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 / blob / 17a320b90f85a7e98e19f2b405d0526b640f4880 / aws / Resource_aws_route53_zone_association.go # L94 -L95
نظرًا لعدم وجود مورد مرتبط بمنطقة AWS ، يتم الاستعلام عن المنطقة نفسها وفشل هذا مع الخطأ _AccessDenied_ عند الاتصال من حساب AWS الذي لم ينشئ المنطقة.

ewbankkit نعم ، هذه مشكلة مع aws_route53_zone_association وموثقة في العلاقات العامة الخاصة بي على https://github.com/terraform-providers/terraform-provider-aws/pull/2005/files#diff -f048cbf19e0fc509e5df5d05134.

كان هذا أيضًا هو السبب الذي جعلني أؤجل إجراء هذه العلاقات العامة لبعض الوقت ، حيث طلب بعض الأشخاص ذلك بغض النظر ، لذا أضفت ملاحظة حول المشكلة (على الرغم من النظر إليها الآن ، يجب إضافتها إلى aws_route53_zone_association doc أيضًا). أنا متأكد من أنه يمكن حل هذا الأمر بطريقة ما ، لكنني لم أتوصل إلى أي شيء لم أشعر به في ذلك الوقت.

يتمثل جوهر المشكلة في أنه لا يمكنك تعداد مناطق Route53 المرفقة بـ VPC ، لذلك يتحقق مورد aws_route53_zone_association لمعرفة ما إذا كان VPC مرفقًا باستخدام GetHostedZone في منطقة Route53 التي لا يحتاجها الحساب عادةً إلى الارتباط الوصول الى.

تضمين التغريدة
مرحبًا ، هل فكرت في طلب مزود ثان لإجراء مكالمة R53 api معه؟

إذا لم يكن نمطًا مضادًا لتشفير TF ، فسأكون سعيدًا بالحاجة إلى تحديد مزودين لمورد ما. أتوقع أن يتم إنشاء التفويض في نفس وقت إنشاء الاقتران كما يفعل المثال أعلاه ، لذلك يجب أن يكون الموفر الثاني متاحًا على أي حال.

لدي فكرة ثانية ، ولكن الإجابة لا تبدو واضحة من مرجع AssociateVPCWithHostedZone API ، ما هو الخطأ / الاستجابة التي تحصل عليها عند محاولة ربط VPC مرتبط بالفعل بمنطقة؟ هل الاستجابة مناسبة لاستخدامها في تحديد ما إذا كان VPC مرتبطًا بالفعل أم لا ، بدلاً من الاضطرار إلى الحصول على قائمة vpcs من المنطقة؟

اعذروني على سذاجتي إذا كان من الواضح أن هذه لا! 😄

هتافات،
جوش

JoshiiSinfield إذا كنت أقرأ ما ورد أعلاه بشكل صحيح ، فقد حاول ewbankkit بالفعل القيام بذلك (ومن هنا جاءت provider "aws" أعلى كود TF الخاص به.

من خلال استخدام aws cli ، من الذاكرة ، أعتقد أنك تحصل على رسالة مختلفة عندما تكون المنطقة مرتبطة بالفعل.

تضمين التغريدة
نعم ، لقد فعل ذلك ، باستثناء أنني كنت على وشك تمرير مزود ثانٍ إلى مورد zone_assembly.

شيء من هذا القبيل (بافتراض استخدام باقي كود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.

أعتقد أنني أتذكر التفكير في شيء من هذا القبيل في وقت ما ،
لست متأكدًا مما إذا كنت لا أعتقد أنه كان ممكنًا أو لم أكن متأكدًا من كيفية القيام بذلك
تنفيذه.
إذا كان ذلك ممكنًا ، يبدو أنه عمل جيد جدًا. لكن ربما
بحاجة إلى التراجع عن هذا العلاقات العامة وسيكون رائعًا إذا كان البعض كذلك
قادرة على أخذ زمام المبادرة هنا.

يوم الإثنين 12 مارس 2018 الساعة 4:19 صباحًا ، جوش سينفيل

psyvision [1]
نعم ، لقد فعل ذلك ، باستثناء أنني كنت على وشك تمرير مزود ثانٍ إلى
موارد ارتباط المنطقة.>

شيء من هذا القبيل (بافتراض استخدام بقية
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

مرحبًا بالجميع ، لم يجرؤ على النظر في هذا الأمر مرة أخرى حتى الآن ولكنهم يريدون ترك هذا هنا ، فقد تبين أن مشكلة واجهة برمجة التطبيقات تمثل أيضًا مشكلة أمنية إلى حد ما. لقد أبلغت عن ذلك إلى أمان AWS منذ حوالي عامين عندما كنت أعمل على هذا في الأصل ولكني لست متأكدًا من أي جدول زمني لإصلاحه.

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

مرحبًا بالجميع ، لقد قررنا أنه لا توجد طريقة يسعدنا القيام بذلك حاليًا ضمن قيود واجهة برمجة التطبيقات. من فضلك لا ترسل علاقات عامة جديدة للمورد الآن. سأترك التذكرة مفتوحة كقضية أولية لإعادة النظر إذا تغير شيء ما.

للحصول على حل بديل ، يمكنك استخدام تعليمات cli بدلاً من ذلك: https://aws.amazon.com/premiumsupport/knowledge-center/private-hosted-zone-different-account/

مرحبًا ، أرى أنكم لا تريدون المضي قدمًا في العلاقات العامة هذه لأن واجهة برمجة التطبيقات لا تملك طريقة جيدة للسماح لحساب ما بعرض ارتباطات vpc على منطقة route53 لا تمتلكها. أعتقد أنه لا تزال هناك استخدامات لهذا المورد ولا أرى أي سبب يجعل القيود المفروضة على ارتباطات API تمنعك من تنفيذ التراخيص API. كل القطع هناك. ومن يدري ، ربما بمجرد أن يضع الناس أيديهم على هذا ، سيكون الطريق إلى جمعيات الطريق عبر الحسابات الكاملة التي تديرها terraform أكثر وضوحًا.

مرحبًا ، لقد تمكنت من حل هذه القيود باستخدام مصادر وموارد بيانات متعددة. يرجى إعلامي إذا كان سيتم قبول هذا ، حيث سأحتاج إلى وقت إضافي لاختبار التغطية.

@ krogon كان من الممكن حل المشكلة من قبل ، كانت المشكلة دائمًا أنها اختراق في أحسن الأحوال. إذا كنت تعتقد أن لديك حلًا جيدًا ولديك الكود في مكان ما ، فسيسعدني إلقاء نظرة عليه.

لماذا لا نقسمها ببساطة إلى مصدرين مع ميزة تأخير؟ هل سيكون من السهل بعد ذلك تحديد موفر لمصدر المصادقة وآخر لمصدر الارتباط؟ ما زلنا بحاجة إلى إجراء بعض مكالمات CLI عندما يكون 99 ٪ من البنية التحتية كلها في TF !!!

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 العادية. هذا يسمح لنا بالقيام بأشياء طبيعية ، في حين أن استخدام local-exec المدمج يتيح لك فقط إنشاء وحذف (نوعًا ما).

يجب أن يكون إنشاء برنامج نصي لتشغيل أوامر CLI لإنشاء / قراءة / حذف أذونات route53 مباشرة إلى الأمام. يتم توفير إخراج json من عملية القراءة في شكل تضاريس مثل أي مورد آخر ، لذا يجب أن يتلاءم هذا بسلاسة مع إعدادك الحالي.

ipnextgen أنت تسيء فهم المشكلة.

للتوضيح ، كانت دائمًا قطعتين منفصلتين. المشكلة الأساسية هي واحدة من تلك القطع التي تحتاج إلى استخدام مزودين اثنين بشكل أساسي ، وبقدر ما أدرك أنه لا توجد طريقة للقيام بذلك تحدد بشكل جيد كيفية استخدام التضاريس حاليًا. تقسيم هذا إلى موارد منفصلة ، أعتقد أن هذا يعني أن يكون أحدهما مسؤولاً عن نصف عمليات CRUD والثاني عن الآخر .. ربما هذا ممكن؟ أقترح - أرى - أحبذ؟ بصراحة ليس لدي أي فكرة عن كيفية عمل هذا بالرغم من ذلك. يسعدني مراجعة أي علاقات عامة متعلقة بهذا الأمر إذا كنت تعتقد أنك وجدت طريقة للقيام بذلك تكون منطقية.

تحرير: حسنًا ، أعتقد أنني قلت أن هذا كان ممكنًا تقنيًا من قبل. لا أستطيع تذكر ما كنت أفكر فيه حينها. ربما سأتوقف عن الرد على هذه المشكلة في الوقت الحالي.

Edit2: إذا أراد أي شخص العمل على هذه الميزة ، فقد أقترح النظر في كيفية حصول وحدة تحكم الويب على معلومات حول المناطق المرتبطة. من وجهة نظري ، على الرغم من أن هذه المعلومات غير متوفرة من خلال واجهة برمجة التطبيقات من حساب المنطقة غير المستضافة ، إلا أنها بطريقة ما من خلال وحدة تحكم الويب.

لقد فتحت هذا للتو هنا # 24286 في مستودع إعادة الشراء ، لكن لم أدرك أن هذا كان موجودًا بالفعل.

أتخيل أن هذا يحتاج فقط إلى مصدرين مشابهين لكيفية إعداد أعمال اتصال الأقران.
باحترام:
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 يحاول معرفة ما إذا كانت المنطقة مرتبطة أم لا أولاً ، ولكن لا يمكنك فعل ذلك باستخدام واجهة برمجة التطبيقات ، فليس لديك أذونات لقراءة المنطقة. إذا تم تخزين هذه المعلومات محليًا ، فيجب أن تكون قادرًا على القيام بذلك ، ولكن لا يمكنك معرفة حالة حسابك بخلاف ذلك (أعتقد أنني لا أزال أشعر بالارتباك بشأن الجزء المتعلق بالتضاريس مقابل الجزء الأمني ​​من هذا). لذلك إذا قمت بإخراج الجزء المقروء من مادة CRUD في مورد الارتباط ، فيجب أن يعمل هذا (؟)

إذا تمت إدارة المورد خارج نطاق التضاريس ، فستواجه مشكلات بالرغم من ذلك. ربما هذا جيد ، لست متأكدًا حقًا. أعتقد أنه تقرر في الغالب أننا لا نريد القيام بذلك ولكن ربما لم يكن هذا الجزء واضحًا من قبل (في الواقع متأكد من أن هذا لم يكن واضحًا من قبل ، أحتاج إلى قراءة هذا الموضوع رغم ذلك).

لقد ذكرت شيئًا عن تمرير الأدوار (على هاتفي من الصعب جدًا البحث عنه) في منشورك الآخر ، إذا كان بإمكانك بطريقة ما منح حق الوصول لقراءة المنطقة وربما تضمينها في مثال على كيفية استخدام هذا ، فربما يعمل ذلك أيضًا .

تحرير 2: الجزء الآخر من هذا هو AWS توصي بإزالة التفويض بعد اكتمال الارتباط. لكن tbh لست متأكدًا حقًا من أنني أفهم سبب القيام بذلك ، أو لماذا لا تريد إعادة ربط VPC. أعتقد أنه ربما يكون من الجيد تدوين ذلك على الرغم من أنه في المستندات ، اعتقدت أنه كان هناك نقاش في مكان ما حول هذا الموضوع ولكن لم أراه الآن.

اسمحوا لي أن أعرف إذا فاتني أي شيء هنا.

تضمين التغريدة

لذلك إذا قمت بإخراج الجزء المقروء من مادة CRUD في مورد الارتباط ، فيجب أن يعمل هذا (؟)

هل تعالج الخطأ 403 الذي وضعته أعلاه؟ أنا أعتقد هذا.

إذا تمت إدارة المورد خارج نطاق التضاريس ، فستواجه مشكلات بالرغم من ذلك.

نحن نتحدث بصرامة عن مجرد ربط حساب VPC-Account B بالمنطقة المستضافة الخاصة-الحساب A .. أعتقد أن هذا لا بأس به.

إذا كان بإمكانك منح حق الوصول بطريقة ما لقراءة المنطقة وربما تضمينها في مثال عن كيفية القيام بذلك
يجب استخدام هذا ربما سيعمل أيضًا.

بدون فكرة افتراض أكثر من ملف تعريف / اسم مستعار داخل مورد / وحدة نمطية (استقبال الأدوار) ، لا يبدو هذا ممكنًا مع 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 التي أشرت إليها أعلاه. كلتا الحالتين اليدويتين لتطبيق العمل وإتلافه بشكل مثالي مع استخدام ملف تعريف واحد فقط مع كل أمر. أتخيل أن هذا يترجم إلى API .. نظرًا لأنه يحتوي فقط على المدخلات التي أقدمها.
عند تشغيل الأمر Associate 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..

وهذا يعني أنه يعمل بشكل جيد مع العلم أنه مرتبط بالفعل. يأتي هذا من ملف تعريف الحساب مع VPC الذي لا يمتلك وصولاً مباشرًا إلى المنطقة المستضافة الخاصة في حساب "route53".

الجزء الآخر من هذا هو AWS توصي بإزالة التفويض بعد اكتمال الارتباط. لكن tbh لست متأكدًا حقًا من أنني أفهم سبب القيام بذلك ، أو لماذا لا تريد إعادة ربط VPC.

هذا لأنه بعد إقرانه ، لم تعد بحاجة إلى ترخيصه. أعتقد أن ذكر هذا يمكن تدوينه في المستندات .. وربما يتم تجاهله.

انا اود الاشاره الى.

يبدو أن هذا تم الإبلاغ عنه لأول مرة بواسطة rginev في 17 نوفمبر 2016 (منذ حوالي 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 الخاص بك العلاقات العامة)

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 (مفتوح)

ربما يكون هناك المزيد من الأشياء التي فاتنيها ، فأنا أحاول فقط أن أشير إلى أن هذا كان مطلوبًا منذ فترة.

يبدو أن كلا من ewbankkitFransUrbo لهما الكثير من التاريخ مع هذا وربما لا يزالان مهتمين بهذا الأمر؟
bflad (
جاء هذا أيضًا في بعض الأبحاث:
https://forums.aws.amazon.com/thread.jspa؟threadID=271250

لقد فكرت كثيرًا في هذا الأمر منذ فترة ، وكان استنتاجي هو أن التقاط سلوك واجهة برمجة التطبيقات هذه في مورد لا يتطابق مع الطريقة التي يعمل بها موفر AWS - أي أن التفاعلات لمورد واحد تتم تحت هوية AWS الفردية التي تم تكوينها في المورد.
قد يكون أحد الحلول هو إنشاء مزود منفصل يحتوي على هذا المورد الجديد ويتم تكوين هذا الموفر الجديد بهويتي AWS. سيكون كل التعقيد في الخيارات العديدة لتكوين تلك الهويات لحزمة AWS SDK الأساسية.
https://github.com/hashicorp/aws-sdk-go-base يمكن أن يحتوي على بعض الأجزاء القابلة لإعادة الاستخدام.

تضمين التغريدة

تتم التفاعلات لمورد واحد بموجب هوية AWS واحدة تم تكوينها في المورد.

أنا لا أفهم القضية tbh.
النظر في:
تخويل API_CreateVPCAss Association
و
API_AssociateVPCWithHostedZone

يبدو أن هذا سيتطلب فقط هوية aws واحدة لكل مورد / استدعاء api / cli cmd.
أقتبس من الرابط الثاني.

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
أي أفكار حول؟ هذا نوع من الألم الذي يجب إدارته عندما يكون لديك العديد من الحسابات التي تستخدم منطقة مستضافة خاصة في حساب آخر.

هل يعلم أي شخص بأية أمثلة في التضاريس حيث يتم تخطي الجزء المقروء من CRUD ، تاركًا العمليات الأخرى للاعتماد فقط على البيانات الموجودة في ملف الحالة؟

أواجه نفس المشكلة وأرغب في رؤية حل ، أو على الأقل بعض الوثائق الإضافية التي توضح هذا السيناريو قبل أن ينتهي الأمر بمزيد من الأشخاص بتشغيله والعثور على هذه المشكلة.

بدلاً من ذلك ، هل من الممكن أن يكون لديك سياسة IAM تسمح للحساب مع VPC بإدراج المناطق المستضافة على الحساب مع المنطقة المستضافة كحل بديل؟

أنا أواجه هذه المشكلة أيضًا وأعتقد أن أي شخص يحاول الاستفادة من منطقة مستضافة خاصة عبر الحسابات ذات terraform سيواجه هذه المشكلة. تعد إدارة حسابات aws المتعددة حالة استخدام شائعة جدًا في الشركات الكبيرة وهو ما يبدو أنه يوصي به باعتباره بنية داخل المؤسسة. إنه لأمر محبط للغاية أن نرى هذا يمر دون حل لسنوات.

فقط أواجه هذه المشكلة بنفسي.

هناك طرق لمعالجة استخدام نقاط النهاية لوحدة الحل (واردة عند _phz-Provider_ ، واردة عند _phz-Consumer_) ، ولكن يتم تحصيل رسوم نقاط النهاية هذه بشكل منفصل بواسطة aws وسيكون من الرائع تجنب هذه الرسوم الإضافية باستخدام phz "المباشر" <-> بديل جمعية vpc.

وفقًا لمقالة قاعدة المعارف هذه ، فإنها توضح كيفية إنجاز التفويض عبر CLI.

يمكنني / سأحاول بنفسي ، لكنني أعتقد أنني سأطرح السؤال على المشاركين ذوي الخبرة في هذا الموضوع:

بافتراض أن جزء __التخويل__ تم إجراؤه يدويًا في سياق حساب _phz-Provider_ ، فهل ستستخدم aws_route53_zone_association في سياق حساب _phz-Consumer_؟

مرحبًا بالجميع ، لقد كنت أبحث في هذا مرة أخرى بعد أن أشار aws_route53_zone_association من رسائل الخطأ التي تم إرجاعها بعد الاستدعاءات المتكررة لواجهة برمجة التطبيقات هذه.

لقد جمعت شيئًا ما معًا لاختبار ذلك في https://github.com/terraform-providers/terraform-provider-aws/compare/master...RyanJarv : جمعية مستضافة عبر الحسابات.

هذا كله مجرد اختبار في الوقت الحالي ، لذا فإن أي أفكار هنا موضع تقدير. في هذا الفرع ، أستخدم خاصية cross_account في المورد aws_route53_zone_association لتغيير سلوك كيفية إجراء أجزاء القراءة والانتظار.

لذلك في هذا الفرع إذا 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 أيضًا.

أردت في الغالب نشر هذا الآن لمعرفة ما إذا كان لدى أي شخص أي آراء حول هذا السلوك في الفرع الذي ربطته وأي أفكار حول التعامل مع الانجراف.

تضمين التغريدة

بدلاً من ذلك ، هل من الممكن أن يكون لديك سياسة IAM تسمح للحساب مع VPC بإدراج المناطق المستضافة على الحساب مع المنطقة المستضافة كحل بديل؟

باستخدام افتراض دور نعم ، ومع ذلك ، فإن terraform afik ليس مصممًا للاتصال بحسابات متعددة في مورد واحد. إذا كان من الممكن القيام بذلك دون افتراض الدور ، فسيكون ذلك أكثر جدوى. لم أتمكن من تحديد أي من هذين الخيارين على الرغم من أنه على الأقل بطريقة منطقية.

@ توني كرز

بافتراض أن جزء التفويض تم يدويًا في سياق حساب موفر phz ، فهل ستستخدم aws_route53_zone_association في سياق حساب phz-Consumer؟

هذا لن ينجح ، بالنسبة للجزء الأكبر aws_route53_zone_association هي المشكلة. إذا كنت ترغب في تجربة الفرع في آخر مشاركة لي قد يعمل من أجلك (تحذير: لم تقم بالكثير من الاختبارات عليه).

لقد واجهنا هذه المشكلة أيضًا. لقد تبين أن محاولة بناء منظمة سريعة الزوال لديها نظام DNS يمثل تحديًا كبيرًا.

هذا ... _bug_؟ ستصبح أكثر وأكثر صلةً بالأعمال التجارية التي نشأت في عصر IAC أثناء نموها لدمج بنى الحسابات المتعددة ، بناءً على توصية AWS التي يمكنني إضافتها!

أنا أيضًا حريص على رؤية حل نظيف لهذه المشكلة وأتفهم أن هذا حل معقد!

لقد حاولت استخدام null_resource لاستدعاء CLI والقيام بالربط. تكمن المشكلة في أنه عند إنشاء المنطقة ، لا يمكنك تحديد حساب VPC الآخر أو تحصل على خطأ ، لذلك بعد تشغيل كل شيء في المرة الأولى وربط VPC بالمنطقة ، تسعى terraforms إلى إزالة VPC من المنطقة المستضافة. كل شيء قبيح للغاية للتعامل معه في الوقت الحالي.

إحدى الطرق شبه "النظيفة" للتعامل مع هذا الآن هي إنشاء منطقة مستضافة عامة وتسجيل يشير إلى 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"]
  }
}

تأثير ما سبق هو أنه يمكنني إعادة تشغيل هذا التضاريس والوصول إلى نفس النتيجة للمنطقة المرتبطة بـ 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-associated-with- your-amazon- vpcs

تتطلب AWS SDK الإصدار 1.32.5 :

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

@ tdmalone توقيت رائع مع هذا

هل ستتم إضافة هذا إلى المزود في أي وقت قريبًا؟ الحلول المقدمة تستخدم exec المحلي لـ aws cli وهذا شيء نحاول بشدة تجنبه عند استخدام Terraform Enterprise. نحن أيضًا بصدد الدخول إلى أكثر من 100 حساب الآن - وكلما قل الاعتماد على العوامل الخارجية كان ذلك أفضل :)

arnvid نسخ تحديث من Brian على العلاقات العامة أعلاه:

وضع علامة على هذا مباشرة بعد أن نكمل عملنا لـ 3.0 في الأسبوع أو الأسبوعين المقبلين ، على الرغم من أن دورات المراجعة قد تجعله قليلاً بعد 3.1 للإصدار الفعلي. 👍

لذلك ، هذا يبدو واعدًا قريبًا جدًا! 🎉

تم دمج دعم Route 53 عبر حسابات VPC عبر مورد جديد aws_route53_vpc_association_authorization وتحديث معالجة الموارد aws_route53_zone_association وسيصدر مع الإصدار 3.1.0 من Terraform AWS Provider ، على الأرجح في وقت لاحق اليوم. بفضل goakley و RyanJarv للتنفيذ. 👍

تم إصدار هذا في الإصدار 3.1.0 من مزود Terraform AWS . يرجى الاطلاع على وثائق Terraform حول إصدار الموفر أو التواصل إذا كنت بحاجة إلى أي مساعدة للترقية.

لمزيد من طلبات الميزات أو تقارير الأخطاء باستخدام هذه الوظيفة ، يرجى إنشاء مشكلة GitHub جديدة باتباع نموذج الفرز. شكرا!

سأقوم بإغلاق هذه المشكلة لأنه تم إغلاقه لمدة _30 يومًا_ ⏳. يساعد هذا المشرفين لدينا في العثور على المشكلات النشطة والتركيز عليها.

إذا كنت تشعر أنه يجب إعادة فتح هذه المشكلة ، فنحن نشجع على إنشاء مشكلة جديدة مرتبطة بهذه المشكلة مرة أخرى من أجل سياق إضافي. شكرا!