search

validatedpatterns / common

Apache License 2.0
2 stars 20 forks source link

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

Open wadebee opened 8 months ago

wadebee commented 8 months ago

References:

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 commented 8 months ago

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 commented 8 months ago

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 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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.