NGINX Plus R23 출시 발표

Liam Crilly제품 관리 부문 수석 이사

NGINX Plus 릴리스 23(R23)이 출시되었음을 기쁘게 알려드립니다. NGINX Open Source를 기반으로 하는 NGINX Plus는 소프트웨어 로드 밸런서, 리버스 프록시 및 API 게이트웨이 기능을 모두 제공하는 유일한 솔루션입니다.

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

• gRPC 상태 확인 – 요청을 보내기 전에 gRPC 서비스가 요청을 처리할 수 있는지 능동적으로 테스트하면 안정성이 크게 향상됩니다.
• 비특권 설치 지원 – 이제 비특권(비‑root) 사용자도 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 모듈을 위한 새로운 Buffer 및 Query String 모듈, 새로운 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은 더 이상 지원되지 않습니다
  • Debian 9는 NGINX Plus R24에서 제거될 예정입니다

새로운 기능 상세 설명

gRPC 상태 확인

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

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

코드 예제를 로드하는 중…

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

각 업스트림 서버에서 여러 gRPC 서비스를 제공하는 경우, 다음 예와 같이 가장 중요한 서비스(종속 또는 하위 서비스가 있는 서비스)의 이름을 grpc_service 매개변수 값으로 지정하여 모니터링할 수 있습니다:

코드 예제를 로드하는 중…

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

백엔드 코드를 수정하지 않고도 gRPC 서비스가 수신 요청에 응답할 수 있는지 확인할 수 있습니다. 이 방법을 사용하면 모든 gRPC 서비스를 모니터링할 수 있습니다:

코드 예제를 로드하는 중…

비특권 사용자 설치

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

$ ps auxf | grep nginxroot  ...  9068  888 ?  Ss 21:44  0:00 nginx: master process nginx
nginx ...  9712 3572 ?  S  21:44  0:00  \_ nginx: worker process

위와 같이 마스터 프로세스는 root 권한으로 실행됩니다. 그 외의 모든 프로세스(워커 및 캐시 관리)는 권한이 없는 사용자 계정인 nginx를 사용합니다.

민감한 데이터를 처리하는 중요 시스템에서는 root 사용자를 사용하지 않는 것이 바람직할 수 있습니다. 이 경우 NGINX Plus R23을 비특권 사용자로 설치하고 실행할 수 있습니다. 다음 운영 체제에서 사용할 수 있도록 GitHub 리포지토리에 설치 스크립트 ngxunprivinst.sh를 제공합니다:

• Alpine Linux
• Amazon Linux, Amazon Linux 2
• CentOS, Red Hat Enterprise Linux
• Debian, Ubuntu

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

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

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

$ chmod +x ngxunprivinst.sh

1. NGINX Plus 인증서와 키(nginx-repo.crt 및 nginx-repo.key)를 로컬 디렉터리에 복사합니다. 모든 ‑c 및 ‑k 옵션은 해당 파일을 지정하기 위해 모든 ngxunprivinst.sh 명령에 포함됩니다.
2. NGINX Plus 리포지토리에서 사용할 수 있는 NGINX Plus 버전을 나열합니다.

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

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

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

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

$ ./ngxunprivinst.sh install -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-module-njs-23%2B0.4.6-1.el8.ngx.x86_64.rpm

1. NGINX를 시작합니다. 이때 경로를 지정하는 ‑p 옵션, 구성 파일의 이름을 지정하는 ‑c 옵션, 오류 로그의 이름을 지정하는 ‑e 옵션을 포함합니다.

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

1. 표시되는 경고 메시지를 억제하기 위해 ‑e 옵션을 포함합니다. NGINX Plus는 시작 중에 구성을 읽기 전까지 기본 오류 로그인 /var/log/nginx/error.log에 기록합니다. 권한이 없는 사용자는 이 파일을 만들거나 쓸 권한이 없으므로 경고가 발생합니다. 구성을 읽은 후에는 error_log 지시문이 권한이 없는 사용자가 쓸 수 있는 위치로 오류 로그를 설정합니다.
2. (선택 사항) NGINX Plus가 비-root 사용자로 실행 중인지 확인하려면 다음 명령을 실행합니다:

$ ps auxf | grep nginx
nginxrun ...  9068  888 ?  Ss 21:55 0:00 nginx: master process
nginxrun ...  9712 3572 ?  S  21:55 0:00  \_ nginx: worker process

OpenID Connect PKCE 지원

코드 교환을 위한 증명 키(PKCE)는 여러 유형의 공격을 방지하고 공개 클라이언트와의 OAuth 교환을 보호하기 위해 최근 OpenID Connect(OIDC) 인증 코드 흐름에 추가된 확장 기능입니다. NGINX Plus R23에서는 이 확장 기능을 지원하도록 OpenID Connect 참조 구현을 업데이트했습니다. PKCE는 OAuth 2.1에서 필수 사항이 될 예정입니다.

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

• code_challenge
• code_verifier

특히 모바일 기기에서 발생할 수 있는 다양한 공격에 대응하기 위해 토큰(액세스 토큰, ID 토큰 또는 리프레시 토큰)에 대한 챌린지가 다음과 같이 조정되었습니다:

1. NGINX Plus는 code_verifier를 생성하고 기억합니다.
2. NGINX Plus는 최종 사용자를 OIDC ID 공급자(IdP) 로그인 페이지로 리디렉션하여 로그인하도록 합니다. 요청에는 code_verifier의 해시 버전인 code_challenge가 포함됩니다.
3. IdP는 사용자의 auth_code를 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 트래픽을 위한 기본 server 블록에 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용 암호화 스위트의 OpenSSL 구현은 이전 인터페이스와 호환되지 않으므로 이 지시문은 TLS v1.3에 적용되지 않습니다. 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_command
  • uwsgi – uwsgi_ssl_conf_command

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

코드 예제를 로드하는 중…

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

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

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

즉, 캐시가 다른 프로세스와 동일한 파일 시스템을 공유하더라도 NGINX Plus는 캐시를 채우는 과정에서 의도치 않게 디스크 공간이 가득 차지 않도록 합니다.

코드 예제를 로드하는 중…

쿠키 플래그 설정을 위한 기본 제공 방법

보안이 적용되지 않은 쿠키는 여전히 위험도가 높은 공격 경로입니다. Mozilla Developer Network(MDN)에서 설명하듯이, 의도하지 않은 사용자나 스크립트가 쿠키에 접근하지 못하도록 하는 한 가지 방법은 HttpOnly 및 Secure와 같은 플래그를 Set-Cookie 헤더에 설정하는 것입니다.

이전 릴리스에서는 이를 위해 타사 set_cookie_flag 지시어를 제공했으며, 이 지시어는 동적 모듈 저장소에서 제공되는 Cookie‑Flag 모듈에 구현되어 있었습니다. NGINX Plus R23에서는 기존 지시어와 모듈을 대체하는 proxy_cookie_flags 지시어가 도입되었습니다.

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

다음은 자체적으로 쿠키 보호 플래그를 설정하지 않는 간단한 백엔드 애플리케이션으로 프록시하기 위한 구성 예시입니다:

코드 예제를 로드하는 중…

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

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

< HTTP/1.1 200 OK< Server: nginx/1.19.4
< Date: Thu, 08 Dec 2020 14:46:12 GMT
< Content-Type: application/octet-stream
< Content-Length: 9
< Connection: keep-alive
< Set-Cookie: appcookie=appserver1; Secure; HttpOnly; SameSite=Strict
< Content-Type: text/html

NGINX Plus R23에서는 다음 예와 같이 SameSite 플래그를 sticky 지시문을 사용하여 쿠키에 추가할 수도 있습니다(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 버전으로 업데이트되었습니다. 이 버전에는 Buffer 모듈이 도입되었으며, 이는 Node.js Buffer 모듈과 유사합니다. Buffer 객체를 사용하면 문자열에 의존하지 않고 바이너리 데이터를 손쉽게 처리할 수 있습니다.

이 모듈의 그 밖의 주요 개선 사항으로는 URL로 전달된 키-값 쌍에 쉽게 액세스할 수 있는 쿼리 문자열 모듈과 디버깅을 위한 줄 단위 역추적 지원이 있습니다.

동적 모듈 변경 사항

Kerberos 모듈용 새로운 SPNEGO

이제 NGINX Plus SPNEGO Kerberos 인증 지원을 동적 모듈 저장소에서 이용할 수 있습니다. 설치 방법과 자세한 정보는 NGINX Plus 관리자 가이드를 참조하세요.

지원 중단된 Cookie-Flags 모듈

위의 쿠키 플래그 설정을 위한 기본 제공 방식에서 자세히 설명한 것처럼, 새로운 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 구성 파일을 업데이트해야 합니다:

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

주요 버그 수정

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

NGINX Plus로 업그레이드하거나 사용해 보기

NGINX Plus를 실행 중이라면 가능한 한 빨리 NGINX Plus R23으로 업그레이드하시기를 강력히 권장합니다. 업그레이드하면 여러 추가 수정 사항과 개선 사항도 적용되며, 지원 티켓을 제출해야 할 때 NGINX가 더 원활하게 지원하는 데 도움이 됩니다.

아직 NGINX Plus를 사용해 보지 않으셨다면 보안, 부하 분산, API 게이트웨이 용도로, 또는 향상된 모니터링 및 관리 API를 갖춘 완전한 지원이 제공되는 웹 서버로 사용해 보시기 바랍니다. 지금 바로 30일 무료 평가판으로 시작해 보세요. NGINX Plus가 애플리케이션을 제공하고 확장하는 데 어떻게 도움이 되는지 직접 확인해 보세요.

작성자 소개

Liam Crilly제품 관리 부문 수석 이사

Liam Crilly의 다른 블로그 게시물