Firstly, I'd like to thank you for this awesome project. It's crazy how HashiCorp hasn't included it yet into Terraform. Now onto the issue at hand.
Issue
I am testing terraform-backend-git standalone server using the Docker image ghcr.io/plumber-cd/terraform-backend-git:latest (v0.1.2 at this time). The Terraform backend is setup like so:
When running terraform init I get the following output:
Initializing the backend...
Successfully configured the backend "http"! Terraform will automatically
use this backend unless the backend configuration changes.
Error refreshing state: Failed to get state: GET http://localhost:6061/?type=git&repository=https://<MY-GIT-SERVER>&ref=main&state=terraform.tfstate giving up after 3 attempt(s)
While the server produces the following output:
WARNING: Published ports are discarded when using host network mode
[terraform-backend-git]: WARNING: HTTP basic auth is disabled, please specify TF_BACKEND_GIT_HTTP_USERNAME and TF_BACKEND_GIT_HTTP_PASSWORD
[terraform-backend-git]: listen on 0.0.0.0:6061
[terraform-backend-git]: Get "https://<MY-GIT-SERVER>/info/refs?service=git-upload-pack": x509: certificate signed by unknown authority
[terraform-backend-git]: Get "https://<MY-GIT-SERVER>/info/refs?service=git-upload-pack": x509: certificate signed by unknown authority
[terraform-backend-git]: Get "https://<MY-GIT-SERVER>/info/refs?service=git-upload-pack": x509: certificate signed by unknown authority
Using http://<MY-GIT-SERVER> instead of https://<MY-GIT-SERVER> yields the same output, as the request is redirected by the git server back to https. Going via ssh is not possible as the access method must be via an access token (i.e. using GIT_USERNAME/GITHUB_TOKEN env vars). As such, the StrictHostKeyChecking option is useless.
Solution
As I see it, there are two ways this can be solved:
Including CA certificates with the docker image.
Adding an option to ignore TLS for HTTPS requests.
Include CA Certs in the image
This would be as simple as adding the following instruction after FROM debian:buster to the Dockerfile
RUN DEBIAN_FRONTEND="noninteractive" apt-get update && apt-get install -y ca-certificates
I have build the image locally and can confirm it works once the certificates are included with the image.
Ignoring TLS for HTTPS requests
As the project is using the go-git library, ignoring TLS would mean including the attribute InsecureSkipTLS: true to all git requests. This would involve more coding as the option has to be added to all constructors of CloneOptions, PullOptions, FetchOptions, PushOptions and ListOptions. Not very complex, but certainly more involved than the first option.
Firstly, I'd like to thank you for this awesome project. It's crazy how HashiCorp hasn't included it yet into Terraform. Now onto the issue at hand.
Issue
I am testing
terraform-backend-git
standalone server using the Docker imageghcr.io/plumber-cd/terraform-backend-git:latest
(v0.1.2
at this time). The Terraform backend is setup like so:When running
terraform init
I get the following output:While the server produces the following output:
Using
http://<MY-GIT-SERVER>
instead ofhttps://<MY-GIT-SERVER>
yields the same output, as the request is redirected by the git server back tohttps
. Going viassh
is not possible as the access method must be via an access token (i.e. usingGIT_USERNAME
/GITHUB_TOKEN
env vars). As such, theStrictHostKeyChecking
option is useless.Solution
As I see it, there are two ways this can be solved:
Include CA Certs in the image
This would be as simple as adding the following instruction after
FROM debian:buster
to the DockerfileI have build the image locally and can confirm it works once the certificates are included with the image.
Ignoring TLS for HTTPS requests
As the project is using the
go-git
library, ignoring TLS would mean including the attributeInsecureSkipTLS: true
to all git requests. This would involve more coding as the option has to be added to all constructors ofCloneOptions
,PullOptions
,FetchOptions
,PushOptions
andListOptions
. Not very complex, but certainly more involved than the first option.