Terraform-provider-aws: حدث خطأ عند تحديث قواعد الدخول المضمنة في SG مع الوصف

تم إنشاؤها على ٢٦ أكتوبر ٢٠١٧  ·  39تعليقات  ·  مصدر: hashicorp/terraform-provider-aws

مرحبا،

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

سطر أوامر terraform
تطبيق $ terraform -target

=== ناتج التضاريس
خطأ: خطأ في تطبيق الخطة:

حدث خطأ واحد (أخطاء):

  • aws_security_group.client-demo-sg-devops: حدث خطأ واحد (أخطاء):

  • aws_security_group. * *: خطأ في إبطال قواعد دخول مجموعة الأمان: InvalidPermission.NotFound: القاعدة المحددة غير موجودة في مجموعة الأمان هذه.
    كود الحالة: 400 ، معرف الطلب: 2bfe24f7-a980-4bbc-a58d-54e5935f57a6

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

bug servicec2

التعليق الأكثر فائدة

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

Terraform v0.11.5
+ Provider.aws v1.13.0

ال 39 كومينتر

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

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

يحتمل أن تكون مرتبطة؟ # 1959

لا ، ليس هذا هو الطول.

نعم ، # 1959 قد تكون ذات صلة.
من الجولة الثانية لتطبيق terraform ، دون تغييرات ، والحصول على خطأ ، لاحظ أنه يقارن القواعد بالقاعدة الأخيرة لمجموعة الأمان.
شكر،

@ تاكيدا - جواو صيد جيد

نفس المشكلة من ذوي الخبرة هنا.

اختبرت للتو AWS Provider 1.2 وما زالت المشكلة قائمة.

أي تعديل حدث في هذه القضية؟ أنا أيضا أواجه هذه المشكلة في تطبيقي.

تم إصلاحه في # 1959 وتم إصداره كجزء من الإصدار 1.3.1

نفس المشكلة هنا. في انتظار اختبار v1.3.1.

أعتقد أن هذه المشكلة لا تزال موجودة. لقد قمت بإنشاء مجموعات أمان جديدة مع terraform وعندما أعيد تشغيل التطبيق ، يشكو terraform مع

* module.webui.aws_security_group.web: 1 error(s) occurred:

* aws_security_group.web: Error revoking security group ingress rules: InvalidPermission.NotFound: The specified rule does not exist in this security group.
    status code: 400, request id: 20c88505-d009-42ba-bc30-c0444cef2e94

عند تعيين علامة التتبع والنظر إلى استدعاء aws ، فإن terraform يمرر الوصف الخاطئ إلى aws:

Action=RevokeSecurityGroupIngress&GroupId=sg-b25012c7&IpPermissions.1.FromPort=3389&IpPermissions.1.IpProtocol=tcp&IpPermissions.1.IpRanges.1.CidrIp=172.16.0.0%2F16&IpPermissions.1.IpRanges.1.Description=RDP&IpPermissions.1.ToPort=3389&Version=2016-11-15

يحاول terraform إزالة القاعدة لـ CIDR 172.16.0.0/16 ووصف RDP ، لكن وصف كتلة CIDR هذه هو في الواقع RDP من مساحات العمل . توجد قاعدة لكتلة CIDR منفصلة وصفها هو RDP

إليك مقتطف من مجموعة الأمان الخاصة بي:

  ingress {
      description = "RDP"
      from_port = 3389
      to_port = 3389
      protocol = "tcp"
      cidr_blocks = ["10.0.0.0/8"]
  }

  ingress {
      description = "RDP from Workspaces"
      from_port = 3389
      to_port = 3389
      protocol = "tcp"
      cidr_blocks = ["${var.workspaces_cidr_blocks}"]
  }

من الناتج terraform plan ، أرى أن terraform تعتقد أنها بحاجة إلى حذف قاعدة RDP وإنشاء قاعدة لـ RDP For Workspaces ، لكنها لا تفعل ذلك.

      ingress.1615219479.cidr_blocks.#:       "1" => "0"
      ingress.1615219479.cidr_blocks.0:       "172.16.0.0/16" => ""
      ingress.1615219479.description:         "RDP" => ""
      ingress.1615219479.from_port:           "3389" => "0"
      ingress.1615219479.ipv6_cidr_blocks.#:  "0" => "0"
      ingress.1615219479.protocol:            "tcp" => ""
      ingress.1615219479.security_groups.#:   "0" => "0"
      ingress.1615219479.self:                "false" => "false"
      ingress.1615219479.to_port:             "3389" => "0"
      ingress.2147368551.cidr_blocks.#:       "0" => "1"
      ingress.2147368551.cidr_blocks.0:       "" => "172.16.0.0/16"
      ingress.2147368551.description:         "" => "RDP from Workspaces"
      ingress.2147368551.from_port:           "" => "3389"
      ingress.2147368551.ipv6_cidr_blocks.#:  "0" => "0"
      ingress.2147368551.protocol:            "" => "tcp"
      ingress.2147368551.security_groups.#:   "0" => "0"
      ingress.2147368551.self:                "" => "false"
      ingress.2147368551.to_port:             "" => "3389"

إصدار Terraform:
""
Terraform v0.11.1

  • Provider.aws v1.5.0
  • Provider.template v1.0.0
  • Provider.terraform v1.0.2

لا تزال هناك مشكلة.
أنا أستخدم أيضًا Provider.aws v1.5.0 ومن المستحيل تشغيل تطبيق ما لم تقم بإزالة حقل الوصف يدويًا (ومن حالات التضاريس).

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

reznet tnx
تحدث هذه المشكلة فقط عند استخدام كتل ingress {} أو egress {} من مورد aws_security_group .

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

resource "aws_security_group" "test" {
  name        = "test-rules"
  description = "test"
}

resource "aws_security_group_rule" "test_rule1" {
  type        = "ingress"
  description = "RDP"
  from_port   = "3389"
  to_port     = "3389"
  protocol    = "tcp"
  cidr_blocks = ["10.0.0.0/8"]

  security_group_id = "${aws_security_group.test.id}"
}

resource "aws_security_group_rule" "test_rule2" {
  type        = "ingress"
  description = "RDP from Workspaces"
  from_port   = "3389"
  to_port     = "3389"
  protocol    = "tcp"
  cidr_blocks = ["170.0.0.0/8"]

  security_group_id = "${aws_security_group.test.id}"
}

هل يمكننا ذكر embedded blocks في عنوان الإصدار؟ لجعلها أكثر واقعية؟

radeksimko wdyt؟

نفس المشكلة هنا.

رؤية هذا أيضا.

tf v.0.11.2
aws.provider 1.2.0 ولكنه تم إصلاحه باستخدام aws-Provider 1.6.0

تم العثور على مصدر المشكلة - بنية البيانات التي تم إرجاعها بواسطة ResourceAwsSecurityGroupIPPermGather ()

ضع في اعتبارك التالي مورد TF:

resource "aws_security_group" "test" {
  name  = "test"

  ingress {
      description = "RDP 11111"
      from_port = 3389
      to_port = 3389
      protocol = "tcp"
      cidr_blocks = ["1.1.1.1/32"]
  }

  ingress {
      description = "RDP 22222"
      from_port = 3389
      to_port = 3389
      protocol = "tcp"
      cidr_blocks = ["2.2.2.2/32"]
  }
}


مقارنة الهياكل المحلية / البعيدة (مطوية)

محلي:

[]interface {}{
    map[string]interface {}{
        "protocol":"tcp", 
        "ipv6_cidr_blocks":[]interface {}{}, 
        "self":false, 
        "description":"RDP 11111", 
        "from_port":3389, 
        "cidr_blocks":[]interface {}{"1.1.1.1/32"}, 
        "security_groups":*Set(map[string]interface {}(nil)), 
        "to_port":3389
    }, 
    map[string]interface {}{
        "self":false, 
        "description":"RDP 22222", 
        "to_port":3389, 
        "protocol":"tcp", 
        "security_groups":*Set(map[string]interface {}(nil)), 
        "from_port":3389, 
        "cidr_blocks":[]interface {}{"2.2.2.2/32"}, 
        "ipv6_cidr_blocks":[]interface {}{}
    }
}

التحكم عن بعد:

[]map[string]interface {}{
    map[string]interface {}{
        "description":"RDP 22222", 
        "from_port":3389, 
        "to_port":3389, 
        "protocol":"tcp", 
        "cidr_blocks":[]string{"1.1.1.1/32", "2.2.2.2/32"}
    }
}

لذا ، تحتوي البنية البعيدة على عنصر واحد فقط مع description منفصل من cidr_blocks ، ولهذا السبب لا يمكن تعيينها بشكل صحيح إلى البنية المحلية.

سأعمل على الإصلاح في الأيام القادمة.

ما هو أفضل حل لهذا في الوقت الحالي؟

kenske ، استخدم aws_security_group_rule

إنه أكثر تعقيدًا قليلاً مما اعتقدته من قبل. تحتاجradeksimkoNinir المشورة اور.

هيكل بيانات cidr_blocks ، ipv6_cidr_blocks ، prefix_list_ids & security_groups كتل من resource_aws_security_group.go يجب أن تتم ترقية من []string إلى []map[string]string للاحتفاظ بالوصف مع قيمة الكتلة أو شريحة من النوع الداخلي الجديد (أفضل هذا):

type sgItem struct {
    Value string
    Description string
}

wdyt؟ تينكس

أي تحديثات؟

@ kenske لقد jaymecd لأننا نستخدم موجود في التعريف. لا أعتقد أن هذا ممكن مع aws_security_group_rule أو ، إذا كان الأمر كذلك ، فلن أتمكن من العثور على طريقة لمسح القواعد التي أضافها شخص ما يدويًا عبر وحدة التحكم / واجهة برمجة تطبيقات AWS.

لقد احتجت إلى تمكين التصحيح / التتبع لمعرفة ما تم استدعاؤه بالضبط (والفشل) عبر RevokeSecurityGroupIngress ، ثم قمت يدويًا بتعيين الوصف على تلك القواعد في AWS ، لذا في المرة التالية التي حاول فيها terraform apply إزالتها ، ينجح. بعد ذلك ، وبدون حقول وصف منافسة ، كان كل terraform plan من تلك النقطة فصاعدًا نظيفًا.

ScottSorrentino كان الأمر مؤلمًا نوعًا ما ، لكنني اتبعت اقتراح

نظرًا لأن حالة العمل الخاصة بالقواعد المضمنة تبدو مفقودة ، فإليك بالتفصيل.

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

عندما يسألنا المدققون:

يرجى وصف كيفية تطبيق قواعد جدار الحماية من خلال التحكم في التغيير.

يسمح لنا استخدام النمط المضمن بتجنب الاضطرار إلى بناء نظام معقد لاستيعاب حدث CloudTrail والارتباط بنظام طلب التغيير الخاص بنا لإظهار أنه يتم تنفيذ التغييرات المعتمدة فقط وأن التغيير الانجراف يتم اكتشافه والانزعاج منه ، إذا لم يتم منعه تمامًا . بدلاً من ذلك ، يمكننا أن نمنحهم سجل الالتزام الخاص بإعادة الشراء الخاصة بنا. يفهم المدققون تدفقات الموافقة على git-repos و merge-request. لقد قالوا من حيث الجوهر:

يا! مثل Puppet ، ولكن لتعريفات مجموعة الأمان!

وهذا يجعل العملية برمتها أسهل بكثير . هذا هو واحد من أكبر القيمة المضافة التي تقدمها لنا Terraform في بنيتنا التحتية.

لقد واجهت هذه المشكلة اليوم أيضًا.
ومع ذلك ، في حالتي حيث لدي قاعدة مثل ما يلي

resource "aws_security_group_rule" "DEFAULT_DO_NOT_USE-1" {
  type            = "ingress"
  from_port       = 0
  to_port         = 0
  protocol        = "-1"
  self            = "true"
  description = "Allow all incoming traffic from withing this security group"
  security_group_id = "${aws_security_group.DEFAULT_DO_NOT_USE.id}"
}

لا يمكنني استخدام aws_security_group_rule كما هو مقترح أعلاه من قبل jaymecd حيث سينتهي بي الأمر إلى إصابة خطأ مختلف موضح في # 1920

أي حل آخر؟

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

لدي تصريح المورد أدناه (تم التعليق على الملاحظة description باستثناء الإدخال الأول):

resource "aws_security_group" "bastion_priv_SG-master" {
  name        = "bastion_priv_SG-master"
  description = "Security group for bastion host"
  vpc_id = "${aws_vpc.us_n_virg_VPC-master-10_100_0_0-16.id}"

  # incoming
  ingress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["xx.xx.xx.xx/32"]
    description = "Allow all incoming traffic from xx.xx.xx.xx/32"
  }

  ingress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    self        = "true"
    #description = "Allow all incoming traffic from within this SG"
  }

  ingress {
    from_port   = 9100
    to_port     = 9100
    protocol    = "tcp"
    security_groups = ["${data.aws_security_group.app_priv_SG_QAMonitor.id}"]
    #description = "Allow all incoming traffic from app_priv_SG_QAMonitor SG"
  }

  # outgoing
  egress {
    from_port       = 0
    to_port         = 0
    protocol        = "-1"
    cidr_blocks     = ["0.0.0.0/0"]
    #description = "Allow all outgoing traffic from this SG to the Internet"
  }

  tags {
    Name = "bastion_priv_SG-master"
  }
}

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

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  ~ aws_security_group.bastion_priv_SG-master
      ingress.1242592041.cidr_blocks.#:              "1" => "0"
      ingress.1242592041.cidr_blocks.0:              "xx.xx.xx.xx/32" => ""
      ingress.1242592041.description:                "" => ""
      ingress.1242592041.from_port:                  "0" => "0"
      ingress.1242592041.ipv6_cidr_blocks.#:         "0" => "0"
      ingress.1242592041.protocol:                   "-1" => ""
      ingress.1242592041.security_groups.#:          "0" => "0"
      ingress.1242592041.self:                       "false" => "false"
      ingress.1242592041.to_port:                    "0" => "0"
      ingress.1698735776.cidr_blocks.#:              "0" => "0"
      ingress.1698735776.description:                "" => ""
      ingress.1698735776.from_port:                  "9100" => "9100"
      ingress.1698735776.ipv6_cidr_blocks.#:         "0" => "0"
      ingress.1698735776.protocol:                   "tcp" => "tcp"
      ingress.1698735776.security_groups.#:          "1" => "1"
      ingress.1698735776.security_groups.3308286315: "sg-5477a429" => "sg-5477a429"
      ingress.1698735776.self:                       "false" => "false"
      ingress.1698735776.to_port:                    "9100" => "9100"
      ingress.502957524.cidr_blocks.#:               "0" => "1"
      ingress.502957524.cidr_blocks.0:               "" => "xx.xx.xx.xx/32"
      ingress.502957524.description:                 "" => "Allow all incoming traffic from xx.xx.xx.xx/32"
      ingress.502957524.from_port:                   "" => "0"
      ingress.502957524.ipv6_cidr_blocks.#:          "0" => "0"
      ingress.502957524.protocol:                    "" => "-1"
      ingress.502957524.security_groups.#:           "0" => "0"
      ingress.502957524.self:                        "" => "false"
      ingress.502957524.to_port:                     "" => "0"
      ingress.753360330.cidr_blocks.#:               "0" => "0"
      ingress.753360330.description:                 "" => ""
      ingress.753360330.from_port:                   "0" => "0"
      ingress.753360330.ipv6_cidr_blocks.#:          "0" => "0"
      ingress.753360330.protocol:                    "-1" => "-1"
      ingress.753360330.security_groups.#:           "0" => "0"
      ingress.753360330.self:                        "true" => "true"
      ingress.753360330.to_port:                     "0" => "0"


Plan: 0 to add, 1 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

aws_security_group.bastion_priv_SG-master: Modifying... (ID: sg-4183373a)
  ingress.1242592041.cidr_blocks.#:              "1" => "0"
  ingress.1242592041.cidr_blocks.0:              "xx.xx.xx.xx/32" => ""
  ingress.1242592041.description:                "" => ""
  ingress.1242592041.from_port:                  "0" => "0"
  ingress.1242592041.ipv6_cidr_blocks.#:         "0" => "0"
  ingress.1242592041.protocol:                   "-1" => ""
  ingress.1242592041.security_groups.#:          "0" => "0"
  ingress.1242592041.self:                       "false" => "false"
  ingress.1242592041.to_port:                    "0" => "0"
  ingress.1698735776.cidr_blocks.#:              "0" => "0"
  ingress.1698735776.description:                "" => ""
  ingress.1698735776.from_port:                  "9100" => "9100"
  ingress.1698735776.ipv6_cidr_blocks.#:         "0" => "0"
  ingress.1698735776.protocol:                   "tcp" => "tcp"
  ingress.1698735776.security_groups.#:          "1" => "1"
  ingress.1698735776.security_groups.3308286315: "sg-5477a429" => "sg-5477a429"
  ingress.1698735776.self:                       "false" => "false"
  ingress.1698735776.to_port:                    "9100" => "9100"
  ingress.502957524.cidr_blocks.#:               "0" => "1"
  ingress.502957524.cidr_blocks.0:               "" => "xx.xx.xx.xx/32"
  ingress.502957524.description:                 "" => "Allow all incoming traffic from xx.xx.xx.xx/32"
  ingress.502957524.from_port:                   "" => "0"
  ingress.502957524.ipv6_cidr_blocks.#:          "0" => "0"
  ingress.502957524.protocol:                    "" => "-1"
  ingress.502957524.security_groups.#:           "0" => "0"
  ingress.502957524.self:                        "" => "false"
  ingress.502957524.to_port:                     "" => "0"
  ingress.753360330.cidr_blocks.#:               "0" => "0"
  ingress.753360330.description:                 "" => ""
  ingress.753360330.from_port:                   "0" => "0"
  ingress.753360330.ipv6_cidr_blocks.#:          "0" => "0"
  ingress.753360330.protocol:                    "-1" => "-1"
  ingress.753360330.security_groups.#:           "0" => "0"
  ingress.753360330.self:                        "true" => "true"
  ingress.753360330.to_port:                     "0" => "0"
aws_security_group.bastion_priv_SG-master: Modifications complete after 2s (ID: sg-4183373a)

Apply complete! Resources: 0 added, 1 changed, 0 destroyed.

الآن ، إذا تقدمت بطلب مرة أخرى دون تغيير أي شيء في الموارد ، فسيفشل:

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  ~ aws_security_group.bastion_priv_SG-master
      ingress.1698735776.cidr_blocks.#:              "0" => "0"
      ingress.1698735776.description:                "" => ""
      ingress.1698735776.from_port:                  "9100" => "9100"
      ingress.1698735776.ipv6_cidr_blocks.#:         "0" => "0"
      ingress.1698735776.protocol:                   "tcp" => "tcp"
      ingress.1698735776.security_groups.#:          "1" => "1"
      ingress.1698735776.security_groups.3308286315: "sg-5477a429" => "sg-5477a429"
      ingress.1698735776.self:                       "false" => "false"
      ingress.1698735776.to_port:                    "9100" => "9100"
      ingress.2396394866.cidr_blocks.#:              "0" => "0"
      ingress.2396394866.description:                "Allow all incoming traffic from xx.xx.xx.xx/32" => ""
      ingress.2396394866.from_port:                  "0" => "0"
      ingress.2396394866.ipv6_cidr_blocks.#:         "0" => "0"
      ingress.2396394866.protocol:                   "-1" => ""
      ingress.2396394866.security_groups.#:          "0" => "0"
      ingress.2396394866.self:                       "true" => "false"
      ingress.2396394866.to_port:                    "0" => "0"
      ingress.502957524.cidr_blocks.#:               "1" => "1"
      ingress.502957524.cidr_blocks.0:               "xx.xx.xx.xx/32" => "xx.xx.xx.xx/32"
      ingress.502957524.description:                 "Allow all incoming traffic from xx.xx.xx.xx/32" => "Allow all incoming traffic from xx.xx.xx.xx/32"
      ingress.502957524.from_port:                   "0" => "0"
      ingress.502957524.ipv6_cidr_blocks.#:          "0" => "0"
      ingress.502957524.protocol:                    "-1" => "-1"
      ingress.502957524.security_groups.#:           "0" => "0"
      ingress.502957524.self:                        "false" => "false"
      ingress.502957524.to_port:                     "0" => "0"
      ingress.753360330.cidr_blocks.#:               "0" => "0"
      ingress.753360330.description:                 "" => ""
      ingress.753360330.from_port:                   "" => "0"
      ingress.753360330.ipv6_cidr_blocks.#:          "0" => "0"
      ingress.753360330.protocol:                    "" => "-1"
      ingress.753360330.security_groups.#:           "0" => "0"
      ingress.753360330.self:                        "" => "true"
      ingress.753360330.to_port:                     "" => "0"

Plan: 0 to add, 1 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

aws_security_group.bastion_priv_SG-master: Modifying... (ID: sg-4183373a)
  ingress.1698735776.cidr_blocks.#:              "0" => "0"
  ingress.1698735776.description:                "" => ""
  ingress.1698735776.from_port:                  "9100" => "9100"
  ingress.1698735776.ipv6_cidr_blocks.#:         "0" => "0"
  ingress.1698735776.protocol:                   "tcp" => "tcp"
  ingress.1698735776.security_groups.#:          "1" => "1"
  ingress.1698735776.security_groups.3308286315: "sg-5477a429" => "sg-5477a429"
  ingress.1698735776.self:                       "false" => "false"
  ingress.1698735776.to_port:                    "9100" => "9100"
  ingress.2396394866.cidr_blocks.#:              "0" => "0"
  ingress.2396394866.description:                "Allow all incoming traffic from xx.xx.xx.xx/32" => ""
  ingress.2396394866.from_port:                  "0" => "0"
  ingress.2396394866.ipv6_cidr_blocks.#:         "0" => "0"
  ingress.2396394866.protocol:                   "-1" => ""
  ingress.2396394866.security_groups.#:          "0" => "0"
  ingress.2396394866.self:                       "true" => "false"
  ingress.2396394866.to_port:                    "0" => "0"
  ingress.502957524.cidr_blocks.#:               "1" => "1"
  ingress.502957524.cidr_blocks.0:               "xx.xx.xx.xx/32" => "xx.xx.xx.xx/32"
  ingress.502957524.description:                 "Allow all incoming traffic from xx.xx.xx.xx/32" => "Allow all incoming traffic from xx.xx.xx.xx/32"
  ingress.502957524.from_port:                   "0" => "0"
  ingress.502957524.ipv6_cidr_blocks.#:          "0" => "0"
  ingress.502957524.protocol:                    "-1" => "-1"
  ingress.502957524.security_groups.#:           "0" => "0"
  ingress.502957524.self:                        "false" => "false"
  ingress.502957524.to_port:                     "0" => "0"
  ingress.753360330.cidr_blocks.#:               "0" => "0"
  ingress.753360330.description:                 "" => ""
  ingress.753360330.from_port:                   "" => "0"
  ingress.753360330.ipv6_cidr_blocks.#:          "0" => "0"
  ingress.753360330.protocol:                    "" => "-1"
  ingress.753360330.security_groups.#:           "0" => "0"
  ingress.753360330.self:                        "" => "true"
  ingress.753360330.to_port:                     "" => "0"

Error: Error applying plan:

1 error(s) occurred:

* aws_security_group.bastion_priv_SG-master: 1 error(s) occurred:

* aws_security_group.bastion_priv_SG-master: Error revoking security group ingress rules: InvalidPermission.NotFound: The specified rule does not exist in th
        status code: 400, request id: 98d8fa95-0aa2-40b8-851d-0a10bb25572b

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.

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

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

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

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

أنا أقوم بتشغيل Terraform v0.11.5

شكر،

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

Terraform v0.11.5
+ Provider.aws v1.13.0

أعاد الخطأ تقديمه مرة أخرى في

""
Terraform v0.11.5
الموفر "aws" (1.13.0)

هل تم إصلاح الخلل بالفعل؟ ما زلت أرى ذلك أيضًا ، على الرغم من أنني لا أستطيع معرفة كيفية تحديث موفر AWS الخاص بي (أنا على 1.6 وتشغيل terraform init لا يفعل شيئًا لتغيير ذلك).

ibrahima ما زال لم يرَ أي تحديثات حول الخطأ.
بالنسبة للإصدار المقدم ، حاول حذف الملف المشابه لـ .terraform/plugins/linux_amd64/terraform-provider-aws_v1.14.1_x4 وهو ما أملكه ثم قم بتشغيل init مرة أخرى. سيؤدي هذا إلى تحديث إصدار الموفر.

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

لتحديث الموفر ، عليك تشغيل terraform init -upgrade .

تعاني من هذا أيضًا.

Terraform v0.11.5
+ provider.archive v1.0.3
+ provider.aws v1.11.0

أردت فقط ملاحظة أن هذا يحدث أيضًا لمورد aws_default_security_group ، حيث لا يعد استخدام موارد aws_security_group_rule الفردية خيارًا

أواجه مشكلة مماثلة عند تحديث قواعد مجموعة الأمان ، ولا علاقة لها بالوصف ، ويبدو أن ملف حالة tf يصبح غير متزامن مع قواعد مجموعة الأمان في وقت التطبيق ، يقوم أولاً بإزالة / تعديل قاعدة الأمان ثم يحاول لإضافة خصائص جديدة.

$ terraform -version
Terraform v0.11.7

  • Provider.aws v1.16.0
  • Provider.null v1.0.0
  • Provider.random v1.2.0
  • Provider.template v1.0.0

لا يزال هذا موجودًا ، لقد قمت بحذف جميع الأوصاف يدويًا في نظام AWS وإعادة تشغيل البرنامج النصي للتهيئة.

Caspain لدي نفس المشكلة اليوم. نجح حذف الأوصاف والتقديم مرة أخرى بشكل جيد

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

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

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

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات