Is it possible to use an HTTPS URL for a Git repository?

[ndouglas]

I've deployed Lagoon-Core and Lagoon-Remote in a cluster located behind a TIC (firewall).

When the project repository has an HTTPS URL, the build process fails within seconds. (I'm not seeing any logs with explicit error messages; I haven't yet managed to set up the full logging infrastructure, though)

According to this:

GIT_REPO | Full URL of Git Repo to clone/checkout, should be a ssh compatible Git Repo

The problem is that outgoing SSH connection attempts are dropped by the TIC. There is no way around this.

The message above about SSH compatibility is unambiguous. However, looking through the scripts, nothing really jumps out at me as a reason that SSH should be required.

Could you tell me if this is by design, or due to limitations in HTTPS cloning, or if it should work but I'm messing something up? 😃

[shreddedbacon]

Hey @ndouglas, we use ssh git urls so that we can use deploy keys to access the repository, and the deploy keys can be added to the repository with read only, because Lagoon doesn't need to push into the repo at all.

If your repository is public, then the https endpoint should work, as there isn't a reason to try and authenticate.

Lagoon doesn't support private repositories that only support HTTPs as the source to pull from, because there isn't currently a way to inject user credentials or api tokens to log in to whichever git provider you're using.

This isn't something that I think I've seen requested before either, but we could possibly build this functionality in.

[ndouglas]

Thanks @shreddedbacon! That's very helpful. Yeah, we have a public repo.

I didn't realize the specifics of how the TIC was implemented. I believe what happens is that outgoing HTTPS requests are answered by a MITM proxy server, which obv presents an internal certificate that must be trusted by the requesting process. So I think it might've been failing immediately because Git was seeing that internal TLS cert and (rightly) bailing.

So I built my own derivative of the kubectl-build-deploy-dind (IIRC) container, injecting that internal cert, and I think that might work. If not, the problem's elsewhere, surely on my side of things 😅

Thanks again for your help, Ben, I deeply appreciate it.

[shreddedbacon]

Ah yes, that MITM would probably cause quite a few issues.

Injecting the internal cert into the kbdd image is a good step, just make sure you do it the alpine way, might be better to do it in the image kbdd is built from which is https://github.com/uselagoon/lagoon/blob/main/images/kubectl/Dockerfile

[ndouglas]

Yeah, that makes sense. Thanks!

[tobybellwood]

a quick note on the fork of uselagoon/service-images - that's suuuper old at the moment - you're better off to fork uselagoon/lagoon - all the service images are current in there

[ndouglas]

Ah, thanks! I'm sure that catch saved me a lot of time.

[tobybellwood]

We will be looking at this again shortly - the kubectl-build-deploy-dind image is updated far more regularly than the others (and indeed the rest of Lagoon) - so it makes more sense to split that out into a separate repo with it's own test/release process