Support for modules registry protocol not working

[cachaldora]

What happened?

I'm trying to use a TF module from a private registry and I got the following error:

cannot get remote Terraform module: error downloading 'file:///tf/9be6dbef-6979-40f2-90b0-2aa6912200ab/api.repo.com/00000000-0000-0000-0000-000000000000/terraform-module-from-pvt-registry/mycompanny': source path error: stat /tf/9be6dbef-6979-40f2-90b0-2aa6912200ab/api.repo.com/00000000-0000-0000-0000-000000000000/terraform-module-from-pvt-registry/mycompanny: no such file or directory

It seem be looking for a local module instead of a remote one. However, the registry implements the Terraform Module Registry Protocol (https://developer.hashicorp.com/terraform/internals/module-registry-protocol) and I've tested with Terraform locally by running:

TF_TOKEN_api_repo_com=<token> terraform init --from-module api.repo.com/00000000-0000-0000-0000-000000000000/terraform-module-from-pvt-registry/mycompanny

The provider documentation refers that:

When the workspace's source is 'Remote' (the default) this can be any address supported by terraform init -from-module, for example a git repository or an S3 bucket. (https://marketplace.upbound.io/providers/upbound/provider-terraform/v0.1.0/resources/tf.upbound.io/Workspace/v1beta1#doc:spec-forProvider-module)

How can we reproduce it?

Create and apply a controller config yaml with private registry authentication:

apiVersion: pkg.crossplane.io/v1alpha1
kind: ControllerConfig
metadata:
  name: controller-terraform-config
  namespace: upbound-system
  labels:
    app: provider-terraform
spec:
  env:
    - name: TF_TOKEN_api_registry_com
      value: <registry auth token>
---
apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
  name: provider-terraform
spec:
  package: xpkg.upbound.io/upbound/provider-terraform:v0.1.0
  controllerConfigRef:
    name: controller-terraform-config

Create a resource:

apiVersion: tf.upbound.io/v1beta1
kind: Workspace
metadata:
  name: dummy-workload-rg
spec:
  providerConfigRef: 
    name: provider-terraform-config
  forProvider:
    source: Remote
    module: api.repo.com/00000000-0000-0000-0000-000000000000/terraform-module-from-pvt-registry/mycompanny
    vars:
    - key: version
      value: 0.0.1

(module and registry written above are dummy data)

What environment did it happen in?

• Universal Crossplane Version: 1.10.1-up.1
• Provider Version: v0.1.0

[bobh66]

@cachaldora the "module" attribute in this instance is expected to be a git or https module path as in the example here: https://github.com/upbound/provider-terraform/blob/main/examples/workspace-remote.yaml#L19

it is not passed directly to Terraform for handling.

You could use an Inline Workspace and point it at the remote module that you specified and then terraform will see it and execute the appropriate processing.

[ytsarev]

Hey @cachaldora, it looks like you hit the right spot with tf module registry! :)

I performed some investigation:

• within the provider-terraform we are using https://github.com/hashicorp/go-getter , exactly the same package as the terraform CLI for the modules checkout.
• so provider-terraform is capable of checkout everything described in https://developer.hashicorp.com/terraform/language/modules/sources with one caveat...
• go-getter and inherently provider-terraform cannot parse TF module registry URLs out of the box
• terraform CLI uses a special package to parse and discover the registry urls
• I've also checked how terragrunt (as an example of the tooling wrapping the terraform) handles a similar situation, and it looks like they also have some special logic around TF Module registry

So adding TF Module Registry protocol support looks not trivial but is doable so we can include it in the project backlog.

While the feature is not implemented, I suggest the following workaround:

• We can get the module tarball URLs by following the process described in https://developer.hashicorp.com/terraform/registry/api-docs#download-source-code-for-a-specific-module-version
• Let's take https://registry.terraform.io/modules/terraform-aws-modules/vpc/aws/latest as an example module we want to checkout
• The source tarball URL for it would look like https://registry.terraform.io/v1/modules/terraform-aws-modules/vpc/aws/3.19.0/download
• After figuring out the source tarball download URL we can use it in provider-terraform Workspace spec:

  source: Remote
  #Instead of module: terraform-aws-modules/vpc/aws we specify the registry download URL 
  module: https://registry.terraform.io/v1/modules/terraform-aws-modules/vpc/aws/3.19.0/download

I've just tested it on my side, and it worked! I hope this workaround is helpful to you. The download URLs should be consistent and easily discoverable for a private registry as well.

[ghost]

The problem is that we need to authenticate in our private registry so the workaround you suggested @ytsarev doesn't work. @bobh66's suggestion to use inline block instead of remote directly seems to be working pretty good.

However, I think that would be great if this provider could use the same remote types as Terraform supports.

[ytsarev]

@cachaldora Thanks, I created https://github.com/upbound/provider-terraform/issues/78 after a discussion with @infbase yesterday, especially highlighting the auth problem.

[ytsarev]

@cachaldora @infbase if we add propagation of https://developer.hashicorp.com/terraform/cli/config/config-file#credentials from a k8s secret, similar to git creds, will it mitigate the issue?

[cachaldora]

I think that it will work. We already use a secret with .git-credentials file and it's working as expected so if you add the same logic for .terraformrc I think that it will solve the issue.

[ytsarev]

@cachaldora https://github.com/upbound/provider-terraform/pull/109 is available for the test