🛠️

ArgoCD insecure 옵션을 통한 무한 리다이렉션 문제 해결기

최민석·2025-07-27

ArgoCD `--insecure` 옵션을 통한 무한 리다이렉션 문제 해결기

argo

ArgoCD를 사용하면서 Web UI 접속이 이상하게 계속 리다이렉션 되는 상황을 겪은 적이 있다.
기존 LoadBalancer 타입으로 배포된 argocd-server를 ClusterIP로 바꾸고, Gateway API에 노출하는 과정에서 발생한 일이었다. URL은 정확한데, 브라우저는 /auth/login으로 계속 튕기고, 로그를 봐도 인증 자체는 성공한 듯 보이는데 진입하지 못했다.

상황 설명

Gateway Controller: Istio
인증서: cert-manager + Let's Encrypt
외부 도메인: *.minseoky.me (dns01 wildcard 사용)
서비스: argocd-server 를 ClusterIP로 운영
UI 접속을 위해 HTTPRoute로 외부에 노출

Gateway 및 HttpRoute 설정은 다음과 같이 구성했다:

minseoky-gateway.yaml

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: minseoky-gateway
  namespace: istio-system
spec:
  gatewayClassName: istio
  listeners:
    - name: https
      protocol: HTTPS
      port: 443
      tls:
        mode: Terminate
        certificateRefs:
          - kind: Secret
            group: ''
            name: wildcard-minseoky-me
            namespace: cert-manager
      allowedRoutes:
        namespaces:
          from: All
    - name: http
      protocol: HTTP
      port: 80
      allowedRoutes:
        namespaces:
          from: All

argocd-route.yaml

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: argocd-route
  namespace: istio-system
spec:
  parentRefs:
    - group: gateway.networking.k8s.io
      kind: Gateway
      name: minseoky-gateway
      namespace: istio-system
  hostnames:
    - argocd.minseoky.me
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - group: ""
          kind: Service
          name: argocd-server
          namespace: argocd
          port: 80
          weight: 1

정확한 문제 상황 설명 이전에, 내 환경 이야기를 먼저 서술해야 할 것 같다. 비용문제로, 나는 클라우드 대신 온프레미스 홈 서버를 사용중이다.

ips

각 IP는 다음과 같다: 우리집 공유기 공인 IP: A.A.A.A
masternode01: 172.30.1.101
masternode02: 172.30.1.102
masternode03: 172.30.1.103
workernode01: 172.30.1.111
workernode02: 172.30.1.112
workernode03: 172.30.1.113
gateway api: 172.30.1.230

그리고 A.A.A.A의 80, 443 번 포트로 들어온 트래픽을 172.30.1.230으로 포트포워딩 해주고 있었다. cert-manager 에 의해 인증서가 발급되고, TLS Termination은 minseoky-gateway에서 발생하고 있었다. 그 이후에 트래픽이 argocd-server에 전달되도록 구성했다.

문제 상황은 이렇다. argocd.minseoky.me 접근시, http://argocd.minseoky.me -> https://argocd.minseoky.me -> https://argocd.minseoky.me -> https://argocd.minseoky.me -> https://argocd.minseoky.me -> ...(무한 반복)

결국 Too many redirection 오류로, 접근이 되질 않았다.

ArgoCD는 왜 기본적으로 HTTPS로 리다이렉션할까?

ArgoCD는 설치 직후 기본적으로 HTTPS를 사용하도록 설정되어 있다. 이는 사용자의 인증 정보, 세션 토큰 등이 네트워크 상에서 노출되지 않도록 하기 위한 보안상의 기본 설정이다. ArgoCD의 argocd-server는 다음과 같은 방식으로 HTTPS를 지원한다:

설치 시 자동으로 self-signed 인증서가 생성되어, HTTPS를 리스닝하도록 구성됨
클라이언트가 HTTP로 접속하면, 이를 HTTPS로 강제 리다이렉션
브라우저에서는 인증서가 신뢰되지 않는 경우 경고를 표시하지만, 기능상 HTTPS를 유지함

이 설정은 로컬 환경 또는 테스트 환경에서는 편의성을 제공하지만, 실제 운영 환경에서는 self-signed 인증서 대신 신뢰할 수 있는 **CA 기반 인증서(Let's Encrypt 등)**로 교체하거나, TLS를 Gateway에서 종료시키는 방식으로 리디렉션 문제를 해결해야 한다.

만약 --insecure 옵션을 제거한 채 사용하고자 한다면, 다음을 반드시 고려해야 한다:

ArgoCD가 HTTPS로 정상 동작하려면 argocd-server에 적절한 TLS 인증서(예: wildcard 인증서)를 수동으로 주입해야 한다 (argocd-secret 이름의 Secret 리소스로 관리됨)
또는 Gateway에서 TLS를 Passthrough 모드로 구성하고, argocd-server가 HTTPS를 직접 처리하도록 해야 한다

이처럼 기본 HTTPS 리다이렉션은 보안을 위한 기본 동작이지만, Istio Gateway 같은 중간 계층에서 TLS를 처리하는 환경에서는 오히려 이 동작이 충돌을 일으킬 수 있다.

insecure 옵션은 어떻게 문제를 해결했을까?

처음 발생한 문제는 클라이언트가 HTTPS로 접속하고, Istio Gateway에서 TLS를 Terminate한 후 HTTP로 전달되었지만, argocd-server는 여전히 HTTPS로 리다이렉션을 시도하면서 발생한 무한 리다이렉션 루프였다.

이때 --insecure 옵션이 해결책이 되었다. 이 옵션은 다음과 같은 방식으로 작동한다:

argocd-server가 HTTPS를 리스닝하지 않고, HTTP로만 리스닝하게 만든다.
ArgoCD는 더 이상 클라이언트 요청을 HTTPS로 리다이렉션하지 않는다.
Gateway에서 TLS Termination이 일어나고, 이후 평문 HTTP 요청이 argocd-server의 8080 포트로 전달되어 정상 처리된다.
이 구성에서는 클라이언트는 여전히 HTTPS로 접속하고 있지만, 내부에서는 안전하게 HTTP로 전달되어 아무런 리다이렉션 충돌 없이 동작하게 된다.

helm으로 배포한 argocd 에 대한 values.yaml 예시를 아래에 첨부한다.

server:
  service:
    type: ClusterIP

  extraArgs:
    - --insecure # ✅ insecure 옵션 추가

configs:
  cm:
    kustomize.buildOptions: "--enable-helm"

정리하면:

클라이언트는 HTTPS로 접속
Istio Gateway는 TLS를 종료하고 평문 HTTP로 트래픽 전달
argocd-server는 --insecure 옵션으로 HTTP만 리스닝하고 HTTPS 리다이렉션을 수행하지 않음
따라서 /auth/login 루프 없이 UI가 정상적으로 렌더링됨

💡 TLS Termination이란?

TLS Termination은 클라이언트와 서버 간 통신에서 TLS(HTTPS) 세션을 **중간 프록시(예: Istio Gateway)**가 종료시키고, 이후 트래픽을 HTTP로 내부 서비스에 전달하는 구조를 의미한다. 보통 다음과 같은 목적에서 사용된다:

클러스터 내부 통신 단순화 (모든 서비스가 TLS를 직접 처리하지 않아도 됨)

통합 인증서 관리

로드밸런서와 연동된 외부 접근 제어

TLS Termination이 발생하면, 서비스 단에서는 반드시 X-Forwarded-Proto, X-Forwarded-For, X-Forwarded-Host 등의 헤더를 참고하여 "실제 클라이언트가 HTTPS로 접근했는지" 판단해야 한다. ZeroTrust 를 지향하는 경우,,, 클러스터의 내부 트래픽도 모두 암호화해야하기 때문에 Termination이 아닌 PassThrough 옵션을 사용해야 할 것이다.

결론

이 문제를 해결하기 위해서는 다음과 같은 구성이 필요했다:

Gateway에서 TLS Termination을 유지한 상태에서
argocd-server에는 --insecure 옵션을 추가하여 HTTP로만 요청을 처리하게 만들고
클라이언트는 HTTPS를 사용하되, 내부 트래픽은 HTTP로 안전하게 전달되도록 구성