Way to manage edge hostnames when using Secure by default

[TBeijen]

The problem

When using Secure by default, an edge hostname is created implicitly by the property API (PAPI) upon activation of the property. As a result the edge hostname configuration cannot be managed by Terraform.

Attempting to create an edge hostname using the terraform resource fails, since the certificate attribute is required when edge_hostname is of type edgekey.net (enhanced TLS).

This prevents the edge hostname attribute ip_behaviour to be modified (as well as the DNS ttl, but seems unsupported currently in edge_hostname anyway).

Some possible solutions I can think of:

• Allow managing implicitly created edge hostnames by the Terraform akamai_edge_hostname resource. Possible way could be optionally specify the property that spawns the edge hostname. The provider would import the edge hostname once it's present and then use Edge Hostnames API to apply changes. (A practice somewhat similar to how aws_default_security_group adopts the security group created via an AWS VPC).
• Allow passing ip_behaviour via the property hostnames argument.

Ultimately this challenge originates from the implicit way such edge hostnames are created via the Akamai API. But that's not something easily changed obviously.

Terraform Version

Terraform: 0.13.7
Akamai provider: 1.8.0

Affected Resource(s)

• akamai_edge_hostname

Terraform Configuration Files

Implicit edge hostname as taken from the Terraform docs

resource "akamai_property" "example" {
    # ...
    hostnames {                                     # Hostname configuration
      cname_from = "example.com"
      cname_to = "example.com.edgekey.net"
      cert_provisioning_type = "DEFAULT"
    }
}

Debug Output

N/A

Expected Behavior

Be able to manage the resulting edge_hostname resource, or be able to modify the resulting edge_hostname properties via the property.

Actual Behavior

N/A
a

Steps to Reproduce

N/A

[piotrpio]

Hello @TBeijen, thanks for reporting the issue.

Our proposed solution to allow managing implicitly created edgehsotname resources is to remove the ForceNew field from ip_behavior, and use HAPI to update the resource. Since there will be no need to recreate an edge_hostname in such case, there will not be a need to pass the certificate field (certEnrolmentId), which is required only for creating the resource (in case enhanced TLS is used).

This change should allow importing existing edge_hostnames of type edgekey.net (enhanced TLS) without providing a certificate and managing the value of ip_behavior with terraform.

Let me know what do you think about this.

[TBeijen]

(Lost sight of this, sry for the late reply)

Ok, so if I summarise this correctly, from a Terraform user perspective this would boil down to:

• plan/apply. Creates property. Implicitly creates edge_hostname
• Enable/add the edge hostname in Terraform code (or ran previous step with --target, avoiding the edge_hostname)
• Import the implicitly created edge_hostname
• Continue managing the edge_hostname using Terraform, which is now possible since it wouldn't throw an error anymore when the certificate is null.

Thinking it through:

• It definitely solves the problem of not being able to manage the implicitly created edge_hostname so that's a big improvement.
• It requires some additional steps to get a new environment up and running. Being able to create entire environments with a single plan/apply is one of the strengths of Terraform. Otoh, using --target is part of Terraform and even supported by platforms like Atlantis.

So, without knowing much of the Akamai provider's internals or your roadmap, I'd say the above approach would for sure help.

And doing so would I think not block future improvements that in time might allow single plan/apply workflows for secure by default edge hostnames.

[piotrpio]

Thanks for the reply. For now we'll stick with the proposed solution, in the future we might also consider improving the workflow for secure by default edge hostnames.
We'll let you know when the change comes out.

[lkowalsk-akamai-com]

Hi @TBeijen, that change that should have addressed this issue was released within 2.2.0 Akamai Terraform Provider release. Closing the ticket. Feel free to reopen in caese of any follow up.