NGINX Plus R23 正式发布

NGINX | 2020年12月08日

我们很高兴地宣布，NGINX Plus Release 23 (R23)现已发布。NGINX Plus基于NGINX Open Source，是一款集软件负载均衡器、反向代理和API网关于一体的产品。

NGINX Plus R23 的新功能包括：

gRPC健康检查：在发送请求前主动测试gRPC服务能否处理请求，可显著提高可靠性。
非特权安装支持：现在可以由非特权（非root）用户安装和升级NGINX Plus。这一获得全面支持的解决方案顺应了日益普及的零信任安全模型趋势。
OpenID Connect PKCE支持：NGINX Plus R23实现了OpenID Connect授权码流程的代码交换证明（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；从NGINX Plus R17开始支持x86_64）
已移除或即将移除的旧版操作系统：
- 不再支持Alpine 3.9；目前支持的最早版本为3.10
- 不再支持CentOS/Oracle Linux/RHEL 6.5及更高版本；支持的最低版本为7.4
- 不再支持Ubuntu 19.10
- NGINX Plus R24 将移除对 Debian 9 的支持

新功能详解

gRPC健康检查

部署为负载均衡器后，NGINX Plus可通过执行主动健康检查来监控后端（上游）服务器的运行状况。NGINX Plus R23支持gRPC健康检查协议，可准确测试后端gRPC服务器能否处理新请求。这在动态和容器化环境中尤其有用。启动gRPC服务的新实例时，务必等到服务“完全启动”后再发送请求。因此，健康检查不能仅查看TCP端口或验证HTTP URI是否可用，还需要由服务本身指示是否已准备好接收请求。

对于实现了gRPC健康检查协议的gRPC服务，配置非常简单。

正在加载代码示例…

此配置会对发送到grpc_backend上游组的所有请求进行负载均衡。health_check指令包含type=grpc参数，用于调用每个上游服务器的Check方法，该方法属于服务器的Health服务。响应为SERVING的服务将被视为健康。mandatory参数可确保在NGINX Plus启动或向上游组添加新服务器时，只有通过健康检查后才会转发流量（否则，默认会将新服务视为健康）。

如果每个上游服务器都公开了多个gRPC服务，则可以监控其中最重要的服务（即存在依赖服务或从属服务的服务）。为此，请将该服务的名称指定为grpc_service参数的值，如下例所示：

正在加载代码示例…

对于未实现gRPC健康检查协议的gRPC服务，可以测试上游服务器是否至少会响应gRPC请求，因为在这种情况下，服务器会返回错误状态码来响应Check方法。根据grpc_health.conf中的配置，未实现gRPC协议的服务应返回状态码12 (UNIMPLEMENTED)。

无需修改后端代码，也可以检查gRPC服务能否响应传入请求。此方法可用于监控任何gRPC服务：

正在加载代码示例…

非特权用户安装

在以前的版本中，NGINX Plus运行时仅有少量进程以特权用户root身份运行。例如，NGINX Plus管理指南中的安装说明会创建以下进程：

$ 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。我们的GitHub存储库中提供了安装脚本ngxunprivinst.sh，适用于以下操作系统：

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

启动NGINX，并使用‑p选项指定路径，使用‑c指定配置文件名，并使用‑e指定错误日志文件名。

$ /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 支持

代码交换证明密钥（PKCE）是近期新增到OpenID Connect（OIDC）授权码流程中的一项扩展，用于防范多种攻击，并保护与公共客户端之间的OAuth交换。我们已在NGINX Plus R23中更新OpenID Connect参考实现，以支持该扩展。PKCE将在OAuth 2.1中成为强制要求。

具体变化是在代码质询中使用两个新值替换client_secret：

code_challenge
code_verifier

为应对不同类型的攻击，尤其是针对移动设备的攻击，令牌（无论是访问令牌、ID令牌还是刷新令牌）的质询机制已调整如下：

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的扩展授权码流：

正在加载代码示例…

新的“$oidc_pkce_enable”变量用于控制是否启用PKCE流程。如果针对特定域将其设置为“1”，则使用PKCE流程。如果设置为“0”（默认值），则使用不含PKCE的授权码流程。

NGINX Plus R23的其他增强功能

精细控制SSL/TLS连接

与之前的TLS版本相比，TLS v1.3可提供更强的安全性，并在服务器之间以及服务器与其客户端之间实现端到端加密。NGINX Plus R23支持直接访问OpenSSL配置，以便对TLS v1.3进行精细控制。

创建不含证书和密钥的默认HTTPS服务器

在以前的版本中，用于受TLS保护的HTTPS流量的默认server块必须包含ssl_certificate和ssl_certificate_key指令，因此需要创建“虚拟”自签名证书和密钥。

使用ssl_reject_handshake指令后，无需再提供证书和密钥，如以下示例配置所示：

正在加载代码示例…

直接配置OpenSSL

NGINX Plus R23让您能够更精细地控制NGINX Plus如何使用OpenSSL 1.0.2及更高版本处理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

以下示例说明如何配置NGINX Plus，将使用旧版TLS的客户端请求升级为使用已知支持TLS v1.3的后端服务器。

正在加载代码示例…

缓存管理器可监控可用磁盘空间

将NGINX Plus配置为缓存代理后，缓存管理器进程会移除最近最少访问的内容，确保缓存大小不超过max_size参数为proxy_cache_path指令设置的限制。

在NGINX Plus R23中，缓存管理器还可以监控缓存所在文件系统的可用磁盘空间，并在可用空间低于min_free这一新增参数设定的值时移除内容。该参数属于proxy_cache_path指令。

这意味着，即使缓存与其他进程共享同一文件系统，NGINX Plus也能确保填充缓存时不会意外占满磁盘。

正在加载代码示例…

设置Cookie标志的原生方法

未受保护的Cookie仍是高风险攻击途径。正如Mozilla Developer Network（MDN）所述，要确保Cookie不被非预期方或脚本访问，一种方法是在HttpOnly和Secure标志。Set-Cookie标头中设置这些

在以前的版本中，我们为此提供了set_cookie_flag指令，该指令由动态模块存储库中提供的第三方Cookie‑Flag模块实现。NGINX Plus R23引入了proxy_cookie_flags指令，用于取代该指令和模块。

已弃用的Cookie‑Flag模块将在NGINX Plus R26中移除，因此建议尽快在配置中查找所有set_cookie_flag指令，并将其替换为proxy_cookie_flags指令。

以下是一个示例配置，用于将请求代理到一个本身不设置任何 Cookie 保护标志的简单后端应用：

正在加载代码示例…

在此示例中，我们将添加HttpOnly、Secure和SameSite标志，以保护由上游服务器创建的appcookie会话Cookie。NGINX Plus使用该Cookie实现会话持久性，具体说明请参阅NGINX Plus管理指南。

使用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指令为Cookie添加sticky标志，如以下示例所示（httponly和secure参数从NGINX Plus R6开始受支持）：

正在加载代码示例…

在Stream模块中设置变量

NGINX Plus R23引入了set指令，可在TCP/UDP配置中设置变量，将这一常用于HTTP流量处理的功能扩展到TCP/UDP配置。

以下示例使用多个变量构造复杂的复合值。

正在加载代码示例…

更复杂的用例使用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对象可以轻松处理二进制数据，无需依赖字符串。

该模块的其他重要增强功能包括：Query String模块，可轻松访问通过URL传递的键值对；此外，还支持用于调试的行级回溯。

动态模块变更

新的SPNEGO for Kerberos模块

现已支持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。