GitHubBinding should align with expectations of the hub CLI

[mattmoor]

I was musing about this with @lberk this morning, wanted to get it into an issue so we don't lose the idea.

Essentially the idea is that instead of inventing our own contract for projecting credentials into a process that we align with the credential model of established tooling. When @evankanderson was talking about the hub CLI in another context this morning it made me realize that we should probably make GitHubBinding setup the environment such that hub "just works(tm)".

@lberk found this description of the hub auth model:

GitHub OAuth authentication
Hub will prompt for GitHub username & password the first time it needs to access the API and exchange it for an OAuth token, which it saves in ~/.config/hub.

To avoid being prompted, use GITHUB_USER and GITHUB_PASSWORD environment variables.

Alternatively, you may provide GITHUB_TOKEN, an access token with repo permissions. This will not be written to ~/.config/hub.

This seems like it would be fairly trivial for us to align on.

[mattmoor]

Here's a sample where we did this for the govc CLI for vSphere: https://github.com/vmware-tanzu/sources-for-knative/blob/master/samples/govc/README.md and I think it really shows the power of using Bindings with unmodified upstream software 🤩

[lionelvillard]

If I understand well this proposal, it seems contrary to proper security best practices which it to not use environment variables for storing secrets. Just saying...

[lberk]

@lionelvillard could one not load the token into ~/.config/hub instead of envvar?

[mattmoor]

Determining the home die may be tricky, but that is also what I would prefer. An alternative would be to file a feature request to support overriding the location of the file (like DOCKER_CONFIG), if it doesn’t exist already. In fact it might even be possible to send a PR 🤔

[lionelvillard]

@lberk yes that should work for the single-tenant github receive adapter.

[tzununbekov]

I can tackle this if no one mind

/assign

[tzununbekov]

An alternative would be to file a feature request to support overriding the location of the file (like DOCKER_CONFIG), if it doesn’t exist already

hub CLI supports the config location overriding from HUB_CONFIG envvar value. Although config format requires specifying a username, I think it can be replaced with dummy value for most of the commands (if we don't want to extend binding spec with username)

off-topic:
Should githubbinding be tied to hub CLI only? For example, recently I hear a lot of positive feedback about another official tool cli.github.com. Does it make sense to differentiate bindings by subject selector to provide appropriate runtime? For example:

apiVersion: bindings.knative.dev/v1alpha1
kind: GitHubBinding
...
  subject:
...
    selector:
      matchLabels:
        githubbinding: hub-cli

will provide hub CLI contract, while githubbinding: gh-cli make a runtime for gh CLI

[mattmoor]

TBH, I think we can surface both, assuming they don't conflict. I knew Github had two CLIs (I just figured they'd deprecated one 🙄), but we should align with whichever is more popular, or newer, or both. 🤣

[tzununbekov]

Okay, turned out that both hub and gh are using git CLI for clone/push operations and it causes unwanted auth prompts for every request even with GITHUB_TOKEN envvar set. To avoid this we can either use a simple auth helper (mounted from configmap) or supply config file with credentials. Where would be the right place to add cm/secret setup? In theory it needs to be done on the psbinding reconciliation, but also it may worth validation on each admission request, wdyt? Thanks!

[sebgoa]

@antoineco any thoughts on this one ?

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.