Provide Ingress configuration option for reverse proxy (or documentation if already available)

[9strands]

Is your feature request related to a problem? Please describe.
In investigating the security posture and configuration of ArgoCD and the GitOps Operator, there seems to be potential risks due to the access that ArgoCD has to the Openshift cluster. ArgoCD has a portal, but its core functionality is not in providing a secure portal, but providing cluster configuration. ArgoCD's documentation provides the capability to setup a reverse proxy, but the GitOps operator only appears to use a route-configuration instead of ingress.

In investigating security we came across this: https://www.trendmicro.com/vinfo/au/security/news/vulnerabilities-and-exploits/abusing-argo-cd-helm-and-artifact-hub-an-analysis-of-supply-chain-attacks-in-cloud-native-applications I found this, which uses the redhat-cop github as a basis for it's exploits and investigation, including making several security recommendations about protecting the portal.

If this is already available, it is not clear to us in the configuration or in documentation as to how to use it - in which case we would request documentation to provide instructions on this setup.

Describe the solution you'd like
ArgoCD has the capability to provide an ingress-based reverse-proxy - https://argo-cd.readthedocs.io/en/stable/operator-manual/ingress/. In order for this to function with a reverse proxy protecting the ArgoCD portal, we need to be able to configure ingress and potentially a secure-configuration of a reverse proxy instead of the route configuration.

Describe alternatives you've considered
In our case, our clusters are public by necessity due to the service we provide, so the OCP API is public. We have no other way to protect the ArgoCD cluster given their positioning.

Additional context
You can see more about our services at
https://github.com/redhat-cop/babylon and
https://github.com/redhat-cop/anarchy

@jkupferer is also attached to this request as we are working together to try and secure ArgoCD/GitOps as a way of managing our clusters.

[anandf]

In investigating security we came across this: https://www.trendmicro.com/vinfo/au/security/news/vulnerabilities-and-exploits/abusing-argo-cd-helm-and-artifact-hub-an-analysis-of-supply-chain-attacks-in-cloud-native-applications I found this, which uses the redhat-cop github as a basis for it's exploits and investigation, including making several security recommendations about protecting the portal.

There is an option provided for disabling the console URL in the ArgoCD CR. Would that be helpful for overcoming this security risk ?
https://access.redhat.com/documentation/en-us/openshift_container_platform/4.12/html-single/cicd/index#gitops-customize-argo-cd-consolelink_setting-up-argocd-instance

ArgoCD operator provides the following options for configuring the Server Ingress.
https://argocd-operator.readthedocs.io/en/latest/reference/argocd/#server-ingress-options

Name	Default	Description
Annotations	[Empty]	The map of annotations to use for the Ingress resource.
Enabled	false	Toggle creation of an Ingress resource.
IngressClassName	[Empty]	IngressClass to use for the Ingress resource.
Path	/	Path to use for Ingress resources.
TLS	[Empty]	TLS configuration for the Ingress.

[9strands]

Hi, @anandf,

Just to make sure, when you say "ArgoCD" Operator, are you talking about the upstream operator? I'm just trying to make sure I understand the recommendation - are you recommending that we drop the official RH operator and use the upstream one for this use-case?

We could disable the console (and that might be our ultimate response if we cannot find a better solution), but the console is a helpful visual tool for ops when there are issues - including in rolling out new applications to see where issues are and what component isn't happy when something breaks. It would definitely be better to keep it up - but shielded - where possible.

I still think the best solution from an application-perspective would be to setup the Gitops Operator to allow a more purpose built system like nginx or apache to reverse proxy with authentication as one of the default setups, to provide some shielding for ArgoCD. This is something I have often seen in Corporate worlds as well for protecting applications inside an intranet so I see this being a request which would likely enable the broader RH Customer-base.

Correct me if I'm wrong, but our Gitops operator does not provide that configuration and setup option?

[jannfis]

Hi @9strands, the GitOps Operator is based on the upstream Argo CD Operator and provides most (if not all) of its functionality. If you have deployed an Ingress controller to your cluster, you can configure the Operator's CR to create an Ingress object instead of a Route in the same way as if you'd configure it in the upstream Argo CD Operator.

[9strands]

Hi, @jannfis, interesting. I'll see if I can tinker that in my development cluster with the operator.