Skip to content
This repository has been archived by the owner on Mar 28, 2024. It is now read-only.

Allow source url rewriting #99

Open
1 task done
benedikt-bartscher opened this issue Apr 29, 2023 · 5 comments
Open
1 task done

Allow source url rewriting #99

benedikt-bartscher opened this issue Apr 29, 2023 · 5 comments

Comments

@benedikt-bartscher
Copy link

benedikt-bartscher commented Apr 29, 2023

Controller

  • KluctlDeployment

Who are you?

No response

What do you want to do?

I am using Gitlab Enterprise, where pricing is dependend from active seats. That's why i created a group access token for the flux-kluctl-controller. Group Access tokens only support http basic auth, no ssh key auth.

If i use git source urls for kluctl everything works fine on my local machine (automatic ssh key auth). If i use http source urls the flux-kluctl-controller works. However i see no way to keep both working with kluctls current apis.

Possible solutions:

  • Allow source url rewriting like contextOverride
  • Add http auth support to kluctl
  • Add k8s secret fetching support to kluctl (just use http auth with the cluster's secret)

Current (ugly) mitigation: I just use --local-git-group-override for all local kluctl commands. But this requires me to keep all those repos up2date on my machine.

Why do you need that?

No response

@codablock
Copy link
Contributor

codablock commented Apr 29, 2023

Kluctl already supports HTTP basic auth for Git. You'd have to setup https://git-scm.com/docs/git-credential-store on your machine and Kluctl will respect it. On the controller side, you'd then have to setup a secret with basic auth credentials.

Edit: Just realised that Git auth via the Kluctl CLI is not documented at all.

@benedikt-bartscher
Copy link
Author

benedikt-bartscher commented Apr 29, 2023

And i thought i missed something. Should've used more ag and grep.
Do you think source url rewriting could still be a useful feature? I kindof wanna keep using ssh key auth for my machine only, cause i have my ssh keys on a yubikey.

Edit: Source url rewriting would also allow using a different git mirror. For example if you mirror all you gitops/infrastructure related repos to another destination for some reason.

@codablock
Copy link
Contributor

Hmm, url rewriting doesn't feel "right" tbh, but I can't fully express why it doesn't feel right :D

What about a new type of Git Urls instead? Something like git+auto://gitlab.com/my-group/my-project and then Kluctl will try SSH + SSH-auth first and then revert to HTTPS + basic-auth. This way it's visible immediately that the URL is "different" compared to what is known and it will kind of force the unexpecting reader to check the docs and then understand the implications.

@benedikt-bartscher
Copy link
Author

It feels a bit wrong but that's the world we are living in... We also have a contextOverwrite cause there are differences between the local setup and the cluster setup.
The "auto-url" idea has the big drawback of lots of failed logins, logs, traffic,... I.m.o. "hardcoded" rewrites for specific domains/prefixes would be more stable and predictable.

@codablock
Copy link
Contributor

Hmm ok, I agree. Let me think about this a bit more but I now also prefer the rewrite way.

Whatever the solution will be, I most likely won't find time for it in the near future. I assume you can for now continue with either the http basic auth solution? Another option would be to use "Deploy Keys" in Gitlab for now, which can however only be configured on project level, meaning that you'd have to do the deploy key configuration multiple times.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants