Allow mutual TLS with registry with redirects to the object storage

Inizia tracciando il pull del chart OCI di source-controller quando .spec.certSecretRef fornisce una CA, quindi confronta la gestione dei certificati con internal/tlsutil/tls.go di Helm intorno alle righe 112-116. Riproduci il reindirizzamento a S3 usando la configurazione del registry fornita e considera completato il lavoro quando il pull attraverso il reindirizzamento ha esito positivo, con il comportamento dei certificati documentato e testato.

Environment:

• OCI registry with redirect on pull configured
• source-controller v1.7.4

Problem statement

Registry with "redirect on pull" here means that when getting the image registry will not give the client a blob directly, but rather a 302 code with a location if this blob on the object storage.

The concrete case is local registry certificate signed by the internal CA which gets passed to in .spec.certSecretRef of a HelmRepository (repositiry type is oci). When chart image gets pulled registry redirects the client (source-controlelr) to the AWS S3 server with a proper trusted PKI certificate.

This results in a situation where source-controller checks the validity of the certificate of the object storage server using the CA certificate provided earlier in the HelmRelease object. This will obviously fail:

chart pull error: failed to download chart for remote reference: failed
      to get ''oci://registry/charts/kcm-templates:1.1.0-rc5'':
      failed to copy: httpReadSeeker: failed open: failed to do request: Get "https://s3.eu-west-3.amazonaws.com/docker/registry/v2/blobs/sha256/f6/f631: tls: failed to verify certificate: x509: certificate is valid for *.s3.eu-west-3.amazonaws.com,
      s3.eu-west-3.amazonaws.com, *.s3-eu-west-3.amazonaws.com, s3-eu-west-3.amazonaws.com,

This pull works with helm cli for example, because helm adds custom certificate to the pool of the system certs and checks the validity against the pool and not just a single CA certificate (ref: https://github.com/helm/helm/blob/main/internal/tlsutil/tls.go#L112-L116).

The request

Flux should allow that types of environments, either by adding system certificate pool implicitly (as in case of helm) or with an additional flag to enable it.

As I understood the current behavior (single certificate check) is to address certain security-related scenarios. But in the previously described environment it's becomes inconvenient and to overcome this it's required to mount custom certificate directly to the source-controller pod, which will add it to the certificate pool by go runtime.