[SURE-9881] CA in a secret referenced in spec.helmSecretName or spec.helmSecretNameForPaths not used when pulling Fleet bundle helm chart from a git repository

[kkaempf]

SURE-9881

Issue description:

The fleet documentation (https://fleet.rancher.io/ref-fleet-yaml) notes the ability to pull the chart in a bundle from a git repository:

 # Git repositories can be downloaded via unauthenticated http, by using for
  # example:
  #
  # `git::http://github.com/rancher/fleet-examples/single-cluster/helm`.

However, this git method does not use any CA configured in a secret referenced on the GitRepo spec.helmSecretName or spec.helmSecretNameForPaths. By comparison, such a CA is used when pulling the chart with simple GET of chart .tgz URL

Business impact:

Customer is unable to deploy charts via Fleet that are hosted in their internal gitea instance, which is deployed with a private CA

[weyfonk]

See PR mentioned above this comment.

This limitation is caused by hashicorp/go-getter's GitGetter not supporting custom client options, unlike the HttpGetter for which transport, and therefore authentication, can be configured with a custom CA bundle.

Possible fixes for this could include:

• enhancing the GitGetter to enable custom CA bundle injection
• bypassing go-getter for git-hosted Helm charts, for instance by relying on go-git as the gitcloner command does.

[darkhonor]

Is there a way to configure the GitRepo to ignore the custom CA certificates until this is patched? I have tried adding insecureSkipTLSVerify: true but with no effect.

This has the effect of rendering Fleet useless in Airgap or STIG environments.

[p-se]

QA Template

1. Create a (self-hosted) git server that supports HTTPS.
2. Provide it with a self-signed certificate.
3. Create a git repository on that self-hosted git server which contains a simple helm chart. It can just contain a ConfigMap.
4. Create a repository that contains a fleet.yaml file which points to the git server in its helm.chart field (e.g. git::http://gitserver/foo/bar). It can but does not have to be on the self-hosted git server. This URL instructs go-getter to (git) clone the repository behind http://gitserver/foo/bar.
5. Create a GitRepo resource which points to the repository that contains the fleet.yaml file. This GitRepo can have different settings, depending on what should be tested:
   1. CABundle field in the GitRepo resource. If this field is set, it will use the certificate to connect to the first git repository that contains the fleet.yaml file. It will also try to use this certificate to connect to the git server that the fleet.yaml's helm.chart field points to, unless
   2. helmSecretName in the GitRepo resource points to an existing secret and has a configured CABundle or has InsecureSkipVerify set to true, or
   3. helmSecretForPaths in the GitRepo resource points to an existing secret and has a configured CABundle or has InsecureSkipVerify set to true, or
   4. skipInsecureVerifyTLS in the GitRepo is set to true.
6. Test meaningful permutations of those settings
   1. On the positive testing side, we need to make sure that
      1. CABundle in GitRepo works for fleet.yaml,
      2. CABundle in secret defined in helmSecretName works for fleet.yaml and
      3. CABundle in secret defined in helmSecretNameForPaths works for fleet.yaml, as well as
      4. InsecureSkipTLSVerify in GitRepo works for fleet.yaml,
      5. InsecureSkipVerify in helmSecretName works for fleet.yaml, and
      6. InsecureSkipVerify in helmSecretNameForPaths works for fleet.yaml.

flowchart TD
  grr[GitRepo Resource]
  subgraph Git Server
    gr1[Git Repository with `fleet.yaml` file]
    gr2["Git Repository with Chart (e.g. ConfigMap)"]
  end

  grr -->|points to| gr1
  gr1 -->|fleet.yaml points to| gr2