Fix/refactor how web console is accessed (protocols, etc)

[StianOvrevage]

I'm having a PITA trying to expose ArgoCD through a regular nginx-ingress. There's all kinds of tips and tricks on how to do this. Annotations. Manually adding flags to this and that service.

The kind of problems a Kubernetes deployment should eliminate.

I think it would be really good for adoption and user happiness to follow the same principles and standards as everything else. I don't have in-depth knowledge of all the things ArgoCD does differently but I would guess these, and possibly more:

• Mix multiple protocols on the same port (gRPC + HTTP mentioned).
• Default to HTTPS. Maybe to support the above.
• Redirect HTTP to HTTPS. Probably related to the above.
• Use own certificate (probably breaks or requires customizing cert-manager to play nicely).
• Since ArgoCD assumes "raw" access to the Internet I'd guess there's also problems with rewriting and redirecting paths.
• Documented workarounds targeting one specific variant of nginx-ingress, not mentioning there are several which will not work with the stated steps (https://github.com/nginxinc/kubernetes-ingress/blob/master/docs/nginx-ingress-controllers.md , this is probably the one that tripped me).

There's a lot of open issues stemming from this:

#3896
#2953
#2968
#2784
#2708
#2593

And maybe:
#3975

And a bunch of closed issues.

But finally, thanks for the awesome work so far. ArgoCD really makes my life easier, which makes me emotional when I can't easily share the joy with my developers via the WebUI 😄

[jessesuen]

@StianOvrevage is there a particular issue that you would like changed? Is this a documentation request? I didn't see the actual request in your description.

[StianOvrevage]

Sorry about that.

I would like to deploy ArgoCD with a regular Ingress (backed by nginx-ingress), that also happens to use cert-manager etc.

Without any hacks, workarounds or custom stuff.

[jessesuen]

Just had a quick discussion about this with @alexmt . Specifically for the gRPC vs. gRPC-Web decision that currently needs to be decided on the CLI, we're thinking to simplify this such that either:

1. the CLI can auto-detect connection protocol and switch accordingly
2. the server can advertise a preferred protocol so that all CLI will use by default

[psionic-k]

Would prefer to decouple the CLI and web access. Typical CLI usage happens with kubectl and port forward availability. Typical use case for web UI is frequently a manager who just wants to see what's on fire and might not have kubectl configured. it would make sense to just not tie them together.

[psionic-k]

I want to clarify that even a CLI user typically will use different creds, such as the admin creds, during the CLI bootstrap phase, switching to SSO after they get it set up. There's basically no value in keeping the two forms of traffic together. Where the CLI talks to and where a web client talks to are so frequently different.

[jessesuen]

Would prefer to decouple the CLI and web access.

I think if this is your use case, I don't think this feature would be used by you. Is there something lacking in current implementation if this is your access pattern to Argo CD?

FYI, there is a argocd XXXX --port-forward flag that allows you to connect to the Argo CD API server using port-forwarding only, so that the server doesn't even need to be exposed at all.