https protocol for git support

[vyckou]

For now, flux does support HTTPS protocol for gitops repository only partially. There are lots of code and functionality, which would not be required to execute, if git-url would be https:// and not ssh://

As you are using git CLI client and invoking git commands to deal with gitops repo, passing url https://apikey@github.com/org/repo.git works, but everything which is linked about SSH keypairs are not required and adds additional overhead for the setup and runtime

If using HTTPS protocol instead of SSH would not require:

• creation of the SSH keypair on flux deployment in K8s
• usage of the ssh generator
• k8s secret with private key

On the git SCM side, that would bring pluses as:

• adding flux git user to the gitops repo(s) with r/w access, instead of putting public keys on the repos

this behaviour would enable to run flux in Openshift environments without granting flux a priv mode. - creation of the dockerfile with USER directive is not working, as often hardened Openshift setups expects userid with custom ranges.

[squaremo]

There is redundant code if you want to use https:// rather than ssh://, but I don't think you especially have to worry about it -- so long as the k8s secret exists, fluxd will create a key and put it there, but you don't have to use it or think about it.

I suppose fluxd might expect/create the key depending on the scheme of the git URL. Is that the sort of thing you had in mind?

[vyckou]

@squaremo Yup putting https:// works, I am more concerned about redundant code and bits and pieces which are being used for setting up and acting , if ssh:// was specified. It's just not neat and a bit misleading. I could try to make a pull request to address the redundant code, if you don't mind

[squaremo]

@vyckou Sure, that would be welcome!

One catch I can think of is that we generally do want to create a key if the git URL isn't given. The reason is to do with bootstrapping: in Weave Cloud, for example, the daemon is started with no arguments, then the SSH key obtained for the user to install in their repo; this way, the daemon is will start syncing as soon as it's given the URL to the repo, rather than requiring another step.

Another is that the read-only git feature (#1741) needs the k8s secret resource, to store its high water mark; so either that needs to be adapted, or we live with always having a secret, even if its empty.

[linuxbsdfreak]

+1 to have this included.

[vyckou]

@squaremo pull request added
#2438

happy to get comments

[gallexme]

Anyway to use it already? / ETA for new release? :)