What paths does the CLI need access to?

[djfinnoy]

I'm running ArgoCD behind an oauth2-proxy auth policy with Istio.

Web UI works fine, but I'm having problems with the CLI. I allow certain endpoints of my ArgoCD URL through without going through the reverse proxy, eg. to make github webhooks work:

...
        - operation:
            hosts:
              - argocd.mydomain.com
            notPaths:
              # Skip oauth2-proxy for these paths
              - /api/webhook
              - /api/dex*
              - /api/v1/*

The CLI does not work with this setting, I get the following error:

$ argocd login --grpc-web argocd.mydomain.com
FATA[0003] rpc error: code = Unknown desc = unexpected EOF 

It works if I disable the oauth2-authentication flow entirely, so I'm guessing that the CLI is hitting the reverse proxy, and that I will need to whitelist more paths above to get it working.

Does anyone know what to do?

[djfinnoy]

Turns out this caused by peculiarities with istio when dealing with grpc. Had to do this:

        - operation:
            notPaths:
              - /application.ApplicationService/List
              - ... # etc, for each grpc command

[karlschriek]

Could you elaborate on this? I am having trouble getting the CLI to connect to argocd.mydomain.com when doing TLS termination in the Gateway and setting the argocd-server to "--insecure". With argocd login --grpc-web argocd.mydomain.com I get:

FATA[0006] rpc error: code = Unknown desc = POST https://argocd.mydomain.com:443/session.SessionService/Create failed with status code 40

More details here: #10371

[djfinnoy]

I have a reverse proxy in front of ArgoCD, and the CLI needed to be allowed to circumvent this reverse proxy and communicate directly with ArgoCD. In other words, I am using an Istio AuthorizationPolicy resource to determine what Istio does with requests going to argocd.mydomain.com.

The CLI needs to speak to Istio directly, so I needed to modify the AuthorizationPolicy so that requests made by the CLI go directly to ArgoCD.
The CLI uses GRPC, not http, so I had to write the appropriate path statements in the AuthorizationPolicy for the CLI to reach ArgoCD, and not the reverse proxy.

I don't think you are having the same issue; I don't see any AuthorizationPolicy resources in your code snippets.

I read your issue. FYI, we have identical setup for the Istio gateway and virtual service.
The only difference I can spot is that I am not using the --insecure flag, this works for me:

argocd login argocd.mydomain.com --username hello --password world --grpc-web

[karlschriek]

Yes, you are right, I don't mention any AuthorizationPolicies since at this point I actually have an "allow-all" policy set up on the argocd namespace. It is definitely the gRPC that is the problem though, since access via the web browser is no issue at all, even when argocd-server is started in --insecure mode (which I need in order to terminate TLS at the Gateway).

The only difference I can spot is that I am not using the --insecure flag, this works for me:

Just want to make sure I understand this statement correcly. Are you not starting up the ArgoCD server with the --insecure flag? Or are you just not using the --insecure flag when running argocd login?

[djfinnoy]

I am using --insecure for the ArgoCD application, and I am not using --insecure in the argocd login CLI call.

Just shooting from the hip here, but I don't think you can use --insecure in the CLI calls when your Istio virtual service is redirecting http to https.