Terraform-provider-aws: ELB Policies are overwritten.

Created on 13 Jun 2017  ยท  8Comments  ยท  Source: hashicorp/terraform-provider-aws

_This issue was originally opened by @mariozet as hashicorp/terraform#12170. It was migrated here as part of the provider split. The original body of the issue is below._


Hello,

Please find a description of unexpected terraform behavior below.

Terraform Version

Terraform v0.8.7

Affected Resource(s)

  • aws_lb_ssl_negotiation_policy
  • aws_lb_cookie_stickiness_policy

Terraform Configuration Files

resource "aws_lb_ssl_negotiation_policy" "stg_publish_elb_ssl_policy" {
    name = "stg-publish-ssl-negotiation-policy"
    load_balancer = "${aws_elb.public_stg_elb.id}"
    lb_port = 443
    attribute {
        name = "Protocol-TLSv1.1"
        value = "true"
    }
    attribute {
        name = "Protocol-TLSv1.2"
        value = "true"
    }
    attribute {
        name = "Server-Defined-Cipher-Order"
        value = "true"
    }
    attribute {
        name = "ECDHE-ECDSA-AES128-GCM-SHA256"
        value = "true"
    }
    attribute {
        name = "ECDHE-RSA-AES128-GCM-SHA256"
        value = "true"
    }
    attribute {
        name = "ECDHE-ECDSA-AES128-SHA256"
        value = "true"
    }
    attribute {
        name = "ECDHE-RSA-AES128-SHA256"
        value = "true"
    }
    attribute {
        name = "ECDHE-ECDSA-AES128-SHA"
        value = "true"
    }
    attribute {
        name = "ECDHE-RSA-AES128-SHA"
        value = "true"
    }
    attribute {
        name = "ECDHE-ECDSA-AES256-GCM-SHA384"
        value = "true"
    }
    attribute {
        name = "ECDHE-RSA-AES256-GCM-SHA384"
        value = "true"
    }
    attribute {
        name = "ECDHE-ECDSA-AES256-SHA384"
        value = "true"
    }
    attribute {
        name = "ECDHE-RSA-AES256-SHA384"
        value = "true"
    }
    attribute {
        name = "ECDHE-RSA-AES256-SHA"
        value = "true"
    }
    attribute {
        name = "ECDHE-ECDSA-AES256-SHA"
        value = "true"
    }
}

resource "aws_lb_cookie_stickiness_policy" "pub_stg" {
      name = "pub-stg-stickiness-policy"
      load_balancer = "${aws_elb.public_stg_elb.id}"
      lb_port = 443
      cookie_expiration_period = 600
}

Expected Behavior

Both ELB's policies should be applied.

Actual Behavior

Currently, after first terraform apply, terraform detects configuration changes and try to apply both policies. However, after successful "apply" only SSL negotiation policy is set on ELB.
When we execute terraform plan then we can notice that stickiness policy is not applied.
During a second round of terraform apply stickiness policy is applied but SSL negotiation policy is overwritten by default ELB policy.

Steps to Reproduce

  1. terraform apply
  2. terraform plan
  3. terraform apply
bug servicelb

Most helpful comment

A workaround is to just use aws_load_balancer_policy and aws_load_balancer_listener_policy

resource "aws_load_balancer_policy" "stg_publish_elb_ssl_policy" {
    load_balancer_name = "${aws_elb.public_stg_elb.name}"
    policy_name = "stg-publish-ssl-negotiation-policy"
    policy_type_name = "SSLNegotiationPolicyType"

    policy_attribute {
        name = "Protocol-TLSv1.1"
        value = "true"
    }

    policy_attribute {
        name = "Protocol-TLSv1.2"
        value = "true"
    }
    // and so on ...
}

resource "aws_load_balancer_policy" "pub_stg" {
  load_balancer_name = "${aws_elb.public_stg_elb.name}"
  policy_name = "pub-stg-stickiness-policy"
  policy_type_name = "LBCookieStickinessPolicyType"

  policy_attribute {
    name = "CookieExpirationPeriod"
    value = "600"
  }
}

resource "aws_load_balancer_listener_policy" "stg_publish_policies" {
  load_balancer_name = "${aws_elb.public_stg_elb.name}"
  load_balancer_port = 443

  policy_names = [
    "${aws_load_balancer_policy.stg_publish_elb_ssl_policy.policy_name}",
    "${aws_load_balancer_policy.pub_stg.policy_name}",
  ]
}

All 8 comments

The same thing happens when you have aws_lb_cookie_stickiness_policy at the same time you have a aws_load_balancer_policy and aws_load_balancer_listener_policy for the same ELB.

A workaround is to just use aws_load_balancer_policy and aws_load_balancer_listener_policy

resource "aws_load_balancer_policy" "stg_publish_elb_ssl_policy" {
    load_balancer_name = "${aws_elb.public_stg_elb.name}"
    policy_name = "stg-publish-ssl-negotiation-policy"
    policy_type_name = "SSLNegotiationPolicyType"

    policy_attribute {
        name = "Protocol-TLSv1.1"
        value = "true"
    }

    policy_attribute {
        name = "Protocol-TLSv1.2"
        value = "true"
    }
    // and so on ...
}

resource "aws_load_balancer_policy" "pub_stg" {
  load_balancer_name = "${aws_elb.public_stg_elb.name}"
  policy_name = "pub-stg-stickiness-policy"
  policy_type_name = "LBCookieStickinessPolicyType"

  policy_attribute {
    name = "CookieExpirationPeriod"
    value = "600"
  }
}

resource "aws_load_balancer_listener_policy" "stg_publish_policies" {
  load_balancer_name = "${aws_elb.public_stg_elb.name}"
  load_balancer_port = 443

  policy_names = [
    "${aws_load_balancer_policy.stg_publish_elb_ssl_policy.policy_name}",
    "${aws_load_balancer_policy.pub_stg.policy_name}",
  ]
}

The workaround is so good, I think it should actually be the chosen way to do this. Just delete the aws_lb_cookie_stickiness_policy resource and document aws_load_balancer_policy as the right way.

Slightly related: if you have both a aws_load_balancer_policy.main and a aws_lb_cookie_stickiness_policy.main, one of them will be overwritten with the other. I suspect they are treated as the same kind of resource in an underlying layer.

Just got the same issue.

I think aws_lb_ssl_negotiation_policy and aws_lb_cookie_stickiness_policy should be:

  • either fixed so it adds both policies;
  • either deprecated in favor to aws_load_balancer_policy

The documentation should also mention that it conflits with each others

Facing similar issue.

Closing as a duplicate of #349.

I'm going to lock this issue because it has been closed for _30 days_ โณ. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!

Was this page helpful?
0 / 5 - 0 ratings