What is the proper way to inject a Corporate CA into a Pattern?

[wadebee]

References:

• https://argo-cd.readthedocs.io/en/stable/operator-manual/tls/#tls-certificates-used-by-argocd-server

• https://access.redhat.com/documentation/en-us/red_hat_openshift_gitops/1.10/html/release_notes/gitops-release-notes#known-issues-1-10_gitops-release-notes

What is the proper way to inject a Corporate CA into a Validated Pattern such that:

1. The Cluster ArgoCD instance picks up the CA
2. The Pattern ArgoCD instance picks up the CA
3. For patterns like MultiCloud Gitops that support "pushing" patterns to a "spoke cluster" - those pushes also properly provision the CA trust?

[mbaldessari]

Hi Wade, this is something I am currently working on. I should have most of the code in place in a few days. I'll ping you.

[wadebee]

BTW - I just ran an install with the new v0.0.43 VP operator and it is picking up my ca-inject CM from openshift-operator namespace properly.

That is a customization I can remove from our bootstrapping. Thanks!

[mbaldessari]

Hi Wade,

good catch on the 0.0.43 ;) Yeah with that release the vp operator should respect any custom CAs injected in the cluster.

Right now to get things working (as you probably already figured out). You will need to add the fqdn of the git server + custom CA in the argocd-tls-certs-cm and you will need to do this in the cluster-wide argo and in the pattern argo instances.

For spoke clusters, right now we only push the self-signed CAs to the remote cluster. It should be relatively trivial to push the hub's CA somewhere on the spokes via ACM though. I kind of assumed that spokes clusters will be installed with the custom CA from the start. Can you maybe expand a bit on the use case you have in mind here?

As to the general high-level plans for this, I was thinking the following:

1. We keep on working with upstream on https://www.github.com/argoproj/argo-cd/pull/17503 (I have some feedback I need to address) which in the future would allow to stop having to add a CA for each FQDN we intend to git clone from via argo. It would make things a bit more gitopsy and simpler.
2. We simply assume that the corporate CA is always injected in the trusted-ca-bundle and we configure both argocd instances (by tweaking the repo.initContainers section, to read the trusted-ca-bundle and use it to trust git clones). This change is a little invasive because historically we had just relied on the default cluster-wide argo instance in openshift-gitops and we now essentially need to take over its management. Since this is potentially a bit invasive I might initially hide this change behind some CRD boolean ("experimental" or similar)

Do let me know if this plan matches your expectation or if you think it needs tweaking. Thanks!

[dwinchell]

FYI wadebee And I were able to successfully test this as a workaround:

We dropped this file this file under common/acm/templates/policies/

[mbaldessari]

Am reopening this one, just to track the release of the 0.0.44 patterns-operator which is needed for this functionality to be tested. It's currently stuck on some infra issues to release it to the operator hub.

[WadeBee-NG]

I would like kick-start this issue again.

1. Even though initially closed - it looks like it was never fully resolved/tested.
2. The fix our team used (which was a direct modification to local common) was never included in the "Slim Common" refactoring. Therefore this is now a regression issue for us having recently updated to VP Slim Common.
3. I have found additional information that may be relevant to correcting this issue and uses a different approach than the previous ACM policy-based patch approach.

Official ArgoCD guidance is for Developers to directly modify the argocd-tls-certs-cm ConfigMap.

Downstream RH GitOps doesn’t support direct overrides of this CM:
argocd-tls-certs-cm is overwritten by the operator (v1.4.0) · Issue #271 · redhat-developer/gitops-operator

Although the above issue is closed the guidance is to:
override .spec.tls.initialCerts of ArgoCD CRD

Description: The .spec.tls.initialCerts property in the Argo CD Custom Resource (CR) for OpenShift GitOps manages the initial set of certificates within the argocd-tls-certs-cm ConfigMap, used for connecting to Git repositories through HTTPS.
Here's a more detailed explanation:
• Purpose: The argocd-tls-certs-cm ConfigMap stores the TLS certificates that Argo CD uses to establish secure connections (HTTPS) with Git repositories.
• initialCerts Property: The .spec.tls.initialCerts property in the Argo CD CR allows you to specify the initial set of certificates that should be placed in this ConfigMap when Argo CD is first deployed or updated.
• How it Works: The Argo CD Operator manages the contents of the argocd-tls-certs-cm ConfigMap based on the values provided in the .spec.tls.initialCerts property of the Argo CD CR.

The VP definition for the deployed ArgoCD template is here and the required spec.tls attribute is currently hard-coded.

My suggestion is to modify this Argo template to parameterize the initialCerts attribute as a helm value override.