NGINX Plus R23 발표

NGINX Plus 릴리스 23(R23)이 출시되어 기쁩니다. NGINX Plus는 NGINX 오픈 소스를 기반으로 하는 유일한 소프트웨어 로드 밸런서, 역방향 프록시 및 API 게이트웨이입니다.

NGINX Plus R23 의 새로운 기능은 다음과 같습니다.

• gRPC 상태 점검 – 요청을 보내기 전에 gRPC 서비스가 요청을 처리할 수 있는지 적극적으로 테스트하면 안정성이 크게 향상됩니다.
• 권한이 없는 설치 지원 – 이제 권한이 없는( 루트가 아닌) 사용자로 NGINX Plus를 설치하고 업그레이드할 수 있습니다. 이 완벽하게 지원되는 솔루션은 제로 트러스트 보안 모델을 향한 확산되는 추세에 부합합니다.
• OpenID Connect PKCE 지원 – NGINX Plus R23은 OpenID Connect 인증 코드 흐름에 PKCE(Proof Key for Code Exchange) 확장을 구현합니다. PKCE는 여러 유형의 공격을 차단하고 공개 클라이언트와의 안전한 OAuth 교환을 가능하게 합니다.

이 릴리스의 핵심은 SSL/TLS에 대한 보다 세부적인 제어, 쿠키 플래그 설정을 위한 기본 방식, Stream 모듈에서의 변수 설정입니다. NGINX Plus 생태계에 대한 업데이트에는 NGINX JavaScript 모듈을 위한 새로운 버퍼 및 쿼리 문자열 모듈, Kerberos 동적 모듈을 위한 새로운 SPNEGO, Prometheus‑njs 동적 모듈에 대한 향상된 기능이 포함됩니다.

행동의 중요한 변화

• 더 이상 사용되지 않는 모듈 – 타사 Cookie‑Flag 모듈은 더 이상 사용되지 않으며 새로운 proxy_cookie_flags 지시어로 대체되었습니다. 해당 모듈은 NGINX Plus R26 에서 제거됩니다. 자세한 내용은 쿠키 플래그 설정을 위한 네이티브 메서드를 참조하세요.
• 지원되는 새로운 운영 체제 :
  • Alpine 3.12(x86_64, aarch64)
  • Debian 10(aarch64; x86_64는 NGINX Plus R17 부터 지원됨)
• 제거되었거나 제거될 예정인 이전 운영 체제:
  • Alpine 3.9는 더 이상 지원되지 않습니다. 가장 오래된 지원 버전은 3.10입니다.
  • CentOS/Oracle Linux/RHEL 6.5+는 더 이상 지원되지 않습니다. 지원되는 가장 오래된 버전은 7.4입니다.
  • Ubuntu 19.10은 더 이상 지원되지 않습니다.
  • NGINX Plus R24 에서는 Debian 9가 제거됩니다.

새로운 기능에 대한 자세한 정보

gRPC 상태 점검

NGINX Plus를 로드 밸런서로 배포하면 활성 상태 검사를 수행하여 백엔드(업스트림) 서버의 상태를 모니터링할 수 있습니다. NGINX Plus R23은 gRPC 상태 검사 프로토콜을 지원하여 백엔드 gRPC 서버가 새로운 요청을 처리할 수 있는지 정확하게 테스트할 수 있습니다. 이는 특히 동적이고 컨테이너화된 환경에서 가치가 있습니다. gRPC 서비스의 새로운 인스턴스를 시작할 때 서비스가 "완전히 가동"된 후에만 요청을 보내는 것이 중요합니다. 이를 위해서는 TCP 포트를 살펴보거나 HTTP URI의 가용성을 확인하는 것보다 더 심층적인 상태 검사가 필요합니다. 즉, 서비스 자체가 요청을 수신할 준비가 되었는지 여부를 나타내는 검사입니다.

gRPC 상태 검사 프로토콜을 구현하는 gRPC 서비스의 경우 구성이 간단합니다.

이 구성은 모든 요청을 grpc_backend 업스트림 그룹으로 로드 밸런싱합니다. health_check 지시어에는 각 업스트림 서버의 Health 서비스에 대한 Check 메서드를 호출하는 type=grpc 매개변수가 포함되어 있습니다. SERVING 으로 응답하는 서비스는 건강한 것으로 간주됩니다. 필수 매개변수는 NGINX Plus가 시작되거나 업스트림 그룹에 새로운 서버가 추가되면 트래픽이 상태 검사를 통과할 때까지 전달되지 않도록 합니다(그렇지 않으면 새로운 서비스는 기본적으로 정상으로 간주됩니다).

각 업스트림 서버에 노출된 gRPC 서비스가 여러 개 있는 경우 가장 중요한 서비스(종속 서비스나 하위 서비스가 있는 서비스)를 모니터링하려면 이 예와 같이 grpc_service 매개변수의 값으로 서비스 이름을 지정하면 됩니다.

gRPC 상태 검사 프로토콜을 구현하지 않는 gRPC 서비스의 경우 업스트림 서버가 최소한 gRPC 요청에 응답하는지 테스트할 수 있습니다. 왜냐하면 이 경우 Check 메서드에 대한 응답으로 오류 상태 코드를 보내기 때문입니다. grpc_health.conf 의 구성을 사용하면 gRPC 프로토콜을 구현하지 않는 서비스가 상태 코드로 응답할 것으로 예상합니다. 12(구현되지 않음) .

또한 백엔드 코드를 수정하지 않고도 gRPC 서비스가 들어오는 요청에 응답할 수 있는지 확인할 수도 있습니다. 이 접근 방식을 사용하면 모든 gRPC 서비스를 모니터링할 수 있습니다.

권한이 없는 사용자 설치

이전 릴리스에서는 NGINX Plus는 권한이 있는 사용자 root 로 실행되는 최소한의 프로세스로 작동했습니다. 예를 들어, NGINX Plus 관리자 가이드 의 설치 지침은 다음과 같은 프로세스를 생성합니다.

$ ps auxf | grep nginx root ...  9068 888 ?  Ss 21:44 0:00 nginx: 마스터 프로세스 nginx nginx ...  9712 3572 ?  S 21:44 0:00 \_ nginx: 워커 프로세스

표시된 대로 마스터 프로세스는 루트 권한으로 실행됩니다. 다른 모든 프로세스(작업자 및 캐시 관리)는 권한이 없는 사용자 계정인 nginx를 사용합니다.

민감한 데이터를 다루는 중요 시스템에서는 root 사용자를 사용하고 싶어하지 않을 수 있습니다. 이 경우 NGINX Plus R23은 권한이 없는 사용자로 설치 및 실행할 수 있습니다. 우리는 GitHub 저장소에서 다음 OS에서 사용할 수 있는 설치 스크립트 ngxunprivinst.sh를 제공합니다:

• 알파인 리눅스
• Amazon Linux, Amazon Linux 2
• CentOS, 레드햇 엔터프라이즈 리눅스
• 데비안, 우분투

메모: NGINX Plus 리스너가 1024 미만의 포트(예: 80 또는 443)에 구성된 경우 마스터 프로세스에 루트 권한이 있어야 합니다(하지만 권한이 없는 사용자 계정에서 NGINX Plus를 설치할 수는 있습니다).

설치 스크립트를 사용하려면 다음 명령을 실행하세요. (사용 가능한 ngxunprivinst.sh 명령을 모두 보려면 명령 이름 매개변수 없이 스크립트를 실행하거나 GitHub 리포지토리에서 스크립트 코드를 확인하세요.)

1. 스크립트를 다운로드 하고 실행 가능한지 확인하세요.

   $ chmod +x ngxunprivinst.sh

2. NGINX Plus 인증서와 키( nginx-repo.crt 및 nginx-repo.key )를 로컬 디렉토리에 복사합니다. 모든 ngxunprivinst.sh 명령에는 이를 식별하기 위한 ‑c 및 ‑k 옵션이 포함되어 있습니다.

3. NGINX Plus 저장소에서 사용 가능한 NGINX Plus 버전을 나열하세요.

   $ ./ngxunprivinst.sh 목록 -c nginx-repo.crt -k nginx-repo.key
   18-1
   18-2
   19-1
   20-1
   21-1
   22-1
   23-1

4. 원하는 패키지를 가져옵니다(여기서는 NGINX Plus R23-1을 가져옵니다). ‑p 옵션은 설치 디렉토리를 지정합니다.

   $ ./ngxunprivinst.sh 페치 -c nginx-repo.crt -k nginx-repo.key -p /home/nginxrun -v 23-1

5. 필요한 패키지를 설치합니다(여기서는 NGINX Plus와 NGINX JavaScript 모듈, njs를 설치합니다).

   $ ./ngxunprivinst.sh 설치 -c nginx-repo.crt -k nginx-repo.key -p /home/nginxrun -v 23.1 nginx-plus-23-1.el8.ngx.x86_64.rpm nginx-plus-모듈-njs-23%2B0.4.6-1.el8.ngx.x86_64.rpm

6. ‑p 옵션으로 경로를 지정하고, ‑c 옵션으로 구성 파일 이름을 지정하고, ‑e 옵션 으로 오류 로그 이름을 지정하여 NGINX를 시작합니다.

   $ /home/nginxrun/usr/sbin/nginx -p /home/nginxrun/etc/nginx -c nginx.conf -e /home/nginxrun/var/log/error.log

   경고 메시지가 나타나지 않도록 ‑e 옵션을 포함했습니다. NGINX Plus는 시작 시 구성을 읽기 전에 기본 오류 로그인 /var/log/nginx/error.log 에 기록합니다. 권한이 없는 사용자는 이 파일을 만들거나 쓸 수 있는 권한이 없으므로 경고가 표시됩니다. 구성을 읽은 후 error_log 지시문은 권한이 없는 사용자가 쓸 수 있는 위치에 오류 로그를 설정합니다.

7. (선택 사항) NGINX Plus가 루트가 아닌 사용자로 실행 중인지 확인하려면 다음 명령을 실행하세요.

   $ ps auxf | grep nginx nginxrun ...  9068 888 ?  Ss 21:55 0:00 nginx: 마스터 프로세스 nginxrun ...  9712 3572 ?  S 21:55 0:00 \_ nginx: 워커 프로세스

OpenID Connect PKCE 지원

PKCE (Proof Key for Code Exchange)는 최근 OpenID Connect(OIDC) 인증 코드 흐름에 추가된 확장 기능으로, 여러 종류의 공격을 방지하고 공개 클라이언트와의 OAuth 교환을 보호합니다. NGINX Plus R23 에서는 해당 확장을 지원하도록 OpenID Connect 참조 구현을 업데이트했습니다. OAuth 2.1 에서는 PKCE가 필수가 됩니다.

구체적인 변경 사항은 코드 챌린지에서 client_secret을 두 개의 새 값으로 바꾸는 것입니다.

• 코드 챌린지
• 코드 검증기

특히 모바일 기기에서 발생하는 다양한 공격에 대처하기 위해 토큰(액세스, ID 또는 새로 고침 토큰)에 대한 챌린지가 다음과 같이 조정되었습니다.

1. NGINX Plus는 code_verifier를 생성하고 기억합니다.
2. NGINX Plus는 최종 사용자를 OIDC ID 공급자(IdP) 로그인 페이지로 리디렉션합니다. 요청에는 code_challenge 라고 하는 code_verifier 의 해시된 버전이 포함되어 있습니다.
3. IdP는 사용자의 인증 코드를 NGINX Plus로 전송합니다.
4. NGINX Plus는 공유 상태를 기반으로 생성된 code_verifier를 찾고 IdP의 토큰 엔드포인트에서 설정된 토큰으로 승인 코드를 교환하기 위한 요청을 보낼 수 있습니다.

PKCE를 추가하기 전에는 NGINX Plus가 IdP와 정적 클라이언트 비밀을 공유하는 것으로 충분했습니다.
업데이트된 OIDC 참조 구현 에서는 NGINX Plus가 PKCE와 클라이언트 비밀 방법론 모두에 대한 인증 코드 흐름을 처리할 수 있습니다.

다음은 PKCE를 사용하여 확장된 인증 코드 흐름을 활성화하는 샘플 구성입니다.

새로운 $oidc_pkce_enable 변수는 PKCE 흐름에 대한 스위치 역할을 합니다. 설정되면1 특정 도메인의 경우 PKCE 흐름이 사용됩니다. 설정되면0 (기본값), PKCE가 아닌 인증 코드 흐름이 사용됩니다.

NGINX Plus R23의 기타 개선 사항

SSL/TLS 연결에 대한 세부적인 제어

TLS v1.3은 서버 간, 서버와 클라이언트 간의 종단간 암호화를 통해 이전 TLS 버전보다 더 강력한 보안을 제공합니다. NGINX Plus R23은 TLS v1.3에 대한 세부적인 제어를 위해 OpenSSL 구성에 대한 직접 액세스를 제공합니다.

인증서 및 키 없이 기본 HTTPS 서버 만들기

이전 릴리스에서는 TLS로 보호되는 HTTPS 트래픽의 기본 서버 블록에 ssl_certificate 및 ssl_certificate_key 지시어를 포함해야 했으며, "더미" 자체 서명 인증서와 키를 만들어야 했습니다.

ssl_reject_handshake 지시어는 이 샘플 구성에서처럼 인증서와 키에 대한 요구 사항을 제거합니다.

직접 OpenSSL 구성

NGINX Plus R23은 NGINX Plus가 OpenSSL 1.0.2 이상을 사용하여 SSL/TLS를 처리하는 방법을 보다 세부적으로 제어할 수 있는 기능을 제공합니다.

다음 사용 사례에서는 새로운 수준의 제어를 활용합니다.

• ChaCha 암호 – NGINX Plus는 클라이언트(일반적으로 모바일)가 선호 목록의 맨 위에 해당 암호를 지정하는 경우 ChaCha20을 사용합니다. ChaCha20은 이를 지원하는 클라이언트의 성능을 현저히 향상시킵니다.

• TLS v1.3 암호 구성 – 이전 릴리스에서는 ssl_ciphers 지시어를 사용하여 이 예와 같이 NGINX Plus의 기본 SSL/TLS 암호 목록을 설정했습니다.

  하지만 이 지침은 TLS v1.3에는 적용되지 않습니다. TLS v1.3에 대한 OpenSSL 암호 구현이 이전 인터페이스와 호환되지 않기 때문입니다. TLS v1.3에 대한 암호 목록을 설정하려면 다음 예와 같이 새로운 ssl_conf_command 지시문을 사용합니다.

  TLS v1.2 및 v1.3 모두에 대한 암호를 설정하려면 구성에 두 지침을 모두 포함하세요.

• 프록시 연결 업그레이드 - ssl_conf_command 지시문에서 구현한 암호 구성 메커니즘을 기반으로 NGINX Plus R23은 다음 프로토콜로 프록시된 연결에 대한 암호 제품군을 동일하게 제어할 수 있도록 해줍니다.

  • HTTP 및 TCP – proxy_ssl_conf_command
  • gRPC – grpc_ssl_conf_명령
  • uwsgi – uwsgi_ssl_conf_command

다음 예제에서는 이전 TLS 버전을 사용하는 클라이언트의 요청을 TLS v1.3을 지원하는 것으로 알려진 백엔드 서버로 업그레이드하기 위해 NGINX Plus를 구성하는 방법을 보여줍니다.

캐시 관리자는 사용 가능한 디스크 공간을 모니터링할 수 있습니다

NGINX Plus가 캐싱 프록시로 구성된 경우, 캐시 관리자 프로세스는 가장 최근에 액세스한 콘텐츠를 제거하여 캐시 크기가 proxy_cache_path 지시문의 max_size 매개변수로 설정된 제한을 초과하지 않도록 보장합니다.

NGINX Plus R23을 사용하면 캐시 관리자가 캐시를 저장하는 파일 시스템에서 사용 가능한 디스크 공간의 양을 모니터링하고, 사용 가능한 공간이 proxy_cache_path 지시문에 지정된 새로운 min_free 매개변수보다 작으면 콘텐츠를 제거할 수 있습니다.

즉, 캐시가 다른 프로세스와 동일한 파일 시스템을 공유하는 경우에도 NGINX Plus는 캐시를 채우면 실수로 디스크가 가득 차지 않도록 보장합니다.

쿠키 플래그 설정을 위한 네이티브 방식

보안되지 않은 쿠키는 여전히 고위험 공격 벡터입니다. Mozilla Developer Network (MDN)에서 언급된 바와 같이 의도치 않은 당사자나 스크립트가 쿠키에 접근하지 못하도록 하는 한 가지 방법은 Set-Cookie 헤더에 HttpOnly 및 Secure 와 같은 플래그를 설정하는 것입니다.

이전 릴리스에서는 이러한 목적을 위해 동적 모듈 리포지토리에서 제공되는 타사 Cookie‑Flag 모듈 에 구현된 대로 set_cookie_flag 지시문을 제공했습니다. NGINX Plus R23은 해당 지시어와 모듈을 대체하기 위해 proxy_cookie_flags 지시어를 도입합니다.

더 이상 사용되지 않는 Cookie‑Flag 모듈은 NGINX Plus R26 에서 제거되므로 구성에서 모든 set_cookie_flag 지시어를 찾아 가능한 한 빨리 proxy_cookie_flags 지시어로 대체하는 것이 좋습니다.

다음은 쿠키 보호 플래그를 설정하지 않는 간단한 백엔드 애플리케이션에 대한 프록시를 위한 샘플 구성입니다.

이 예제에서는 NGINX Plus가 NGINX Plus 관리자 가이드 에 설명된 대로 세션 지속성을 위해 사용하는 업스트림 서버에서 생성한 appcookie 세션 쿠키를 보호하기 위해 HttpOnly , Secure 및 SameSite 플래그를 추가합니다.

curl 명령이나 브라우저의 개발자 도구를 사용하면 appcookie 에 대해 HttpOnly , Secure 및 SameSite 플래그가 이제 설정된 것을 볼 수 있습니다.

< HTTP/1.1 200 OK< 서버: nginx/1.19.4
< 날짜: 목, 2020년 12월 8일 14:46:12 GMT
< 콘텐츠 유형: application/octet-stream
< 콘텐츠 길이: 9
< 연결: keep-alive
< 쿠키 설정: appcookie=appserver1; 보안; HttpOnly; SameSite=Strict
< 콘텐츠 유형: text/html

NGINX Plus R23을 사용하면 이 예시와 같이 sticky 지시문을 사용하여 쿠키에 SameSite 플래그를 추가할 수도 있습니다( httponly 및 secure 매개변수는 NGINX Plus R6부터 지원됨):

스트림 모듈에서 변수 설정

NGINX Plus R23은 TCP/UDP 구성에서 변수를 설정하는 set 지시어를 도입하여 HTTP 트래픽 처리 에 일반적으로 사용되는 기능을 확장합니다.

다음은 여러 변수에서 복잡한 합성값을 구성하는 예입니다.

좀 더 정교한 사용 사례에서는 set 지시문을 사용하여 키‑값 저장소를 업데이트합니다. DNS 부하 분산을 위한 이 구성에서 키-값 저장소는 각 클라이언트 IP 주소가 DNS 요청을 하는 시간을 기록하고 각 레코드를 24시간 동안 보관합니다.

그런 다음 NGINX Plus API를 사용하여 각 클라이언트가 지난 24시간 동안 가장 최근의 DNS 요청을 만든 시기를 알 수 있습니다.

$ curl http://localhost:8080/api/6/stream/keyvals/dns_timestamp { "172.17.0.1": "2020-12-08T15:51:28+00:00", "172.17.0.2": "2020-12-08T12:36:08+00:00", "172.17.0.7": "2020-12-08T15:15:42+00:00" }

NGINX Plus 에코시스템 업데이트

NGINX JavaScript 모듈의 향상

NGINX JavaScript 모듈(njs)이 업데이트되었습니다.0.5.0 . 이 버전에서는 Node.js Buffer 모듈과 유사한 Buffer 모듈을 소개합니다. 버퍼 객체를 사용하면 문자열에 의존하지 않고도 이진 데이터로 쉽게 작업할 수 있습니다.

모듈의 다른 주목할 만한 개선 사항으로는 URL에서 전달된 키-값 쌍에 쉽게 액세스할 수 있는 쿼리 문자열 모듈 과 디버깅을 위한 줄 수준 백트레이스 지원이 있습니다.

동적 모듈의 변경 사항

Kerberos 모듈용 새 SPNEGO

NGINX Plus 동적 모듈 저장소 에서 SPNEGO Kerberos 인증에 대한 지원을 사용할 수 있습니다. 설치 지침과 자세한 내용은 NGINX Plus 관리자 가이드를 참조하세요.

더 이상 사용되지 않는 쿠키 플래그 모듈

위의 쿠키 플래그 설정을 위한 기본 방법 에서 자세히 설명한 대로, 새로운 proxy_cookie_flags 지시문은 타사 Cookie‑Flag 모듈에서 구현된 set_cookie_flag 지시문을 대체합니다. 이 지시문은 현재 더 이상 사용되지 않으며 NGINX Plus R26 에서 삭제될 예정입니다. 구성에 set_cookie_flag 지시어가 포함되어 있는 경우 최대한 빨리 proxy_cookie_flags 로 바꿔주세요.

Prometheus-njs 모듈 업데이트

이제 Prometheus‑njs 모듈은 추가적인 메트릭을 제공합니다. NGINX JavaScript 모듈(njs)을 사용하는 배포를 수용하도록 업그레이드되었습니다. Prometheus‑njs를 버전 1.3.1 이상으로 업그레이드하는 경우 더 이상 사용되지 않는 njs 구성에 대한 참조를 방지하기 위해 NGINX 구성 파일을 업데이트하는 것이 중요합니다.

• js_include 지시문은 더 이상 사용되지 않으며 js_import 지시문으로 대체되었습니다.
• js_content 및 js_set 지시문은 모듈 함수를 참조할 수 있습니다.

주목할만한 버그 수정

변수가 비어 있지 않은지 테스트하기 위해 match 블록에서 require 지시문을 사용하는 상태 검사는 응답이 proxy_buffer_size 지시문의 값보다 큰 경우, 비정상적 업스트림 서버를 감지하지 못할 수 있습니다.

업그레이드 또는 NGINX Plus를 사용해 보세요

NGINX Plus를 사용하고 계시다면 가능한 한 빨리 NGINX Plus R23 으로 업그레이드하실 것을 적극 권장합니다. 또한 몇 가지 추가적인 수정 사항과 개선 사항을 얻을 수 있으며, 지원 티켓을 제출해야 할 때 NGINX에서 도움을 주는 데 도움이 됩니다.

NGINX Plus를 사용해보지 않으셨다면 보안, 부하 분산, API 게이트웨이로 사용하거나 향상된 모니터링 및 관리 API를 갖춘 완벽히 지원되는 웹 서버로 사용해보시기 바랍니다. 오늘 무료 30일 체험판을 통해 시작해 보세요. NGINX Plus가 어떻게 귀하의 애플리케이션을 제공하고 확장하는 데 도움이 될 수 있는지 직접 확인해 보세요.