NGINX Plus R14 출시 발표

NGINX | 2017년 12월 12일

NGINX Plus Release 14(R14)를 이제 NGINX Plus 구독 고객에게 제공하게 되어 기쁘게 생각합니다. NGINX Plus는 로드 밸런서, 콘텐츠 캐시 및 웹 서버를 하나로 통합한 유일한 솔루션입니다. NGINX Open Source를 기반으로 하며, 독점 기능과 함께 수상 경력에 빛나는 24시간 지원을 제공합니다. NGINX Plus R14에는 새로운 보안 및 클러스터링 개선 사항이 포함되어 있습니다.

NGINX Plus를 사용하면 JSON 웹 토큰(JWT)을 통해 액세스 제어를 적용할 수 있습니다. NGINX Plus R14에는 중첩된 JWT 클레임 지원이 추가되어 JWT 내에 중첩된 그룹 멤버십 정보를 기반으로 액세스를 허용하거나 거부할 수 있습니다. NGINX Plus R10에서 처음 도입된 기본 JWT 인증 지원을 통해 NGINX Plus를 API 및 애플리케이션의 인증 게이트웨이로 사용할 수 있습니다.

그 밖의 NGINX Plus R14 기능은 다음과 같습니다:

  • 확장된 클러스터링 지원(기술 프리뷰) – 클러스터 내 NGINX Plus 인스턴스 간에 상태 정보를 공유하는 새로운 기능의 프리뷰를 테스트해 보시기 바랍니다. 이 프리뷰에서는 sticky learn 세션 지속성 방식의 상태가 공유됩니다. 향후 릴리스에서는 다른 NGINX Plus 기능으로 클러스터링 지원을 확대할 예정입니다.
  • 더 긴 JWT 키 크기 – 중첩된 JWT 클레임과 배열 데이터 지원에 더해, 이제 JWT 서명 알고리즘에서 더 긴 키 크기(최대 512비트)를 지원합니다. 이를 통해 JWT를 검증할 때 보안성과 유연성이 향상됩니다.
  • 스트림 키-값 저장소 및 API – 릴리스 13에서 HTTP 애플리케이션용으로 도입된 강력한 키-값 저장소와 API가 stream 컨텍스트의 TCP 및 UDP 애플리케이션으로 확장되었습니다.
  • NGINX JavaScript 모듈 개선 사항 – NGINX Plus에서 JavaScript 코드를 실행할 수 있게 해주는 이 모듈은 이제 JSON 객체에 대한 언어 지원이 추가되었습니다. [이 모듈의 이전 명칭은 nginScript였습니다.] 이를 통해 백엔드 API에서 수신한 JSON 응답의 정보를 기본 기능으로 구문 분석하고 추출할 수 있으며, Node.js 스타일의 메서드를 사용하여 파일 시스템에 액세스할 수 있습니다. 또한 이제 다양한 예외 및 오류 객체가 발생할 때 역추적 정보를 제공하여 디버깅과 문제 해결을 용이하게 합니다.
  • 추가 기능 – NGINX Plus에는 업데이트된 실시간 활동 모니터링 대시보드, 새로운 SSL 변수, 업스트림 서버 드레이닝 기능도 포함되어 있습니다.

동작 변경 사항

  • NGINX Plus API가 버전 2로 업그레이드되었습니다. 새로운 NGINX Plus API 기능을 사용하려는 경우 API 호환성 문서를 확인하세요.
  • Upstream-Conf 및 확장 Status 모듈의 API(upstream_conf 및 status 지시문으로 활성화)는 NGINX Plus R13부터 더 이상 사용되지 않습니다. 이 API들은 새로운 NGINX Plus API로 대체되었으며, 이 API는 R14에 포함된 업데이트된 실시간 활동 모니터링 대시보드에서 사용됩니다.
  • 이제 Ubuntu 17.10(Artful Aardvark)에서 NGINX Plus를 사용할 수 있습니다.
  • NGINX Plus는 더 이상 Debian 7(Wheezy)을 지원하지 않습니다.

NGINX Plus R14 기능 상세 설명

JWT 기능 개선

API 및 마이크로서비스 배포 담당자들은 간편성과 유연성 때문에 JSON 웹 토큰(JWT, “jot”으로 발음) 표준을 채택하고 있습니다. JWT는 ID 정보를 교환하기 위한 간결하고 이식성이 뛰어난 수단입니다. Okta, OneLogin, 자체 개발 솔루션 등 다양한 발급자로부터 JWT를 받을 수 있습니다. 그러면 NGINX Plus는 사용자 또는 API 클라이언트가 유효한 JWT를 제시했는지 여부에 따라 액세스를 허용하거나 거부할 수 있습니다.

NGINX Plus R14에서는 중첩된 JWT 클레임과 배열 데이터뿐만 아니라 JWT 서명 알고리즘을 위한 더 긴 키 크기도 지원합니다. 이를 통해 JWT를 검증할 때 유연성과 보안성이 더욱 향상됩니다.

중첩 JWT 클레임 및 배열 데이터 지원

JWT 페이로드에는 그룹 멤버십과 같이 사용자에 대한 추가적인 ‘중첩’ 정보가 포함될 수 있으며, 이 정보는 리소스에 대한 액세스 권한을 부여하는 데 사용할 수 있습니다. 이를 통해 사용자 요청을 승인하기 위해 데이터베이스를 여러 번 조회할 필요가 없습니다.

다음 JWT 페이로드를 살펴보겠습니다:

{  "exp": 1513429677,
  "sub": "xample@example.com",
  "aud": "nginx",
  "attributes": {
    "name": "Xavier Ample",
    "room": "A123",
    "dept": "Demonstrations"
  },
  "groups": [
    "Administrator",
    "Foobar",
    "Bazpub"
  ]
}

위 JWT에서 attributes는 '중첩 클레임' 객체이고, groups는 배열입니다. 다음 구성 스니펫을 사용하여 attributes 객체의 name 값을 백엔드에 전달하고 Administrator 그룹에 속하지 않은 사용자의 액세스를 거부할 수 있습니다.

auth_jwt_claim_set $jwt_groups groups; # Array value will join as comma-separated valuesauth_jwt_claim_set $jwt_real_name attributes name; # This value is two levels deep

map $jwt_groups $isAdmin {
	"~\bAdministrator\b" 1; # Appears within word boundaries (\b) of CSV list
	default              0;
}

server {
    listen 443 ssl;
    #ssl_*; # Config for SSL/TLS termination

    auth_jwt "closed site";
    auth_jwt_key_file jwk.json;

    location / {
        proxy_set_header X-RealName $jwt_real_name; # Pass real name as header
        proxy_set_header X-Subject  $jwt_claim_sub; # L1 claims set automatically
        proxy_pass http://my_backend;
    }
 
    location /admin {
        if ( $isAdmin = 0 ) {
            return 403; # Forbidden
        }
        proxy_pass http://my_backend;
    }
}

이 구성의 작동 방식에 대한 자세한 내용은 다음과 같습니다:

  • Using the auth_jwt_claim_set 지시문을 사용하여 $jwt_groups NGINX 변수를 JWT에 정의된 groups 배열로 설정합니다. 배열의 값은 쉼표로 구분되어 $jwt_groups에 할당됩니다.
  • Using the map 지시어를 사용하여 그룹 목록에서 Administrator 키워드를 검색합니다. 이 키워드가 있으면 사용자를 관리자로 간주하고 $isAdmin을 1로 설정합니다. 그렇지 않으면 $isAdmin을 0으로 설정합니다.
  • The location 블록은 /admin URI에 대해 $isAdmin 변수를 확인합니다. 값이 0이면 NGINX는 클라이언트에 403 Forbidden 상태 코드를 반환합니다.

NGINX Plus R14에서는 중첩된 JWT 클레임으로 변수를 생성할 수도 있습니다. 그런 다음 백엔드 서버로 프록시하기 전에 해당 변수를 HTTP 헤더에 넣을 수 있습니다.

위 예시에서는 auth_jwt_claim_set 지시어를 사용하여 $jwt_real_name NGINX 변수를 attributes 클레임 내 name 객체의 값으로 설정합니다. proxy_set_header 지시어는 X-RealName HTTP 헤더를 name 객체의 값으로 설정하고 요청을 my_backend로 프록시합니다.

NGINX Plus에서 JWT를 인증하는 데 사용할 수 있는 모든 구성 지시문에 대한 자세한 내용은 참조 문서를 확인하세요.

JWT 서명 알고리즘을 위한 더 긴 키 크기

NGINX Plus R14는 이제 256비트, 384비트 및 512비트 서명 키를 지원하여 서명 검증을 강화하고 기본적으로 더 긴 서명 키를 사용하는 ID 및 액세스 관리(IAM) 제품과 더욱 쉽게 통합할 수 있습니다. 더 긴 서명 키는 지원되는 모든 서명 알고리즘에서 사용할 수 있습니다:

  • SHA‑2를 사용하는 HMAC(“HS”)
  • SHA‑2를 사용하는 RSA PKCS #1(“RS”)
  • 타원 곡선 디지털 서명 알고리즘(“ES”)

예를 들어 NGINX Plus R14가 RS512 알고리즘으로 서명된 JSON 웹 토큰만 허용하도록 구성할 수 있습니다:

server {    listen 443 ssl;
    #ssl_*; # Config for SSL/TLS termination

    auth_jwt "closed site";
    auth_jwt_key_file jwk.json;

    location / {
        if ( $jwt_header_alg != RS512 ) {
            return 401;
        }
        proxy_pass http://my_backend;
    }
}

이 경우 JWT가 RS512 알고리즘으로 서명되지 않았다면 NGINX Plus는 요청을 프록시하지 않고, 요청을 보낸 클라이언트에 상태 코드 401 Unauthorized를 반환합니다.

참고: JWT 지원은 NGINX Plus에서만 제공됩니다.

스트림 모듈용 키-값 저장소 및 API

NGINX Plus R13에서는 HTTP용 키-값 저장소 모듈이 도입되어 하나 이상의 공유 메모리 영역에서 키-값 쌍을 즉시 생성, 수정 및 삭제할 수 있습니다. 키-값 저장소 API의 대표적인 활용 사례로는 fail2ban과 함께 사용하여 동적 IP 차단 목록을 생성하는 것이 있습니다.

NGINX Plus R14에는 스트림용 키-값 저장소 모듈이 추가되어 HTTP 앱과 동일한 키-값 쌍 기능을 TCP 및 UDP 애플리케이션에서도 사용할 수 있습니다.

키-값 저장소를 동적으로 재구성하는 기능은 stream 컨텍스트에서 NGINX Plus R14의 NGINX Plus API 일부로 구현되었습니다.

참고: 키-값 저장소와 API는 NGINX Plus에서만 사용할 수 있습니다.

NGINX JavaScript 모듈의 향상된 기능

NGINX JavaScript 모듈(이전 명칭: nginScript)은 NGINX Plus를 위한 JavaScript 기반 스크립팅 언어입니다. NGINX Plus R14에서는 프로그래밍 기능을 더욱 개선하기 위해 NGINX JavaScript의 기능이 확장되었습니다. 업데이트된 NGINX JavaScript 동적 모듈 패키지는 다음과 같은 새로운 개선 사항을 제공합니다.

JSON 객체 지원

이제 JavaScript JSON 객체를 NGINX JavaScript에서 네이티브 객체로 사용할 수 있습니다. 이를 통해 복잡한 데이터 구조를 더욱 편리하게 관리할 수 있으며, NGINX JavaScript에서 백엔드 API로부터 받은 JSON 응답을 파싱하고 조작할 수도 있습니다.

다음 njs 셸 예제에서는 기본 제공 객체 구문을 사용하여 JSON 데이터를 파싱하고 추출하는 방법을 보여 줍니다.

$ njsinteractive njscript

v.<Tab> -> the properties and prototype methods of v.
type console.help() for more information

>> var my_data = '{"colors":[{"name":"red","fancy":"brick dust"}, {"name":"blue","fancy":"sea spray"}]}';
>> var my_object = JSON.parse(my_data);
>> my_object.colors[1].fancy;
sea spray
>>

파일 시스템 액세스

가장 널리 사용되는 서버 측 JavaScript 구현인 Node.js는 OS 파일 시스템에 액세스하기 위한 기본 제공 메서드를 지원합니다(클라이언트 측 JavaScript에서는 파일 시스템에 액세스할 수 없음). NGINX Plus R14부터는 NGINX JavaScript에서 Node.js 파일 시스템 메서드를 사용하여 파일을 읽고 쓸 수 있으므로 애플리케이션 제공 워크플로를 맞춤 설정할 수 있습니다. 허용되는 작업은 다음과 같습니다:

  • 읽기 – fs.readFile, fs.readFileSync
  • 쓰기 – fs.writeFile, fs.writeFileSync
  • 추가 – fs.appendFile, fs.appendFileSync

이 NGINX JavaScript 셸 예제에서는 NGINX JavaScript를 사용하여 파일 내용을 변수로 읽어 오는 방법을 보여 줍니다.

$ njsinteractive njscript

v.<Tab> -> the properties and prototype methods of v.
type console.help() for more information

>> var fs = require('fs');
>> var tz = fs.readFileSync('/etc/timezone');
>> tz
Europe/London
>>

오류 객체 및 역추적

개발자의 디버깅 및 문제 해결을 더욱 지원하기 위해 이제 다양한 오류 객체를 사용할 수 있습니다:

  • 오류
  • EvalError
  • InternalError
  • RangeError
  • ReferenceError
  • SyntaxError
  • TypeError
  • URIError

또한 이제 NGINX JavaScript는 오류 및 예외에 대한 역추적을 제공합니다. 다음 오류 로그 항목은 실패한 시스템 작업에 대한 간단한 역추적을 보여 줍니다.

2017/12/12 01:52:08 [error] 43441#43441: *10 js exception: Error: No such file or directory    at native (native)
    at my_function (:1)
    at main (native)
, client: 127.0.0.1, server: , request: "GET / HTTP/1.1", host: "localhost:80"

Learn how to 블로그에서 NGINX JavaScript<.htmla>를 시작하는 방법을 알아보세요.

NGINX Plus API를 사용하는 NGINX Plus 대시보드

NGINX Plus R13에서는 NGINX Plus API가 도입되어 JSON 형식의 실시간 모니터링 및 메트릭에 액세스할 수 있게 되었습니다. NGINX Plus R14에서는 기본 제공되는 실시간 활동 모니터링 대시보드가 이제 NGINX Plus API를 사용하여 사용자에게 80개 이상의 모니터링 메트릭을 실시간으로 제공합니다.

이전 버전의 NGINX Plus에서 대시보드가 사용하던 동적 재구성 및 확장 상태 API는 더 이상 사용되지 않습니다. 이 API는 이번 릴리스에서도 계속 사용할 수 있으며 NGINX Plus R15에도 포함될 예정입니다. NGINX Plus R16에서는 완전히 제거될 예정이므로 지금 구성을 업데이트하시기 바랍니다.

지원 중단된 대시보드의 구성은 다음과 같습니다:

location /status { # DEPRECATED    status;        # DEPRECATED
    # directives controlling access, such as 'allow' and 'deny'
}

location = /status.html {       # DEPRECATED
    root /usr/share/nginx/html; # DEPRECATED
}

기존 NGINX Plus 인스턴스를 새로운 NGINX Plus 대시보드로 마이그레이션하려면 이전 코드 조각을 다음으로 교체하세요:

location /api {    api write=on;
    # directives controlling access, such as 'allow' and 'deny'
}

location = /dashboard.html {
    root /usr/share/nginx/html;
}

# Redirect requests made to the old dashboard
location = /status.html {
    return 301 /dashboard.html;
}

코드 조각에 표시된 것처럼 API에 대한 액세스를 제한할 것을 강력히 권장합니다. 예를 들어 allow 및 deny 지시어를 사용할 수 있습니다. 기존 액세스 제어 설정을 /status 위치에서 /api 위치로 반드시 이전하세요.

새로운 NGINX Plus API에 대한 자세한 내용은 NGINX Plus R13 발표를 참조하세요.

참고: 기본 제공 대시보드는 NGINX Plus에서만 사용할 수 있습니다.

구성 파일에서 업스트림 서버 드레이닝

서버를 오프라인으로 전환할 때 기존 세션은 완료되도록 허용하면서 새 세션이 설정되지 않도록 하면 사용자 경험을 개선할 수 있습니다. 활성 세션이 하나도 남지 않을 때까지 서버는 오프라인으로 전환되지 않습니다. 이를 서버 드레이닝이라고 합니다. 해당 서버의 API 리소스에 PATCH 요청을 보내면서 {"drain":true}을 포함하면 NGINX Plus API를 통해 이 작업을 동적으로 수행할 수 있습니다.

NGINX Plus R14에서는 업스트림 drain 지시문에 server 매개변수를 제공하여 이 기능을 파일 기반 구성으로 확장합니다.

upstream my_backend {        server  10.0.0.1;
        server  10.0.0.2;
        server  10.0.0.3 drain;
}

NGINX Plus 구성을 다시 로드하면 IP 주소가 10.0.0.3인 업스트림 서버가 드레이닝 모드로 전환됩니다. 나중에 해당 server 지시어를 제거하거나 draining 매개변수를 down으로 바꾸어 서버를 완전히 사용 중지할 수 있습니다.

Sticky Learn 클러스터링 지원(기술 미리 보기)

NGINX Plus R14에서 NGINX Plus 인스턴스 클러스터 전체에 걸쳐 상태를 공유하는 향후 기능의 기술 프리뷰를 선보이게 되어 기쁘게 생각합니다. 이 기술 프리뷰에서는 세션 지속성의 sticky learn 방식을 구현하여, 그렇지 않으면 각 인스턴스에서 개별적으로 관리해야 하는 세션 데이터를 공유할 때의 이점을 보여줍니다.

이 기술 프리뷰는 별도로 설치할 수 있는 패키지로 제공되며, 요청 시 이용할 수 있습니다. 액세스하려면 NGINX 영업 담당자에게 문의해 주세요.

참고:

  1. sticky learn 클러스터링 기능은 현재 프리뷰 상태이므로 프로덕션 환경에서 사용하기에 적합하지 않습니다. 클러스터 간 상태 공유가 사용 환경의 중요한 요구 사항이라면 이 기술 프리뷰를 테스트하고 요구 사항을 얼마나 잘 충족하는지 NGINX에 피드백을 제공해 주시기 바랍니다.
  2. 기술 프리뷰 패키지는 CentOS/RHEL/Oracle Linux 7, Debian 8 및 9, Ubuntu 16.04, 16.10 및 17.10에서 사용할 수 있습니다.

참고: 클러스터링 지원과 sticky-learn 세션 지속성은 모두 NGINX Plus에서만 제공됩니다.

추가 기능

NGINX Plus R14에는 다음과 같은 개선 사항도 포함되어 있습니다:

  • 다시 로드해도 유지되는 리졸버 상태 – 업스트림 그룹의 서버 집합을 동적으로 재구성하는 한 가지 방법은 호스트 이름이나 도메인을 server 지시문의 매개변수로 사용하는 것입니다. DNS는 주기적으로 이름을 확인하며 NGINX Plus는 변경된 서버 집합을 자동으로 사용합니다(NGINX Plus 관리 가이드 참조). 이제 NGINX Plus는 다시 로드한 후에도 호스트 이름이나 도메인 이름의 DNS 레코드를 유지합니다. 이전에는 다시 로드한 후 이름을 다시 확인해야 했기 때문에 이름 확인이 완료되기 전에 도착한 요청을 처리할 수 없었습니다.
  • 새로운 SSL 클라이언트 인증서 변수 – $ssl_client_escaped_cert 변수는 클라이언트 인증서를 HTTP 헤더에 안전하고 편리하게 인코딩하여 백엔드 애플리케이션으로 전송할 수 있도록 해 주는 새로운 NGINX 내장 변수입니다. 이 변수는 URL 인코딩됩니다.

NGINX Plus 업그레이드 또는 체험

NGINX Plus R14에는 클라이언트 애플리케이션을 위한 향상된 인증 기능, 추가 클러스터링 기능, NGINX JavaScript 개선 사항 및 주요 버그 수정 사항이 포함되어 있습니다. 특히 NGINX Plus R13에서는 이전 워커 프로세스가 상태 확인을 무기한 수행할 수 있는 능동 상태 확인 관련 버그가 발생했습니다. 이 문제는 NGINX Plus R14에서 해결되었습니다.

NGINX Plus를 사용 중이라면 가능한 한 빨리 릴리스 14로 업그레이드할 것을 강력히 권장합니다. 업그레이드하면 여러 수정 사항과 개선 사항이 적용되며, 지원 티켓을 제출해야 할 때 NGINX가 더 원활하게 지원하는 데 도움이 됩니다. 설치 및 업그레이드 지침은 고객 포털에서 확인할 수 있습니다.

업그레이드를 진행하기 전에 이 블로그 게시물에 설명된 새로운 기능과 동작 변경 사항을 주의 깊게 검토하시기 바랍니다.

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


공유

작성자 소개

관련 블로그 게시물

시청하기: KubeCon North America 2023에서의 NGINX Gateway Fabric
NGINX | 2023. 11. 30.

시청하기: KubeCon North America 2023에서의 NGINX Gateway Fabric

이 영상에서는 KubeCon의 NGINX 부스를 찾아가, 저희가 공개한 Kubernetes Gateway API 구현을 살펴봅니다.

F5 NGINX로 대규모 WAF 플릿을 확인하고 관리하는 2가지 방법
NGINX | 2023. 03. 23.

F5 NGINX로 대규모 WAF 플릿을 확인하고 관리하는 2가지 방법

앱 보안을 강화하는 두 가지 방법을 소개합니다. NGINX Management Suite를 통해 WAF 운영에 대한 가시성을 높이고, NGINX App Protect WAF를 활용해 코드형 보안을 구현하는 것입니다.

Ingress 컨트롤러 선택 가이드, 4부: NGINX Ingress Controller 옵션
NGINX | 2021. 09. 27.

Ingress 컨트롤러 선택 가이드, 4부: NGINX Ingress Controller 옵션

개발 주체, 개발 철학, 프로덕션 환경 준비도, 보안 및 지원을 기준으로 어떤 NGINX Ingress 컨트롤러가 가장 적합한지 알아보세요.

진화하는 공격 환경에 NGINX App Protect Denial of Service가 적응하는 방법
NGINX | 2021. 07. 06.

진화하는 공격 환경에 NGINX App Protect Denial of Service가 적응하는 방법

NGINX App Protect Denial of Service(DoS)가 계층 7 DoS 공격을 방어하기 위해 완화 방법을 실시간으로 조정하는 방식을 설명합니다. 정상적인 사용자 행동과 서버 상태에 대한 모델을 생성하여 공격을 나타내는 이상 징후를 감지하고 맞춤형 완화 시그니처를 적용할 수 있습니다.

NGINX Instance Manager를 활용한 대규모 구성 업데이트 및 인증서 관리
NGINX | 2021. 06. 30.

NGINX Instance Manager를 활용한 대규모 구성 업데이트 및 인증서 관리

NGINX Instance Manager 버전 1.0에는 두 가지 새로운 기능이 도입되었습니다. NGINX 인스턴스에 태그와 사용자 역할을 지정하면 전체 그룹에 구성을 한 번에 적용할 수 있습니다. 인증서 검사는 만료 예정인 인증서를 감지하여 서비스 중단을 방지할 수 있도록 인증서를 교체할 수 있게 해줍니다.

Netflix가 자사 CDN의 핵심으로 NGINX를 선택한 이유
NGINX | 2015. 03. 25.

Netflix가 자사 CDN의 핵심으로 NGINX를 선택한 이유

Netflix가 글로벌 콘텐츠 전송 네트워크인 Open Connect의 스트리밍 미디어 기술로 NGINX를 선택한 이유를 NGINX 개발자 Gleb Smirnoff에게서 알아보세요.