NGINX Plus R23 발표

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

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

이 릴리스를 마무리하는 것은 SSL/TLS에 대한 보다 세부적인 제어, 쿠키 플래그를 설정하는 기본 방법, Stream 모듈의 변수 설정입니다. NGINX Plus 에코시스템의 업데이트에는 NGINX JavaScript 모듈을 위한 새로운 Buffer 및 Query String 모듈, Kerberos 동적 모듈을 위한 새로운 SPNEGO, Prometheus‑njs 동적 모듈에 대한 향상이 포함됩니다.

행동의 중요한 변화

• 사용되지 않는 모듈  - 타사 Cookie‑Flag 모듈은 사용되지 않으며 새 지시어로 대체됩니다 . 이 모듈은 NGINX Plus R26proxy_cookie_flags 에서 제거됩니다 . 자세한 내용은 쿠키 플래그 설정을 위한 네이티브 메서드를 참조하세요 .
• 지원되는 새로운 운영 체제:
  • 알파인 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지시문에는 각 업스트림 서버 서비스 의 메서드 type=grpc를 호출하는 매개변수가 포함됩니다. 로 응답하는 서비스는 정상으로 간주됩니다. 이 매개변수는 NGINX Plus가 시작되거나 업스트림 그룹에 새 서버가 도입될 때 트래픽이 상태 검사를 통과할 때까지 전달되지 않도록 합니다(그렇지 않으면 새 서비스는 기본적으로 정상으로 간주됩니다).CheckHealthSERVINGmandatory

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

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

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

권한이 없는 사용자 설치

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

$ 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.

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

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

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

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

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

   $ chmod +x ngxunprivinst.sh

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

3. 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

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

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

5. 필요한 패키지를 설치합니다(여기서는 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

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

   $ /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가 비사용자로 실행 중인지 확인하려면 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 지원

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

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

• code_challenge
• code_verifier

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

1. NGINX Plus는 .을 생성하고 기억합니다 code_verifier.
2. code_verifierNGINX Plus는 최종 사용자를 OIDC ID 공급자(IdP) 로그인 페이지에 로그인하도록 리디렉션합니다. 요청에는 a라고 하는 해시된 버전이 포함됩니다 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_certificatessl_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 암호 목록을 설정하는 데 사용되었습니다.

  
  

  ssl_ciphers ALL:!aNULL:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;

  view rawtls_ciphers.conf hosted with ❤ by GitHub

  
  

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

  
  

  ssl_conf_command Ciphersuites TLS_CHACHA20_POLY1305_SHA256;

  view rawtls_ciphers.conf hosted with ❤ by GitHub

  
  

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

  
  

  	ssl_protocols TLSv1.2 TLSv1.3;
  	# For TLS 1.2
  	ssl_ciphers ALL:!aNULL:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
  	# For TLS 1.3
  	ssl_conf_command Ciphersuites TLS_CHACHA20_POLY1305_SHA256;

  view rawtls_ciphers.conf hosted with ❤ by GitHub

  
  

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

  • HTTP와 TCP –proxy_ssl_conf_command
  • gRPC –grpc_ssl_conf_command
  • 우즈기 –uwsgi_ssl_conf_command

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

  
  

  	upstream my_backend {
  	zone my_backend 64k;
  	server 10.0.0.1:8443;
  	}
  	server {
  	listen 443 ssl;
  	ssl_protocols       TLSv1.1 TLSv1.2;
  	ssl_certificate     /etc/ssl/api.example.com.crt;
  	ssl_certificate_key /etc/ssl/api.example.com.key;
  	location / {
  	proxy_pass https://my_backend;
  	proxy_ssl_protocols    TLSv1.3;
  	proxy_ssl_conf_command Ciphersuites TLS_AES_256_GCM_SHA384;
  	}
  	}

  view rawtls_upgrade.conf hosted with ❤ by GitHub

  
  

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

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

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

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

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

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

이전 릴리스에서는 동적 모듈 리포지토리에서 사용 가능한 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명령어나 브라우저의 개발자 도구를 사용하면 appcookieHttpOnly 에 대해 , Secure, 및 SameSite플래그가 설정된 것을 볼 수 있습니다 .

< 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과 함께 쿠키에 플래그를 추가할 수도 있습니다 ( 및 매개변수는 NGINX Plus R6부터 지원됨 ):stickyhttponlysecure

스트림 모듈에서 변수 설정

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

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

더 정교한 사용 사례는 키-값 저장소를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 모듈이 도입되었습니다 . Buffer 객체는 문자열에 의존하는 대신 바이너리 데이터로 작업하기 쉽게 해줍니다.

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

동적 모듈의 변경 사항

Kerberos 모듈용 새 SPNEGO

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

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

위의 쿠키 플래그 설정을 위한 네이티브 메서드 에서 자세히 설명한 대로 , 새 지시문은 타사 쿠키 플래그 모듈에서 구현된 지시문을 proxy_cookie_flags대체합니다 . 이 지시문은 현재 더 이상 사용되지 않으며 NGINX Plus R26 에서 제거될 예정입니다 . 구성에 지시문이 포함되어 있는 경우 최대한 빨리 로 대체하세요 .set_cookie_flagset_cookie_flagproxy_cookie_flags

Prometheus-njs 모듈 업데이트

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

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

주목할만한 버그 수정

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