NGINX Plus R23 の発表
NGINX Plus リリース 23 (R23)が利用可能になったことをお知らせします。 NGINX オープンソースをベースにした 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 モジュール用の新しいバッファーおよびクエリ文字列モジュール、Kerberos 動的モジュール用の新しい SPNEGO、および 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ディレクティブには、各アップストリーム サーバーのHealthサービスのCheckメソッドを呼び出すためのtype=grpcパラメータが含まれています。 SERVINGで応答するサービスは正常であると見なされます。 必須パラメータにより、NGINX Plus が起動したとき、または新しいサーバーがアップストリーム グループに導入されたときに、ヘルス チェックに合格するまでトラフィックが転送されないことが保証されます (それ以外の場合、新しいサービスはデフォルトで正常であると見なされます)。
各アップストリーム サーバーで複数の gRPC サービスが公開されている場合は、次の例のように、 grpc_serviceパラメーターの値としてその名前を指定することにより、最も重要なサービス (依存サービスまたは従属サービスを持つサービス) を監視できます。
gRPC ヘルス チェック プロトコルを実装していない gRPC サービスの場合、上流サーバーが少なくとも gRPC 要求に応答しているかどうかをテストできます。その場合、上流サーバーはCheckメソッドに応答してエラーステータス コードを送信するためです。 grpc_health.confの設定では、gRPCプロトコルを実装していないサービスがステータスコードで応答することを期待しています。 12(未実装) 。
また、バックエンド コードを変更することなく、gRPC サービスが受信リクエストに応答できるかどうかを確認することもできます。 このアプローチを使用して、任意の gRPC サービスを監視できます。
権限のないユーザーによるインストール
以前のリリースでは、NGINX Plus は特権ユーザーrootとして実行される最小限のプロセスで動作していました。 たとえば、 NGINX Plus 管理者ガイドのインストール手順では、次のプロセスが作成されます。
$ ps auxf | grep nginx root ... 9068 888 ? Ss 21:44 0:00 nginx: マスター プロセス nginx nginx ... 9712 3572 ? S 21:44 0:00 \_ nginx: ワーカープロセス示されているように、マスター プロセスはroot権限で実行されています。 他のすべてのプロセス (ワーカーとキャッシュ管理) は、特権のないユーザー アカウントnginxを使用します。
機密データを扱う重要なシステムでは、ユーザーroot を使用しない方がよい場合があります。 この場合、 NGINX Plus R23 は非特権ユーザーとしてインストールおよび実行できます。 以下の OS で使用するために、GitHub リポジトリにインストール スクリプトngxunprivinst.shが用意されています。
- アルパインリナックス
- Amazon Linux、Amazon Linux 2
- CentOS、Red Hat Enterprise Linux
- デビアン、ウブントゥ
注記： 1024 未満のポート (たとえば、80 または 443) に NGINX Plusリスナーが設定されている場合、マスター プロセスにはルート権限が必要です (ただし、権限のないユーザー アカウントで NGINX Plus をインストールすることは可能です)。
インストール スクリプトを使用するには、次のコマンドを実行します。 (利用可能なすべてのngxunprivinst.shコマンドを確認するには、コマンド名パラメータなしでスクリプトを実行するか、GitHub リポジトリでスクリプトのコードを参照してください。)
スクリプトをダウンロードし、実行可能であることを確認します。
$ chmod +x ngxunprivinst.sh- NGINX Plus 証明書とキー ( nginx-repo.crtとnginx-repo.key ) をローカル ディレクトリにコピーします。 すべての
ngxunprivinst.shコマンドには、これらを識別するために‑cおよび‑kオプションが含まれています。 -
NGINX Plus リポジトリで利用可能な NGINX Plus のバージョンを一覧表示します。
$ ./ngxunprivinst.sh リスト -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 フェッチ -c nginx-repo.crt -k nginx-repo.key -p /home/nginxrun -v 23-1-
必要なパッケージをインストールします (ここでは、NGINX Plus と NGINX JavaScript モジュール njs をインストールします)。
nginx-repo.crt をインストールします。 パスを指定するための
‑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 が非
ルートユーザーとして実行されていることを確認するには、次のコマンドを実行します。$ ps auxf | grep nginx nginxrun ... 9068 888 ? Ss 21:55 0:00 nginx: マスター プロセス nginxrun ... 9712 3572 ? S 21:55 0:00 \_ nginx: ワーカープロセス
OpenID Connect PKCE サポート
コード交換用証明キー ( PKCE ) は、さまざまな種類の攻撃を防ぎ、パブリック クライアントとの OAuth 交換を保護するために、OpenID Connect (OIDC) 認証コード フローに最近追加された拡張機能です。 NGINX Plus R23では、拡張機能をサポートするためにOpenID Connect リファレンス実装を更新しました。 OAuth 2.1では PKCE が必須になります。
具体的な変更点は、コード チャレンジでclient_secret を2 つの新しい値に置き換えることです。
コードチャレンジコード検証者
特にモバイル デバイスでのさまざまな攻撃に対処するために、トークン (アクセス トークン、ID トークン、またはリフレッシュ トークン) のチャレンジが次のように調整されました。
- NGINX Plus は
code_verifierを生成（および記憶）します。 - NGINX Plus は、エンドユーザーを OIDC アイデンティティ プロバイダー (IdP) ログイン ページにログインするようにリダイレクトします。 リクエストには、
code_challengeと呼ばれるcode_verifierのハッシュバージョンが含まれます。 - IdP はユーザーの
auth_code をNGINX Plus に送信します。 - 共有状態に基づいて、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 トラフィックのデフォルトのサーバーブロックにssl_certificateおよびssl_certificate_keyディレクティブを含める必要があり、「ダミー」の自己署名証明書とキーを作成する必要がありました。
ssl_reject_handshakeディレクティブは、次のサンプル構成のように、証明書とキーの必要性を排除します。
直接 OpenSSL 設定
NGINX Plus R23 では、OpenSSL 1.0.2 以降で NGINX Plus が 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
- HTTP と TCP –
次の例は、古い TLS バージョンを使用しているクライアントからのリクエストを、TLS v1.3 をサポートしていることがわかっているバックエンド サーバーを使用するようにアップグレードするように NGINX Plus を構成する方法を示しています。
キャッシュマネージャは利用可能なディスク容量を監視できる
NGINX Plus がキャッシュ プロキシとして設定されている場合、キャッシュ マネージャープロセスは、最も最近アクセスされていないコンテンツを削除することで、キャッシュ サイズがproxy_cache_pathディレクティブのmax_sizeパラメーターで設定された制限を超えないことを保証します。
NGINX Plus R23では、キャッシュ マネージャーはキャッシュを格納するファイルシステム上の使用可能なディスク容量を監視し、使用可能な容量がproxy_cache_pathディレクティブの新しいmin_freeパラメータよりも少ない場合にコンテンツを削除することもできます。
つまり、キャッシュが他のプロセスと同じファイルシステムを共有している場合でも、NGINX Plus はキャッシュへのデータの取り込みによってディスクが誤っていっぱいにならないようにします。
クッキーフラグを設定するためのネイティブメソッド
保護されていない Cookie は、依然として高リスクの攻撃ベクトルとなります。 Mozilla Developer Network (MDN) で述べられているように、意図しない第三者やスクリプトによって Cookie がアクセスされないようにする 1 つの方法は、 Set-CookieヘッダーにHttpOnlyやSecureなどのフラグを設定することです。
以前のリリースでは、この目的のためにset_cookie_flagディレクティブを提供していました。これは、動的モジュール リポジトリで利用可能なサードパーティのCookie-Flag モジュールに実装されています。 NGINX Plus R23 では、そのディレクティブとモジュールを置き換えるproxy_cookie_flagsディレクティブが導入されています。
非推奨の Cookie‑Flag モジュールはNGINX Plus R26で削除される予定なので、設定内のset_cookie_flagディレクティブを見つけて、できるだけ早くproxy_cookie_flagsディレクティブに置き換えることをお勧めします。
以下は、Cookie 保護フラグを一切設定しない単純なバックエンド アプリケーションにプロキシするためのサンプル構成です。
この例では、NGINX Plus 管理者ガイドで説明されているように、NGINX Plus がセッションの永続性に使用するアップストリーム サーバーによって作成されたappcookieセッション Cookie を保護するために、 HttpOnly 、 Secure 、 SameSiteフラグを追加しています。
curlコマンドまたはブラウザの開発者ツールを使用すると、 appcookieにHttpOnly 、 Secure 、 SameSiteフラグが設定されていることがわかります。
< HTTP/1.1 200 OK< サーバー: nginx/1.19.4
< 日付: 2020 年 12 月 8 日（木）14:46:12 GMT
< コンテンツ タイプ: application/octet-stream
< コンテンツの長さ: 9
< 接続: キープアライブ
< Set-Cookie: appcookie=appserver1; Secure; HttpOnly; SameSite=Strict
< コンテンツ タイプ: text/htmlNGINX Plus R23では、次の例のように、 stickyディレクティブを使用して、Cookie にSameSiteフラグを追加することもできます ( 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 。 このバージョンでは、 Node.js の Buffer モジュールに類似したBuffer モジュールが導入されています。 バッファ オブジェクトを使用すると、文字列に頼るのではなく、バイナリ データを簡単に操作できます。
モジュールのその他の注目すべき機能強化としては、URL で渡されるキーと値のペアに簡単にアクセスできるクエリ文字列モジュールと、デバッグのための行レベルのバックトレースのサポートがあります。
動的モジュールの変更
Kerberos モジュール用の新しい SPNEGO
SPNEGO Kerberos 認証のサポートが、NGINX Plus動的モジュール リポジトリで利用できるようになりました。 インストール手順と詳細情報については、 NGINX Plus 管理者ガイドを参照してください。
廃止された Cookie-Flags モジュール
上記のCookie フラグを設定するためのネイティブメソッドで詳しく説明されているように、新しい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 構成ファイルを更新することが重要です。
js_includeディレクティブは非推奨となり、js_importディレクティブに置き換えられました。js_contentおよびjs_setディレクティブはモジュール関数を参照できる
注目すべきバグ修正
変数が空でないことをテストするためにmatchブロックでrequireディレクティブを使用したヘルス チェックでは、応答がproxy_buffer_sizeディレクティブの値よりも大きい場合、異常なアップストリーム サーバーを検出できない可能性があります。
NGINX Plus をアップグレードまたは試用する
NGINX Plus を実行している場合は、できるだけ早くNGINX Plus R23にアップグレードすることを強くお勧めします。 また、いくつかの追加の修正と改善も行われ、サポート チケットを発行する必要があるときに NGINX がサポートしやすくなります。
NGINX Plus をまだお試しいただいていない方は、セキュリティ、負荷分散、API ゲートウェイとして、または強化された監視および管理 API を備えた完全にサポートされた Web サーバーとして、ぜひお試しください。 30 日間の無料トライアルを今すぐ開始できます。 NGINX Plus がアプリケーションの配信と拡張にどのように役立つかを実際にご確認ください。
「このブログ投稿には、入手できなくなった製品やサポートされなくなった製品が参照されている場合があります。 利用可能な F5 NGINX 製品およびソリューションに関する最新情報については、 NGINX 製品ファミリーをご覧ください。 NGINX は現在 F5 の一部です。 以前の NGINX.com リンクはすべて、F5.com の同様の NGINX コンテンツにリダイレクトされます。"