Failure when creating Proxy CF

[tricoder42]

Hey, thank you for this module 👍

I can't deploy the app using steps described in tutorial (I also checked all examples). proxy.aws_cloudfront_distribution can't be created because referenced Origin Access Identity is invalid:

module.tf_next.module.proxy.aws_cloudfront_distribution.distribution: Creating...

Error: error creating CloudFront Distribution: AccessDenied: CloudFront cannot access the specified Amazon S3 bucket using the specified origin access identity.
        status code: 403, request id: 48abad2a-9f92-451f-bfbc-448e348450d0

I was checking latest commits and I've found this one ad7047c. I'm using eu-west-1 as my default provider, but I also have us-east-1 for global resources:

locals {
  aws_region  = "eu-west-1"
  aws_profile = "my-profile"
}

provider "aws" {
  region  = local.aws_region
  profile = local.aws_profile
}

// us-east-1 provider for global resources (.e.g Certificate Manager, Lambda@Edge)
provider "aws" {
  alias   = "ue1"
  region  = "us-east-1"
  profile = local.aws_profile
}

I pass this provider to the tf_next module:

module "tf_next" {
  source      = "dealmore/next-js/aws"
  next_tf_dir = "../.next-tf"

  domain_names                      = [local.domain]
  create_domain_name_records        = false
  cloudfront_viewer_certificate_arn = data.aws_acm_certificate.hawkker_com.arn

  providers = {
    // tried both with and without this line. Code completition suggests only `global_region`
    // aws               = aws
    aws.global_region = aws.ue1
  }

  tags = local.default_tags
}

Could it be related to this commit?

[ofhouse]

Hi, thanks for reaching out!
ad7047c is an unreleased change, so it should have no impact when installing the module from the Terraform registry as you did here (source = "dealmore/next-js/aws").

The code of the latest version from the Terraform registry can be found here: Tag/v0.6.2.

We mostly use eu-central-1 here, so I am a bit surprised that eu-west-1 behaves differently.
Normally no additional provider configuration (pass-through) in the module should be necessary, since we initialize an additional us-east-1 alias provider inside the module for the CloudFront deployment.

Anyway, I will take a look by tomorrow and test some deployment configurations in eu-west-1 region to see if I can reproduce it.

[tricoder42]

The problem isn't different region, but different aws profile.

// main.tf
provider "aws" {
  profile = "my-profile"
}

// dealmore/terraform-aws-next-js/provider.tf
provider "aws" {
  region = "us-east-1"
  // profile is missing and terraform uses `default` profile
}

I've just confirmed that those missing resources from proxy-config module were created in my personal AWS account and not my client's account.

Using AWS_PROFILE environment variable instead of profile inside provider block is one possible workaround.

EDIT: Workaround is actually using AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY because s3-put command doesn't seem to read AWS_PROFILE env var.

---

I'll check later if there's another way how to pass profile to providers in modules. I guess passing providers explicitly to submodules would solve the issue as well.

In more complex situations there may be multiple provider configurations, or a child module may need to use different provider settings than its parent. For such situations, you must pass providers explicitly — Passing Providers Explicitly (last paragraph above the title)

[tricoder42]

Unfortunately, I'm gonna drop this module because we simply have too specific requirements for origins and behaviors. Feel free to close this issue.

Thank you anyway! This module has very interesting deployment approach. Pity that cloudfront in terraform doesn't allow more granular management of resources.

[ofhouse]

Haha, yes CloudFront is a configuration monster 🙈

As soon as Hashicorp has merged the support for Origin & Cache policies we plan to move to a more modular structure of this module, so that it is possible use it together with an external CloudFront resource.
We already have support for passing custom origins and cache behaviours to the internal CloudFront distribution, but I think for the most developers it would make more sense to integrate the module into an existing CloudFront setup.

Anyway thanks for testing and reporting the bug caused by using multiple AWS profiles.
I created a follow up ticket for it here #50 so I close this ticket.