NGINX Plus リリース 29 (R29) が利用可能になったことをお知らせいたします。 NGINX オープンソースをベースにした NGINX Plus は、唯一のオールインワン ソフトウェア Web サーバー、ロード バランサー、リバース プロキシ、コンテンツ キャッシュ、API ゲートウェイです。
NGINX Plus R29 の新機能と強化された機能は次のとおりです。
注記: NGINX Plus R28 以外のリリースからアップグレードする場合は、現在のバージョンとこのバージョン間のすべてのリリースについて、以前の発表ブログの「動作の重要な変更」セクションを必ず確認してください。
古いパッケージ リポジトリplus-pkgs.nginx.comは、NGINX Plus R29 のリリースとともに直ちに廃止されます。 このリポジトリは NGINX Plus R25 以降更新されていないため、 NGINX Plus R24 で導入されたpkgs.nginx.comパッケージ リポジトリを使用することを強くお勧めします。
サポートされる新しいオペレーティング システム:
削除された古いオペレーティング システム:
NGINX Plus R30 で非推奨となり削除が予定されている古いオペレーティング システム:
ModSecurity EOL 発表に沿って、NGINX Plus R29 では ModSecurity パッケージのサポートが削除されます。 ModSecurity パッケージを使用している NGINX Plus の顧客の場合、まもなく ModSecurity とNGINX App Protect間のトレードイン プログラムに参加できるようになります。 詳細は近日中に公開される予定ですので、詳細については F5 の担当者にお問い合わせください。
MQTT (Message Queuing Telemetry Transport) は、インターネット経由で IoT デバイスとアプリケーション (クライアント) を接続するのに最適な、人気の高い軽量のパブリッシュ/サブスクライブ メッセージング プロトコルです。 これにより、クライアントは特定のトピックにメッセージを公開し、他のトピックをサブスクライブできるようになります。 サブスクライブしたクライアントは、そのトピックに公開されたすべてのメッセージを受信し、多くのデバイスとサービス間で効率的かつフォールト トレラントなデータ交換を可能にします。
MQTT アーキテクチャの中心となるのはブローカーです。 ブローカーは、クライアントとクライアントがサブスクライブしているトピックを追跡し、メッセージを処理し、それらのメッセージを適切なシステムにルーティングする役割を担うサーバーです。 NGINX Plus R29 はMQTT 3.1.1とMQTT 5.0をサポートしています。 これはクライアントとブローカー間のプロキシとして機能し、システム アーキテクチャを簡素化し、タスクの負荷を軽減し、コストを削減します。
初期の MQTT 機能セットにより、次のことが可能になります。
MQTT プロトコルは、CONNECT、PUBLISH、SUBSCRIBE など、いくつかのメッセージ タイプを定義します。 NGINX Plus R29 は、MQTT CONNECT メッセージの一部をアクティブに解析および書き換えることができるため、これまではカスタム スクリプトでのみ可能だった構成シナリオが可能になります。
MQTTメッセージの解析と書き換えは、NGINX構成ファイルのストリームコンテキストで定義する必要があり、 ngx_stream_mqtt_preread_module
で可能になります。
およびngx_stream_mqtt_filter_module
モジュール。
MQTTの例
MQTT デバイスから送信されるデフォルトのクライアント識別子を変更すると、NGINX はデバイスのシリアル番号などの機密情報を非表示にすることができます。 この最初の例では、識別子がデバイスの IP アドレスに書き換えられます。
注記: 実稼働環境では、デバイスの IP アドレスを MQTT クライアント識別子として使用することは推奨されません。
ストリーム { mqtt オン;
サーバー { listen 1883; proxy_pass 10.0.0.8:1883; mqtt_set_connect clientid '$remote_addr'; } }
MQTT クライアントの一時的な性質を考えると、負荷分散されたブローカーへのスティッキー セッションを確立するためにデバイスのホスト名または IP アドレスに単純に依存することはできません。 この例では、デバイスの MQTT クライアント識別子は、負荷分散されたクラスター内の個々の MQTT ブローカーへの接続を維持するためのハッシュ キーとして機能します。
ストリーム { mqtt_preread オン;
アップストリームブローカー{ゾーン tcp_mem 64k; ハッシュ $mqtt_preread_clientid 一貫性あり;
サーバー 10.0.0.7:1883; # MQTT ブローカー 1 サーバー 10.0.0.8:1883; # MQTT ブローカー 2 サーバー 10.0.0.9:1883; # MQTT ブローカー 3 }
サーバー { listen 1883; proxy_pass ブローカー; proxy_connect_timeout 1s; } }
NGINX Plus の MQTT の今後の開発には、他の MQTT メッセージ タイプの解析や、次のような機能を実現するための CONNECT メッセージのより深い解析が含まれる可能性があります。
お客様にとって最も重要な機能についてのフィードバックをお待ちしております。 コメント欄であなたの考えをお聞かせください。
SAML (Security Assertion Markup Language) は、アイデンティティ プロバイダー (IdP) がリソースへのアクセスについてユーザーを認証し (エンド ユーザーが実際に本人であることを確認)、その認証情報とそのリソースに対するユーザーのアクセス権をサービス プロバイダー (SP) に渡して承認を受けられるようにするオープン フェデレーション標準です。
SAML は、ID データを交換するための安全な手段を提供してきた長い実績があり、IdP と SP 間で認証および承認情報を交換するために広く採用されているプロトコルです。
企業や政府機関が SAML を採用する主な理由は次のとおりです。
SAML には、次のようないくつかの利点もあります。
SAML の現在のリファレンス実装はSAML 2.0を使用し、 NGINX JavaScript (njs) フレームワークを使用して構築されています。 この実装では、NGINX Plus は SAML SP として機能し、SAML IdP を使用した SSO セットアップに参加できるようになります。 現在の実装は、既存の NGINX Plus 機能であるキー値ストアにも依存しており、追加の変更を加えなければ NGINX Open Source には適していません。
NGINX Plus の SAML サポートは、GitHub のリファレンス実装として利用できます。 GitHub リポジトリには、特定のユースケース向けのインストール、構成、微調整の手順が記載されたサンプル構成が含まれています。
OpenTelemetry (OTel) は、アプリケーションの監視、トレース、トラブルシューティング、最適化に使用できるテクノロジーと標準です。 OTel は、プロキシ、アプリケーション、または展開されたアプリケーション スタック内のその他のサービスなど、さまざまなソースからテレメトリ データを収集することによって機能します。
プロトコル対応のリバース プロキシおよびロード バランサーとして、NGINX は、アプリケーションの要求と応答をトレースするためのテレメトリ呼び出しを開始するのに最適です。 サードパーティの OTel モジュールは以前から利用可能でしたが、新しい動的モジュールにより、NGINX Plus で OTel がネイティブにサポートされることを発表できることを嬉しく思います。
新しいモジュールngx_otel_module は
、 nginx-plus-module-otel
パッケージを使用してインストールでき、サードパーティ モジュールに次のようないくつかの重要な改善を提供します。
OTel 動的モジュールの詳細については、 NGINX ドキュメントを参照してください。
OTel トレースの例
以下は、NGINX によって直接提供されるアプリケーションの基本的な OTel トレースの例です。
モジュールモジュール/ngx_otel_module.soをロードします。
イベント {}
http { otel_exporter { エンドポイント localhost:4317; }
サーバー{ listen 127.0.0.1:8080;
otel_trace オン; otel_span_name app1; } }
次の例では、受信リクエストからトレース コンテキストを継承し、親スパンがサンプリングされた場合にのみスパンを記録します。 また、トレース コンテキストとサンプリング決定を上流サーバーに伝播します。
モジュールモジュール/ngx_otel_module.soをロードします。
http { server { location / { otel_trace $otel_parent_sampled; otel_trace_context propagate; proxy_pass http://backend; } } }
この比率ベースの例では、トレースはトラフィックのパーセンテージ (この場合は 10%) に対して構成されています。
http { # リクエストの10%をトレースする split_clients "$otel_trace_id" $ratio_sampler { 10% on; * off; }
# または、ユーザーセッションの10%を追跡できます
split_clients "$cookie_sessionid" $session_sampler { 10% オン; * オフ; }
サーバー { 場所 / { otel_trace $ratio_sampler; otel_trace_context inject;
proxy_pass http://backend; } } }
この API 制御の例では、/api エンドポイントを介してキー値ストアを操作することでトレースが有効になります。
http { keyval "otel.trace" $trace_switch ゾーン=名前;
サーバー { 場所 / { otel_trace $trace_switch; otel_trace_context inject; proxy_pass http://backend; }
場所 /api { api write=on; } } }
NGINX Open Source のプレビュー バイナリ パッケージの発表に続き、NGINX Plus R29 の実験的な QUIC パッケージを発表できることを嬉しく思います。 これにより、NGINX Plus を使用して HTTP/3 をテストおよび評価できるようになります。
新しい基盤プロトコル スタックにより、HTTP/3 は UDP と QUIC をトランスポート層に導入します。 QUIC は、接続の多重化を提供し、ヘッドオブライン ブロッキングなどの問題を解決することで TCP を改善するように設計された暗号化トランスポート プロトコルです。 接続の確立、輻輳制御、信頼性の高い配信など、HTTP/1.1 および HTTP/2 の多数の TCP 機能を再実装および強化します。 QUIC は、TLS を別個のレイヤーとして持つ HTTP/1.1 および HTTP/2 とは異なり、TLS を不可欠なコンポーネントとして組み込んでいます。 つまり、HTTP/3 メッセージはデフォルトで暗号化された接続を介して送信されるため、本質的に安全です。
通常、安全な通信と暗号化機能のために、NGINX Plus はOpenSSLに依存し、オペレーティング システムに付属の SSL/TLS ライブラリを使用します。 ただし、この記事の執筆時点では QUIC の TLS インターフェースは OpenSSL でサポートされていないため、HTTP/3 に必要な TLS 機能が不足している場合は、サードパーティのライブラリが必要になります。
この懸念に対処するために、QUIC 用の OpenSSL 互換性レイヤーを開発し、quictls、BoringSSL、LibreSSL などのサードパーティの TLS ライブラリを構築して出荷する必要がなくなりました。 これにより、カスタム TLS 実装の負担やサードパーティ ライブラリのスケジュールやロードマップへの依存なしに、NGINX でエンドツーエンドの QUIC+HTTP/3 エクスペリエンスを管理できるようになります。
注記: OpenSSL 互換性レイヤーは、実験的な NGINX Plus QUIC+HTTP/3 パッケージに含まれており、 TLSv1.3 (QUIC プロトコルで必要) を提供するには OpenSSL 1.1.1 以上が必要です。 0-RTT はまだ実装されていません。
QUIC+HTTP/3 サンプル設定
NGINX Plus での QUIC+HTTP/3 のサンプル構成を見てみましょう。
http { log_format quic '$remote_addr - $remote_user [$time_local]' '"$request" $status $body_bytes_sent ' '"$http_referer" "$http_user_agent" "$http3"';
access_log ログ/access.log quic;
server { # 互換性を高めるために、quic と https に同じポートを使用することをお勧めします listen 8443 quic reuseport; listen 8443 ssl;
ssl_certificate certs/example.com.crt; ssl_certificate_key certs/example.com.key;
location / { # ブラウザが quic ポートに誘導するために必要 add_header Alt-Svc 'h3=":8443"; ma=86400'; } } }
HTTP/2 の実装と同様に、NGINX Plus がプロキシとして機能する場合、クライアント側で QUIC+HTTP/3 接続が行われ、バックエンドおよびアップストリーム サービスに接続するときに HTTP/1.1 に変換されます。
NGINX Plus QUIC+HTTP/3 実験パッケージは、既存の NGINX Plus 証明書とキーを使用してアクセスできる別のリポジトリから入手できます。 実験的な QUIC パッケージのインストールは、標準のNGINX Plus のインストールと同様です。 インストール手順で強調されているように、必ず QUIC リポジトリを使用してください。
QUIC+HTTP/3 用に NGINX を構成する方法の詳細については、「QUIC+HTTP/3 用に NGINX を構成する」を参照してください。 すべての新しいディレクティブと変数の詳細については、 nginx-quic READMEの「構成」セクションを参照してください。
次のステップ
近い将来、QUIC+HTTP/3 コードを NGINX メインライン ブランチにマージする予定です。 QUIC + HTTP/3 をサポートする最新バージョンの NGINX メインラインは、次の NGINX Plus リリースに統合されます。 今年後半には、NGINX Plus での QUIC+HTTP/3 サポートの正式な提供開始に関する発表が予定されています。
OpenID Connect (OIDC) サポートは NGINX Plus R15 で導入され、その後のバージョンで大幅に強化されました。 NGINX Plus R29 では、以下の追加により OIDC が引き続き強化されています。
アクセストークンのサポート
アクセス トークンは、トークンベースの認証で使用され、OIDC クライアントがユーザーに代わって保護されたリソースにアクセスできるようにします。 NGINX Plus は、ユーザーが正常に認証してアクセスを承認した後、アクセス トークンを受信し、それをキー値ストアに保存します。 NGINX Plus は、ダウンストリーム アプリケーションに送信されるすべてのリクエストに対して、HTTP Authorization ヘッダーでそのトークンをBearer Tokenとして渡すことができます。
注記: NGINX Plus は、各リクエストでアクセス トークンの有効性を検証しません (ID トークンの場合のように)。そのため、アクセス トークンの有効期限が切れているかどうかを知ることはできません。 アクセス トークンの有効期間が ID トークンの有効期間よりも短い場合は、 proxy_intercept_errors
on ディレクティブを使用する必要があります。 これにより、 401 Unauthorized
応答がインターセプトされ、NGINX にリダイレクトされ、アクセス トークンが更新されます。
NGINX Plus を使用した OpenID Connect および JSON Web Token (JWT) 検証の詳細については、 「OpenID Connect と NGINX Plus を使用した既存のアプリケーションへのユーザーの認証」を参照してください。
OIDC認証エンドポイントに追加された引数
Keycloakなどの一部の ID プロバイダーでは、認証リクエストに追加のクエリ文字列引数を追加して、追加機能を有効にすることができます。 たとえば、Keycloak では、認証リクエストにkc_idp_hint
パラメーターを追加することで、デフォルトの IdP を指定できます。 この機能強化の一環として、ユーザーは OIDC 認証エンドポイントに追加の引数を指定できます。
NGINX Plus R28 では、クライアント側とサーバー側の接続の HTTP モジュールと Stream モジュールの両方で、ハンドシェイク エラーと証明書検証の失敗に対するSSL カウンター サポートが追加されました。 NGINX Plus メトリックを Prometheus 準拠の形式に変換するPrometheus-njsモジュールが、これらのカウンターをサポートするようになりました。
internal_redirect
ディレクティブ 新しいinternal_redirect
ディレクティブとモジュールにより、リクエスト処理制限、接続処理制限、アクセス制限をチェックした後、内部リダイレクトが可能になります。
以下はinternal_redirect
設定の例です。
http { limit_req_zone $jwt_claim_sub ゾーン=jwt_sub:10m レート=1r/s;
サーバー { 場所 / { auth_jwt "realm"; auth_jwt_key_file key.jwk;
内部リダイレクト @rate_limited; }
場所 @rate_limited { 内部; limit_req zone=jwt_sub バースト=10;
proxy_pass http://backend ; } } }
上記の例では、ロケーション ブロックで JWT 認証が実行され、トークンが有効な場合、リクエストは内部コンテンツ ハンドラー @rate_limited に渡され、サブ クレーム値に基づいてリクエスト レート制限が適用されます。 これは、リクエストがアップストリーム サービスに渡される前に JWT で発生します。
この特定の構成により、攻撃者が特定のユーザーをサブフィールドとしてエンコードした読み取り可能な JWT を含む大量のリクエストを送信するサービス拒否 (DoS) 攻撃を防止できます。 この大量のリクエストは認証に合格しませんが、レート制限にカウントされます。 リクエストをコンテンツ ハンドラーに渡す前に JWT を認証することで、有効なリクエストのみがレート制限にカウントされるようになります。
NGINX Plus R29 は NGINX Open Source 1.23.4 をベースとしており、NGINX Plus R28 のリリース以降 (NGINX 1.23.3 から 1.23.4) に行われた機能変更とバグ修正を継承しています。
変更点
ssl_protocols
( HTTP 、ストリーム、メール) proxy_ssl_protocols
( HTTP 、ストリーム) grpc_ssl_プロトコル
uwsgi_ssl_プロトコル
ゾーン同期SSLプロトコル
特徴
ngx_http_gzip_static_module
でバイト範囲がサポートされるようになりました。バグ修正
ngx_http_autoindex_module
、 ngx_http_dav_module
、 include ディレクティブでサポートされていなかった Windows のファイル名の非 ASCII 文字を修正しました。error_page
ディレクティブを使用してコードでエラーをリダイレクトするときに時々発生するソケットリークを修正しました。400
。syslog
へのログ記録中にエラーが発生したという情報が含まれていない、 syslog
へのログ記録エラーに関するメッセージを修正しました。回避策
zlib-ng
の使用時に、 zip フィルターが事前に割り当てられたメモリを使用できなかったという
アラートがログに表示されました。 listen
ディレクティブで使用されるホスト名が複数のアドレスに解決される場合、NGINX はこれらのアドレス内の重複を無視するようになりました。これらのリリースから継承された新機能、変更、バグ修正、および回避策の完全なリストについては、 CHANGESファイルを参照してください。
NGINX Plus R29 には、NGINX JavaScript (njs) モジュール バージョン 0.7.9 から 0.7.12 までの変更が組み込まれています。 njs には次のようないくつかの魅力的な機能が追加されました:
njs バージョン 0.7.9 から 0.7.12 までのすべての機能、変更、バグ修正の包括的なリストについては、 njs 変更ログを参照してください。
Headers()
、 Request()
、 Response()
コンストラクターが、その他の機能強化とともに Fetch API に追加されました。
非同期関数 makeRequest(uri, headers) { let h = new Headers(headers);
h.delete("bar");
h.append("foo", "xxx");
let r = new Request(uri, {headers: h});
return await ngx.fetch(r);
}
Web Crypto API は JSON Web Key (JWK) 形式をサポートするように拡張され、importKey() は入力として JWK 形式のキーを受け取るようになりました。
非同期関数 importSigningJWK(jwk) { return await crypto.subtle.importKey('jwk', jwk,
{name: "RSASSA-PKCS1-v1_5"},
true、['sign']);
}
njs 0.7.10 では、 generateKey() メソッド
とexportKey()
メソッドも追加されました。 generateKey()
メソッドを使用すると、対称アルゴリズム用の新しいキーまたは公開キー アルゴリズム用のキー ペアを生成できます。 exportKey()
メソッドは、 CryptoKey
オブジェクトを入力として受け取り、外部の移植可能な形式でキーを返します。 キーを JSON オブジェクトとしてエクスポートするための JWK 形式をサポートしています。
詳細については、 Web Crypto APIを参照してください。
XML モジュールは、XML ドキュメントを操作するためのネイティブ サポートを提供するために、njs 0.7.10 で追加されました。
XML ドキュメントの文字列またはバッファを解析できるようになりました。解析された XML ドキュメントを表すXMLDocラッパー オブジェクトが返されます。
const xml = require("xml"); let data = `<note><to b="bar" a= "foo">Tove</to><from>Jani</from></note>`;
let doc = xml.parse(data);
console.log(doc.note.to.$text) /* 'Tove' */
console.log(doc.note.to.$attr$b) /* 'bar' */
console.log(doc.note.$tags[1].$text) /* 'Jani' */
XML文書を変更するためのXMLNode API
XMLNode API は、XML ドキュメントを変更するために njs 0.7.11 で追加されました。
Const xml = require("xml"); let data = `<note><to b="bar" a="foo">Tove</to><from>Jani</from></note>`;
let doc = xml.parse(data);
doc.$root.to.$attr$b = 'bar2';
doc.$root.to.setAttribute('c', 'baz');
doc.$root.to.$attr$a を削除します。
console.log(xml.serializeToString(doc.$root.to))
/* '<to b="bar2" c="baz">Tove</to>' */
doc.$root.to.removeAllAttributes();
doc.$root.from.$text = 'Jani2';
console.log(xml.serializeToString(doc))
/* '<note><to>Tove</to><from>Jani2</from></note>' */
doc.$root.to.$tags = [xml.parse(`<a/>`), xml.parse(`<b/>`)];
doc.$root.to.addChild(xml.parse(`<a/>`));
console.log(xml.serializeToString(doc.$root.to))
/* '<to><a></a><b></b><a></a></to>' */
doc.$root.to.removeChildren('a');
console.log(xml.serializeToString(doc.$root.to))
/* '<to><b></b></to>' */
XML 関連のすべての機能強化の詳細については、 XML ドキュメントを参照してください。
zlib モジュールは njs 0.7.12 で追加され、deflate および inflate アルゴリズムを使用した圧縮機能を提供します。
定数 zlib = require('zlib'); zlib.deflateRawSync('αβγ').toString('base64') /* "O7fx3KzzmwE=" */
zlib.inflateRawSync(Buffer.from('O7fx3KzzmwE=', 'base64')).toString() /* "αβγ" */
zlib の詳細については、 zlib ドキュメントを参照してください。
NGINX Plus を実行している場合は、できるだけ早く NGINX Plus R29 にアップグレードすることを強くお勧めします。 素晴らしい新機能に加えて、いくつかの追加の修正と改善も得られます。最新の状態にしておくと、サポート チケットを発行する必要がある場合に NGINX がサポートしやすくなります。
NGINX Plus をまだお試しいただいていない方は、セキュリティ、負荷分散、API ゲートウェイとして、または強化された監視および管理 API を備えた完全にサポートされた Web サーバーとして、ぜひお試しください。 今すぐ30 日間の無料トライアルを始めましょう。
「このブログ投稿には、入手できなくなった製品やサポートされなくなった製品が参照されている場合があります。 利用可能な F5 NGINX 製品およびソリューションに関する最新情報については、 NGINX 製品ファミリーをご覧ください。 NGINX は現在 F5 の一部です。 以前の NGINX.com リンクはすべて、F5.com の同様の NGINX コンテンツにリダイレクトされます。"