feat: allow connecting to HTTP Git repositories #1504
Conversation
In preparation of allowing insecure (non-TLS) HTTP endpoints for Git URLs. Which we do want to allow to connect to e.g. local (development) servers, but without ever passing credentials to them. To not introduce breaking changes for HTTP Helm repositories which at present appear to allow passing basic auth credentials over an insecure wire, we specifically check for the type to equal Git before bailing. If we decide this is actually undesired behavior, it can easily be removed. Signed-off-by: Hidde Beydals <hidde@hhh.computer>
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
✅ Deploy Preview for docs-kargo-akuity-io ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
This widens the refusal to an HTTP endpoint for _any_ type, which at present includes "classic" Helm repository HTTP endpoints. Signed-off-by: Hidde Beydals <hidde@hhh.computer>
|
waiting for v0.5.0 🤞 |
|
@geowalrus4gh we build nightlies. Feel free to use the latest. |
|
tried the latest [0.4.1-unstable-20240223] but getting the below error |
|
Did you also update the CustomResourceDefinitions on the cluster to match the changed regular expression? |
|
Yes, I installed a fresh Kargo helm installation after deleting old CRDs. Here is the extract from the new Warehouse CRD installed. |
|
@geowalrus4gh what is the command you used to apply? Did you use kubectl or kargo CLI? |
|
i used helm command to install. I copied the crds from the github and applied, then it worked. But now am getting an authentication failed error.
Does that mean, the repo secret for the http URL is not being read by kargo? |
|
That is correct. It was a compromise we arrived at in order to support unsecured connections -- we won't pass credentials over them. |
|
@krancour, How are you doing? I didn't fully understand what that meant?! if I want to use a HTTP git repo the Kargo Controller will not use the creds stored in the secret. |
|
Hey @tal-hason, good to hear from you!
Making sure you spotted the missing "S". (Easy to overlook.) This is strictly for HTTP and not HTTPS. Kargo is refusing to pass credentials over an unsecure connection. Practically speaking, this shouldn't be much of a limitation. The only time I can think of where you would conceivably access a repo over an unsecure connection would be during local development, in which case you can just skip the creds entirely and configure the repo to allow pushes without authenticating. |
|
Hi @krancour , Everything is awesome 😎. Hope you are good to. Soooo, I didn't miss the "S" in the HTTP. I have a customer that we are trying to implement Kargo. They have their own local disconnected bitbucket git, they are running it unsecured, but you must authenticate before pushing any changes to the repo. So to not use the defined cerds, is a bit miss. Also, you don't have to pass the creds in the HTTP url. Store it in the .gitconfig and in the .git-credentails and the git will use it. Also it is possible to add an use unsecure connection, with a note that this is not recommended. And let the customer decided what best for him. But to disable it totally, it over controlling, don't be apple 😜 |
Well, both of these are technically true. The credentials are passed as a header. And on an insecure connection the header is perfectly accessible to anyone or anything reading the request. This is exactly why the decision was made in the first place to disallow the use of creds over an unsecure connection. After even a single use, you have to assume the credentials could have been compromised. At the time we made that decision, there was some precedent for it (or so we thought?), as we could recall kubectl disallowing the use of credentials over an unsecure connection. Just now, I've been searching for any reference to that and keep coming up empty-handed, perhaps partly because as far back as v1.22.0, unsecure connections to the API server aren't even possible. So if our recollection was correct, it was in the distant past and since then, if anything, Kubernetes has moved in a more dogmatically secure-by-default direction. Anyway -- that's all background. We discussed at our team meeting this morning and all agreed that we will consider adding this as some kind of highly discouraged option in the future if we hear of more users / use cases that require this. Even as an opt-in, we don't want to relax security if this use case is an extreme outlier. Please feel free to open a new issue. If the issue attracts a lot of attention, it will strengthen the case for this option to exist and may also accelerate the timeframe for getting it done. |
|
@krancour ,thanks as always on the detailed answer 😃. I can tell you the I going at least 3-4 customers that have the potential to work with Kargo that have unsecured git server, do to that their network is disconnected. I understand the secure by design concept and constraints, but security at the end is the customer risk to take. I will Open an issue and see what is what. |
Fixes: #872
This adds support for connecting to Git repositories over an (insecure) HTTP wire as described in #872 (comment), while taking into account the effect it would have on HTTP Helm repositories as observed in #872 (comment).
Effectively, this means that connecting to any HTTP endpoint is now allowed as long as this does not require authentication. This includes "classic" Helm repositories served over HTTP, where basic authentication used to be supported in the past.