NGINX Ingress Controller를 활용한 향상된 TCP/UDP 로드 밸런싱 및 WAF 구성

Amir Rawdat솔루션 엔지니어

표준 Kubernetes Ingress 리소스는 기본적인 Ingress 부하 분산을 프로비저닝하고 구성하는 데 매우 유용하지만, Kubernetes를 프로덕션 환경에 적합하게 만드는 데 필요한 사용자 지정 기능은 제공하지 않습니다. 따라서 NGINX를 사용하지 않는 사용자는 오류가 발생하기 쉽고 사용하기 어려우며 안전하지 않을 뿐만 아니라 세분화된 범위 지정 기능도 부족한 어노테이션, ConfigMap 및 사용자 지정 템플릿을 사용해야 합니다. NGINX Ingress 리소스는 이러한 문제를 해결하기 위한 솔루션입니다.

NGINX Ingress 리소스는 NGINX Ingress Controller의 NGINX Open Source 버전과 NGINX Plus 기반 버전 모두에서 사용할 수 있습니다. 이 리소스는 네이티브 방식의 형식 안전성과 들여쓰기를 지원하는 구성 스타일을 제공하여 Ingress 부하 분산을 더 간편하게 구현할 수 있도록 합니다. 이 블로그에서는 WAF 및 부하 분산 정책을 더 쉽게 구성할 수 있도록 NGINX Ingress Controller 1.11.0에 도입된 두 가지 기능을 중점적으로 살펴봅니다:

• TransportServer 리소스 – TransportServer 리소스는 TCP, UDP 및 TLS 패스스루 부하 분산을 위한 구성을 정의합니다. TCP/UDP 부하 분산을 개선하기 위해 상태 확인, 상태 보고 및 구성 스니펫을 추가했습니다.
• NGINX Ingress WAF 정책 – NGINX Ingress Controller와 함께 NGINX App Protect 3.0을 배포하면 NGINX Ingress 리소스를 활용하여 특정 Kubernetes 서비스에 WAF 정책을 적용할 수 있습니다.

TransportServer 리소스 개선 사항

NGINX Ingress Controller 1.11.0에서는 다음 영역에서 TransportServer(TS) 리소스가 확장되었습니다:

• 스니펫
• 상태 확인
• 여러 TS 리소스 지원

참고: 릴리스 1.11.0에서 TransportServer 리소스에 추가된 기능은 현재 활발히 개발 중인 기술 프리뷰입니다. 향후 릴리스에서 안정적인 프로덕션 지원 품질 기준을 충족하는 정식 기능으로 전환될 예정입니다.

TransportServer 스니펫

In NGINX Ingress Controller에서는 HTTP 기반 클라이언트를 위한 NGINX Ingress 구성을 기본 방식으로 확장할 수 있도록 VirtualServer 및 VirtualServerRoute(VS 및 VSR) 리소스용 구성 스니펫을 도입했습니다. 릴리스 1.11.0에서는 TS 리소스용 스니펫이 도입되어 NGINX 및 NGINX Plus의 모든 기능을 손쉽게 활용해 TCP/UDP 기반 서비스를 제공할 수 있습니다. 예를 들어 스니펫을 사용하여 IP 주소와 범위를 기준으로 서비스에 액세스할 수 있는 클라이언트를 지정하는 deny 및 allow 지시문을 추가할 수 있습니다.

apiVersion: k8s.nginx.org/v1alpha1kind: TransportServer
metadata:
  name: cafe
spec:
  host: cafe.example.com
  serverSnippets: |
    deny  192.168.1.1;
    allow 192.168.1.0/24;
  upstreams:
  - name: tea
    service: tea-svc
    port: 80

상태 확인

Kubernetes 클러스터의 상태를 모니터링하기 위해 NGINX Ingress Controller는 애플리케이션 Pod에서 로컬로 수행되는 Kubernetes 프로브뿐만 아니라 TCP/UDP 기반 업스트림 서비스 간의 네트워크 상태도 지속적으로 확인합니다. 진행 중인 트랜잭션의 상태를 평가하는 수동 상태 확인과 합성 연결 요청을 통해 엔드포인트를 주기적으로 검사하는 능동 상태 확인(NGINX Plus 전용)을 사용합니다.

상태 확인은 회로 차단 및 애플리케이션 오류 처리에 매우 유용할 수 있습니다. 상태 확인은 TS 리소스의 parameters in the healthCheck 필드에 있는 매개변수를 사용하여 사용자 지정할 수 있습니다. 이러한 매개변수로 프로브 간 간격, 프로브 제한 시간, 프로브 간 지연 시간 등을 설정할 수 있습니다.

또한 NGINX Ingress Controller에서 보내는 상태 프로브의 업스트림 서비스 및 대상 포트를 설정할 수 있습니다. 이는 애플리케이션의 여러 다운스트림 구성 요소를 모니터링하는 다른 프로세스나 하위 시스템이 별도의 리스너를 통해 업스트림 애플리케이션의 상태를 노출하는 경우에 유용합니다.

여러 TransportServer 리소스 지원: ingressClassName

TS 리소스를 업데이트하고 적용할 때는 구성이 유효하며 해당 Ingress Controller 배포에 성공적으로 적용되었는지 확인하는 것이 좋습니다. 릴리스 1.11.0에서는 ingressClassName 필드와 TS 리소스의 상태 보고 기능이 도입되었습니다. ingressClassName 필드는 여러 배포가 있는 환경에서 특정 Ingress Controller 배포가 TS 리소스를 처리하도록 합니다.

하나 또는 모든 TS 리소스의 상태를 표시하려면 kubectl get transportserver 명령을 실행합니다. 출력에는 상태(Valid 또는 Invalid), 가장 최근 업데이트의 사유, 그리고 단일 TS의 경우 사용자 지정 메시지가 포함됩니다.

$ kubectl get transportserver  NAME      STATE   REASON           AGE
  dns-tcp   Valid   AddedOrUpdated   47m

$ kubectl describe transportserver dns-tcp
. . .
Status:
  Message:  Configuration for default/dns-tcp was added or updated
  Reason:   AddedOrUpdated
  State:    Valid

여러 TS 리소스가 동일한 호스트/리스너를 두고 경합하는 경우, NGINX Ingress Controller는 타임스탬프가 가장 오래된 TS 리소스를 선택하여 해당 상황에서 결과가 일관되게 결정되도록 합니다.

네이티브 NGINX App Protect 지원을 사용하여 WAF 정책 정의

NGINX Ingress 리소스는 구성을 더 쉽고 유연하게 만들 뿐만 아니라, VirtualServerRoute(VSR) 리소스에 정의된 애플리케이션 하위 경로를 소유한 사용자에게 더 엄격한 권한 제한을 적용하고 트래픽 제어를 여러 팀에 위임할 수 있도록 해줍니다. 적절한 팀에 적절한 Kubernetes 리소스에 대한 액세스 권한을 부여함으로써 NGINX Ingress 리소스는 네트워킹 리소스를 세밀하게 제어하고, 사용자 계정이 침해되거나 해킹당했을 때 애플리케이션에 발생할 수 있는 피해를 줄여줍니다.

릴리스 1.11.0에서는 Kubernetes 배포 환경의 NGINX App Protect 구성에도 이러한 이점을 확대 적용할 수 있도록 네이티브 웹 애플리케이션 방화벽(WAF) Policy 객체를 도입했습니다. 이 정책은 APLogConf 및 APPolicy 객체를 활용합니다. 이 객체들은 릴리스 1.8.0에서 도입되었으며 VirtualServer(VS) 및 VSR 리소스 모두에 연결할 수 있습니다. 즉, 보안 관리자는 VS 리소스를 통해 Ingress 구성의 전체 범위를 관리하면서, VSR 리소스를 참조하여 다른 팀에 보안 책임을 위임할 수 있습니다.

다음 예에서는 waf-prod 정책이 webapp-prod 업스트림으로 라우팅되는 사용자에게 적용됩니다. 서로 다른 팀이 소유한 네임스페이스 간에 /v2 경로의 보안 책임을 위임하기 위해 강조 표시된 route 지시문은 VSR 리소스를 참조합니다.

apiVersion: k8s.nginx.org/v1kind: VirtualServer
metadata:
  name: webapp
spec:
  host: webapp.example.com
  policies:
  - name: waf-prod 
  tls:
    secret: app-secret
  upstreams:
  - name: webapp-prod
    service: webapp-svc
    port: 80
  routes:
  - path: /v2
    route: test/test
  - path: /v1
    action:
      pass: webapp-prod

The teams that manage the test 네임스페이스를 관리하는 팀은 해당 네임스페이스의 VSR 리소스를 사용하여 자체 매개변수와 WAF 정책을 설정할 수 있습니다.

apiVersion: k8s.nginx.org/v1kind: VirtualServerRoute
metadata:
  name: test 
  namespace: test
spec:
  host: webapp.example.com
  upstreams:
  - name: webapp 
    service: webapp-test-svc
    port: 80
  subroutes:
  - path: /v2
    policies:
    - name: waf-test
    action:
      pass: webapp

이 예제에서는 네임스페이스별로 테넌트를 분리하고 webapp-test-svc 서비스에 대해 test 네임스페이스에서 다른 WAF 정책을 적용합니다. 리소스를 여러 팀에 위임하고 객체로 캡슐화하면 프로덕션 환경의 애플리케이션에 영향을 주지 않고 새로운 기능을 더 쉽게 테스트할 수 있음을 보여 줍니다.

릴리스 1.11.0의 또 다른 새로운 기능은 무엇인가요?

NGINX Ingress Controller 1.11.0에서도 유연하고 강력하며 사용하기 쉬운 프로덕션급 Ingress 컨트롤러를 제공하겠다는 약속을 이어갑니다. WAF 및 TS 개선 사항 외에도 릴리스 1.11.0에는 다음과 같은 향상된 기능이 포함되어 있습니다:

• 더 많은 어노테이션 검증 – 구성 오류를 더 많이 방지
• 정책 상태 정보 – Policy 객체가 Ingress 구성에 적용되기 전에 해당 객체의 상태를 표시합니다
• Istio 호환성 – Istio 환경에서 NGINX Ingress Controller의 고급 기능 활용
• 업스트림 엔드포인트용 클러스터 IP 주소 – NGINX Ingress Controller 구성의 업스트림 엔드포인트를 서비스/클러스터 IP 주소로 채웁니다

더 많은 어노테이션 검증

릴리스 1.10.0에서 도입된 주석 유효성 검사 개선 사항을 바탕으로 이제 다음과 같은 추가 주석의 유효성을 검사합니다:

주석 유효성 검사nginx.org/client-max-body-size 유효한 오프셋이어야 합니다nginx.org/fail-timeout 유효한 시간이어야 합니다nginx.org/max-conns 유효한 음이 아닌 정수여야 합니다nginx.org/max-fails 유효한 음이 아닌 정수여야 합니다nginx.org/proxy-buffer-size 유효한 크기여야 합니다nginx.org/proxy-buffers 유효한 프록시 버퍼 사양이어야 합니다nginx.org/proxy-connect-timeout 유효한 시간이어야 합니다nginx.org/proxy-max-temp-file-size 유효한 크기여야 합니다nginx.org/proxy-read-timeout 유효한 시간이어야 합니다nginx.org/proxy-send-timeout 유효한 시간이어야 합니다nginx.org/upstream-zone-size 유효한 크기여야 합니다

Ingress 리소스가 적용될 때 어노테이션 값이 유효하지 않으면 Ingress Controller는 해당 리소스를 거부하고 NGINX에서 관련 구성을 제거합니다.

정책 상태 정보

이제 kubectl get policy 명령은 정책의 상태(Valid 또는 Invalid)를 보고하며, 단일 TS의 경우 사용자 지정 메시지와 가장 최근 업데이트의 사유도 함께 보고합니다.

$ kubectl get policy  NAME              STATE   AGE
  webapp-policy     Valid   30s

$ kubectl describe policy webapp-policy
. . .
Status:
  Message:  Configuration for default/webapp-policy was added or updated
  Reason:   AddedOrUpdated
  State:    Valid

Istio와의 호환성

이제 Istio 서비스 메시 내에서 실행되는 애플리케이션의 Ingress 컨트롤러로 NGINX Ingress Controller를 사용할 수 있습니다. 따라서 사용자는 별도의 우회 방법 없이도 Istio 기반 환경에서 NGINX Ingress Controller가 제공하는 고급 기능을 계속 활용할 수 있습니다. 이 통합에는 다음 두 가지 요구 사항이 있습니다:

• NGINX Ingress Controller 배포에 Istio 사이드카 삽입
• 백엔드에는 HTTP Host 헤더가 하나만 전송됩니다

첫 번째 요구 사항을 충족하려면 NGINX Ingress Deployment 파일의 annotations 필드에 다음 항목을 포함하세요.

annotations:   traffic.sidecar.istio.io/includeInboundPorts: "" 
  traffic.sidecar.istio.io/excludeInboundPorts: "80,443"         
  traffic.sidecar.istio.io/excludeOutboundIPRanges: "10.90.0.0/16,10.45.0.0/16"     sidecar.istio.io/inject: 'true'

두 번째 요구 사항은 requestHeaders 필드의 동작을 변경하여 충족됩니다. 이전 릴리스에서는 다음 구성을 사용할 경우 두 개의 Host 헤더가 백엔드로 전송되었습니다. 즉, $host와 지정된 값인 bar.example.com입니다.

apiVersion: k8s.nginx.org/v1kind: VirtualServer
metadata:
  name: foo 
spec:
  host: foo.example.com
  upstreams:
  - name: foo
    port: 8080
    service: backend-svc
    use-cluster-ip: true
  routes:
  - path: "/"
    action:
      proxy:
        upstream: foo
        requestHeaders: set: - name: Host value: bar.example.com

릴리스 1.11.0 이상에서는 지정된 값만 전송됩니다. $host를 전송하려면 requestHeaders 필드를 완전히 생략하세요.

업스트림 엔드포인트의 클러스터 IP 주소

이제 NGINX Ingress Controller 구성의 업스트림 엔드포인트에 개별 Pod 엔드포인트의 IP 주소 대신 서비스/클러스터 IP 주소를 지정할 수 있습니다. NGINX Ingress Controller가 클러스터 IP 서비스로 트래픽을 라우팅하도록 하려면 VS 또는 VSR 구성의 use-cluster-ip: true 필드를 upstreams 섹션에 포함하세요:

upstreams:  - name: tea
    service: tea-svc
    port: 80
    use-cluster-ip: true
  - name: coffee
    service: coffee-svc
    port: 80
    use-cluster-ip: true

리소스

릴리스 1.11.0의 전체 변경 내역은 릴리스 노트를 참조하세요.

NGINX Plus 및 NGINX App Protect와 함께 Kubernetes용 NGINX Ingress Controller를 사용해 보려면 지금 30일 무료 평가판을 시작하거나 사용 사례에 대해 논의하려면 문의해 주세요.

NGINX Open Source와 함께 NGINX Ingress Controller를 사용해 보려면 릴리스 소스 코드를 받거나 DockerHub에서 사전 빌드된 컨테이너를 다운로드할 수 있습니다.

Ingress 컨트롤러 간의 차이점에 관한 자세한 내용은 저희 블로그의 잠깐, 내가 사용 중인 Kubernetes용 NGINX Ingress Controller는 무엇일까?를 참조하세요.

작성자 소개

Amir Rawdat솔루션 엔지니어

Amir Rawdat의 다른 블로그 게시물