NGINX Ingress Controller를 사용한 향상된 TCP/UDP 부하 분산 및 WAF 구성

표준 Kubernetes Ingress 리소스는 기본 Ingress 부하 분산을 프로비저닝하고 구성하는 데 매우 유용하지만 Kubernetes를 프로덕션 수준으로 만드는 데 필요한 종류의 사용자 지정 기능이 포함되어 있지 않습니다. 대신 NGINX가 아닌 사용자는 오류가 발생하기 쉽고, 사용하기 어렵고, 안전하지 않으며, 세분화된 범위 지정이 부족한 주석, ConfigMaps 및 사용자 정의 템플릿을 사용해야 합니다. NGINX Ingress 리소스는 이 문제에 대한 우리의 답입니다.

NGINX Ingress 리소스는 NGINX 오픈 소스 버전과 NGINX Plus 기반 버전의 NGINX Ingress Controller에서 모두 사용할 수 있습니다. Ingress 부하 분산 구현을 간소화하는 기본적이고 유형이 안전하며 들여쓰기가 적용된 구성 스타일을 제공합니다. 이 블로그에서는 WAF 및 부하 분산 정책을 보다 쉽게 구성할 수 있게 해주는 NGINX Ingress Controller 1.11.0에 도입된 두 가지 기능에 초점을 맞춥니다.

• TransportServer 리소스 – TransportServer 리소스는 TCP, UDP 및 TLS Passthrough 부하 분산에 대한 구성을 정의합니다. 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 스니펫

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

api 버전: k8s.nginx.org/v1alpha1kind: TransportServer
메타데이터:
이름: cafe
스펙:
호스트: cafe.example.com
serverSnippets: |
deny 192.168.1.1;
allow 192.168.1.0/24;
업스트림:
- 이름: tea
서비스: tea-svc
포트: 80

건강 검진

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

상태 점검은 회로 차단 이나 애플리케이션 오류 처리에 매우 유용할 수 있습니다. TS 리소스의 healthCheck 필드에 있는 매개변수를 사용하여 프로브 간 간격, 프로브 시간 초과, 프로브 간 지연 시간 등을 설정하여 상태 검사를 사용자 정의할 수 있습니다.

또한 NGINX Ingress Controller에서 상태 프로브의 업스트림 서비스와 포트 대상을 설정할 수 있습니다. 이 기능은 여러 다운스트림 구성 요소를 모니터링하는 다른 프로세스나 하위 시스템에 의해 업스트림 애플리케이션의 상태가 다른 리스너에 노출되는 상황에서 유용합니다.

ingressClassName을 사용하여 여러 TransportServer 리소스 지원

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

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

$ kubectl get transportserver 이름 상태 이유 나이 dns-tcp 유효 AddedOrUpdated 47m $ kubectl describe transportserver dns-tcp . . .
상태:
  메시지:  default/dns-tcp에 대한 구성이 추가되거나 업데이트되었습니다. 이유:   AddedOrUpdated 상태:    유효한

여러 TS 리소스가 동일한 호스트/리스너를 놓고 경합하는 경우 NGINX Ingress Controller는 가장 오래된 타임스탬프를 가진 TS 리소스를 선택하여 해당 상황에서 결정적인 결과를 보장합니다.

네이티브 NGINX App Protect 지원을 통한 WAF 정책 정의

NGINX Ingress 리소스는 구성을 더 쉽고 유연하게 만들 뿐만 아니라, 트래픽 제어를 다른 팀에 위임하고 VirtualServerRoute(VSR) 리소스에 정의된 대로 애플리케이션 하위 경로를 소유한 사용자에게 더 엄격한 권한 제한을 부과할 수 있게 해줍니다. NGINX Ingress 리소스는 적절한 팀에 적절한 Kubernetes 리소스에 대한 액세스 권한을 제공함으로써 네트워크 리소스를 세부적으로 제어하고 사용자가 손상되거나 해킹당할 경우 애플리케이션의 잠재적 손상을 줄일 수 있습니다.

릴리스 1.11.0에서는 Kubernetes 배포에서 NGINX App Protect를 구성할 때 이러한 이점을 확장하기 위해 기본 웹 애플리케이션 방화벽(WAF) 정책 개체가 도입되었습니다. 이 정책은 릴리스 1.8.0에 도입된 APLogConf 및 APPolicy 객체를 활용하며 VirtualServer(VS) 및 VSR 리소스에 모두 연결할 수 있습니다. 즉, 보안 관리자는 VSR 리소스를 참조하여 다른 팀에 보안 책임을 위임하는 동시에 VS 리소스를 사용하여 Ingress 구성의 전체 범위에 대한 소유권을 가질 수 있습니다.

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

api 버전: k8s.nginx.org/v1kind: VirtualServer 메타데이터: 이름: webapp 사양: 호스트: webapp.example.com 정책: - 이름: waf-prod tls: 비밀: app-secret 업스트림: - 이름: webapp-prod 서비스: webapp-svc 포트: 80개 경로: - 경로: /v2 경로: test/test - 경로: /v1 작업: 통과: webapp-prod

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

api 버전: k8s.nginx.org/v1kind: VirtualServerRoute
메타데이터:
이름: 테스트
네임스페이스: 테스트
스펙:
호스트: webapp.example.com
업스트림:
- 이름: 웹앱
서비스: webapp-test-svc
포트: 80
하위 경로:
- 경로: /v2
정책:
- 이름: waf-test
작업:
패스: webapp

이 예제에서는 네임스페이스별로 테넌트를 구분하고 테스트 네임스페이스의 webapp-test-svc 서비스에 대해 다른 WAF 정책을 적용합니다. 이는 리소스를 여러 팀에 위임하고 이를 객체로 캡슐화하는 것이 프로덕션에서 애플리케이션을 중단시키지 않고도 새로운 기능을 테스트하는 과정을 간소화하는 방법을 보여줍니다.

릴리스 1.11.0의 다른 새로운 기능은 무엇입니까?

NGINX Ingress Controller 1.11.0을 통해 우리는 유연하고 강력하며 사용하기 쉬운 프로덕션 등급 Ingress 컨트롤러를 제공하려는 노력을 계속합니다. WAF 및 TS 개선 사항 외에도 릴리스 1.11.0에는 다음과 같은 개선 사항이 포함되어 있습니다.

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

추가 주석의 검증

릴리스 1.10.0에 도입된 주석 검증 개선 사항을 바탕으로 이제 다음과 같은 추가 주석을 검증하고 있습니다.

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

정책에 대한 상태 정보

kubectl get policy 명령은 이제 정책 상태( 유효 또는 무효 )와 (단일 TS의 경우) 사용자 지정 메시지와 최근 업데이트 이유를 보고합니다.

$ kubectl 정책 이름 주 나이 웹앱 정책 유효 기간 30초를 가져옵니다 . $ kubectl 정책 웹앱 정책 . . .
상태:
  메시지:  default/webapp-policy에 대한 구성이 추가되거나 업데이트되었습니다. 이유:   AddedOrUpdated 상태:    유효한

Istio와의 호환성

NGINX Ingress Controller를 이제 Istio 서비스 메시 내부에서 실행되는 앱의 Ingress 컨트롤러로 사용할 수 있습니다. 이를 통해 사용자는 다른 해결책을 사용하지 않고도 Istio 기반 환경에서 NGINX Ingress Controller가 제공하는 고급 기능을 계속 사용할 수 있습니다. 이 통합에는 두 가지 요구 사항이 포함됩니다.

• NGINX Ingress Controller 배포에 Istio 사이드카 주입
• 백엔드로는 단 하나의 HTTP 호스트 헤더만 전송됩니다.

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

주석: 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: '참'

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

api 버전: k8s.nginx.org/v1kind: VirtualServer 메타데이터: 이름: foo 사양: 호스트: foo.example.com 업스트림: - 이름: foo 포트: 8080 서비스: 백엔드 서비스 클러스터 IP 사용: true 경로: - 경로: "/" 작업: 프록시: 업스트림: foo 요청 헤더: 설정: - 이름: 호스트 값: bar.example.com

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

업스트림 엔드포인트에 대한 클러스터 IP 주소

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

상류: - 이름: 티 서비스: tea-svc 포트: 80 use-cluster-ip: true - 이름: 커피 서비스: coffee-svc 포트: 80 클러스터 IP 사용: 참

리소스

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

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

NGINX 오픈 소스로 NGINX Ingress Controller를 사용해 보려면 릴리스 소스 코드를 얻거나 DockerHub 에서 미리 빌드된 컨테이너를 다운로드하세요.

Ingress 컨트롤러 간 차이점에 대한 논의는 블로그의 '잠깐만요, Kubernetes용 NGINX Ingress 컨트롤러는 뭐예요?'를 참조하세요.