The following configuration was performed according to the official documentation(https://argoproj.github.io/argo-cd/getting_started/):
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: argocd-server-ingress
annotations:
kubernetes.io/ingress.class: crs-nginx
nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
nginx.ingress.kubernetes.io/ssl-passthrough: "true"
spec:
rules:
now锛宔ncounter a redirect loop or are getting a 307 response code.So I added nginx.ingress.kubernetes.io/backend-protocol: "HTTPS" according to the official documentation to the configuration above.
The web page can be opened normally,But I got the following error during argocd login command
FATA[0008] rpc error: code = Internal desc = transport: received the unexpected content-type "text/plain; charset=utf-8"
I don't know how to configure it to open the page normally and the argocd login command can log in normally.
Same problem, any workaround ?
Same problem!
After searching for a while I found a solution that works in my case.
I'm using Traefik instead of Nginx, but I believe this can be used with any ingress controller.
The problem is that by default Argo-CD handles TLS termination itself and always redirects HTTP requests to HTTPS. Combine that with an ingress controller that also handles TLS termination and always communicates with the backend service with HTTP and you get Argo-CD's server always responding with a redirects to HTTPS.
So one of the solutions would be to disable HTTPS on Argo-CD, which you can do by using the --insecure flag on argocd-server.
This is actually documented here:
https://argoproj.github.io/argo-cd/operator-manual/ingress/#option-2-multiple-ingress-objects-and-hosts
Its just not exactly obvious.
It would be nice if there was a page with command line flags for the server somewhere in the docs.
Using NGINX ingress, send --insecure arg for container of argocd-server Deployment. It works for me.
spec:
containers:
- command:
- argocd-server
- --staticassets
- /shared/app
- --insecure
Help: https://argoproj.github.io/argo-cd/operator-manual/ingress/
Somehow I ran into the same issue with a 308 redirect. I added the --insecure arg but no change so far. Any ideas?
Nginx and other reverse proxies send the header X-Forwarded-Proto to indicate that TLS is being handled by the proxy. This could be checked in addition to checking the secure setting in the useSecure function. I have yet to venture into writing Go, so I am not sure of how that is done exactly. Maybe I will give it a shot.
For my case, i have AWS ELB where the SSL is offloaded, then ingress controller receives on port 80, then forward to argocd-server service on insecure port (80).
I fixed the issue of too-many-redirects by implementing the above solution:
spec:
containers:
- command:
- argocd-server
- --staticassets
- /shared/app
- --insecure # <-- this thing needs to be added
I was struggling with this issue for ours, and finally found this thread.
@georgepaoli suggesiton worked. Adding --insecure fixed the issue. I suggest adding this to Argo's Traefik docs while the issue persists.
Spent half a day with ingress settings only to figure out this small piece of information missing. Thanks @leandro-manifesto
Most helpful comment
After searching for a while I found a solution that works in my case.
I'm using Traefik instead of Nginx, but I believe this can be used with any ingress controller.
The problem is that by default Argo-CD handles TLS termination itself and always redirects HTTP requests to HTTPS. Combine that with an ingress controller that also handles TLS termination and always communicates with the backend service with HTTP and you get Argo-CD's server always responding with a redirects to HTTPS.
So one of the solutions would be to disable HTTPS on Argo-CD, which you can do by using the
--insecureflag onargocd-server.This is actually documented here:
https://argoproj.github.io/argo-cd/operator-manual/ingress/#option-2-multiple-ingress-objects-and-hosts
Its just not exactly obvious.
It would be nice if there was a page with command line flags for the server somewhere in the docs.