NGINX Plus R23リリースのお知らせ

NGINX | 2020年12月08日

NGINX Plus Release 23（R23）の提供開始をお知らせします。NGINX Open SourceをベースとするNGINX Plusは、ソフトウェアロードバランサー、リバースプロキシ、APIゲートウェイの機能を兼ね備えた唯一の製品です。

NGINX Plus R23の新機能は次のとおりです。

gRPCヘルスチェック – リクエストを送信する前に、gRPCサービスがリクエストを処理できるかどうかを能動的にテストすることで、信頼性が大幅に向上します。
非特権インストールのサポート – NGINX Plusは、非特権（非root）ユーザーとしてインストールおよびアップグレードできるようになりました。この正式にサポートされるソリューションは、ゼロトラストセキュリティモデルへの移行が進む傾向に沿ったものです。
OpenID Connect PKCEのサポート – NGINX Plus R23は、OpenID Connect認可コードフローの拡張機能であるProof Key for Code Exchange（PKCE）を実装しています。PKCEは複数の種類の攻撃を防ぎ、パブリッククライアントとの安全なOAuth通信を可能にします。

このリリースではさらに、SSL/TLSのきめ細かな制御、Cookieフラグを設定するネイティブな方法、Streamモジュールでの変数設定が追加されています。NGINX Plusエコシステムのアップデートには、NGINX JavaScriptモジュール向けの新しいBufferモジュールとQuery Stringモジュール、新しいSPNEGO for Kerberos動的モジュール、Prometheus‑njs動的モジュールの機能強化が含まれます。

動作に関する重要な変更

非推奨モジュール – サードパーティ製のCookie-Flagモジュールは非推奨となり、新しいproxy_cookie_flagsディレクティブに置き換えられました。このモジュールはNGINX Plus R26で削除されます。詳細については、「Cookieフラグを設定するネイティブな方法」を参照してください。
新たにサポートされるオペレーティングシステム：
- 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ディレクティブにはtype=grpcパラメーターが含まれており、各アップストリームサーバーのHealthサービスのCheckメソッドを呼び出します。SERVINGと応答するサービスは正常と見なされます。mandatoryパラメーターを指定すると、NGINX Plusの起動時、またはアップストリームグループへの新しいサーバーの追加時に、ヘルスチェックに合格するまでトラフィックが転送されません（指定しない場合、新しいサービスはデフォルトで正常と見なされます）。

各アップストリームサーバーで複数のgRPCサービスが公開されている場合は、次の例のように、依存サービスまたは下位サービスを持つ最も重要なサービスの名前をgrpc_serviceパラメーターの値として指定することで、そのサービスを監視できます。

コード例を読み込み中…

gRPCヘルスチェックプロトコルを実装していないgRPCサービスでも、アップストリームサーバーが少なくともgRPCリクエストに応答しているかどうかをテストできます。この場合、サーバーはエラーステータスコードをCheckメソッドへの応答として返すためです。grpc_health.confの設定では、gRPCプロトコルを実装していないサービスからステータスコード12 (UNIMPLEMENTED)が返されることを想定しています。

バックエンドのコードを変更せずに、gRPCサービスが受信リクエストに応答できるかどうかを確認することもできます。この方法を使用すると、あらゆるgRPCサービスを監視できます。

コード例を読み込み中…

非特権ユーザーによるインストール

以前のリリースでは、NGINX Plusは、必要最小限のプロセスを特権ユーザーrootとして実行していました。たとえば、NGINX Plus Admin Guideのインストール手順では、次のプロセスが作成されます。

$ 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は非特権ユーザーとしてインストールし、実行できます。以下のOSで使用できるインストールスクリプト「ngxunprivinst.sh」をGitHubリポジトリで提供しています。

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リポジトリにあるスクリプトのコードを参照してください。）

スクリプトをダウンロードし、実行可能であることを確認します：

$ chmod +x ngxunprivinst.sh

NGINX Plusの証明書とキー（nginx-repo.crtおよびnginx-repo.key）をローカルディレクトリにコピーします。これらを指定するため、すべての‑cおよび‑kオプションをngxunprivinst.shコマンドに含めます。
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

目的のパッケージを取得します（ここではNGINX Plus R23-1を取得します）。‑pオプションでインストール先ディレクトリを指定します。

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

必要なパッケージをインストールします（ここでは、NGINX PlusとNGINX JavaScript Moduleの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

パスを指定する‑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ディレクティブによって、非特権ユーザーが書き込める場所にエラーログが設定されます。
（任意）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）は、複数の種類の攻撃を防ぎ、パブリッククライアントとのOAuth交換を保護するために、OpenID Connect（OIDC）の認可コードフローに最近追加された拡張機能です。NGINX Plus R23では、この拡張機能をサポートするようにOpenID Connectリファレンス実装を更新しました。PKCEはOAuth 2.1で必須となる予定です。

具体的な変更点は、コードチャレンジ内の「client_secret」を次の2つの新しい値に置き換えることです。

code_challenge
code_verifier

特にモバイルデバイスを狙ったさまざまな攻撃に対処するため、トークン（Access Token、ID Token、Refresh Tokenのいずれの場合も）のチャレンジは、次のように調整されています。

NGINX Plusはcode_verifierを生成し、記憶します。
NGINX Plusは、エンドユーザーをOIDCアイデンティティプロバイダー（IdP）のログインページにリダイレクトして、ログインを促します。リクエストには、code_verifierをハッシュ化したcode_challengeが含まれます。
IdPはユーザーのauth_codeをNGINX Plusに送信します。
共有状態に基づいて、NGINX Plusは生成された「code_verifier」を特定し、IdPのトークンエンドポイントに認可コードをトークンセットと交換するリクエストを送信できます。

PKCEを追加する前は、NGINX PlusとIdPの間で静的なクライアントシークレットを共有すれば十分でした。
更新されたOIDCリファレンス実装では、NGINX PlusはPKCE方式とクライアントシークレット方式の両方の認可コードフローを処理できます。

PKCEを使用した拡張Authorization Codeフローを有効にする設定例を次に示します。

コード例を読み込み中…

新しい変数「$oidc_pkce_enable」は、PKCEフローの切り替えスイッチとして機能します。特定のドメインに対して「1」に設定すると、PKCEフローが使用されます。「0」（デフォルト）に設定すると、PKCEを使用しない認可コードフローが使用されます。

NGINX Plus R23のその他の機能強化

SSL/TLS接続のきめ細かな制御

TLS v1.3では、サーバー間、およびサーバーとクライアント間のエンドツーエンド暗号化により、従来のTLSバージョンよりも強固なセキュリティを実現できます。NGINX Plus R23では、OpenSSLの設定に直接アクセスでき、TLS v1.3をきめ細かく制御できます。

証明書と鍵を使用しないデフォルトHTTPSサーバーの作成

以前のリリースでは、TLSで保護されたHTTPSトラフィック用のデフォルトの「server」ブロックに「ssl_certificate」ディレクティブと「ssl_certificate_key」ディレクティブを含める必要があり、そのため「ダミー」の自己署名証明書と鍵を作成しなければなりませんでした。

次のサンプル設定のように、ssl_reject_handshakeディレクティブを使用すると、証明書と鍵が不要になります。

コード例を読み込み中…

OpenSSLの直接設定

NGINX Plus R23では、OpenSSL 1.0.2以降を使用したNGINX PlusのSSL/TLS処理を、よりきめ細かく制御できます。

この新たなレベルの制御は、次のユースケースで活用できます。

ChaCha暗号 – クライアント（通常はモバイル）が優先リストの最上位にChaCha20を指定すると、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を構成する方法を示します。

コード例を読み込み中…

Cache Managerで使用可能なディスク容量を監視可能

NGINX Plusをキャッシュプロキシとして構成すると、キャッシュマネージャープロセスは、最終アクセス日時が最も古いコンテンツを削除することで、キャッシュサイズがmax_sizeパラメーターでproxy_cache_pathディレクティブに設定された上限を超えないようにします。

NGINX Plus R23では、キャッシュマネージャーが、キャッシュを格納するファイルシステムの空きディスク容量も監視し、空き容量がmin_free（proxy_cache_pathディレクティブの新しいパラメーター）で指定した値を下回ると、コンテンツを削除できます。

つまり、キャッシュが他のプロセスと同じファイルシステムを共有している場合でも、NGINX Plusにより、キャッシュへのデータ格納で意図せずディスク容量を使い切ることを防止できます。

コード例を読み込み中…

Cookieフラグを設定するネイティブ方式

セキュリティが確保されていないCookieは、依然としてリスクの高い攻撃経路です。Mozilla Developer Network（MDN）で説明されているように、意図しない第三者やスクリプトによるCookieへのアクセスを防ぐ方法の1つは、HttpOnlyやSecureなどのフラグをSet-Cookieヘッダーに設定することです。

以前のリリースでは、この目的のために、サードパーティ製のset_cookie_flagディレクティブを提供していました。このディレクティブは、F5のダイナミックモジュールリポジトリで提供されているCookie‑Flagモジュールに実装されています。NGINX Plus R23では、このディレクティブとモジュールに代わるproxy_cookie_flagsディレクティブが導入されました。

非推奨のCookie‑FlagモジュールはNGINX Plus R26で削除されるため、構成内のset_cookie_flagディレクティブを特定し、できるだけ早くproxy_cookie_flagsディレクティブに置き換えることを推奨します。

Cookie保護フラグを設定しないシンプルなバックエンドアプリケーションにプロキシする場合の設定例を次に示します。

コード例を読み込み中…

この例では、アップストリームサーバーが作成し、NGINX Plusがセッションの永続化に使用するHttpOnly、Secure、SameSiteフラグをappcookieセッションCookieに追加して保護します。詳しくは、NGINX Plus Admin Guideをご覧ください。

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ディレクティブでCookieに追加することもできます（httponlyおよびsecureパラメーターはNGINX Plus R6以降でサポートされています）。

コード例を読み込み中…

Streamモジュールでの変数の設定

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 Moduleの機能強化

NGINX JavaScriptモジュール（njs）が0.5.0に更新されました。このバージョンでは、Bufferモジュールが導入されています。これはNode.js Bufferモジュールに相当します。Bufferオブジェクトを使用すると、文字列に依存せず、バイナリデータを容易に扱えます。

このモジュールのその他の主な機能強化として、URLで渡されたキーと値のペアに簡単にアクセスできる「Query String module」と、デバッグ用の行レベルのバックトレース対応があります。

Dynamic Modulesの変更点

新しいSPNEGO for Kerberosモジュール

Support for SPNEGO Kerberos認証のサポートが、NGINX Plusの「動的モジュールリポジトリ」で利用できるようになりました。インストール手順と詳細情報については、「NGINX Plus管理者ガイド」を参照してください。

非推奨となったCookie-Flagsモジュール

上記の「Cookieフラグを設定するネイティブ方式」で詳しく説明しているように、新しい「proxy_cookie_flags」ディレクティブは、set_cookie_flagディレクティブに代わるものです。このディレクティブはサードパーティ製の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と管理APIを備え、充実したサポートを受けられるWebサーバーとして、ぜひお試しください。今すぐ30日間の無料トライアルを開始できます。NGINX Plusがアプリケーションの提供とスケーリングにどのように役立つか、ぜひご確認ください。

注目のブログ記事

クラウドネイティブ技術、プラットフォームエンジニアリング、AIの最新トレンド

F5 NGINX OneによるアプリとAPIデリバリーのライフサイクル全体の管理

モダンアプリケーションデリバリをシンプルに：F5 NGINX Oneの9か月