[Ncloud] NCP NKS와 NPLB(Envoy Ingress Gateway)에서 X-Forwarded-For 설정하여 Client Real IP 알아내는 방법

안녕하세요.

 

이번 시간에는 네이버 클라우드 플랫폼의 쿠버네티스 서비스인 NKS에서 Envoy Ingress Gateway에서 XFF를 설정하여 Client의 Real IP를 알아내는 방법을 작성하도록 하겠습니다.

 

1. 문제 상황

NKS 환경에서 애플리케이션을 운영하면서 외부 클라이언트가 서비스에 접속할 때 애플리케이션 로그에 찍히는 IP가 전부 NPLB의 프록시 IP로만 보이는 문제가 있을 텐데요.

- 기대했던 값: 클라이언트 실제 IP (예: 123.123.xxx.xxx)

- 실제 확인된 값: NPLB 노드 IP 혹은 Ingress Gateway Pod IP

즉, 실제 사용자 IP를 확인할 수 없는 상황이 발생하게 되는데요. 이럴 경우 보안 로그, 접근 제어, 분석 등의 관점에서 클라이언트의 Real IP는 꼭 필요한 정보이기 때문에 이 문제를 해결하는 것은 필수적입니다.

 

2. 원인 분석

Ncloud에서 네트워크 프록시 로드밸런서(NPLB)와 NKS Ingress Gateway(Envoy 기반)은 L7 프록시 역할을 수행할 수 있습니다.

클라이언트 → NPLB → Envoy Ingress Gateway (Filter) → Service Pod

 

이 구조에서 클라이언트 IP는 기본적으로 로드밸런서/프록시 IP로 덮어씌워지기 때문에 애플리케이션 Pod에서 직접 확인하면 클라이언트의 Real IP를 알 수 없습니다.

 

따라서, 로드밸런서가 전달하는 X-Forwarded-For 헤더를 신뢰하도록 Envoy Ingress Gateway를 설정해주어야 합니다.

 

3. 해결 방법

 1. NPLB에서 Proxy Protocol 확인 및 활성화

원래 기본적으로 네트워크 로드밸런서에서는 L4의 기능을 수행하기 때문에 클라이언트 요청이 들어올 때 X-Forwarded-For가 아닌 Proxy Protocol v2로 헤더 값이 확장되어 들어오게 되는데요. Ncloud의 NPLB는 L7 프록시 역할을 수행할 뿐만 아니라 클라이언트 요청이 들어올 때 자동으로 X-Forwarded-For 헤더에 클라이언트 IP를 추가해 주게 됩니다.

 

apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/ncloud-load-balancer-size: 'SMALL'
    service.beta.kubernetes.io/ncloud-load-balancer-idle-timeout: "180"
    service.beta.kubernetes.io/ncloud-load-balancer-proxy-protocol: "true"
    proxy.istio.io/config: '{"gatewayTopology" : { "numTrustedProxies": 2 }}'

네이버 클라우드에서 제공하는 NKS Annotation이 별도로 있기 때문에 NPLB를 생성하실 때 해당 어노테이션으로 생성해주어야 합니다. 로드밸런서의 타입을 지정하지 않으면 기본적으로 NPLB로 생성되며, ncloud-load-balancer-proxy-protocol을 true로 활성화해주어야 합니다.

 

2. Envoy 기반의 Ingress Gateway를 사용할 때 listener_filter 활성화

기존에 애플리케이션에서 istio를 사용하고 있다면 프록시로 Envoy를 사용하는 경우가 많습니다. Envoy는 각 서비스 파드에 사이드카 패턴으로 배포되어 모든 네트워크 트래픽을 가로채고 처리하는데요.

 

트래픽 관리를 담당하여 로드 밸런싱, 라우팅, 회로 차단기(Circuit Breaker), 타임아웃, 재시도 등의 기능을 수행합니다. 이를 통해 서비스 간 통신의 안정성과 성능을 보장하는 핵심 컴포넌트입니다.

 

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: proxy-protocol
  namespace: istio-system
spec:
  workloadSelector:
    labels:
      istio: ingressgateway
  configPatches:
  - applyTo: LISTENER
    patch:
      operation: MERGE
      value:
        listener_filters:
        - name: envoy.filters.listener.proxy_protocol
          typed_config:
            "@type": type.googleapis.com/envoy.extensions.filters.listener.proxy_protocol.v3.ProxyProtocol
        - name: envoy.filters.listener.tls_inspector
          typed_config:
            "@type": type.googleapis.com/envoy.extensions.filters.listener.tls_inspector.v3.TlsInspector

Envoy Filter가 트래픽 패턴에 맞는 값을 리스너 필터를 통해 분류하게 되는데 매칭되는 트래픽이 있을 경우 해당 값으로 트래픽이 라우팅 됩니다. 만약 트래픽 패턴에 맞는 값이 없을 경우 no matching envoy filter not found라는 오류를 출력하면서 서비스로 통신되지 않으니 서비스 다운이 일어날 수 있습니다. 적용하실 때는 개발 환경에서 테스트를 하신 후에 운영 환경에 적용해야 합니다.

 

3. Ingress Gateway 로그 확인

위와 같이 배포 완료하였다면 Envoy Ingress Gateway 로그를 확인해야 합니다.

kubectl get pods -n istio-system
kubectl logs <ingress-gateway pod name> -n istio-system

로그를 확인하시면 기존에 NPLB의 사설 IP가 아닌 클라이언트의 Real IP가 확인되는 것을 볼 수 있습니다.

 

Ncloud이기 때문에 다음 문서와 케이스가 일부 다르지만 아래 Document를 참고해 볼 수 있습니다. 다만 Envoy Filter 등 실제 적용했을 때 적용이 안 되는 부분이 있어 해당 자료가 정확하진 않습니다.

https://istio.io/latest/blog/2020/show-source-ip/

Proxy protocol on AWS NLB and Istio ingress gateway

 

Ncloud NKS 환경에서 NPLB + Envoy Ingress Gateway를 사용할 때, 애플리케이션에서 클라이언트의 Real IP가 보이지 않은 것은 흔한 문제입니다.

 

이를 해결하려면
1. NPLB에서 전달하는 XFF 헤더를 활용하고 proxy protocol을 활성화

2.Envoy Ingress Gateway와 Envoy filter에서 NPLB에서 전달하는 XFF 신뢰하는 설정과 필터 리스너 값을 추가

 

이렇게 구성하면 로그와 서비스 레벨에서 실제 클라이언트 IP를 정확하게 확인할 수 있습니다.

이는 보안 감사, 접근 제어, 사용자 행태 분석 등 서비스 운영에 있어 필수적인 요소이므로 반드시 고려되어야 합니다.

 

이번 시간에는 NCP NKS와 NPLB(Envoy Ingress Gateway)에서 X-Forwarded-For 설정하여 Client Real IP 알아내는 방법을 알아봤습니다.

 

감사합니다.