NGINX Plus R14を発表

NGINX | 2017年12月12日

NGINX Plus Release 14（R14）がNGINX Plusサブスクライバー向けに提供開始されたことをお知らせします。NGINX Plusは、ロードバランサー、コンテンツキャッシュ、Webサーバーを一体化した唯一の製品です。NGINX Open Sourceをベースに、独自機能と受賞歴のある24時間サポートを追加しています。NGINX Plus R14には、セキュリティとクラスタリングに関する新たな機能強化が含まれています。

NGINX Plusでは、JSON Web Token（JWT）を使用してアクセス制御を適用できます。NGINX Plus R14では、ネストされたJWTクレームのサポートが追加され、JWT内にネストされたグループメンバーシップ情報に基づいてアクセスを許可または拒否できます。ネイティブJWT認証のサポートは、NGINX Plus R10で初めて導入され、NGINX PlusをAPIやアプリケーションの認証ゲートウェイとして使用できるようになりました。

NGINX Plus R14のその他の機能：

クラスタリングサポートの拡張（テクノロジープレビュー） – クラスタ内のNGINX Plusインスタンス間で状態情報を共有する新機能のプレビューをぜひお試しください。このプレビューでは、sticky learnセッション永続化方式の状態が共有されます。今後のリリースでは、クラスタリングサポートをNGINX Plusの他の機能にも拡張する予定です。
より長いJWTキーサイズ – ネストされたJWTクレームと配列データのサポートに加え、JWT署名アルゴリズムで、より長いキーサイズ（最大512ビット）がサポートされるようになりました。これにより、JWTの検証時のセキュリティと柔軟性が向上します。
ストリームのキー／値ストアとAPI – Release 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で非推奨となりました。これらは新しいNGINX Plus APIに置き換えられています。このAPIは、R14に含まれる更新版のライブアクティビティ監視ダッシュボードで使用されます。
NGINX PlusがUbuntu 17.10（Artful Aardvark）で利用できるようになりました。
NGINX PlusはDebian 7（Wheezy）でサポートされなくなりました。

NGINX Plus R14の機能詳細

JWTの機能強化

APIやマイクロサービスの導入担当者は、そのシンプルさと柔軟性から、JSON Web Token（JWT、「ジョット」と発音）標準を採用するようになっています。JWTは、ID情報を交換するためのコンパクトで可搬性の高い手段です。JWTは、Okta、OneLogin、独自開発のソリューションなど、さまざまな発行元から取得できます。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は配列です。次の設定スニペットを使用すると、nameの値をattributesオブジェクトからバックエンドに渡し、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ディレクティブを使用して、NGINX変数$jwt_groupsに、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ディレクティブを使用して、NGINX変数$jwt_real_nameに、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」）

たとえば、RS512アルゴリズムで署名されたJSON Web Tokenのみを受け入れるようにNGINX Plus R14を設定できます。

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でのみサポートされます。

Streamモジュール向けKey-ValueストアとAPI

NGINX Plus R13では、HTTP向けKey-Value Storeモジュールが導入され、1つ以上の共有メモリゾーン内でキーと値のペアを動的に作成、変更、削除できるようになりました。Key-Value Store APIの優れたユースケースの1つは、fail2banと組み合わせて動的なIP拒否リストを作成することです。

NGINX Plus R14では、Stream向けKey‑Value Storeモジュールが追加され、HTTPアプリと同じキーと値のペアの機能をTCPおよびUDPアプリケーションでも利用できるようになりました。

Dynamically reconfiguring the key‑value store in the 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のネイティブオブジェクトとして利用できるようになりました。これにより、複雑なデータ構造をより簡単に管理できるほか、バックエンドAPIから受信したJSONレスポンスをNGINX JavaScriptで解析、操作できます。

次の「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
>>

エラーオブジェクトとバックトレース

開発者によるデバッグとトラブルシューティングをさらに支援するため、さまざまなエラーオブジェクトが利用できるようになりました。

Error
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は非推奨となりました。これらの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;
}

スニペットに示すように、たとえばallowディレクティブとdenyディレクティブを使用して、APIへのアクセスを制限することを強く推奨します。既存のアクセス制御は、必ず/statusロケーションから/apiロケーションに移行してください。

新しいNGINX Plus APIの詳細については、「NGINX Plus R13の発表」をご覧ください。

注記：組み込みダッシュボードはNGINX Plus専用です。

設定ファイルでアップストリームサーバーをドレイン状態にする

サーバーをオフラインにする際、新しいセッションの確立を防ぎながら既存のセッションを完了させることで、ユーザーエクスペリエンスを向上できます。アクティブなセッションがなくなるまで、サーバーはオフラインになりません。この処理をサーバーの「ドレイン」と呼びます。NGINX Plus APIを使用し、対象サーバーのAPIリソースに「PATCH」リクエストを送信して、そのリクエストに「{"drain":true}」を含めることで、動的に実行できます。

NGINX Plus R14では、アップストリームのdrainserverディレクティブにパラメーターを追加することで、この機能をファイルベースの設定にも拡張しています。

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の営業担当者までお問い合わせください。

注記：

sticky learnクラスタリング機能はプレビュー段階にあるため、本番環境での使用には適していません。クラスタ全体での状態共有がお使いの環境にとって重要な要件である場合は、このテクノロジープレビューをテストし、ニーズをどの程度満たしているかについてNGINXにフィードバックをお寄せください。
テクノロジープレビュー版のパッケージは、CentOS/RHEL/Oracle Linux 7、Debian 8および9、Ubuntu 16.04、16.10、17.10向けに提供されています。

注記：クラスタリングのサポートとsticky‑learnセッション永続化は、いずれもNGINX Plusでのみ利用できます。

その他の機能

NGINX Plus R14には、以下の機能強化も含まれています。

リロード後もリゾルバーの状態を維持 – アップストリームグループ内のサーバーセットを動的に再構成する方法の1つは、ホスト名またはドメインをserverディレクティブのパラメーターとして使用することです。DNSは名前を定期的に解決し、NGINX Plusは更新されたサーバーセットを自動的に使用します（NGINX Plus Admin Guideを参照）。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をご利用の場合は、できるだけ早くRelease 14へアップグレードすることを強く推奨します。アップグレードにより、さまざまな修正や改善が適用されるほか、サポートチケットを起票する必要が生じた際に、NGINXがより円滑にサポートできるようになります。インストールおよびアップグレードの手順については、カスタマーポータルをご覧ください。

アップグレードを実行する前に、このブログ記事で説明している新機能と動作の変更点をよくご確認ください。

まだNGINX Plusをお試しでない場合は、ぜひご利用ください。Webアクセラレーション、負荷分散、アプリケーションデリバリに加え、強化された監視・管理APIを備えた、フルサポートのWebサーバーとしても活用できます。今すぐ無料の30日間評価版をお試しいただけます。NGINX Plusがアプリケーションの提供とスケーリングにどのように役立つか、ぜひご確認ください。