Add the possibility to provide custom headers for the module download request

[debondb]

Terraform Version

Terraform v1.5.7
on darwin_amd64

Use Cases

The Google Artifact Registry is now providing "generic" repositories where we can upload our terraform modules in a zip file. Allowing us to manage smoothly access permissions on the distant module. The problem appears when we try to download the module from the artifact registry using the link found on this documentation page : https://cloud.google.com/artifact-registry/docs/generic#api_1
Even if correctly authenticated with gcloud and terraform, we get a 403 error response because the download url expects an "Authorization: Bearer $(gcloud auth print-access-token)" that we cannot provide with the module's source attribute.

Attempted Solutions

Tried several methods to authenticate through gcloud and terraform. Tried different urls. Tried to pass the access_token as a get parameter (bad practice I know...) but at the end couldn't make it work. The curl request works though :
curl -X GET -H "Authorization: Bearer $(gcloud auth print-access-token)" --output ./MODULE_NAME "https://artifactregistry.googleapis.com/download/v1/projects/PROJECT_ID/locations/REGION/repositories/REPOSITORY_ID/files/FILE_NAME:download?alt=media&archive=zip"

Other solutions exists though and we are aware that we could version our terraform module using git but it would be much harder to configure access permissions for my organization, same thing for GCS buckets.

Proposal

If it's possible and doesn't have too much side effect as a feature, it would be a great relief for my work (and maybe others) to configure custom headers in addition to the source attribute of a module in order to add those headers in the module download request.

Love your work, thanks for considering this request

References

No response

[crw]

Thanks for this feature request! If you are viewing this issue and would like to indicate your interest, please use the 👍 reaction on the issue description to upvote this issue. We also welcome additional use case descriptions. Thanks again!