Terraform-provider-aws: Obtiene un error al actualizar las reglas de ingreso incrustadas de SG con descripción
Hola,
Estoy usando terraform v0.10.8 y el proveedor de AWS 1.1.0 y obtengo el siguiente error al actualizar las reglas de ingreso de un grupo de seguridad agregando un campo de descripción.
Puedo actualizar el SG, pero necesitaba eliminar todas las reglas manualmente. Entonces terraform trabaja y actualiza el SG. Cuando intento actualizar el SG nuevamente, ocurre el error.
Este error no ocurre si el SG no tiene reglas con campo de descripción.
línea de comando terraform
$ terraform aplicar-objetivo
=== salida de terraform
Error: Error al aplicar el plan:
Ocurrió 1 error (s):
aws_security_group.client-demo-sg-devops: se produjo 1 error (s):
aws_security_group. * *: Error al revocar las reglas de ingreso del grupo de seguridad: InvalidPermission.NotFound: La regla especificada no existe en este grupo de seguridad.
código de estado: 400, id de solicitud: 2bfe24f7-a980-4bbc-a58d-54e5935f57a6
Terraform no retrocede automáticamente ante errores.
En cambio, su archivo de estado de Terraform se ha actualizado parcialmente con
cualquier recurso que se haya completado con éxito. Por favor, solucione el error.
anterior y aplique nuevamente para cambiar gradualmente su infraestructura.
takeda-joao
Todos 39 comentarios
Extraño.
Se realizaron más cambios y hay un SG que se actualiza bien, con una descripción incluida.
Esta segunda SG tiene el mismo número de reglas de entrada que la que obtiene el error y no genera errores cuando se actualiza.
Haciendo más pruebas.
takeda-joao
en 26 oct. 2017
Parece que está relacionado con la longitud del contenido del campo de descripción.
Si la longitud del contenido del campo de descripción de todas las reglas de ingreso en la SG es la misma, el error no ocurre.
takeda-joao
en 26 oct. 2017
¿Potencialmente relacionado? # 1959
bflad
en 26 oct. 2017
No, no es la longitud.
takeda-joao
en 26 oct. 2017
Sí, el # 1959 puede estar relacionado.
Desde la segunda ejecución de terraform apply, sin cambios, y obteniendo error, notó que está comparando reglas con la última regla del grupo de seguridad.
Gracias,
takeda-joao
en 26 oct. 2017
@ takeda-joao buena atrapada
jaymecd
en 1 nov. 2017
El mismo problema experimentado aquí.
colin-lyman
en 7 nov. 2017
Acabo de probar AWS Provider 1.2 y el problema persiste.
colin-lyman
en 7 nov. 2017
¿Alguna actualización sobre este tema? También estoy enfrentando este problema en mi implementación.
SmaranNA
en 7 dic. 2017
fue corregido en # 1959 y lanzado como parte de v1.3.1
jaymecd
en 7 dic. 2017
El mismo problema aquí. Esperando que v1.3.1 se pruebe.
hugohenley
en 7 dic. 2017
Creo que este problema aún existe. Creé nuevos grupos de seguridad con terraform y cuando vuelvo a ejecutar Apply, terraform se queja con
* 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
configurando la marca de seguimiento y mirando la llamada aws, terraform está pasando la descripción incorrecta a 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 está intentando eliminar la regla para CIDR 172.16.0.0/16 y la descripción RDP , pero la descripción para ese bloque CIDR es en realidad RDP de Workspaces . Existe una regla para un bloque CIDR separado cuya descripción es RDP
Aquí hay un fragmento de mi grupo de seguridad:
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}"]
}
De la salida terraform plan , veo que terraform cree que necesita eliminar la regla para RDP y crear una regla para RDP para
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"
Versión Terraform:
''
Terraform v0.11.1
- provider.aws v1.5.0
- provider.template v1.0.0
- provider.terraform v1.0.2
reznet
en 8 dic. 2017
El problema persiste.
También estoy usando provider.aws v1.5.0 y hace imposible ejecutar la aplicación a menos que elimine el campo de descripción manualmente (y desde los estados de terraform).
takeda-joao
en 8 dic. 2017
También veo este problema. Si continúo y elimino la descripción en la consola, luego elimino el campo de descripción en el estado tf, se ejecutará terraform apply. Pero si intento ejecutar Apply de nuevo sin cambiar nada, fallará.
tsiang
en 13 dic. 2017
@reznet tnx para comentarios, confirmado.
Este problema existe solo cuando se utilizan bloques ingress {} o egress {} integrados del recurso aws_security_group
La declaración separada del grupo y las reglas funciona como se esperaba y es la forma más preferida de hacerlo.
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}"
}
¿Podríamos mencionar embedded blocks en el título del problema? para hacerlo más concreto?
@radeksimko wdyt?
jaymecd
en 14 dic. 2017
El mismo problema aquí.
karimodm
en 10 ene. 2018
Viendo esto también.
tf v.0.11.2
aws.provider 1.2.0 pero se corrigió con aws-provider 1.6.0
MooreDerek
en 11 ene. 2018
Se ha encontrado la fuente del problema: su estructura de datos devuelta por resourceAwsSecurityGroupIPPermGather ()
Considere el siguiente recurso 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"]
}
}
Comparación de estructuras locales / remotas (contraído)
LOCAL:
[]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 {}{}
}
}
REMOTO:
[]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"}
}
}
Entonces, la estructura remota tiene solo 1 elemento con description separado de cidr_blocks , por eso no se pudo asignar correctamente a la estructura local.
Voy a trabajar en la solución en los próximos días.
jaymecd
en 11 ene. 2018
¿Cuál es la mejor solución para esto mientras tanto?
kenske
en 12 ene. 2018
@kenske , use el recurso dedicado aws_security_group_rule
jaymecd
en 13 ene. 2018
Es un poco más complejo de lo que pensaba antes. @radeksimko @Ninir necesita tu consejo.
La estructura de datos de cidr_blocks , ipv6_cidr_blocks , prefix_list_ids & security_groups bloques de resource_aws_security_group.go debe actualizarse de []string a []map[string]string para mantener la descripción junto con el valor del bloque o para cortar el nuevo tipo interno (prefiero este):
type sgItem struct {
Value string
Description string
}
wdyt? Tnx
jaymecd
en 16 ene. 2018
¿alguna actualización?
red97gst
en 31 ene. 2018
@kenske Me @jaymecd ya que usamos Terraform para asegurarnos de que las reglas SG coincidan exactamente con lo que está en la definición. No creo que eso sea posible con aws_security_group_rule o, si lo es, no he podido encontrar una manera de borrar las reglas que alguien agregó manualmente a través de la consola / API de AWS.
Necesitaba habilitar la depuración / seguimiento para averiguar exactamente qué se estaba llamando (y fallando) a través de RevokeSecurityGroupIngress, luego configuré manualmente la descripción de esas reglas en AWS para que la próxima vez que terraform apply intente eliminarlas, lo haría tener éxito. Después de eso, y sin campos de descripción competidores, cada terraform plan partir de ese momento estaba limpio.
ScottSorrentino
en 2 feb. 2018
@ScottSorrentino Fue un poco doloroso, pero seguí la sugerencia de
kenske
en 2 feb. 2018
Dado que parece que falta el argumento comercial para las reglas en línea, aquí está en detalle.
Las declaraciones de estilo en línea son una forma de decir solo estas reglas , donde el estilo de recurso separado dice al menos estas reglas . Desde el punto de vista del cumplimiento, solo estas reglas son un mecanismo de aplicación de políticas , donde al menos estas reglas simplemente aseguran que la funcionalidad aprobada esté presente. Esto tiene un impacto muy grande cuando llega el momento de una auditoría.
Cuando los auditores nos preguntan:
Describa cómo se aplican las reglas de su firewall mediante el control de cambios.
El uso del estilo en línea nos permite evitar tener que construir un sistema complicado de ingestión y correlación de eventos de CloudTrail con nuestro sistema de solicitud de cambio para mostrar que solo se implementan los cambios aprobados y que la deriva del cambio se detecta y se alarma, si no se previene por completo . En su lugar, podemos darles el registro de confirmación para nuestro repositorio terraform. Los auditores comprenden los flujos de aprobación de git-repos y merge-request. Han dicho, en esencia:
Oh! Como Puppet, ¡pero para definiciones de grupos de seguridad!
Y eso hace que todo el proceso sea mucho más fácil . Este es uno de los mayores valores agregados que Terraform nos brinda en nuestra infraestructura.
sysadmin1139
en 15 mar. 2018
Acabo de abordar este tema hoy también.
Sin embargo, en mi caso donde tengo una regla como la siguiente
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}"
}
No puedo usar aws_security_group_rule como lo sugirió anteriormente @jaymecd ya que terminaré encontrando un error diferente explicado en # 1920
¿Alguna otra solución?
piersf
en 27 mar. 2018
Hola de nuevo,
Después de jugar mucho con esto, llegué a la conclusión de que el problema es cuando se usa el campo description para una regla de entrada o salida y se vuelve a aplicar después de la primera vez. A continuación escribo los pasos que me llevaron a esta conclusión.
Tengo la siguiente declaración de recursos (nota que description está comentada excepto en la primera entrada):
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"
}
}
Aplicar eso la primera vez funciona bien y veo los cambios esperados en el grupo de seguridad. Extrañamente, terraform elimina y recrea la primera regla de entrada. Pero se aplica con éxito. A continuación se muestra el resultado de la acción de aplicar:
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.
Ahora, si vuelvo a presentar una solicitud sin cambiar nada en los recursos, fallará:
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.
¿Dónde está el problema ...?
En el resultado de la segunda acción de aplicación anterior, observe la regla de entrada con el número 2396394866
Terraform, de alguna manera y desde algún lugar, ve una regla de entrada que intenta eliminar y que no existe en ningún lugar de mi archivo de estado o mi grupo de seguridad en AWS. Y es por eso que se queja de que la regla de ingreso del grupo de seguridad no existe.
Por qué y cómo Terraform ve algo que no existe en el .tf o en el archivo de estado es la pregunta.
Y como eso no es suficiente, no puedo salir de esta situación incluso si comento la descripción de la regla de ingreso. Todavía fallará con el mismo error. Y sospecho que eso se debe a que el archivo de estado ahora está en un estado inconsistente ya que no se revierte.
Tengo que eliminar manualmente el recurso del grupo de seguridad del archivo de estado, actualizar, importarlo y luego crear una por una las reglas de entrada y salida sin la descripción.
Realmente no puedo decir dónde está el error aquí, pero sugeriría a cualquier otra persona que no proporcione una descripción de las reglas de entrada y salida anidadas si no quiere entrar en esta situación.
Estoy ejecutando Terraform v0.11.5
Gracias,
piersf
en 28 mar. 2018
Me mordió esta noche. Incluso si comenté la descripción, todavía desencadenaba el error. Solo después de eliminar completamente la línea, las cosas comenzaron a funcionar como se esperaba.
Terraform v0.11.5
+ provider.aws v1.13.0
shanemeyers
en 30 mar. 2018
Error reintroducido de nuevo en
''
Terraform v0.11.5
Proveedor "aws" (1.13.0)
rajbettaswamy
en 4 abr. 2018
¿Se solucionó el error alguna vez? Todavía lo veo también, aunque no puedo averiguar cómo actualizar mi proveedor de AWS (estoy en 1.6 y ejecutar terraform init no hace nada para cambiar eso).
ibrahima
en 12 abr. 2018
@ibrahima todavía no ha visto ninguna actualización sobre el error.
En cuanto a la versión proporcionada, intente eliminar el archivo similar a .terraform/plugins/linux_amd64/terraform-provider-aws_v1.14.1_x4 que es lo que tengo y luego ejecute init nuevamente. Esto actualizará la versión del proveedor.
piersf
en 12 abr. 2018
Ah, está bien, de hecho me di cuenta de eso después de publicar el comentario (un poco contradictorio, porque el mensaje terraform init dice que instaló la última versión, pero bueno). Y ahora estoy experimentando más errores en lugar de menos :(
ibrahima
en 12 abr. 2018
Para actualizar el proveedor, ejecute terraform init -upgrade .
junkangli
en 12 abr. 2018
Experimentando esto también.
Terraform v0.11.5
+ provider.archive v1.0.3
+ provider.aws v1.11.0
russellsherman
en 12 abr. 2018
Solo quería señalar que esto también sucede para el recurso aws_default_security_group , donde el uso de recursos aws_security_group_rule individuales no es una opción
pmacdougall
en 24 abr. 2018
Me enfrento a un problema similar al actualizar las reglas del grupo de seguridad, no tiene nada que ver con la descripción, parece que el archivo de estado tf no está sincronizado con las reglas del grupo de seguridad en el momento de la aplicación, primero elimina / modifica la regla de seguridad y luego intenta para agregar nuevas propiedades.
$ 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
reza
en 26 abr. 2018
Esto todavía está presente, eliminé manualmente todas las descripciones en aws y volví a ejecutar el script terraform.
Caspain
en 8 may. 2018
@Caspain También tuve el mismo problema hoy. Eliminar descripciones y aplicar nuevamente funcionó bien
carlosescura
en 9 may. 2018
Hola amigos 👋 Lo siento, este ha sido un problema de larga data con el proveedor de AWS. La solución para esto debería estar contenida en # 4416 que se lanzará con la v1.19.0 del proveedor de AWS, probablemente a mediados de la próxima semana.
Saludos a @svanharmelen, quienes enviaron un PR anterior, probablemente correcto, que debo haber revisado y combinado antes: # 3628).
Dado que hubo tantos problemas relacionados con este error, bloquearé este problema (entre todos los demás) para alentar a que cualquier problema / discusión persistente se describa completamente en los nuevos números para su consolidación. Gracias por su comprensión.
bflad
en 10 may. 2018
Temas relacionados
hashibot
·
3Comentarios
hashibot
·
3Comentarios
hashibot
·
3Comentarios
hashibot
·
3Comentarios
dvishniakov
·
3Comentarios
Comentario más útil
Me mordió esta noche. Incluso si comenté la descripción, todavía desencadenaba el error. Solo después de eliminar completamente la línea, las cosas comenzaron a funcionar como se esperaba.
Terraform v0.11.5
+ provider.aws v1.13.0