[Question] add security headers on cloudfront response?

[aquanow-jeffen]

Hi, I have been using this module to deploy my project to production for some time and we have a requirement to add security headers to every page response. Currently what I'm doing is adding the header through getServerSideProps, which have a page loading speed overhead. I am aware there is a ticket in the backlog about adding support for it. But do you know if there is any way I can add it from the infrastructure side, do you recommend if I provide my own CloudFront module through CloudFront function or edge function?

Thank you very much!

[ofhouse]

If the content of the header is static I probably would recommend using CloudFront response headers policies for it.

Another way would be to add a CloudFront function that adds the headers to the response.

This is not supported by the internal CloudFront distribution, so before applying one of these, the CloudFront distribution should be outsourced following the with existing CloudFront distribution example.

[aquanow-jeffen]

Thanks for replying! I also would like to get some thoughts on the migration plan.
Terraform probably won't let me migrate the existing auto-generated CloudFront to outsourced without downtime? I'd imagine it will destroy auto-generated one because it should be managed by tf-next module.
I think I probably need to create a new CloudFront distribution, apply, and then replace auto-generated with newly created one right?

[ofhouse]

Terraform probably won't let me migrate the existing auto-generated CloudFront to outsourced without downtime? I'd imagine it will destroy auto-generated one because it should be managed by tf-next module.

Yeah, that would be the default behavior and would result in probably ~30min downtime, since the Lambda@Edge needs to be detached and reattached to the new CloudFront (Detaching can take up to 30min).
Also when using a custom domain there can also AWS wide only one CloudFront distribution that is associated with the domain. So you have to wait until the existing distribution is deleted, before deploying the new one.
So I would not recommend going this way.

Fortunately the latest Terraform 1.1 release introduced a new way to migrate and refactor resources between modules.
Using the new moved statements you should be able to move & update the distribution without recreating it: https://www.terraform.io/language/modules/develop/refactoring#splitting-one-module-into-multiple

[aquanow-jeffen]

I tried to use moved block refactor my infrastructure yesterday but wasn't successful. I tried to create a new module and move there, but it still want to destroy old CF and create a new one.

# ... tf_next_new module but with new configs below
cloudfront_create_distribution = false
cloudfront_external_id         = aws_cloudfront_distribution.distribution.id
cloudfront_external_arn        = aws_cloudfront_distribution.distribution.arn
# Below is resource cloudfront distribution
moved {
  from = module.tf_next
  to     = module.tf_next_new
}

Might be because I couldn't move a resource from the remote module or am I missing anything? And I am also a little concerned about outsourced CloudFront will get more discrepancy over time when this project adds features and configs.

Would it be ok if I open a PR adding variable response_headers_policy_id just like cloudfront_origin_request_policy?

[ofhouse]

Unfortunately I never worked with the moved blocks before, so I would need to check it out by myself what prevents Terraform from moving the resource correctly.
Currently reworking the website, I will add this topic (moving from internal to external CloudFront distribution) as a potential guide topic to the backlog.

Would it be ok if I open a PR adding variable response_headers_policy_id just like cloudfront_origin_request_policy?

Yes, would accept an PR on this, since we don't use this policy and it could provide a good workaround until I find out how to handle #9. 👍