Support use of Git repository credentials during Helm dependency update

[scalen]

Summary

Support should be added for using private Git repositories as the repositories for Helm sub-chart dependencies. This is currently not available.

Motivation

Say you have an umbrella chart containing many inter-connected sub-applications, each managed in their own private Git repository, with their Helm chart source alongside them. You want to use Git for versioning your Charts, rather than a chart museum, so you specify the sub-chart repositories using the helm-git plugin and the git+https:// downloader plugin it provides. Developers who wish to deploy the umbrella chart locally specify their own credentials for the private sub-application repositories via the credentials.helper store git config and their ~/.git-credentials file.

You now want to deploy the Umbrella chart on production with ArgoCD. You do the equivalent of setting up the git config credentials.helper store, i.e. setting up each sub-application Git repository with appropriate credentials as a separate HTTPS Git repository in Settings > Repositories.

You try to create an Application for the Umbrella chart, but you get the following error:

`helm dependency build` failed exit status 1: fatal: could not read Username for 'https://github.com': No such device or address
fatal: could not read Username for 'https://github.com': No such device or address
Error in plugin 'helm-git': Unable to fetch remote. Check your Git url.

Proposal

Credentials for all configured Git repositories should be available at templating time, presumably via a git config credentials.helper mechanism.

I have been looking into building a simple credentials helper using the Argo CD RepositoryService API (specifically Get Repository, or the equivalent argocd cli command), but this appears to NOT:

1. contain passwords, even when in a session logged in as admin.

   argocd@argocd-server-7ffd7df6d5-m7f9s:~$ argocd repo get https://github.com/***/*** -o json
   {
   "repo": "https://github.com/***/***",
   "username": "scalen",
   "connectionState": {
   "status": "Successful",
   "message": "",
   "attemptedAt": "2021-06-29T20:55:58Z"
   },
   "type": "git",
   "name": "***"
   }

2. be supported in a generic way when calling from the container itself:

   argocd@argocd-server-7ffd7df6d5-m7f9s:~$ curl \
   https://localhost:8080/api/v1/repositories \
   --insecure \
   -H "Authorization: Bearer $(cat < /var/run/secrets/kubernetes.io/serviceaccount/token)"
   {"error":"invalid session: SSO is not configured","code":16,"message":"invalid session: SSO is not configured"}

   argocd@argocd-server-7ffd7df6d5-m7f9s:~$ curl \
   https://localhost:8080/api/v1/session \
   --insecure \
   -d "{\"token\": \"$(cat < /var/run/secrets/kubernetes.io/serviceaccount/token)\"}"
   {"error":"token-based session creation no longer supported. please upgrade argocd cli to v0.7+","code":16,"message":"token-based session creation no longer supported. please upgrade argocd cli to v0.7+"}

My proposal therefore involves providing an endpoint within one of the existing executables (or a new executable) that re-uses existing repository credential fetching logic to serve the Git credential helper interface, and setting that as a git config --global credential.helper.

Alternative for my usecase

If ArgoCD Helm repository specifications were to support Helm downloader plugin protocols, then these sub-application Git repositories could be specified as Helm repositories directly using the git+https:// protocol, and the Umbrella chart could then refer to them by reference (e.g. "@sub-application"). However, Helm downloader plugins are not currently utilised when trying to create connections to Helm repositories via the Argo CD UI.

This could be implemented by using the helm repo add command (or equivalent Go code) under the hood to verify the settings.

[scalen]

Other Usecases

The proposed solution above has wider application than during helm dependency update when using the helm-git plugin. It applies to any use of Git outside the scope of the Argo CD binary.

An example of this that does not involve extending the Argo CD Docker image with helm plugins is the use of Argo CD Config Management plugins. Consider the following example:

A project is split into two repositories: The application code and its abstract configuration values, owned by an application team; and the Helm chart and environment-specific configuration values, owned by an infrastructure team. Both repositories are private, with separate credentials.

The infrastructure team wants to use Argo CD to deploy this application by its chart, incorporation both application configuration and infrastructure configuration values. As such, they create a Config Management plugin that clones the configuration from the application repo, then uses both that and the already-checked-out infrastructure configuration when calling helm template.

Without access to the Argo CD repository DB from on-host Git processes, they would be required to specify the credentials for the application repo in plain text (e.g. https://USER:PASSWORD@github.com/organisation/application-repo). With this access, however, they could securely store the credentials for this second Git repository in Argo CD, and still access the repository in this Config Management plugin.